Start with a job you have already explained more than once. The first useful skill is rarely a broad assistant persona. It is a repeatable piece of work with recognizable inputs and an output someone can inspect: release notes from merged pull requests, a research brief from source material, or a production check from a deployed URL.

Describe the result before the procedure

Open SkillForge and write the job in the build field as you would explain it to a capable colleague. Name who the result is for, what evidence should be used, and what a good result contains. “Create release notes” leaves too much open. “Create customer release notes from merged product pull requests, grouped by product area, with no claim that cannot be traced to shipped work” gives the builder a usable boundary.

Let the first draft expose assumptions

Build the skill and read the result as a document. Check the title and description first because they decide how another agent discovers the workflow. Then inspect the steps. Look for hidden inputs, missing stop conditions, vague verbs, and instructions that depend on knowledge only you have.

You do not need to write raw frontmatter or Markdown to make those decisions. SkillForge maps the document into editable parts and preserves unsupported source blocks without silently rewriting them.

Open one relevant example

Choose a protected example that solves a similar structural problem. The example does not need to share the same subject. A good review skill may teach evidence handling for a research skill. A good release procedure may teach completion checks for a deployment skill. Select the exact passage that helps and explain the effect you want in your draft.

Review the proposal

SkillForge sends the target, selected reference, and your explanation through its bounded improvement request. The result arrives as a proposal. Accept only the sections that belong, edit wording that is too broad, and leave unrelated content alone. Reference examples remain read-only throughout the process.

Run three small tests

  1. Use a realistic request that should activate the skill.
  2. Use a nearby request that shares words but needs different behavior.
  3. Remove one required input and check that the workflow asks for it or stops clearly.

Inspect the delivered result rather than the amount of text. The skill should choose the right evidence, follow the intended sequence, respect its boundaries, and produce the promised artifact. Save or download SKILL.md only after that behavior is understandable.

Decide where it belongs

Place a repository skill with the code or project it governs. Use a personal location for a workflow you need across projects. Publish through a public Git repository or platform-specific package only after the source, license, dependencies, and test cases are reviewable.