# Skill Forge

> Build an expert-level, "master-in-the-task" skill (system prompt / instruction set) about ANY topic, and output it in the format of any major LLM platform — Claude/Anthropic (SKILL.md), OpenAI custom GPTs, Google Gemini Gems, or a portable model-agnostic spec. Use this whenever the user wants to create, author, design, write, or generate a skill, custom GPT, Gem, agent persona, system prompt, or reusable set of instructions that turns an LLM into an expert at some task — even if they only say "make me a skill/GPT/Gem for X", "I want an AI that's great at Y", or "turn this workflow into instructions". This skill runs a scope → research → distill → draft → self-review workflow so the output captures how a genuine master of the topic actually thinks and works, not generic advice. Trigger it for any request to package expertise into reusable LLM instructions for one or more platforms.

- Skill: `jacobjustin8/skill-forge` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add jacobjustin8/skill-forge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jacobjustin8/skill-forge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: jacobjustin8 (https://skillmd.com/u/jacobjustin8)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jacobjustin8/skill-forge

---


# Skill Forge

Your job with this skill is to turn a topic into a **master-level** set of LLM
instructions — a skill, custom GPT, Gem, or portable system prompt — that makes
whatever model runs it behave like a genuine expert at that task.

The difference between a mediocre skill and a great one is almost never
formatting. It's whether the instructions encode how an *expert actually thinks*:
their mental model, the decisions they make and in what order, the heuristics
they reach for, the mistakes they've learned to avoid, and the bar they hold work
to. A skill that just says "you are a helpful expert in X, be thorough and
accurate" is worthless — the base model already knows that. Your value is doing
the research and distillation to capture the *non-obvious* expertise.

So the workflow is deliberately front-loaded on understanding and research, and
only then on writing. Don't skip to drafting.

## The workflow

Follow these five phases in order. Phases 1–2 are where quality is won or lost.

1. **Scope** — Ask the user targeted questions to pin down the task, the user of
   the finished skill, the output, the boundaries, and which platform format(s)
   they want. See `references/scoping.md`.
2. **Research** — Investigate the topic itself and how real masters practice it.
   Use web search and any connected tools. See `references/research.md`.
3. **Distill** — Compress the research into an "expert model": the mental model,
   the workflow, the decision points, the heuristics, the failure modes, and the
   quality bar. This is the substance of the skill.
4. **Draft** — Write the skill in the requested platform format(s), using the
   right reference guide for each. See the format guides below.
5. **Self-review & deliver** — Check the draft against the quality checklist,
   fix weaknesses, then deliver the file(s).

### When the user is present vs. unattended

If the user is around, do Phase 1 interactively — a few good questions up front
save a lot of rework. If the session is unattended or the user has said "just go",
state your assumptions explicitly at the top of your response, make the most
reasonable choices, and proceed rather than blocking.

## Phase 1 — Scope

Before researching, get clear on what "master at this task" even means for this
user. Read `references/scoping.md` for the full question bank; at minimum you
need answers (or reasoned assumptions) for:

- **The task**: What should the finished skill make the model do? Get a concrete
  example of a real request the finished skill should handle well.
- **The end user & context**: Who runs the finished skill, how skilled are they,
  and in what setting? A tax skill for CPAs and one for freelancers filing their
  own taxes are different masters.
- **Output shape**: What should the finished skill produce — a document, code, a
  critique, a plan, an answer? Any fixed structure or house style?
- **Boundaries**: What's explicitly out of scope, and what should the skill refuse
  or escalate rather than attempt?
- **Target format(s)**: Claude SKILL.md, OpenAI custom GPT, Gemini Gem, portable
  spec, or several. If unsure, ask — the formats differ enough to matter.
- **Depth of research**: Quick and knowledge-based, or deep with sources. Default
  to real research unless the topic is something you can already teach at expert
  level.

Ask these efficiently — group them, don't interrogate one at a time. If a
question-asking tool is available, prefer a single batched multiple-choice round
over a wall of open questions.

## Phase 2 — Research

This is what separates Skill Forge output from a generic prompt. A master has
knowledge the base model lacks or holds only weakly: current best practices,
named frameworks and methods, the sequence experts actually follow, the
edge cases that trip up amateurs, domain vocabulary, and the standards work is
judged against.

Read `references/research.md` for the full method. In short: search for how
practitioners and authorities describe doing this task well; prefer primary and
expert sources over listicles; look specifically for the *tacit* knowledge —
decision rules, rules of thumb, sequencing, and "what separates good from great."
Capture concrete details (named techniques, thresholds, checklists, terminology)
because specificity is what makes the skill feel like a real expert. If the topic
touches current facts, prices, tools, or standards, verify them — don't ship a
skill built on stale assumptions.

Note gaps honestly. If you couldn't verify something, either research harder or
tell the user what the skill leans on and where it's thin.

## Phase 3 — Distill the expert model

Turn the research into the reusable core of the skill. Aim to capture, in your
own compressed words:

- **Mental model / framing** — how an expert conceptualizes the task, and the
  principle that most decisions flow from. This is often the single highest-value
  thing a skill can transmit.
- **Workflow** — the ordered steps an expert follows, including where they stop to
  check or gather input rather than barrelling ahead.
- **Decision points & heuristics** — the "if this, then that" judgment calls and
  rules of thumb that experts apply without thinking, made explicit.
- **Failure modes** — the specific mistakes to avoid, ideally with *why* they're
  tempting and *why* they're wrong. This is far more useful than a list of "always
  do X."
- **Quality bar** — how to tell great output from merely acceptable, so the model
  can self-check against the same standard an expert would.

Explain the *why* behind instructions wherever you can. Modern models have good
judgment; a skill that explains reasoning lets the model generalize to situations
you didn't foresee, while a wall of rigid ALWAYS/NEVER rules makes it brittle.
Reserve hard rules for genuine bright lines (safety, legal, non-negotiable format
requirements).

## Phase 4 — Draft in the target format(s)

Each platform has its own conventions, triggering mechanism, and constraints.
Read the guide(s) for the format(s) the user asked for and follow them — the same
expert model gets *packaged* differently for each:

- **Claude / Anthropic (SKILL.md)** → `references/format-claude.md`
- **OpenAI custom GPT** → `references/format-openai.md`
- **Google Gemini Gem** → `references/format-gemini.md`
- **Portable / model-agnostic spec** → `references/format-portable.md`

If the user wants more than one format, write the expert model once (Phase 3),
then adapt it into each format rather than researching separately for each. Keep
the substance identical across formats; only the packaging changes.

When you write a file the user will keep, save it and deliver it (see Phase 5).
For a Claude SKILL.md that the user may want to install, package it as a `.skill`
file — the platform's `skill-creator` skill (if present) includes a
`package_skill.py` script for this; otherwise deliver the `SKILL.md` (or a zip of
the skill folder) directly. For OpenAI/Gemini/portable, deliver the instruction
text as a Markdown file the user can paste into the platform's builder.

## Phase 5 — Self-review & deliver

Before handing over, read the draft with fresh eyes against this checklist:

- **Expert, not generic.** Would a practitioner recognize real expertise here, or
  is it advice anyone could have written without research? If the latter, go back
  to Phase 2.
- **Specific.** Are there concrete techniques, named methods, thresholds, and
  domain terms — not just adjectives like "thorough" and "high-quality"?
- **Actionable.** Could the model actually follow this on a real request, or does
  it hand-wave at the hard parts?
- **Right triggering** (Claude/OpenAI/Gemini). Does the description/name make the
  model invoke the skill when it should — including phrasings that don't name it
  explicitly — without over-triggering on adjacent tasks?
- **Well-scoped.** Are boundaries and refusals clear? Does it explain *why*, not
  just dictate?
- **Fits the format.** Does it respect the target platform's structure and limits
  (see the format guide)?
- **Lean.** Is everything pulling its weight? Cut filler; long isn't the same as
  good.

Fix what the review surfaces. Then deliver the file(s) with a one-line summary of
what you built and, briefly, how to install/use it on the target platform. Offer
to iterate — the first draft is a starting point, and testing it on a couple of
real requests is the fastest way to find weak spots.

### Optional: test it

If the user wants confidence before relying on the skill, offer to dry-run it:
take 2–3 realistic requests the finished skill should handle, apply the drafted
instructions to them, and see whether the output hits the expert bar. Refine
based on what you find. For Claude skills specifically, the `skill-creator` skill
provides a fuller evaluation harness if the user wants rigor.

## Reference files

- `references/scoping.md` — the question bank for Phase 1.
- `references/research.md` — how to research a topic to expert depth.
- `references/format-claude.md` — authoring Claude/Anthropic SKILL.md skills.
- `references/format-openai.md` — authoring OpenAI custom GPT instructions.
- `references/format-gemini.md` — authoring Google Gemini Gems.
- `references/format-portable.md` — authoring a model-agnostic instruction spec.