Skill Builder

Builds lean SKILL.md-based skills: decides when a skill is justified, drafts a minimal skill skeleton, and audits existing skills for bloat and drift. Use wh...

Security Scan

The skill is an instruction-only 'skill-builder' for creating and auditing SKILL.md-based skills; its declared requirements, files, and runtime instructions are coherent and proportionate to that purpose.

Purpose & Capability

Name, description, and provided reference files all align: the skill's job is to decide/build/audit SKILL.md skills and the repository contains decision trees, checklists, writing patterns, and supporting-file guidance that directly serve that purpose. No unrelated credentials, binaries, or config paths are requested.

Instruction Scope

SKILL.md instructs the agent to consult internal references (decision-tree, supporting-files-guide, audit checklist) and to produce minimal skill skeletons or audit recommendations. It does not ask the agent to read system files, external endpoints, or unrelated environment variables; scope is narrow and documented.

Install Mechanism

No install spec and no code files — the skill is instruction-only. Nothing is downloaded or written to disk by an installer, which minimizes install-time risk.

Credentials

The skill declares no required environment variables, credentials, or config paths. The instructions operate solely on skill text and bundled reference files, so requested environment access is proportional and minimal.

Persistence & Privilege

always:false and no persistence or requests to modify other skills' configs. The skill is user-invocable and may be autonomously invoked by the agent (platform default), but it does not request elevated privileges or persistent system presence.

Assessment

This skill appears coherent and low-risk: it's an instruction-only tool for deciding, building, and auditing SKILL.md-style skills and contains appropriate internal references. Before enabling it broadly, you may want to: (1) test it with a few realistic prompts to confirm triggers and outputs, (2) confirm it does not prompt the model to access or be given any external credentials during use, and (3) review any future edits to references for unexpected external calls or instructions to read system files. Otherwise it's appropriate for use as a lightweight editorial/audit helper.

Use this skill when the job is to decide, build, or audit a skill itself.

This is a narrow builder, not a meta-agent and not a skill factory. Prefer the smallest useful answer.

Modes

1. Decide — choose between plain edit, existing tool/skill, subagent, or a lean skill
2. Build — draft a minimal skill skeleton only when a skill is justified
3. Audit — tighten or lightly restructure an existing skill

Use when

• deciding whether a new skill is justified at all
• drafting a lean new skill skeleton after deciding a skill is warranted
• tightening an existing skill's trigger description or scope
• moving detail out of SKILL.md into references/
• auditing a skill for bloat, stale instructions, duplicate content, or spec drift

Do not use when

• a plain file edit will solve the problem faster
• an existing tool or installed skill already covers the work
• the problem is implementation labor across many files rather than reusable guidance
• you are inventing process theater to justify a skill
• you are trying to generate a large framework of boilerplate, governance, or publishing machinery

Default workflow

1. Run the decision tree first Read references/decision-tree.md and choose between plain edit, existing tool/skill, subagent, or a lean skill.

2. If the answer is not "use a skill," stop there Prefer the honest recommendation over unnecessary skill creation.

3. If a skill is justified, build the smallest workable skeleton Read references/supporting-files-guide.md and produce only what is earned:

• skill folder
• SKILL.md
• references/ with 1-3 files only if they reduce context load or hold optional detail
• assets/ only if the skill produces output that depends on bundled files
• scripts/ stub only if deterministic execution is clearly warranted

4. Write the skill body well Read references/writing-patterns.md for guidance on voice, examples, output templates, and explaining the why behind instructions.

5. Keep SKILL.md minimal Include only:

• clear frontmatter (name, description) — see references/frontmatter-patterns.md
• scope and non-scope
• default workflow
• reference pointers when optional detail is useful

6. Smoke test before shipping Try 2-3 realistic prompts against the skill before calling it done:

• one clear trigger (should activate the skill)
• one edge case (should activate but tests a boundary)
• one near-miss (should not activate — tests specificity)

If any of these behave wrong, revisit the description or workflow before shipping.

7. Audit before expanding Use references/audit-checklist.md to remove bloat, stale claims, weak triggers, duplicate guidance, and files that do not earn their keep.

8. Apply the Tool Addition Gate lightly If the proposed skill is compensating for a missing primitive, check this order: existing tools → lean skill → subagent/retrieval pattern → new tool only if clearly needed.

Build output

When building, produce the smallest useful package in this order:

1. Recommendation State whether the answer is:

• Use a skill
• Use the existing tool/skill
• Use a subagent
• Do nothing special; just edit it

2. Folder tree Show a minimal tree such as:

skill-name/
├── SKILL.md
└── references/
└── optional-file.md

3. Draft frontmatter Provide only:

• name
• description

4. SKILL.md outline Include only the sections the skill actually needs.

5. Optional additions Suggest 1-3 references/ files if justified. Suggest an assets/ folder only if the skill needs bundled templates or static files. Suggest a scripts/ stub only if exact repeatable execution matters. Optionally suggest publish metadata ideas (description/tags), but do not package or publish.

Minimal build example

Recommendation: Use a skill

skill-name/
├── SKILL.md
└── references/
 └── checklist.md

name: skill-name
description: Helps with X. Use when the user asks for Y or needs Z.

SKILL.md should then contain only:

• scope / non-scope
• default workflow
• pointer to references/checklist.md

Good outcomes

• A plain edit stays a plain edit
• An existing skill gets tightened instead of replaced
• A new skill has a sharp trigger description and a short SKILL.md
• A new skill skeleton is minimal and immediately editable
• Supporting files exist only when they reduce context load or improve reliability
• The skill triggers correctly on natural phrasings (not just its literal name)

Avoid

• turning one-off work into a permanent skill
• adding README, changelog, install notes, or setup clutter inside the skill unless publishing truly needs it
• stuffing examples, schemas, and edge cases into SKILL.md
• creating scripts for things that are better as instructions
• inventing governance layers, registries, dashboards, or lifecycle systems
• writing ALWAYS/NEVER/CRITICAL in all caps instead of explaining reasoning

Works well with

This skill handles the pre-flight phase: deciding if a skill is warranted and structuring the smallest viable version. For testing, iteration, and benchmarking of a built skill, hand off to skill-creator (if available), which provides eval runners, comparison viewers, and description optimization loops.

References

• references/decision-tree.md — choose skill vs tool vs subagent vs plain edit
• references/frontmatter-patterns.md — lean frontmatter, description patterns, and pushy trigger guidance
• references/writing-patterns.md — voice, examples, output templates, and instruction style
• references/supporting-files-guide.md — progressive disclosure model and what belongs in each folder
• references/audit-checklist.md — fast bloat/spec-drift review

Output style

Lead with the recommendation, then provide only the smallest justified build or edit plan.