Skill Creator

When to use

• "make a skill", "add a skill", "turn this into a skill" (Korean: "skill 만들어줘", "skill 추가해줘", "이거 skill로 만들자")
• "review this skill", "validate this skill" (Korean: "이 skill 리뷰해줘", "skill 검증해줘")
• "improve this skill", "fix this skill" (Korean: "skill 개선해줘", "skill 고쳐줘")
• "create a skill", "review this skill"
• On invocation, classify the user's intent as one of create/review/improve, then run that mode's phases. Enforces 8 principles, including one question at a time, automatic inference first, no hard-coding, and separate config.

This document is a decision procedure, not an essay. Run it top to bottom, and do not move to the next phase until the current phase's "exit condition" is met.

On invocation: determine the mode in §1 below → register with TaskCreate → start at that mode's Phase 1. Do not write analysis or explanation first. Decision rules: if unclear, do not force an inference — ask right away. One message = one question. Never ask again for information already given. Confirm risky work before running it. Language: talk to the user in the user's language (or the configured language preference).

Where to read

0. Hard constraints

Never violate these in any phase or mode. If you detect a violation, stop and say so.

The remaining 2 principles (automatic inference first, flexible input) are enforced by the Phase 1 procedure.

1. Determine the mode

Priority:

1. A specific existing skill path + "review"/"check" → REVIEW
2. A specific existing skill path + "improve"/"fix" → IMPROVE
3. Neither, and a new capability is proposed → CREATE
4. If unclear, ask once: "Should I create a new one, or review/improve an existing skill?"

After deciding, register the mode's task list with TaskCreate (CREATE below; REVIEW/IMPROVE in references).

2. CREATE mode — create a new skill

[create] Phase 0: Brainstorming (what to build and why)
[create] Phase 1: Absorb intent + automatic extraction
[create] Phase 2: Ask only for missing information, one at a time
[create] Phase 3: Write SKILL.md (+ config/scripts templates)
[create] Phase 4: 8-principle self-review
[create] Phase 5: Trigger utterance check (5 samples)
[create] Phase 6: Report to the user + agreement
[create] Phase 7: Check real invocation behavior

Phase 0 — Brainstorming

• Goal: agree on scope, approach, boundaries and the relation to existing skills. Output: a one-line agreement on "what to build" + the chosen approach.
• Exit condition: scope is right / 1 approach chosen / boundaries clear / overlap resolved (all 4) → Phase 1.
• It can be short, but do not skip it — five minutes of design decides the quality of hundreds of calls. "Too simple to need design" is an anti-pattern.
• Procedure, the format for presenting 2~3 approaches, and scope criteria: references/phase0_brainstorming.md.
• When you may skip it: the user already stated scope, approach and the relation to existing skills. Even then, say in one line "Skipping Phase 0 because: ~".

Phase 1 — Absorb intent + automatic extraction

• Keep a status table of the 6 slots purpose, triggers, inputs, outputs, auto_extract, pain_points in memory only (definitions and inference rules: references/phase1_slots.md).
• Exit condition: all 6 are "has value" or "inferable". 0 empty slots → Phase 3 / 1 or more → Phase 2.
• Show the user only a one-line summary of the intent and confirm with "Did I understand this right?" — showing the whole slot table overwhelms them.

Phase 2 — Ask only for missing information, one at a time

One message = one slot (references/phase2_question_format.md). If the user answers several slots at once, take them all and re-check only the empty slots. If no slot is empty, skip this phase.

Phase 3 — Write SKILL.md (+ config/scripts)

• Output: SKILL.md (required) + config.json.example (optional) + scripts/ (optional). Exit condition: the files exist + the required sections are present.
• Frontmatter: name and description required, version recommended.
• Write the new skill's prose in English by default (frontmatter description, headings and body). If the skill's users speak another language, add their trigger phrases next to the English ones in description and "When to use", and tell the skill to reply in the user's language. Use another language for the prose only when the user asks for it.
• Body skeleton:

# {Skill Name}

## When to use
- Trigger scenario 1
- Trigger scenario 2
- (Also recommended: one line on when NOT to use it)

## Setup (only for skills that need a config file)

## Workflow
### Phase 0 — Gather information
### Phase 1 — Run
### Phase 2 — Verify / report

## Common pitfalls (from real experience)

• If you need scripts or a config, copy templates/config.json.example (the standard for separating accounts and URLs into settings) and templates/python_cli_script.py (stdlib CLI skeleton — UTF-8 console, SSL opt-out, structured errors). Python calls follow the 3-layer standard and the router form "find the scripts once + reuse {PYTHON} {SCRIPTS}/x_cli.py" → references/meta_principles.md §2.
• How to write (give reasons, prefer multiple choice, length matched to complexity, confirm section by section, go back when needed): references/meta_principles.md §1.

Phase 4 — 8-principle self-review

Always re-read the file you just wrote with Read and fill in the 8 checks one line each ("I just wrote it, so I know" is not allowed). Checklist and fixes: references/phase4_checklist.md. If anything FAILs, fix it and check again until there are 0 violations.

Phase 5 — Trigger utterance check

The agent simulates this without a separate CLI.

1. 3 should-trigger — utterances a user would really say, phrased without naming the skill directly.
2. 2 should-not-trigger — nearby topics that must not invoke the skill.
3. For each, ask yourself "Would I call this skill from the description alone?" 5/5 passes; if any is wrong, fix the description and try again.

Quantitative optimization (the official run_loop.py) is optional — references/trigger_optimization.md.

Phase 6 — Report to the user + agreement

Use the format in references/phase6_report_format.md. Report only when every row of the 8-principle table is ✅; if there is any ⚠️/❌, go back to Phase 4.

Phase 7 — Check real invocation behavior (strongly recommended)

Offer "Shall we invoke it once now to test it?" — using it immediately exposes missing description triggers, script errors and config mismatches. If the user says "later", skip it.

Customize

Your own language, tone and rules apply: see ../references/preferences.md. Read them once at the start: run the snippet in ../references/preferences.md with SKILL_ID=pro-skill-creator. Keys for this skill: the common language, tone, rules only. Preferences change presentation only; approval gates, secret protection and --dry-run stay in force.