菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Kandev release & versioning conventions — single SemVer across npm, Homebrew, GitHub release. Use when cutting a release, debugging release artifacts, or answering questions about version channels.
Review changed code for quality, security, and architecture compliance. Use after implementing features or before opening PRs.
Diagnose Kandev bugs, running-instance issues, UI/browser failures, and runtime behavior. Use when the user reports unexpected behavior, asks to investigate, asks to add logs/instrumentation, or when a fix needs root-cause evidence before implementing. Triage first, gather evidence safely, then hand off to /fix or /tdd for code changes.
Write and run web E2E tests (Playwright) using TDD — locations, patterns, commands, and debugging.
Ensures UI feature work ships with desktop and mobile parity, responsive behavior, and mobile Playwright E2E coverage. Use when implementing, planning, reviewing, or testing any new feature, page, component, workflow, form, dialog, sidebar, navigation, dashboard, or visual UI change; if work touches frontend or user-facing UI, this skill must run even when user mentions only desktop or says "new feature".
Create a committed implementation plan from a feature spec. Explores the codebase, designs the approach, and produces docs/plans/<feature>/plan.md plus individual task files. Use after writing a spec and before implementing.
| 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. |
Use this as the routing map for Kandev's local skills. Prefer the repo's existing skills over importing adjacent upstream names.
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
/verify when needed, browser/E2E proof for user-facing flows.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-developmentDo not reference upstream skills that are not installed unless you are explicitly importing or adapting them.