Godmode Skill Forge

Outcome

Produce a small, validated skill with explicit routing and observable acceptance checks. Do not create a skill for a one-off request, a vague preference, or work already covered by an installed skill.

Workflow

1. Search the installed and project skill set for an adequate capability.
2. Record the concrete gap and at least three observed reusable uses of one task type - each one cited by the archive record (seq:<n>, from godmode history) that proves it happened (a bare count is not evidence). The forge refuses three citations that are not three distinct, existing records; that the cited records are successes of this task type is your judgement, not something it can check for you.
3. Define one purpose, two positive routing examples, two nearby negative examples, and observable behavior assertions.
4. Capture a baseline showing how the current workflow misses the assertions.

5. Run the local forge:

   <plugin-root>/bin/godmode --project <path> skill forge --destination <skills-directory> --name <skill-name> --purpose "<purpose>" --gap-evidence "<evidence>" --repeated-uses 3 --success-evidence "seq:<n>" --success-evidence "seq:<n>" --success-evidence "seq:<n>" --positive "<trigger one>" --positive "<trigger two>" --negative "<near miss one>" --negative "<near miss two>" --assertion "<observable result>"

6. Validate the generated structure with skill validate, then use the host's official skill validator when available.
7. Exercise positive, near-negative, and behavior cases. Revise only from observed failures.
8. Remove unnecessary instructions or resources and re-run validation.

Read godmode-forge-contract.md before approving a new skill.

Constraints

• Keep frontmatter to name and description; put interface metadata in agents/openai.yaml.
• Use lowercase hyphen-case and make the description state both capability and trigger.
• Prefer progressive disclosure: compact SKILL.md, detailed references only when needed.
• Generate original project language and organization. Do not include external URLs, source-project names, copied templates, or imported implementation text.
• Runs with no model subprocess, no network fetch, no dependency install, and no self-update.
• If two proposals overlap, synthesize one coherent skill using the strongest compatible behaviors and one routing boundary.
• Preserve failed evaluations as evidence; never rewrite a baseline to manufacture improvement.

Lifecycle

Skills carry a lifecycle state: skill lifecycle lists them, skill retire --name X --reason ... deprecates with a recorded reason, and evals executes the routing corpus against its snapshots so a wording change shows a diff. lessons runs the promote-or-retire pipeline: a recorded lesson either gets its guard observed running or is retired — never appended forever.

Completion

A forged skill is complete only when its structure validates, both positive examples route correctly, near-negative examples stay out, every assertion is evidenced, and its instructions are smaller than the workflow they replace.