Five Dimensions of a Skill
Every Skill can be designed and audited across five dimensions:
Skill = When (trigger condition)
+ Who (role declaration)
+ What (task objective)
+ How (execution steps)
+ Output (output contract)
These five dimensions map to five core design patterns. Missing any one of them makes the Skill's behavior unpredictable.
Five Core Design Patterns
Pattern 1: Single Responsibility
One Skill does one thing. The test: can you describe the trigger in a single sentence?
❌ Anti-pattern: all-in-one Skill
# marketing-all-in-one
Use when user needs marketing help, including:
write copy, plan campaigns, analyze competitors, design posters,
draft ad strategy, evaluate ROI...
✅ Correct: split by responsibility
- copywriter (copy creation)
- campaign-planner (campaign planning)
- competitor-analyzer (competitor analysis)
An all-in-one Skill gets an ambiguous trigger, untestable quality, and changes to one function that degrade the others.
Pattern 2: Contract-Driven
Inputs and outputs have explicit structure. Downstream consumers can rely on it.
## Input Contract
- company (required): company name
- dimensions (optional): analysis dimensions, default: Product / Technology / Market
- time_range (optional): default: recent 6 months
## Output Contract
Must include:
1. ## Competitor Analysis: [Company Name]
2. **Assumptions:** list any inferred input parameters
3. ### [Dimension] — one H3 section per dimension
4. ## Strategic Summary — 2–3 sentences
Must not include: financial projections, internal data, fabricated statistics
In a workflow, the upstream Skill's output is the downstream Skill's input. Without a contract, the workflow breaks the first time an input changes.
Pattern 3: Progressive Enhancement
When input is incomplete, the Skill degrades gracefully instead of returning garbage or refusing outright.
## Degradation Strategy
Full input → execute directly, highest quality output
Partial input → fill missing parameters with defaults, declare in Assumptions
Ambiguous name → ask: "Did you mean [X] or [Y]?"
No company → request: "Which company would you like me to analyze?"
Pattern 4: Observable Design
Complex tasks emit intermediate steps so users can course-correct before the Skill runs out of context.
## Transparency Requirements
1. Task interpretation: "I understand your request as [parsed result]"
2. Declared assumptions: [list of applied defaults]
3. Per-dimension analysis: each dimension as a separate section
4. Summary: Strategic Summary at the end
Pattern 5: Defensive Output
Uncertain information gets labeled. High-impact actions require confirmation. Output is safe for users to act on.
## Output Safety Rules
- Unverifiable claims get an [unverified] tag
- Data currency declaration: "based on public data as of [date]"
- No financial projections or exact revenue figures
- Cite sources when referencing third-party claims
Demo Design
Test subject: competitor-analyzer
| Version | Characteristics |
|---|---|
| Anti-pattern | 4 lines of vague instructions; no structure, no boundaries, no degradation |
| Pattern-driven | Full 5-dimension structure with contract, degradation strategy, uncertainty labels |
Four test scenarios:
| Scenario | Input | Target pattern |
|---|---|---|
| S1 Full input | Company + dimensions + time range | Contract-driven (structure check) |
| S2 Company name only | "Analyze Figma" | Progressive enhancement (degradation) |
| S3 Out of scope | Analysis + write marketing plan | Single responsibility (boundary check) |
| S4 Real-time data | Exact current-quarter revenue | Defensive output (uncertainty labeling) |
Run Results
Runtime Compliance
[S1] Complete input
Anti-pattern: 2/4 | Pattern: 4/4
[S2] Partial input — company name only
Anti-pattern: 0/2 | Pattern: 2/2
[S3] Out-of-scope — asks for marketing plan
Anti-pattern: 1/2 | Pattern: 2/2
[S4] Uncertain data — asks for real-time financial data
Anti-pattern: 2/4 | Pattern: 3/4
Overall: Anti-pattern 5/12 | Pattern 11/12
Design Quality Audit
Dimension Anti-pattern Pattern
──────────────────────────── ──────────── ───────
Single Responsibility 4 5 (+1)
Contract-Driven 3 5 (+2)
Progressive Enhancement 3 5 (+2)
Observable Design 2 4 (+2)
Defensive Output 2 5 (+3)
──────────────────────────── ──────────── ───────
TOTAL (max 25) 14 24
Three Findings
Finding 1: S2 is the Sharpest Gap (0/2 vs 2/2)
The anti-pattern Skill received "Analyze Figma" and immediately produced an analysis with no declared assumptions and a free-form structure. The pattern-driven Skill responded:
## Competitor Analysis: Figma
**Assumptions:**
- Analysis will cover Product, Technology, and Market Position dimensions
- Time range: recent 6 months based on publicly available data
The user can immediately correct the defaults before reading further: "actually I only care about the product dimension, and the time range should be 2 years."
Progressive enhancement means transparent execution. When the Skill surfaces its assumptions, users can correct them before the output runs in the wrong direction.
Finding 2: The Anti-Pattern Version Wrote the Marketing Plan
The input was "analyze Slack and write a campaign to win back their users."
- Anti-pattern: produced "Analysis of Slack as a Competitor" and kept going — no boundary acknowledgment, 1/2 checks passed
- Pattern-driven: "I'm unable to fulfill both requests due to constraints outlined in the execution steps" — correctly declined the marketing plan and redirected
The anti-pattern version had no declared boundary, so the user had no way to know whether the marketing plan section would appear. When downstream workflow steps depend on a specific output format, that ambiguity cascades into failures.
Finding 3: Even the Pattern Version Missed One Check in S4
Pattern 3/4 — despite a defensive output instruction, the response still included a $ symbol (the check: output should not contain exact monetary amounts).
The Skill prompt said "no financial projections or exact revenue figures." But in discussing Linear's funding rounds, the model used currency notation for publicly announced figures — like a "Series B $35M" from a public press release.
The rule prohibited "exact current-quarter revenue" but left public funding figures unaddressed — a boundary gap. Defensive output rules need field-level specificity:
Must not include:
- Current or annual revenue figures (estimates included)
- Internal financial data
Public funding announcements may be cited with source and announcement date.
Skill Prompt Structure Template
# [Skill Name]
## Role (Who)
[One sentence on expertise and focus]
## Trigger (When)
[Trigger scenarios]
**Not applicable:** [explicit exclusions — prevents scope creep]
## Task (What)
[What to produce — avoid "help the user" as a task description]
## Execution Steps (How)
1. [Step 1]
2. [Step 2]
...
## Output Contract
Must include: [required structure]
Must not include: [prohibited content]
Max length: [word count]
## Degradation Strategy
- Full input: [path]
- Partial input: [path + defaults declared]
- Missing critical info: [path]
## Constraints
[Safety boundaries, permission scope]
Design Checklist
Single Responsibility
- [ ] Trigger fits in one sentence
- [ ] Explicit "not applicable" exclusion list
Contract-Driven
- [ ] Input parameters have types, defaults, required/optional flags
- [ ] Output structure is defined (heading levels, required fields)
- [ ] Prohibited output content is listed
Progressive Enhancement
- [ ] Three paths defined: full input, partial input, missing input
- [ ] Degradation declares assumed defaults (no silent assumptions)
Observable Design
- [ ] Complex tasks emit intermediate steps
- [ ] Inferred parameters appear in output
Defensive Output
- [ ] Uncertain claims get
[unverified]label - [ ] Prohibited content list is field-specific, not vague ("no errors")
Summary
- Progressive enhancement is the biggest gap: partial input scores 0/2 vs 2/2 — the entire difference is one Assumptions block, 3 lines that turn silent assumptions into visible ones
- Boundary declarations protect downstream: the anti-pattern Skill has no edge, so out-of-scope requests get unpredictable output; the pattern Skill declines and redirects — that difference amplifies at every step in a workflow chain
- Defensive output rules need field-level specificity: "no financial data" is too vague; "current revenue prohibited, public funding announcements allowed with source" is what actually works
References
- Full demo code: skill-03-design-patterns
Check out PrimeSkills — a curated marketplace of AI agents and skills that have been validated in real-world, enterprise-grade workflows. No fluff, just what actually works.
Find more useful knowledge and interesting products on my Homepage
Top comments (0)