Make inspect emit materializable skillset candidates

[jon-devlapaz]

Problem

GitHub inspection currently represents inferred skillsets as a name, path, and recursive member count. It can count descendants under nested categories, include empty structural peers or fixtures, and still present the result as a skillset proposal.

skillset add, however, can only materialize explicit immediate member directories under sourceRoot. Inspection can therefore recommend a candidate that Tink itself cannot install.

Directory/frontmatter name mismatches are diagnosed but do not make the candidate visibly non-installable. A conventional direct skills/ collection also loses the enclosing creator/plugin identity.

Relevant code: src/inspect.rs, the GitHub inspection CLI rendering in src/lib.rs, and docs/GITHUB-INSPECTION-SPEC.md.

Proposed change

Represent each candidate with:

• canonical candidate name;
• explicit sourceRoot;
• concrete member names and directories;
• provenance basis: creator/plugin manifest or structural inference;
• installability status and exclusion reasons.

Prefer creator/plugin manifests over directory heuristics. Descend through structural wrappers only until immediate skill roots are reached. If meaningful categories remain, emit separate ancestry-qualified candidates or a hierarchy diagnostic; never flatten them into an installable count.

Default output should separate installable creator groups from empty, test, fixture, example, and documentation peers. Add stable JSON output for downstream catalog generation.

Small path fixes to include:

• accept exactly sourceRoot: "." while still rejecting absolute paths and ..;
• mark directory/frontmatter mismatches non-installable during inspection;
• preserve creator/container identity for conventional skills/ roots.

Acceptance

• plugins/acme/skills/{alpha,beta} yields an installable acme-skillset with root plugins/acme/skills.
• Nested category trees are split or marked non-installable, never flattened falsely.
• Empty/test/fixture peers are not default installable proposals.
• Every installable JSON candidate can be converted to catalog metadata and immediately added.
• Existing raw skill diagnostics remain available.

Related

Path-policy consolidation in #31 should be reused rather than duplicated.

Priority

P0 — inspection must not claim non-materializable output.