Claude Code Skill Factory: Turn Repetitive Workflows Into SKILL.md

You are helping me build a reusable Claude Code Agent Skill (a `SKILL.md` file) that captures a workflow I currently repeat by hand. Follow the real Claude Code skill format and conventions. Do NOT invent fields that do not exist.

## What I want to turn into a skill
{{WORKFLOW_DESCRIPTION}}

## Where it should live
Scope: {{SKILL_SCOPE}}  (personal = `~/.claude/skills/<name>/SKILL.md` available in all my projects; project = `.claude/skills/<name>/SKILL.md` checked into this repo for my team)

## Phase 1 — Interview me (ask, do not assume)
Ask me a tight batch of questions, then wait for my answers. Cover:
1. The trigger: what should make Claude auto-load this skill? Give me 3-5 candidate trigger phrases / situations to react to or edit.
2. The exact step-by-step procedure, in order, including any commands to run and files to read or write.
3. The definition of done: how do we know the skill succeeded? What output or side effect must exist?
4. Failure / edge cases the skill must handle gracefully (e.g. empty input, missing file, dirty git tree).
5. Any reference material too long to inline (style guides, API specs, examples) that should become a separate supporting file instead of bloating the main body.
6. Should the model be allowed to invoke this automatically, or only me via `/<name>`? (For anything with side effects like deploy/commit/send, recommend manual-only.)

## Phase 2 — Produce the skill
After I answer, output the complete files as code blocks, ready to save:

### A) `SKILL.md`
- YAML frontmatter between `---` markers. Use only real fields: `name` (lowercase-hyphenated; this is the display name — the command comes from the directory name), `description` (what it does AND when to use it — put the key use case first; this is what Claude reads to decide when to auto-load), and where appropriate `when_to_use` (extra trigger phrases), `allowed-tools` (tools usable without a permission prompt while active), `disable-model-invocation: true` (if it should be manual-only via `/<name>`), `argument-hint` (if it takes arguments). Keep `description` + `when_to_use` well under ~1500 characters total.
- A concise markdown body that STATES what to do (imperative), not narrates why. Number the steps. Bake in the definition-of-done as an explicit final "Verify" step. Handle the edge cases I listed. Keep the body under ~500 lines; push long reference material into supporting files.
- Reference any supporting files by relative path so Claude knows what each contains and when to load it (progressive disclosure — they cost nothing until needed).
- If the procedure benefits from live context, show how to inline a shell command result using the !`<command>` dynamic-injection syntax (e.g. inlining `git diff HEAD`).

### B) Supporting files (only if needed)
For each long reference, output its filename and content (e.g. `reference.md`, `examples.md`, or a `scripts/<name>.sh` helper). Keep the main `SKILL.md` pointing at them.

### C) Save + test instructions
Give me the exact shell commands to create the directory and save the files for my chosen scope, then two ways to test it:
1. An example natural-language request that should make Claude AUTO-trigger it (matching the description).
2. The direct `/<name>` invocation.
Note that personal/project `.claude/skills/` edits are picked up live in-session, but a brand-new top-level skills directory needs a Claude Code restart.

## Rules
- Original wording only. Do not copy any existing skill text verbatim.
- Only use fields and syntax that actually exist in Claude Code. If you are unsure a field exists, leave it out and say so.
- Optimize the `description` for triggering: it is the single most important line for whether Claude loads the skill at the right moment.
- End with a 4-item checklist confirming: valid frontmatter, trigger-optimized description, explicit verify step, save+test commands provided.