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
|
|-- Standalone interview or stress test? --> /interview-me
|-- Feature/fix planning assumptions? -----> /interview-me (question only material unknowns)
|-- Large initiative with dependent unknowns? -> /interview-me decision-mapping reference
|-- Create/change/fix/publish Kandev plugin? -> /create-kandev-plugin plus /fix or /tdd as needed
|-- New feature or behavior-changing fix? --> /spec-driven-development
|-- Bug regression? ------------------------> /fix -> requirement/design check -> fix plan/work orders -> /tdd
|-- Running/debugging Kandev locally? ------> /debug
|-- Need focused context setup? ------------> /context-engineering
|-- Code change with test coverage? --------> /tdd
|-- Browser/E2E coverage? ------------------> /e2e
|-- Seed isolated product demo data? -------> /product-demo-seeding
|-- Record landing/product media? ----------> /product-demo-seeding -> /product-video-capture (always in that order)
|-- Frontend/UI change? --------------------> /mobile-parity plus /e2e as needed
|-- High-impact security boundary/concern? -> pause for a strong-model review per /planner-orchestration
|-- Test strategy or coverage gaps? --------> /tdd or /e2e in the current conversation
|-- Add debug logs? ------------------------> /debug
|-- Add Jira/Linear-style integration? -----> /add-integration
|-- Add/roll out/promote/graduate/remove a runtime feature flag or release toggle? -> /runtime-feature-flags
|-- Validate implementation? ----------------> /tdd plus exact task-defined tests/E2E
|-- Need local QA/review/simplification? ----> only on explicit user request or PR finding
|-- Improve skills/agents/commands? --------> /harness-improvement
|-- Record decisions/specification changes? -> /record
|-- Public docs impact? --------------------> /docs-maintainer -> /diagram-design when a visual helps
|-- Commit/push/PR? ------------------------> /commit -> /push or /pr
`-- Release/versioning? --------------------> /release
When runtime-flag work also matches new behavior or validation, compose
/runtime-feature-flags with /spec-driven-development and /tdd as needed.
Use the smallest covering set and state the order.
Operating Rules
- Work in the user-started primary conversation; do not create a worker session.
- 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 task-defined tests and browser/E2E proof for
user-facing flows. The two PR AI reviewers provide semantic review after PR
creation; do not add broad local gates by default.
- Keep all repository work in the primary conversation. Use durable
requirements, system designs, plans, and work orders as the user-controlled
handoff when switching models.
- Product media always invokes
/product-demo-seeding before /product-video-capture, even when a prior seed or capture exists. Re-prove current origin/main, disposable runtime/data, and teardown; never capture a developer instance or database.
- In Kandev repos, local
/commit, /push, and /pr workflows, the repository
PR template, and .github/AGENTS.md are authoritative for publication.
External github:yeet is transport fallback only and must still use the
local template and checklist; never replace them with a hand-composed body.
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 -> user-requested strong-model design review under
/planner-orchestrationtest-engineer -> /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 -> direct design challenge inside
/spec-driven-development; use /code-review or /qa only on explicit
user request or PR/CI remediation
Do not reference upstream skills that are not installed unless you are explicitly importing or adapting them.
1---2name: using-agent-skills3description: 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.4---56# Using Agent Skills78Use this as the routing map for Kandev's local skills. Prefer the repo's existing skills over importing adjacent upstream names.910## Skill Map1112```text13Task arrives14|15|-- Standalone interview or stress test? --> /interview-me16|-- Feature/fix planning assumptions? -----> /interview-me (question only material unknowns)17|-- Large initiative with dependent unknowns? -> /interview-me decision-mapping reference18|-- Create/change/fix/publish Kandev plugin? -> /create-kandev-plugin plus /fix or /tdd as needed19|-- New feature or behavior-changing fix? --> /spec-driven-development20|-- Bug regression? ------------------------> /fix -> requirement/design check -> fix plan/work orders -> /tdd21|-- Running/debugging Kandev locally? ------> /debug22|-- Need focused context setup? ------------> /context-engineering23|-- Code change with test coverage? --------> /tdd24|-- Browser/E2E coverage? ------------------> /e2e25|-- Seed isolated product demo data? -------> /product-demo-seeding26|-- Record landing/product media? ----------> /product-demo-seeding -> /product-video-capture (always in that order)27|-- Frontend/UI change? --------------------> /mobile-parity plus /e2e as needed28|-- High-impact security boundary/concern? -> pause for a strong-model review per /planner-orchestration29|-- Test strategy or coverage gaps? --------> /tdd or /e2e in the current conversation30|-- Add debug logs? ------------------------> /debug31|-- Add Jira/Linear-style integration? -----> /add-integration32|-- Add/roll out/promote/graduate/remove a runtime feature flag or release toggle? -> /runtime-feature-flags33|-- Validate implementation? ----------------> /tdd plus exact task-defined tests/E2E34|-- Need local QA/review/simplification? ----> only on explicit user request or PR finding35|-- Improve skills/agents/commands? --------> /harness-improvement36|-- Record decisions/specification changes? -> /record37|-- Public docs impact? --------------------> /docs-maintainer -> /diagram-design when a visual helps38|-- Commit/push/PR? ------------------------> /commit -> /push or /pr39`-- Release/versioning? --------------------> /release40```4142When runtime-flag work also matches new behavior or validation, compose43`/runtime-feature-flags` with `/spec-driven-development` and `/tdd` as needed.44Use the smallest covering set and state the order.4546## Operating Rules47481. Work in the user-started primary conversation; do not create a worker session.492. Check for an applicable local skill before starting non-trivial work.503. If multiple skills apply, use the smallest set that covers the task and state the order.514. Skills are workflows, not suggestions. Follow required verification and stop conditions.525. Surface assumptions before building on them. If requirements, specs, and code disagree, stop and name the conflict.536. Keep scope tight. Do not refactor adjacent systems or add "useful" features that are not in the request/spec.547. Verify with evidence: targeted task-defined tests and browser/E2E proof for55 user-facing flows. The two PR AI reviewers provide semantic review after PR56 creation; do not add broad local gates by default.578. Keep all repository work in the primary conversation. Use durable58 requirements, system designs, plans, and work orders as the user-controlled59 handoff when switching models.609. Product media always invokes `/product-demo-seeding` before `/product-video-capture`, even when a prior seed or capture exists. Re-prove current `origin/main`, disposable runtime/data, and teardown; never capture a developer instance or database.6110. In Kandev repos, local `/commit`, `/push`, and `/pr` workflows, the repository62 PR template, and `.github/AGENTS.md` are authoritative for publication.63 External `github:yeet` is transport fallback only and must still use the64 local template and checklist; never replace them with a hand-composed body.6566## Upstream Name Mapping6768When adapting external skill references, map them to Kandev skills:6970- `test-driven-development` -> `/tdd`71- `spec-driven-development` -> `/spec-driven-development`72- `planning-and-task-breakdown` -> `/plan`73- `incremental-implementation` -> `/spec-driven-development` or `/tdd`74- `debugging-and-error-recovery` -> `/debug` or `/fix`75- `browser-testing-with-devtools` -> `/playwright-cli` and `/e2e`76- `code-review-and-quality` -> `/code-review`77- `security-auditor` -> user-requested strong-model design review under78 `/planner-orchestration`79- `test-engineer` -> `/tdd` or `/e2e`80- `code-simplification` -> `/simplify`81- `git-workflow-and-versioning` -> `/commit`, `/push`, `/pr`82- `documentation-and-adrs` -> `/record`83- `harness-improvement` -> `/harness-improvement`84- `observability-and-instrumentation` -> `/debug`85- `shipping-and-launch` -> `/pr`, `/push`, `/release`86- `frontend-ui-engineering` -> `/mobile-parity`, `/e2e`, and frontend guidance in `apps/web/AGENTS.md`87- `api-and-interface-design` -> scoped backend/frontend `AGENTS.md` plus `/spec` for public contracts88- `source-driven-development` -> use official docs or primary sources, then follow the relevant implementation skill89- `doubt-driven-development` -> direct design challenge inside90 `/spec-driven-development`; use `/code-review` or `/qa` only on explicit91 user request or PR/CI remediation9293Do not reference upstream skills that are not installed unless you are explicitly importing or adapting them.
kdlbs