// Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured.
Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan".
Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.
Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.
Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
| name | using-agent-skills |
| description | Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked. |
Agent Skills is a collection of engineering workflow skills organized by development phase. Each skill encodes a specific process that senior engineers follow. This meta-skill helps you discover and apply the right skill for your current task.
When a task arrives, identify the development phase and apply the corresponding skill:
Task arrives
│
├── Don't know what you want yet? ──────→ interview-me
├── Have a rough concept, need variants? → idea-refine
├── New project/feature/change? ──→ spec-driven-development
├── Have a spec, need tasks? ──────→ planning-and-task-breakdown
├── Implementing code? ────────────→ incremental-implementation
│ ├── UI work? ─────────────────→ frontend-ui-engineering
│ ├── API work? ────────────────→ api-and-interface-design
│ ├── Need better context? ─────→ context-engineering
│ ├── Need doc-verified code? ───→ source-driven-development
│ └── Stakes high / unfamiliar code? ──→ doubt-driven-development
├── Writing/running tests? ────────→ test-driven-development
│ └── Browser-based? ───────────→ browser-testing-with-devtools
├── Something broke? ──────────────→ debugging-and-error-recovery
├── Reviewing code? ───────────────→ code-review-and-quality
│ ├── Security concerns? ───────→ security-and-hardening
│ └── Performance concerns? ────→ performance-optimization
├── Committing/branching? ─────────→ git-workflow-and-versioning
├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
├── Writing docs/ADRs? ───────────→ documentation-and-adrs
└── Deploying/launching? ─────────→ shipping-and-launch
These behaviors apply at all times, across all skills. They are non-negotiable.
Before implementing anything non-trivial, explicitly state your assumptions:
ASSUMPTIONS I'M MAKING:
1. [assumption about requirements]
2. [assumption about architecture]
3. [assumption about scope]
→ Correct me now or I'll proceed with these.
Don't silently fill in ambiguous requirements. The most common failure mode is making wrong assumptions and running with them unchecked. Surface uncertainty early — it's cheaper than rework.
When you encounter inconsistencies, conflicting requirements, or unclear specifications:
Bad: Silently picking one interpretation and hoping it's right. Good: "I see X in the spec but Y in the existing code. Which takes precedence?"
You are not a yes-machine. When an approach has clear problems:
Sycophancy is a failure mode. "Of course!" followed by implementing a bad idea helps no one. Honest technical disagreement is more valuable than false agreement.
Your natural tendency is to overcomplicate. Actively resist it.
Before finishing any implementation, ask:
If you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.
Touch only what you're asked to touch.
Do NOT:
Your job is surgical precision, not unsolicited renovation.
Every skill includes a verification step. A task is not complete until verification passes. "Seems right" is never sufficient — there must be evidence (passing tests, build output, runtime data).
These are the subtle errors that look like productivity but create problems:
Check for an applicable skill before starting work. Skills encode processes that prevent common mistakes.
Skills are workflows, not suggestions. Follow the steps in order. Don't skip verification steps.
Multiple skills can apply. A feature implementation might involve idea-refine → spec-driven-development → planning-and-task-breakdown → incremental-implementation → test-driven-development → code-review-and-quality → shipping-and-launch in sequence.
When in doubt, start with a spec. If the task is non-trivial and there's no spec, begin with spec-driven-development.
For a complete feature, the typical skill sequence is:
1. interview-me → Extract what the user actually wants
2. idea-refine → Refine vague ideas
3. spec-driven-development → Define what we're building
4. planning-and-task-breakdown → Break into verifiable chunks
5. context-engineering → Load the right context
6. source-driven-development → Verify against official docs
7. incremental-implementation → Build slice by slice
8. doubt-driven-development → Cross-examine non-trivial decisions in-flight
9. test-driven-development → Prove each slice works
10. code-review-and-quality → Review before merge
11. git-workflow-and-versioning → Clean commit history
12. documentation-and-adrs → Document decisions
13. shipping-and-launch → Deploy safely
Not every task needs every skill. A bug fix might only need: debugging-and-error-recovery → test-driven-development → code-review-and-quality.
| Phase | Skill | One-Line Summary |
|---|---|---|
| Define | interview-me | Surface what the user actually wants before any plan, spec, or code exists |
| Define | idea-refine | Refine ideas through structured divergent and convergent thinking |
| Define | spec-driven-development | Requirements and acceptance criteria before code |
| Plan | planning-and-task-breakdown | Decompose into small, verifiable tasks |
| Build | incremental-implementation | Thin vertical slices, test each before expanding |
| Build | source-driven-development | Verify against official docs before implementing |
| Build | doubt-driven-development | Adversarial fresh-context review of every non-trivial decision |
| Build | context-engineering | Right context at the right time |
| Build | frontend-ui-engineering | Production-quality UI with accessibility |
| Build | api-and-interface-design | Stable interfaces with clear contracts |
| Verify | test-driven-development | Failing test first, then make it pass |
| Verify | browser-testing-with-devtools | Chrome DevTools MCP for runtime verification |
| Verify | debugging-and-error-recovery | Reproduce → localize → fix → guard |
| Review | code-review-and-quality | Five-axis review with quality gates |
| Review | security-and-hardening | OWASP prevention, input validation, least privilege |
| Review | performance-optimization | Measure first, optimize only what matters |
| Ship | git-workflow-and-versioning | Atomic commits, clean history |
| Ship | ci-cd-and-automation | Automated quality gates on every change |
| Ship | documentation-and-adrs | Document the why, not just the what |
| Ship | shipping-and-launch | Pre-launch checklist, monitoring, rollback plan |