| name | design-skills |
| description | Design the complete skill set for the target OS — each skill's purpose, inputs, process, output format, auto-triggers, and quality checks. |
/design-skills - Skill Set Design
When to Use
- After all domain-input/ files are filled (or at least domain-workflow, audiences, scoring-rubrics, identity-model, quality-contract)
- When designing the .claude/skills/ directory for the target OS
Inputs
- Auto-loaded: ALL
domain-input/ files
- Auto-loaded:
reference/skill-anatomy.md (structural template for skills)
- Auto-loaded:
reference/architecture-patterns.md (design principles)
Process
Step 1: Skill Derivation from Workflow
Map the user's workflow to skills. Every recurring action and every event-driven response from domain-input/domain-workflow.md is a skill candidate.
Use these universal skill categories as a starting framework:
| Category | Purpose | Job-Search-OS Examples |
|---|
| Triage | Quick assessment — should the user invest time? | /quick-start, /job-fit-scorer |
| Research | Deep-dive on a target or topic | /company-research, /salary-research |
| Generate (artifact) | Create a deliverable from context + input | /resume-tailor, /cover-letter, /work-product |
| Generate (communication) | Create outreach or messages | /connection-request, /referral-request, /hiring-manager-msg |
| Prepare | Get ready for an event | /interview-prep |
| Practice | Interactive rehearsal | /mock-interview |
| Debrief | Post-event analysis → update history | /interview-debrief |
| Follow-up | Post-event communication | /thank-you-note |
| Track | Pipeline / status management | /app-tracker |
| Audit | Review existing assets for quality | /linkedin-audit |
| Negotiate | Analyze and respond to an offer | /negotiate |
| Retro | Periodic performance review | /weekly-retro |
For each category, ask: "Does this domain have an equivalent? What would it be called? What would it do?"
Step 2: Skill Prioritization
Not every skill needs to exist in v1. Prioritize:
- Must-have (v1): Skills that cover the daily workflow. Without these, the OS doesn't function.
- Should-have (v1): Skills that handle common events. The OS works without them but is weaker.
- Nice-to-have (v2): Skills for edge cases or advanced users. Save for later.
Target: 8-15 skills for v1. More than 18 means the scope is too broad. Fewer than 6 means critical workflow gaps exist.
Step 3: Skill Specification
For each v1 skill, design the full specification using this template:
## Skill: /[name]
### Purpose
[one sentence — what problem does this solve for the user]
### When to Use
- [trigger 1]
- [trigger 2]
### Inputs
- **Required:** [what the user provides]
- **Auto-loaded:** [which context-library files]
- **Optional:** [what's nice to have but not required]
### Process (High-Level)
1. [Step 1 — what to do]
2. [Step 2 — what to do]
3. [Step 3 — what to do]
### Output Format
[describe or sketch the output structure]
### Auto-Triggers
- After this skill runs: [what runs automatically — sub-agents, other skills]
- After this skill runs: [what state files get updated]
### Quality Checks
**Good output:**
- [specific criterion 1]
- [specific criterion 2]
**Bad output:**
- [specific anti-pattern 1]
- [specific anti-pattern 2]
### Empty Context Behavior
- If [file] is missing: [STOP / WARN / proceed]
- Message: "[exact text]"
Step 4: Auto-Behavior Map
Design the trigger chains — what automatically happens after each skill:
## Auto-Behavior Map
| After This Skill | Auto-Trigger | Purpose |
|-----------------|-------------|---------|
| /[create skill] | /review-as-[audience] | Quality gate |
| /[debrief skill] | Update [history file] | Accumulate data |
| /[any application action] | Prompt /[tracker] | Pipeline tracking |
Step 5: Zero-Setup Entry Point
Confirm which skill works with zero context (from quality-contract.md). Design it to:
- Deliver immediate value in under 60 seconds
- Show the user what the OS can do
- Naturally lead to "if you fill in [context file], I can do [much more]"
Step 6: Skill Interdependency Map
Chart how skills relate to each other:
[triage] ──→ [generate artifact] ──→ [review sub-agent]
──→ [track]
[research] ──→ [prepare] ──→ [practice] ──→ [debrief] ──→ [history update]
──→ [follow-up]
[retro] reads ──→ [history], [tracker], [briefings]
Output
Write the complete skill set design to output/designs/skill-designs.md.
For each skill, include the full specification from Step 3.
Tell the designer:
Skill set designed:
- [N] skills for v1: [list with one-line descriptions]
- [N] skills deferred to v2: [list]
- Auto-behavior chains: [N] auto-triggers
- Zero-setup entry point: /[X]
- Sub-agent triggers: [list which skills trigger which reviewers]
Skill flow: [one sentence describing the main user journey through skills]
Next: Run /design-sub-agents to design the reviewer personas.
Quality Checks
Good skill design:
- Skills map cleanly to the daily workflow — no orphan skills that don't connect to anything
- Every creation skill has an auto-triggered reviewer
- Every skill has quality checks section with "good" and "bad" examples
- The interdependency map shows compounding (skills that feed data to other skills)
- 8-15 skills total — focused, not exhaustive
Bad skill design:
- Skills are too granular (20+ skills for v1)
- No auto-triggers — everything is manual
- Skills are isolated — no data flows between them
- Missing a triage/entry-point skill
- Missing a retro/feedback skill
- Quality checks are generic across all skills instead of skill-specific
