| name | using-agent-skills |
| description | Discover and choose the right Kandev agent skill for a task. Use when starting a session, when the user asks which skill applies, when work spans multiple phases, or when existing skill references need to be mapped to this repo's actual skills. |
Using Agent Skills
Use this as the routing map for Kandev's local skills. Prefer the repo's existing skills over importing adjacent upstream names.
Skill Map
Task arrives
|
|-- Need to clarify intent first? ----------> /interview-me
|-- New feature or behavior-changing fix? --> /spec-driven-development
|-- Small self-contained bug regression? ---> /fix -> /tdd
|-- Running/debugging Kandev locally? ------> /debug
|-- Need focused context setup? ------------> /context-engineering
|-- Code change with test coverage? --------> /tdd
|-- Browser/E2E coverage? ------------------> /e2e
|-- Frontend/UI change? --------------------> /mobile-parity plus /e2e as needed
|-- Security-sensitive change? -------------> security-auditor subagent plus /code-review
|-- Test strategy or coverage gaps? --------> test-engineer subagent plus /tdd or /e2e
|-- Add debug logs? ------------------------> /debug
|-- Add Jira/Linear-style integration? -----> /add-integration
|-- Verify implemented behavior? -----------> /qa then /verify
|-- Simplify recent code? ------------------> /simplify
|-- Review code? ---------------------------> /code-review
|-- Improve skills/agents/commands? --------> /harness-improvement
|-- Record decisions/spec changes? ---------> /record
|-- Commit/push/PR? ------------------------> /commit -> /push or /pr
`-- Release/versioning? --------------------> /release
Operating Rules
- Check for an applicable local skill before starting non-trivial work.
- If multiple skills apply, use the smallest set that covers the task and state the order.
- Skills are workflows, not suggestions. Follow required verification and stop conditions.
- Surface assumptions before building on them. If requirements, specs, and code disagree, stop and name the conflict.
- Keep scope tight. Do not refactor adjacent systems or add "useful" features that are not in the request/spec.
- Verify with evidence: targeted tests, full
/verify when needed, browser/E2E proof for user-facing flows.
Upstream Name Mapping
When adapting external skill references, map them to Kandev skills:
test-driven-development -> /tddspec-driven-development -> /spec-driven-developmentplanning-and-task-breakdown -> /planincremental-implementation -> /spec-driven-development or /tdddebugging-and-error-recovery -> /debug or /fixbrowser-testing-with-devtools -> /playwright-cli and /e2ecode-review-and-quality -> /code-reviewsecurity-auditor -> security-auditor subagenttest-engineer -> test-engineer subagent, /tdd, or /e2ecode-simplification -> /simplifygit-workflow-and-versioning -> /commit, /push, /prdocumentation-and-adrs -> /recordharness-improvement -> /harness-improvementobservability-and-instrumentation -> /debugshipping-and-launch -> /pr, /push, /releasefrontend-ui-engineering -> /mobile-parity, /e2e, and frontend guidance in apps/web/AGENTS.mdapi-and-interface-design -> scoped backend/frontend AGENTS.md plus /spec for public contractssource-driven-development -> use official docs or primary sources, then follow the relevant implementation skilldoubt-driven-development -> use /code-review, /qa, or a direct design challenge inside /spec-driven-development
Do not reference upstream skills that are not installed unless you are explicitly importing or adapting them.
