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.
- package/README.md +89 -208
- package/dist/hooks/bridge.js +5 -2
- package/dist/hooks/bridge.js.map +1 -1
- package/docs/CLAUDE.md +29 -7
- package/docs/plans/2026-02-26-skill-optimization-design.md +158 -0
- package/docs/plans/2026-02-26-skill-optimization-impl.md +606 -0
- package/package.json +1 -1
- package/skills/AGENTS.md +1 -0
- package/skills/ai-commenting/SKILL.md +108 -0
- package/skills/skill-development/SKILL.md +218 -0
- package/skills/skill-development/references/description-patterns.md +160 -0
- package/skills/skill-development/references/format-guide.md +203 -0
- package/skills/skill-quality-analyzer/SKILL.md +39 -41
|
@@ -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.
|