claudecode-omc 4.3.5 → 4.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,108 @@
1
+ ---
2
+ name: ai-commenting
3
+ description: AI-native code annotation protocol that encodes intent, risk, dependencies, constraints, and test expectations in machine-parseable comments.
4
+ ---
5
+
6
+ # AI Commenting Skill
7
+
8
+ Create and maintain AI-native annotations so coding agents can understand intent, risk, and constraints quickly and safely.
9
+
10
+ ## When to Use
11
+
12
+ Use this skill when:
13
+ - introducing a new module with high coupling
14
+ - touching auth/payment/state consistency paths
15
+ - preparing codebase context for multi-agent implementation
16
+ - reducing repeated prompt context for long tasks
17
+
18
+ ## Annotation Format
19
+
20
+ Canonical format:
21
+
22
+ ```text
23
+ /*@ai:key=value|key=value|key=value*/
24
+ ```
25
+
26
+ Rules:
27
+ - ASCII keys/values only
28
+ - `|` as field separator
29
+ - no spaces around `=`
30
+ - one annotation per scope (file or risky block)
31
+
32
+ ## Field Schema
33
+
34
+ Core file-level fields:
35
+ - `risk=1-5`
36
+ - `core=<domain>`
37
+ - `deps=<A,B,C>`
38
+ - `intent=<why>`
39
+ - `test=<unit|integration|e2e|contract>`
40
+
41
+ Extended fields:
42
+ - `chain=<A->B->C>`
43
+ - `auth=<none|required|strict>`
44
+ - `security=<none|pii|payment|secret>`
45
+ - `invariant=<must_hold>`
46
+ - `sidefx=<db,cache,queue,event>`
47
+ - `perf=<budget>`
48
+ - `rollback=<strategy>`
49
+
50
+ ## Risk Rubric
51
+
52
+ - `risk=1`: isolated local logic
53
+ - `risk=2`: low coupling, easy rollback
54
+ - `risk=3`: moderate coupling or external dependency
55
+ - `risk=4`: critical cross-module path
56
+ - `risk=5`: security/payment/core-state high blast radius
57
+
58
+ Escalate by +1 if auth/session/payment/PII/secrets are touched.
59
+
60
+ ## Placement Strategy
61
+
62
+ 1. File header annotation for critical modules
63
+ 2. Block-level annotation only for risky functions
64
+
65
+ Keep annotations high-signal. Avoid tagging trivial code.
66
+
67
+ ## Example
68
+
69
+ ```typescript
70
+ /*@ai:risk=5|core=UserCRUD|intent=protect_user_consistency|deps=UserModel,AuthService,AuditService*/
71
+ /*@ai:chain=Auth->User->Permission->Audit|auth=strict|sidefx=db,event|test=integration|rollback=feature_flag*/
72
+ class UserManager {
73
+ /*@ai:risk=4|invariant=user_id_unique|security=pii|perf=p95<200ms*/
74
+ async deleteUser(userId: string) {
75
+ // ...
76
+ }
77
+ }
78
+ ```
79
+
80
+ ## Workflow
81
+
82
+ 1. Discover high-risk boundaries
83
+ 2. Add file-level core tags
84
+ 3. Add targeted block-level tags
85
+ 4. Validate syntax and consistency
86
+ 5. Ensure `risk>=4` has explicit `test` and `rollback`
87
+
88
+ ## Quality Gates
89
+
90
+ - all `risk>=4` files include file-level annotation
91
+ - `security!=none` implies `auth!=none`
92
+ - no contradictory tags per scope
93
+ - prefer 1 annotation per 60-120 LOC
94
+
95
+ ## Parsing Helpers
96
+
97
+ ```javascript
98
+ const aiTagPattern = /\/\*@ai:([^*]+)\*\//g;
99
+ const fieldPattern = /(\w+)=([^|*]+)/g;
100
+ ```
101
+
102
+ ## Output
103
+
104
+ Return a concise markdown report:
105
+ - Result summary
106
+ - Files changed
107
+ - Validation evidence
108
+ - Risks / next actions
@@ -0,0 +1,218 @@
1
+ ---
2
+ name: skill-development
3
+ description: This skill should be used when the user wants to "create a skill", "write a new skill", "add a skill", or "improve an existing skill". Covers structure, description quality, progressive disclosure, and the quality pipeline.
4
+ ---
5
+
6
+ # Writing Skills for Claude Code (OMC)
7
+
8
+ Guide for creating effective skills in the oh-my-claudecode (OMC) environment. Skills are modular `.claude/skills/<name>/SKILL.md` files that teach Claude specialized workflows, domain knowledge, and tool integrations.
9
+
10
+ ## Agent Workflow
11
+
12
+ Follow this **Hybrid Workflow** for every skill creation or improvement task:
13
+
14
+ 1. **Requirement Gathering (Soft)**: Before writing anything, ask for **concrete trigger examples**.
15
+ - *Agent Question*: "Give me 3 exact phrases a user would say to trigger this skill."
16
+ - These become the quoted trigger phrases in the description.
17
+ 2. **Structural Planning (Hard)**: Decide the file structure based on complexity.
18
+ - Simple knowledge or utility → just `SKILL.md`
19
+ - Workflow with detailed reference content → `SKILL.md` + `references/`
20
+ - Script-heavy → add `scripts/`
21
+ 3. **Implementation**: Write with correct YAML frontmatter and consistent body format.
22
+
23
+ ## Integration with the OMC Skill Pipeline
24
+
25
+ This skill is the **entry point**. After creating or editing a skill, run:
26
+
27
+ 1. `skill-development` — create/author the skill (this skill)
28
+ 2. `skill-quality-analyzer` — score it across 6 dimensions (target ≥80)
29
+ 3. `skill-debugger` — check if description triggers correctly
30
+ 4. `skill-tester` — verify behavioral correctness
31
+
32
+ ## Anatomy of an OMC Skill
33
+
34
+ ```
35
+ skill-name/ ← folder name = YAML name (kebab-case)
36
+ ├── SKILL.md ← required; ≤200 lines ideally
37
+ └── references/ ← optional; detailed content loaded on demand
38
+ ├── patterns.md
39
+ └── examples.md
40
+ ```
41
+
42
+ ### SKILL.md (required)
43
+
44
+ **Frontmatter**: The `description` field is what Claude sees in the system-reminder when deciding whether to invoke the skill. Make it specific.
45
+
46
+ Two formats for the description:
47
+
48
+ ```yaml
49
+ # For skills intended for auto-discovery (user/project skills):
50
+ description: "This skill should be used when the user asks to 'trigger phrase 1', 'trigger phrase 2', 'trigger phrase 3'."
51
+
52
+ # For OMC core workflow skills (already triggered by CLAUDE.md keywords):
53
+ description: "Concise capability summary. Triggered by: 'keyword1', 'keyword2'."
54
+ ```
55
+
56
+ **Body formats** — choose one and be consistent:
57
+
58
+ - **XML tags** (for workflow/process skills): `<Purpose>`, `<Use_When>`, `<Do_Not_Use_When>`, `<Steps>`, `<Examples>`, `<Final_Checklist>`, `<Advanced>`
59
+ - **Markdown headers** (for utility/reference skills): `## When to Use`, `## Workflow`, `## Examples`
60
+
61
+ See `references/format-guide.md` for complete tag-by-tag reference.
62
+
63
+ ### references/ (optional)
64
+
65
+ Load only when Claude determines it's needed during execution.
66
+
67
+ - **When to use**: SKILL.md body would exceed ~200 lines without it
68
+ - **Move here**: detailed patterns, API references, advanced techniques, long examples
69
+ - **Keep in SKILL.md**: core workflow, quick reference tables, pointers to references/
70
+
71
+ ### Progressive Disclosure
72
+
73
+ Skills use a three-level loading system:
74
+
75
+ | Level | What loads | When |
76
+ |-------|-----------|------|
77
+ | Metadata | `name` + `description` | Always |
78
+ | Body | SKILL.md content | When skill triggers |
79
+ | References | `references/*.md` | When Claude reads them |
80
+
81
+ ## Skill Creation Process
82
+
83
+ ### Step 1: Understand the Use Case
84
+
85
+ Skip only when usage patterns are completely clear.
86
+
87
+ Ask for concrete examples:
88
+ - "What would a user say to trigger this skill?"
89
+ - "What's the main output or artifact it produces?"
90
+ - "What should it NOT do?" (defines `<Do_Not_Use_When>`)
91
+
92
+ Aim for 3 trigger phrases before writing any content.
93
+
94
+ ### Step 2: Plan the Structure
95
+
96
+ Analyze each concrete example:
97
+ 1. What would Claude need to execute this from scratch?
98
+ 2. What reference material would help if repeated?
99
+ 3. Any scripts or assets needed?
100
+
101
+ ### Step 3: Write the Description
102
+
103
+ **Hard rule**: The description must contain quoted trigger phrases.
104
+
105
+ ```yaml
106
+ # ✅ Good — specific trigger phrases, third person, summary at end
107
+ description: "This skill should be used when the user asks to 'create a validation rule', 'define trigger conditions', or 'validate tool instructions'. Provides comprehensive guidance with clear trigger phases and quality gates."
108
+
109
+ # ❌ Bad — vague, no trigger phrases, wrong person
110
+ description: Use this skill when working with hooks.
111
+ description: Provides hook guidance.
112
+ ```
113
+
114
+ ### Step 4: Write the Body
115
+
116
+ **Style**: Imperative/infinitive form, not second person.
117
+
118
+ ```
119
+ ✅ "Start by reading the configuration file."
120
+ ✅ "Validate the input before processing."
121
+ ❌ "You should start by reading the configuration file."
122
+ ❌ "You need to validate the input."
123
+ ```
124
+
125
+ **Size target**: ≤200 lines for SKILL.md body. Move detail to `references/` if exceeded.
126
+
127
+ ### Step 5: Validate
128
+
129
+ Run `skill-quality-analyzer` on the new skill. Target score ≥80.
130
+
131
+ Check the description manually:
132
+ ```bash
133
+ grep "^description:" skills/<name>/SKILL.md
134
+ # Verify it contains quoted trigger phrases
135
+ ```
136
+
137
+ Check line count:
138
+ ```bash
139
+ wc -l skills/<name>/SKILL.md
140
+ # Target: ≤200
141
+ ```
142
+
143
+ ### Step 6: Iterate
144
+
145
+ After using the skill on real tasks:
146
+ - Notice struggles or missed triggers
147
+ - Strengthen description with additional trigger phrases
148
+ - Move long sections to `references/` if context bloat is observed
149
+ - Add missing edge cases to `<Do_Not_Use_When>`
150
+
151
+ ## Validation Checklist
152
+
153
+ **Frontmatter:**
154
+ - [ ] `name` matches folder name exactly (kebab-case)
155
+ - [ ] `description` contains at least 2 quoted trigger phrases
156
+ - [ ] Description is ≤200 characters
157
+
158
+ **Content:**
159
+ - [ ] Body uses imperative form (not "you should")
160
+ - [ ] SKILL.md ≤200 lines (move detail to references/ if not)
161
+ - [ ] Referenced files in `references/` actually exist
162
+ - [ ] No platform-specific branding (e.g., "Codex CLI")
163
+
164
+ **Quality:**
165
+ - [ ] `skill-quality-analyzer` score ≥80
166
+ - [ ] `<Do_Not_Use_When>` or equivalent section present (prevents misuse)
167
+ - [ ] At least 3 usage examples (Good + Bad preferred)
168
+
169
+ ## Common Mistakes
170
+
171
+ ### Mistake 1: Weak trigger description
172
+
173
+ ```yaml
174
+ # ❌ Bad
175
+ description: Provides guidance for working with hooks.
176
+
177
+ # ✅ Good
178
+ description: "This skill should be used when the user asks to 'create a hook', 'add a pre-tool hook', or 'set up hook validation'. Full hook development guide with examples and scripts."
179
+ ```
180
+
181
+ ### Mistake 2: Everything in SKILL.md
182
+
183
+ ```
184
+ # ❌ Bad
185
+ skill-name/
186
+ └── SKILL.md (900 lines — everything in one file)
187
+
188
+ # ✅ Good
189
+ skill-name/
190
+ ├── SKILL.md (180 lines — core workflow)
191
+ └── references/
192
+ ├── patterns.md (250 lines)
193
+ └── advanced.md (300 lines)
194
+ ```
195
+
196
+ ### Mistake 3: Second-person writing
197
+
198
+ ```
199
+ # ❌ Bad
200
+ You should start by reading the config file.
201
+ You need to validate the input.
202
+
203
+ # ✅ Good
204
+ Start by reading the config file.
205
+ Validate the input before processing.
206
+ ```
207
+
208
+ ## Additional Resources
209
+
210
+ - `references/format-guide.md` — complete XML tag reference, style rules, size targets
211
+ - `references/description-patterns.md` — Good/Bad description catalog for all OMC skill categories
212
+
213
+ ## Related Skills
214
+
215
+ - `skill-quality-analyzer` — score a skill across 6 quality dimensions
216
+ - `skill-debugger` — debug why a skill isn't triggering
217
+ - `skill-tester` — verify a skill triggers and behaves correctly
218
+ - `skill` — manage installed skills (list, add, remove, sync)
@@ -0,0 +1,160 @@
1
+ # Description Patterns — Good/Bad Catalog
2
+
3
+ Reference for writing the `description` field in SKILL.md frontmatter.
4
+
5
+ Claude sees this description in the system-reminder when deciding whether to invoke a skill.
6
+ Format: `"This skill should be used when the user asks to '[trigger]', '[trigger]'. [Summary]."`
7
+
8
+ ---
9
+
10
+ ## The Format Standard
11
+
12
+ ```yaml
13
+ # Auto-discovery skills (user/project skills):
14
+ description: "This skill should be used when the user asks to '[trigger 1]', '[trigger 2]', or '[trigger 3]'. [One-sentence summary]."
15
+
16
+ # OMC core workflow skills (also triggered by CLAUDE.md keywords):
17
+ description: "[Capability summary]. Triggered by: '[kw1]', '[kw2]'."
18
+ ```
19
+
20
+ **Required**: At least 2 quoted trigger phrases using `'single quotes'`.
21
+
22
+ ---
23
+
24
+ ## Anti-Pattern Catalog
25
+
26
+ ### Anti-pattern 1: Tagline instead of trigger
27
+
28
+ ```yaml
29
+ # ❌ Tagline — describes what it IS, not WHEN to use it
30
+ description: Full autonomous execution from idea to working code
31
+ description: Parallel execution engine for high-throughput task completion
32
+ description: Self-referential loop until task completion with architect verification
33
+
34
+ # ✅ Trigger-forward
35
+ description: "Use when user wants full-auto development ('build me', 'autopilot', 'I want a'). End-to-end pipeline from idea to verified code."
36
+ description: "Use when running multiple independent tasks in parallel ('ulw', 'ultrawork', 'run in parallel'). Tiered agent routing with haiku/sonnet/opus."
37
+ description: "Use when task must complete guaranteed ('ralph', 'don't stop', 'must complete'). Persistence loop with architect sign-off."
38
+ ```
39
+
40
+ ### Anti-pattern 2: Wrong platform branding
41
+
42
+ ```yaml
43
+ # ❌ Platform-specific (Codex, not Claude Code)
44
+ description: Analyzes Codex skill quality with 6-dimension scoring system
45
+ description: Tests Codex skill functionality with TDD approach
46
+
47
+ # ✅ Platform-neutral
48
+ description: "This skill should be used when the user asks to 'analyze skill quality', 'score skill', or 'skill quality report'. 6-dimension scoring for Claude Code skills."
49
+ description: "This skill should be used when the user asks to 'test skill', 'verify skill', or 'skill test'. Trigger tests and behavioral validation for Claude Code skills."
50
+ ```
51
+
52
+ ### Anti-pattern 3: Second person in description
53
+
54
+ ```yaml
55
+ # ❌ Second person
56
+ description: Use this skill when you want to plan before coding
57
+ description: Load this skill when user asks for parallel execution
58
+
59
+ # ✅ Third person or neutral
60
+ description: "This skill should be used when the user asks to 'plan this', 'plan the', or 'let's plan'. Interview, direct, consensus, and review modes."
61
+ ```
62
+
63
+ ### Anti-pattern 4: No trigger phrases (vague)
64
+
65
+ ```yaml
66
+ # ❌ Vague — no specific triggers
67
+ description: Helps with various tasks
68
+ description: Provides guidance for working with hooks
69
+ description: Deep analysis and investigation
70
+
71
+ # ✅ Specific
72
+ description: "This skill should be used when the user asks to 'create a hook', 'add validation hook', or 'configure hook behavior'. Full hook development with examples."
73
+ description: "Use when debugging or investigating failures ('analyze', 'debug', 'investigate', 'why is this failing'). Delegates to debugger agent for root-cause analysis."
74
+ ```
75
+
76
+ ---
77
+
78
+ ## Pattern Catalog by Category
79
+
80
+ ### Workflow / Orchestration Skills
81
+
82
+ These are invoked by keyword — triggers must match CLAUDE.md `<skills>` section keywords.
83
+
84
+ ```yaml
85
+ # autopilot
86
+ description: "Use when user wants full-auto development ('build me', 'autopilot', 'I want a', 'create me'). End-to-end: spec→plan→code→QA→validation with no manual intervention."
87
+
88
+ # ralph
89
+ description: "Use when task must complete guaranteed ('ralph', 'don't stop', 'must complete', 'finish this'). Persistence loop with ultrawork parallelism and architect sign-off."
90
+
91
+ # ultrawork
92
+ description: "Use when running multiple independent tasks in parallel ('ulw', 'ultrawork', 'run in parallel'). Tiered agent routing: haiku/sonnet/opus fired simultaneously."
93
+
94
+ # plan
95
+ description: "Use when planning before coding ('plan this', 'plan the', 'let's plan', 'make a plan'). Interview, direct, consensus (--consensus), and review (--review) modes."
96
+
97
+ # team
98
+ description: "Use when coordinating multiple agents on a project ('team', 'coordinated team', 'multi-agent', 'swarm'). TeamCreate→tasks→parallel agents→verify→TeamDelete pipeline."
99
+ ```
100
+
101
+ ### Quality / Skill Tooling
102
+
103
+ ```yaml
104
+ # writing-skills
105
+ description: "This skill should be used when the user asks to 'create a skill', 'write a new skill', 'add a skill', or 'improve an existing skill'. Covers structure, description quality, progressive disclosure, and the quality pipeline."
106
+
107
+ # skill-quality-analyzer
108
+ description: "This skill should be used when the user asks to 'analyze skill quality', 'score skill', 'skill quality report', or 'audit skill'. 6-dimension scoring: clarity, structure, examples, triggers, practices, maintainability."
109
+
110
+ # skill-debugger
111
+ description: "This skill should be used when the user asks to 'debug skill', 'skill not triggering', 'why isn't skill working', or 'skill discovery issue'. Diagnoses description quality, naming, conflicts, and file structure."
112
+
113
+ # skill-tester
114
+ description: "This skill should be used when the user asks to 'test skill', 'verify skill', 'does this skill trigger', or 'skill test'. Trigger tests, functional tests, and edge case validation."
115
+ ```
116
+
117
+ ### Domain / Code Skills
118
+
119
+ ```yaml
120
+ # tdd
121
+ description: "This skill should be used when the user asks to 'tdd', 'test first', 'red green refactor', or 'write tests first'. Enforces Red→Green→Refactor cycle — no implementation before failing test."
122
+
123
+ # security-review
124
+ description: "This skill should be used when the user asks to 'security review', 'check for vulnerabilities', 'OWASP audit', or 'security scan'. Comprehensive review across OWASP Top 10, authn/authz, and trust boundaries."
125
+
126
+ # code-review
127
+ description: "This skill should be used when the user asks to 'code review', 'review this PR', 'review code', or 'check my code'. Multi-layer review: style, quality, security, API compatibility, performance."
128
+
129
+ # ai-commenting
130
+ description: "This skill should be used when the user asks to 'ai comment', 'annotate code', 'add ai tags', or 'mark high-risk code'. Machine-parseable @ai: protocol for risk, intent, deps, auth, invariants."
131
+ ```
132
+
133
+ ### Utility / Management Skills
134
+
135
+ ```yaml
136
+ # note
137
+ description: "This skill should be used when the user asks to 'note', 'remember this', 'save note', or 'notepad'. Persists to .omc/notepad.md — survives context compaction."
138
+
139
+ # cancel
140
+ description: "This skill should be used when the user wants to 'cancel', 'stop', or 'abort' an active OMC mode. Cleanly exits autopilot, ralph, ultrawork, ultraqa, team, pipeline state."
141
+
142
+ # trace
143
+ description: "This skill should be used when the user asks to 'trace', 'show agent trace', 'what agents ran', or 'session timeline'. Renders timeline of agent calls and results."
144
+
145
+ # hud
146
+ description: "This skill should be used when the user asks to 'hud', 'configure display', 'hud layout', or 'status bar'. Sets layout, visible elements, and display presets."
147
+ ```
148
+
149
+ ---
150
+
151
+ ## Quick Self-Check
152
+
153
+ Before finalizing a description, ask:
154
+
155
+ 1. **Natural?** Would a user actually say these trigger phrases?
156
+ 2. **Specific?** Would it distinguish this skill from similar ones?
157
+ 3. **Quoted?** Does it contain at least 2 phrases in `'single quotes'`?
158
+ 4. **Summarized?** Does the last sentence say what it produces?
159
+
160
+ If all 4 are yes → the description is ready.
@@ -0,0 +1,203 @@
1
+ # Format Guide — OMC Skill Body Structure
2
+
3
+ Reference for the two body formats used in oh-my-claudecode skills.
4
+
5
+ ---
6
+
7
+ ## Format Selection
8
+
9
+ | Use case | Format |
10
+ |----------|--------|
11
+ | Workflow/process/orchestration skills (autopilot, ralph, plan, ultrawork) | XML tags |
12
+ | Utility/tool/management skills (note, trace, hud, skill) | Markdown headers |
13
+ | Domain skills with a clear protocol (tdd, security-review, ai-commenting) | Either — be consistent |
14
+
15
+ **Rule**: Pick one format per skill and don't mix them.
16
+
17
+ ---
18
+
19
+ ## XML Tag Format (Workflow Skills)
20
+
21
+ ### Required tags
22
+
23
+ ```xml
24
+ <Purpose>
25
+ What the skill does and what it produces. 2-4 sentences.
26
+ Answers: "What is this?" and "What do I get at the end?"
27
+ </Purpose>
28
+
29
+ <Use_When>
30
+ - Specific trigger conditions (be concrete, not vague)
31
+ - List exact phrases: User says "autopilot", "build me", "I want a..."
32
+ - List task types that warrant this skill
33
+ </Use_When>
34
+
35
+ <Do_Not_Use_When>
36
+ - Explicitly redirect to the right skill: "use `ralph` instead"
37
+ - List cases where users commonly misapply this skill
38
+ </Do_Not_Use_When>
39
+
40
+ <Why_This_Exists>
41
+ 1-2 sentences explaining the problem this solves.
42
+ Prevents misuse by setting expectations.
43
+ </Why_This_Exists>
44
+
45
+ <Steps>
46
+ Ordered procedure. Each step should be a concrete action.
47
+ Include sub-steps where needed.
48
+ Reference agents with: Task(subagent_type="oh-my-claudecode:executor", ...)
49
+ </Steps>
50
+
51
+ <Examples>
52
+ <Good>
53
+ Concrete correct usage with explanation.
54
+ Why good: [specific reason]
55
+ </Good>
56
+
57
+ <Bad>
58
+ Common mistake with explanation.
59
+ Why bad: [specific reason]
60
+ </Bad>
61
+ </Examples>
62
+
63
+ <Final_Checklist>
64
+ - [ ] Checkboxes that verify completion
65
+ - [ ] Each item must be tool-verifiable or judgment-based (label which)
66
+ </Final_Checklist>
67
+ ```
68
+
69
+ ### Optional tags
70
+
71
+ ```xml
72
+ <Execution_Policy>
73
+ Hard rules that override default behavior.
74
+ Use for: parallelism rules, model selection, iteration limits.
75
+ </Execution_Policy>
76
+
77
+ <Tool_Usage>
78
+ Which tools to use and when.
79
+ Required if the skill uses MCP tools (ToolSearch, ask_codex, ask_gemini).
80
+ </Tool_Usage>
81
+
82
+ <Escalation_And_Stop_Conditions>
83
+ When to stop and report vs. keep going.
84
+ Required for loop/persistence skills (ralph, ultrawork, ultraqa).
85
+ </Escalation_And_Stop_Conditions>
86
+
87
+ <Advanced>
88
+ Detail that's useful but not needed for basic execution.
89
+ This implements progressive disclosure — moved here from main body to keep it lean.
90
+ </Advanced>
91
+ ```
92
+
93
+ ### Anti-patterns in XML format
94
+
95
+ ```xml
96
+ <!-- ❌ Vague Use_When -->
97
+ <Use_When>
98
+ - When the user needs help
99
+ - For complex tasks
100
+ </Use_When>
101
+
102
+ <!-- ✅ Specific Use_When -->
103
+ <Use_When>
104
+ - User says "autopilot", "build me", "I want a [project]"
105
+ - Task requires multiple phases: spec, code, test, validate
106
+ - User wants hands-off execution to completion
107
+ </Use_When>
108
+ ```
109
+
110
+ ---
111
+
112
+ ## Markdown Header Format (Utility Skills)
113
+
114
+ ```markdown
115
+ # Skill Name
116
+
117
+ One-sentence purpose statement.
118
+
119
+ ## When to Use
120
+
121
+ Use this skill when:
122
+ - [specific scenario]
123
+ - [specific scenario]
124
+
125
+ ## When NOT to Use
126
+
127
+ - [redirect]: use `other-skill` instead
128
+
129
+ ## Workflow
130
+
131
+ 1. [Step]
132
+ 2. [Step]
133
+
134
+ ## Examples
135
+
136
+ **Basic**:
137
+ "[example invocation]"
138
+
139
+ **Advanced**:
140
+ "[example invocation]"
141
+
142
+ ## Notes / Limitations
143
+
144
+ - [caveat]
145
+ ```
146
+
147
+ ---
148
+
149
+ ## Size Targets
150
+
151
+ | File | Target | Maximum |
152
+ |------|--------|---------|
153
+ | SKILL.md body | ≤150 lines | 200 lines |
154
+ | references/*.md | ≤250 lines | 400 lines |
155
+
156
+ If SKILL.md body exceeds 200 lines:
157
+ 1. Identify the largest "reference-style" section (tables, long examples, advanced techniques)
158
+ 2. Move it to `references/<topic>.md`
159
+ 3. Add a pointer in SKILL.md: `See references/<topic>.md for detailed patterns.`
160
+
161
+ ---
162
+
163
+ ## Writing Style Rules
164
+
165
+ ### Imperative form (required)
166
+
167
+ ```
168
+ ✅ "Start by reading the configuration file."
169
+ ✅ "Validate the input before processing."
170
+ ✅ "Use the Read tool to examine the skill content."
171
+
172
+ ❌ "You should start by reading the configuration file."
173
+ ❌ "You need to validate the input."
174
+ ❌ "Claude should use the Read tool."
175
+ ```
176
+
177
+ ### Description (frontmatter) — third person
178
+
179
+ ```yaml
180
+ ✅ description: "This skill should be used when the user asks to 'create X', 'configure Y'."
181
+ ✅ description: "Use when user wants to [scenario] ('[trigger 1]', '[trigger 2]')."
182
+
183
+ ❌ description: Use this skill when you want to create X.
184
+ ❌ description: Load when user needs help.
185
+ ```
186
+
187
+ ### No platform branding
188
+
189
+ Never include "Codex CLI", "Codex skill", or similar in body content — this is a Claude Code skill.
190
+
191
+ ---
192
+
193
+ ## Frontmatter Fields
194
+
195
+ ```yaml
196
+ ---
197
+ name: skill-name # required; must match folder name exactly (kebab-case)
198
+ description: "..." # required; must contain quoted trigger phrases
199
+ argument-hint: "<args>" # optional; shown in skill listing
200
+ ---
201
+ ```
202
+
203
+ Only `name` and `description` are used by Claude for skill discovery and invocation. Additional fields are ignored at runtime.