design-skills

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:

1. Must-have (v1): Skills that cover the daily workflow. Without these, the OS doesn't function.
2. Should-have (v1): Skills that handle common events. The OS works without them but is weaker.
3. 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