From nexus
Creates, refactors, or debugs SKILL.md files with production-ready structure and trigger optimization. Also identifies when existing skills should be extended or merged.
How this skill is triggered — by the user, by Claude, or both
Slash command
/nexus:skill-writerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produce a **complete, production-ready skill** every session — not a draft, not a skeleton.
Produce a complete, production-ready skill every session — not a draft, not a skeleton.
skill-name/
├── SKILL.md ← entry point, <500 lines
├── checklists/
│ └── execution-checklist.md
├── anti-patterns/
│ └── common-mistakes.md
└── validation/
└── output-validation.md
Every SKILL.md must have YAML frontmatter:
---
name: nexus-{skill-name} # kebab-case, unique, descriptive
description: > # THE TRIGGER MECHANISM — be explicit and dense
Use this skill when ... [detailed trigger conditions].
Trigger phrases include: "...", "...", "...".
Also trigger when ... [edge cases].
When in doubt, use this skill.
---
The description is the single most important field. Claude selects skills based only on name + description. A vague description means the skill never triggers. Under-triggering is the #1 skill failure mode.
Before writing anything, classify the request:
New skill or extension?
available_skills in the system prompt.| Option | Best when | Risk |
|---|---|---|
| Extend existing | Same domain, similar triggers | May bloat the existing skill |
| Create new | Distinct triggers, different output contract | Maintenance overhead |
| Merge two skills | Overlapping triggers, narrow scopes | Wider scope per skill |
Never decide for the user — present options and wait for direction.
Category:
| Category | Description |
|---|---|
| engineering | Code generation, architecture, implementation |
| debugging | Failure investigation, root cause, regression |
| devops | CI/CD, infra, deployments |
| code-review | PR review, diff analysis, quality checks |
| testing | Test writing, coverage, test strategy |
| reliability | SLOs, on-call, incident management |
| observability | Logs, metrics, traces, dashboards |
| refactoring | Code transformation, technical debt |
| performance | Profiling, optimization, benchmarking |
Primary or sub-skill? Primary = own directory + full SKILL.md. Sub-skill = .md inside an existing skill directory (only for very narrow, truly subordinate scope).
Ask conversationally — max 2 questions per turn. Extract answers from context first; only ask what you cannot infer. Do not proceed to Phase 2 without answers to Q1, Q2, Q3.
| # | Question | Why |
|---|---|---|
| 1 | What should this skill enable Claude to do? | Defines scope |
| 2 | What phrases/contexts should trigger it? | Shapes description |
| 3 | What is the expected output format? | Shapes Output Contract |
| 4 | Are there constraints? (tools, env, audience) | Shapes Compatibility |
| 5 | Example input + ideal output? | Becomes a production example |
| 6 | What does failure look like? What must never happen? | Shapes Failure Modes |
| 7 | What context must be gathered before acting? | Shapes Context Acquisition |
| 8 | What are the hallucination risks or dangerous assumptions? | Shapes Failure Modes |
Never assume answers to Q6, Q7, or Q8.
Use this exact section order. Adapt depth to domain; do not drop sections.
Required sections (in order):
name + description (5+ trigger phrases, ends with "When in doubt, use this skill.")Create or update all supporting files for every skill. These are not optional.
10 things NOT to do, each with: name, what it looks like, why it fails, what to do instead.
| # | Check | Pass Condition |
|---|---|---|
| 1 | Description trigger density | 5+ distinct, concrete trigger phrases |
| 2 | Step actionability | Every step has a specific verb — read, search, compare, extract, run, list, flag |
| 3 | Output contract defined | Output Contract table exists with all required fields |
| 4 | Anti-patterns present | 3+ "Never do X → do Y instead" rules |
| 5 | Production example present | 1+ real production-scale example (not toy) |
| 6 | Engineering heuristics are decision rules | Each heuristic is IF/THEN/BECAUSE |
| 7 | Failure modes documented | 3+ failure modes with mitigations |
| 8 | Validation criteria defined | Concrete pass/fail criteria for testing the skill |
State which items passed and which require user input to complete.
Deliver finished skill as ready-to-write files. For each file specify:
After delivery, state:
npx claudepluginhub aayushostwal/nexus --plugin nexusGuides creating, modifying, and optimizing SKILL.md files with intent capture, drafting, testing, and progressive-disclosure organization.
Create, improve, and test SKILL.md files to extend Claude Code with project-specific knowledge and reusable workflows.
Creates and refines SKILL.md files with better trigger descriptions, progressive disclosure, and testable behavior. Audits collections for redundancy and evaluates trigger quality.