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.
\nWhen a task arrives, identify the development phase and apply the corresponding skill:
\nTask arrives\n │\n ├── Don't know what you want yet? ──────→ interview-me\n ├── Have a rough concept, need variants? → idea-refine\n ├── New project/feature/change? ──→ spec-driven-development\n ├── No quality bar written down? ──→ constraint-driven-development\n ├── Have a spec, need tasks? ──────→ planning-and-task-breakdown\n ├── Implementing code? ────────────→ incremental-implementation\n │ ├── UI work? ─────────────────→ frontend-ui-engineering\n │ ├── API work? ────────────────→ api-and-interface-design\n │ ├── Need better context? ─────→ context-engineering\n │ ├── Need doc-verified code? ───→ source-driven-development\n │ └── Stakes high / unfamiliar code? ──→ doubt-driven-development\n ├── Writing/running tests? ────────→ test-driven-development\n │ └── Browser-based? ───────────→ browser-testing-with-devtools\n ├── Something broke? ──────────────→ debugging-and-error-recovery\n ├── Reviewing code? ───────────────→ code-review-and-quality\n │ ├── Too complex? ─────────────→ code-simplification\n │ ├── Security concerns? ───────→ security-and-hardening\n │ └── Performance concerns? ────→ performance-optimization\n ├── Committing/branching? ─────────→ git-workflow-and-versioning\n ├── CI/CD pipeline work? ──────────→ ci-cd-and-automation\n ├── Deprecating/migrating? ────────→ deprecation-and-migration\n ├── Writing docs/ADRs? ───────────→ documentation-and-adrs\n ├── Adding logs/metrics/alerts? ───→ observability-and-instrumentation\n └── Deploying/launching? ─────────→ shipping-and-launch\nThese behaviors apply at all times, across all skills. They are non-negotiable.
\nBefore implementing anything non-trivial, explicitly state your assumptions:
\nASSUMPTIONS I'M MAKING:\n1. [assumption about requirements]\n2. [assumption about architecture]\n3. [assumption about scope]\n→ Correct me now or I'll proceed with these.\nDon'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.
\nWhen you encounter inconsistencies, conflicting requirements, or unclear specifications:
\nBad: Silently picking one interpretation and hoping it's right.\nGood: \"I see X in the spec but Y in the existing code. Which takes precedence?\"
\nYou are not a yes-machine. When an approach has clear problems:
\nSycophancy is a failure mode. \"Of course!\" followed by implementing a bad idea helps no one. Honest technical disagreement is more valuable than false agreement.
\nYour natural tendency is to overcomplicate. Actively resist it.
\nBefore finishing any implementation, ask:
\nIf you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.
\nTouch only what you're asked to touch.
\nDo NOT:
\nYour job is surgical precision, not unsolicited renovation.
\nEvery 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).
\nPer-skill verification is the local check. The project-wide bar that applies to every change, regardless of which skill is active, is the Definition of Done: tests pass, no regressions, behavior verified at runtime, docs updated. See ../../references/definition-of-done.md. It complements each task's acceptance criteria rather than replacing them.
These are the subtle errors that look like productivity but create problems:
\nCheck for an applicable skill before starting work. Skills encode processes that prevent common mistakes.
\nSkills are workflows, not suggestions. Follow the steps in order. Don't skip verification steps.
\nMultiple 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 → code-simplification → 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:
\n1. interview-me → Extract what the user actually wants\n2. idea-refine → Refine vague ideas\n3. spec-driven-development → Define what we're building\n4. planning-and-task-breakdown → Break into verifiable chunks\n5. context-engineering → Load the right context\n6. source-driven-development → Verify against official docs\n7. incremental-implementation → Build slice by slice\n8. observability-and-instrumentation → Instrument as you build (runs parallel with 7-9, not after)\n9. doubt-driven-development → Cross-examine non-trivial decisions in-flight\n10. test-driven-development → Prove each slice works\n11. code-review-and-quality → Review before merge\n12. code-simplification → Reduce unnecessary complexity while preserving behavior\n13. git-workflow-and-versioning → Clean commit history\n14. documentation-and-adrs → Document decisions\n15. deprecation-and-migration → Retire old systems and move users safely when needed\n16. shipping-and-launch → Deploy safely\nNot every task needs every skill. A bug fix might only need: debugging-and-error-recovery → test-driven-development → code-review-and-quality.
| Phase | \nSkill | \nOne-Line Summary | \n
|---|---|---|
| Define | \ninterview-me | \nSurface what the user actually wants before any plan, spec, or code exists | \n
| Define | \nidea-refine | \nRefine ideas through structured divergent and convergent thinking | \n
| Define | \nspec-driven-development | \nRequirements and acceptance criteria before code | \n
| Plan | \nplanning-and-task-breakdown | \nDecompose into small, verifiable tasks | \n
| Build | \nincremental-implementation | \nThin vertical slices, test each before expanding | \n
| Build | \nsource-driven-development | \nVerify against official docs before implementing | \n
| Build | \ndoubt-driven-development | \nAdversarial fresh-context review of every non-trivial decision | \n
| Build | \ncontext-engineering | \nRight context at the right time | \n
| Build | \nfrontend-ui-engineering | \nProduction-quality UI with accessibility | \n
| Build | \napi-and-interface-design | \nStable interfaces with clear contracts | \n
| Verify | \ntest-driven-development | \nFailing test first, then make it pass | \n
| Verify | \nbrowser-testing-with-devtools | \nChrome DevTools MCP for runtime verification | \n
| Verify | \ndebugging-and-error-recovery | \nReproduce → localize → fix → guard | \n
| Review | \ncode-review-and-quality | \nFive-axis review with quality gates | \n
| Review | \ncode-simplification | \nPreserve behavior while reducing unnecessary complexity | \n
| Review | \nsecurity-and-hardening | \nOWASP prevention, input validation, least privilege | \n
| Review | \nperformance-optimization | \nMeasure first, optimize only what matters | \n
| Ship | \ngit-workflow-and-versioning | \nAtomic commits, clean history | \n
| Ship | \nci-cd-and-automation | \nAutomated quality gates on every change | \n
| Ship | \ndeprecation-and-migration | \nRemove old systems and migrate users safely | \n
| Ship | \ndocumentation-and-adrs | \nDocument the why, not just the what | \n
| Ship | \nobservability-and-instrumentation | \nStructured logs, RED metrics, traces, symptom-based alerts | \n
| Ship | \nshipping-and-launch | \nPre-launch checklist, monitoring, rollback plan | \n