When this skill is activated, always start your first response with the 🔨 emoji.

skill-forge

Generate production-ready AbsolutelySkilled skills from any source - GitHub repos, documentation URLs, or pure domain knowledge. This is the bootstrapping tool for the registry.

A skill is a folder, not a file. Think of the entire file system as context engineering and progressive disclosure. SKILL.md is the entry point, but scripts, references, assets, and data files are where the real power lives.

Slash command

/skill-forge <url-or-topic>

Setup

On first run, check for ${CLAUDE_PLUGIN_DATA}/forge-config.json. If it doesn't exist, ask the user these questions (use AskUserQuestion with multiple choice):

1. Default output directory - skills/ (registry PR) or custom path?
2. Auto-propagate recommendations? - yes/no (Phase 7)
3. Skill type preference - code-heavy, knowledge-heavy, or balanced?

Store answers in ${CLAUDE_PLUGIN_DATA}/forge-config.json. Read this config at the start of every forge session.

Forge history

After every successful forge, append an entry to ${CLAUDE_PLUGIN_DATA}/forge-log.jsonl:

{"skill": "api-design", "type": "domain", "date": "2025-01-15", "lines": 245, "refs": 3, "evals": 12}

Read this log at the start of each session. It helps you:

• Avoid creating duplicate skills
• Reference patterns from previously forged skills
• Track which categories are over/under-represented

Step 0 - Detect input type

• URL input (starts with http, github.com, or looks like a domain) -> Phase 1A
• Domain topic (a word or phrase) -> Phase 1B
• Ambiguous -> ask the user

Phase 1A - Research (URL-based)

The quality of the skill is entirely determined by the depth of research here. Do not write a single line of SKILL.md until research is complete.

Crawl order (priority high to low)

1. /llms.txt or /llms-full.txt   - AI-readable doc map (gold)
2. README.md                      - overview, install, quickstart
3. /docs/                         - main documentation index
4. API reference                  - endpoints, params, errors
5. Guides / tutorials             - real-world usage patterns
6. Changelog                      - breaking changes, versioning

Stop fetching a category once you have good coverage - 5 pages that give the full picture beats 20 pages of marginal detail.

Discovery questions

While crawling, answer these six questions - they form your mental model:

1. What does this tool do? (1 sentence)
2. Who uses it?
3. What are the 5-10 most common agent tasks?
4. What are the gotchas? (auth, rate limits, pagination, SDK quirks)
5. What's the install/auth story?
6. Are there sub-domains needing separate references/ files?

Uncertainty handling

Flag ambiguous or missing detail inline - never skip a section:

<!-- VERIFY: Could not confirm from official docs. Source: https://... -->

Aim for < 5 flags. More than 5 means you haven't crawled enough.

Phase 1B - Brainstorm Discovery (domain-based)

For domain topics, run an interactive brainstorm with the user.

HARD GATE: Do NOT write any SKILL.md until the user approves the scope. "TypeScript" could mean best practices, migration guides, or project setup.

Ask these questions one at a time (use multiple choice when possible):

1. Target audience?
2. Scope? (offer 2-3 options with your recommendation)
3. Top 5-8 things an agent should know?
4. Common mistakes to prevent?
5. Sub-domains needing their own references/ files?
6. Output format? (code, prose, templates, checklists, or mix)

Present a proposed outline. Wait for approval before proceeding.

Phase 2 - Write SKILL.md

Read references/frontmatter-schema.md for YAML fields and references/body-structure-template.md for the markdown scaffold.

Key principles for writing

Focus on what pushes Claude out of its defaults. Claude already knows how to write markdown and structure content. Your skill should teach it things it would get wrong without the skill - the gotchas, the non-obvious patterns, the domain quirks that trip up even experienced developers.

The description field is a trigger, not a summary. Claude scans every skill description at session start to decide which to activate. Write it as a when-to-trigger condition with specific tool names, synonyms, and action verbs.

Build the Gotchas section first. This is the highest-signal content in any skill. Start with 3-5 known failure points and expect the section to grow over time as users hit new edge cases. Put gotchas inline next to the relevant task, not in a separate section users might skip.

Use progressive disclosure. SKILL.md should be the entry point, not the encyclopedia. Point to references/ files for deep detail. Tell Claude what files exist and when to read them - it will load them on demand.

Don't railroad. Give Claude the what and why, not rigid step-by-step procedures. Skills get reused across many contexts - overly prescriptive instructions break in unexpected situations. Prefer guidelines over rules.

After writing

Run scripts/validate-skill.sh <path-to-skill-dir> to check structure and catch common issues before finalizing.

Always append the shared footer from references/skill-footer.md as the very last section.

Phase 3 - Write references/

Create a references/ file when:

• A topic has more than ~10 API endpoints
• A topic needs its own mental model (e.g. Stripe Connect vs Payments)
• Including it inline would push SKILL.md past 300 lines

Every references file must start with:

<!-- Part of the <ToolName> AbsolutelySkilled skill. Load this file when
     working with <topic>. -->

Consider adding these non-markdown files when they'd help the agent:

• Scripts (scripts/) - validation, setup, code generation helpers
• Templates (assets/) - output templates the agent can copy and fill
• Data (data/) - lookup tables, enum lists, config schemas as JSON/YAML
• Examples (examples/) - complete working code the agent can reference

Phase 4 - Write evals.json

Read references/evals-schema.md for the JSON schema and worked examples.

Write 10-15 evals covering: trigger tests (2-3), core tasks (4-5), gotcha/edge cases (2-3), anti-hallucination (1-2), references load (1).

Phase 5 - Write sources.yaml

Read references/sources-schema.md for the YAML schema. Only for URL-based skills. Domain skills can omit this if purely from training knowledge and user input.

Phase 6 - Output

Write to skills/<skill-name>/ (or the path from forge-config.json).

skills/<skill-name>/
  SKILL.md
  sources.yaml       (optional for domain skills)
  evals.json
  references/        (if needed)
  scripts/           (if needed)
  assets/            (if needed)

Print a summary and append to forge-log.jsonl.

Phase 7 - Propagate recommended_skills

If auto-propagate is enabled in config (or always for new skills):

1. Read the new skill's recommended_skills
2. For each companion, check if it reciprocally lists the new skill
3. Add if the companion has < 5 recommendations and the relationship is genuine
4. Never remove existing recommendations without clear reason
5. Print which skills were updated in the summary

Gotchas

These are the most common failure points when forging skills. Update this list as new patterns emerge.

1. Description too vague - "A skill for testing" will never trigger. Include the tool name, 3-5 task types, and common synonyms. This is the #1 reason skills don't activate.

2. Stuffing everything into SKILL.md - If you're past 300 lines, you're doing it wrong. Move detail to references/ files. The agent reads them on demand - trust the progressive disclosure.

3. Stating what Claude already knows - Don't explain how REST APIs work or what JSON is. Focus on the non-obvious: auth quirks, deprecated methods, version differences, naming inconsistencies.

4. No gotchas in the generated skill - Every skill should have inline gotchas next to relevant tasks. "This method requires amount in cents, not dollars" saves more time than 50 lines of API docs.

5. Railroading the agent - "Always do X, then Y, then Z" breaks when the context doesn't match. Give guidelines, not rigid procedures. The agent needs flexibility to adapt.

6. Forgetting the folder is the skill - SKILL.md is just the entry point. Scripts, templates, data files, and examples are what make a skill genuinely useful. A data-science skill with fetch_events.py beats one with 200 lines explaining how to query your event source.

7. Not checking for duplicates - Always read references/skill-registry.md before forging. Redundant skills fragment the registry.

8. Generic domain advice - For knowledge skills, "write good copy" is useless. "Use the PAS framework: Problem, Agitate, Solution" is actionable. Every piece of advice should be specific enough to act on immediately.

Quality checklist

• Description is a trigger condition (tool name + 3-5 task types + synonyms)
• Gotchas are present and inline next to relevant tasks
• SKILL.md under 300 lines (detail moved to references/)
• No obvious-to-Claude content (how markdown works, what APIs are, etc.)
• Progressive disclosure: references/ files listed with when-to-read guidance
• For URL skills: sources.yaml has only official doc URLs
• For domain skills: user approved scope before writing
• Evals cover all 5 categories
• Flagged items use <!-- VERIFY: --> format
• Footer appended from references/skill-footer.md
• Forge history log updated
• Recommendations propagated (Phase 7)

References

Load these files only when you need them for the current phase:

• references/frontmatter-schema.md - YAML template + category taxonomy (Phase 2)
• references/body-structure-template.md - Markdown body scaffold (Phase 2)
• references/evals-schema.md - JSON schema + worked example (Phase 4)
• references/sources-schema.md - YAML schema for sources (Phase 5)
• references/worked-example.md - Resend end-to-end example (first-time orientation)
• references/skill-registry.md - Full catalog of existing skills (duplicate check)
• scripts/validate-skill.sh - Structural validation for generated skills (Phase 2)

Related skills

When this skill is activated, check if the following companion skills are installed. For any that are missing, mention them to the user and offer to install before proceeding with the task. Example: "I notice you don't have [skill] installed yet - it pairs well with this skill. Want me to install it?"

• skill-creator - Guide for creating effective skills manually
• writing-skills - Creating, editing, and verifying skills before deployment

Install a companion: npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>