Skills reference
FeatureKit 0.14.1 ships 30 skills. Each is a plain SKILL.md file that your coding agent reads; there is no runtime.
- You run it means the skill only starts when you invoke it, for example
/to-prd. - You or the agent means the agent may also load it when the work calls for it. Skills that write still wait for your approval.
Start and route
Section titled “Start and route”setup-featurekit
Section titled “setup-featurekit”Initialize or refresh a target product repo for FeatureKit by persisting session bootstrap and automatic orchestration in its agent instructions and recording repo conventions under docs/agents. Use when the user asks to set up or refresh FeatureKit, after an upgrade, or when repo conventions change; writes only after approval.
using-featurekit
Section titled “using-featurekit”Route a FeatureKit request to the smallest workflow while preserving planning, interview, security, and implementation gates. Use at session start or after compaction.
ask-featurekit
Section titled “ask-featurekit”Start clarification for a raw feature or route another product or engineering request to the right FeatureKit flow. Use explicitly when the user is unsure what to run or has a new idea, bug, PRD, slice, implementation, review, prototype, or handoff need. User-invoked router; do not write production code inside this skill.
Clarify and decide
Section titled “Clarify and decide”grill-with-docs
Section titled “grill-with-docs”Run the FeatureKit design-tree interview with repo facts and durable docs. Use explicitly before a PRD or implementation when scope or success criteria need clarification.
grilling
Section titled “grilling”Reusable design-tree interview for turning a fuzzy idea, plan, or design into clear decisions. Use when the model needs dependency-aware questions before planning, PRD creation, or implementation.
domain-modeling
Section titled “domain-modeling”Maintain and sharpen product domain language for a repo. Use when work introduces new business terms, ambiguous concepts, product rules, or architecture decisions that should be captured in CONTEXT.md or ADRs.
prototype
Section titled “prototype”Build or plan a disposable prototype to answer a concrete product, UX, architecture, state, performance, or integration uncertainty before committing to implementation. Use explicitly when discussion cannot settle a decision. User-invoked; prototype output is not production code.
record-adr
Section titled “record-adr”Record or update architectural decision records (ADRs) for durable technical decisions in a product repo. Use explicitly when a feature, PRD, prototype, design review, implementation, or migration chooses or changes architecture that future work must follow.
adr-guidance
Section titled “adr-guidance”Read and apply architectural decision records (ADRs) as governing project context. Use when planning, designing, implementing, reviewing, diagnosing, or handing off work that may touch architecture, data, integrations, deployment, public APIs, or durable technical conventions.
to-prd
Section titled “to-prd”Turn a clarified product idea, plan, or conversation into a concise PRD for a full-stack product change. Use explicitly after grilling or when a durable spec is needed before implementation. Writes or drafts a PRD in the repo’s configured workflow location.
to-slices
Section titled “to-slices”Split a PRD or approved plan into small vertical implementation slices that can be built one at a time. Use explicitly after a PRD exists and the work is too large for one implementation session or PR.
implement
Section titled “implement”Implement one approved FeatureKit plan or slice using repository conventions, tests, and runtime evidence. Use explicitly after final approval and implementation intent.
execute-slices
Section titled “execute-slices”Execute multiple approved FeatureKit implementation slices from a written PRD or plan. Use explicitly when ordered slices already exist and the user wants autonomous batch execution with verification, review checkpoints, optional subagents, and no branch, commit, push, or PR actions.
orchestrate-work
Section titled “orchestrate-work”Choose direct work, the current agent, or one bounded worker by capability, risk, and evidence. Use inside an active FeatureKit workflow when substantive work could be routed or has failed.
Use a red-green-refactor loop for business logic, data transformations, services, API behavior, bug fixes, and other testable product behavior. Use during implementation whenever meaningful behavior can be specified with tests.
diagnosing-bugs
Section titled “diagnosing-bugs”Diagnose and fix hard, flaky, unclear, or production-impacting bugs. Use when the user reports broken behavior, cannot reproduce an issue, sees intermittent failures, or needs a root-cause-driven regression fix.
codebase-design
Section titled “codebase-design”Improve or evaluate codebase architecture with a focus on clear boundaries, deep modules, stable interfaces, and maintainable full-stack product design. Use when planning architecture, reviewing a design, or cleaning up codebase complexity.
Prove and review
Section titled “Prove and review”validate-feature
Section titled “validate-feature”Map feature acceptance criteria to actual test and runtime evidence, including platform and hardware gaps. Use when planning verification or deciding whether implementation, a bug fix, or a prototype is proven; use verify-tests separately for test quality.
verify-tests
Section titled “verify-tests”Verify that generated or changed tests actually protect the intended behavior. Use when tests look weak, assertion-light, mock-only, snapshot-heavy, implementation-detail-focused, high-risk, generated by an agent, or when the user asks for mutation testing, Stryker, or proof that a test would fail for the right reason.
review-change
Section titled “review-change”Review a code change, diff, PR, or implementation against the PRD, slice, product context, ADRs, and repo conventions. Use before human review or whenever code needs risk-focused review.
Security
Section titled “Security”secure-design
Section titled “secure-design”Apply lightweight secure design and threat modeling during planning, PRD creation, architecture work, API design, deployment planning, or security-sensitive feature work. Use when work touches trust boundaries, authentication, authorization, sensitive data, external inputs, third-party integrations, generated code, deployment/runtime behavior, or durable security posture.
secure-code
Section titled “secure-code”Apply secure implementation discipline while writing or reviewing generated code. Use during implementation, bug fixes, refactors, or reviews when code handles untrusted input, auth/authz, sensitive data, secrets, cryptography, storage, files, network calls, dependencies, errors, logging, or any security-sensitive behavior.
secure-api
Section titled “secure-api”Apply API security guardrails during API planning, implementation, integration, testing, or review. Use when work adds or changes REST, GraphQL, RPC, webhook, event, internal service, third-party API, or public contract behavior.
secure-deploy
Section titled “secure-deploy”Apply deployment, runtime, CI/CD, secrets, and supply-chain hardening guidance during deployment planning, infrastructure changes, release workflows, production configuration, migration planning, or review. Use when work touches environments, hosting, pipelines, secrets, IAM, containers, artifacts, observability, rollback, or production operations.
security-review
Section titled “security-review”Perform a focused security review of a PRD, plan, slice, diff, pull request, API change, deployment plan, generated code, or suspicious implementation. Use explicitly when the user asks for security review, hardening review, OWASP review, threat review, secure code review, API security review, deployment security review, or when review-change finds material security risk.
Continue
Section titled “Continue”handoff
Section titled “handoff”Preserve compact continuation state or create a user-selected fresh implementation task without replaying the conversation. Use for pauses, long context, or substantial approved work.
Optional tooling
Section titled “Optional tooling”git-guardrails-claude-code
Section titled “git-guardrails-claude-code”Set up Claude Code hooks that block dangerous git commands such as push, reset –hard, clean, destructive checkout/restore, and branch deletion. Use when a repo needs Claude Code-specific safety guardrails around git operations.
setup-pre-commit
Section titled “setup-pre-commit”Set up or improve pre-commit hooks for a product repo using its package manager and verification commands. Use when the user wants commit-time formatting, linting, typechecking, tests, Husky, lint-staged, or equivalent guardrails.
scaffold-exercises
Section titled “scaffold-exercises”Scaffold course, tutorial, workshop, or exercise directories with problem, solution, and explainer variants. Use when a repo needs structured learning content or exercise stubs.
migrate-to-shoehorn
Section titled “migrate-to-shoehorn”Migrate TypeScript test fixtures from unsafe as assertions to @total-typescript/shoehorn helpers. Use when tests need partial typed data, intentionally invalid typed input, or a cleanup of as unknown as in test files.