What is FeatureKit?

FeatureKit is a portable skill harness for building real full-stack products with AI coding agents.

It is not a framework, app scaffold, or custom runtime. It is a set of small Markdown skills that help you work with agents in a disciplined way: clarify the idea, capture security requirements, write the spec, split the work, implement slices, verify them, review them, and hand off cleanly.

What FeatureKit Solves

Agents move fast, but speed is dangerous when the goal is fuzzy. The common failures are predictable:

• the agent builds the wrong thing,
• the context gets too messy,
• PRs become too large,
• the implementation drifts from the plan,
• nobody understands the generated diff,
• product language changes every session.

FeatureKit counters this with repeatable workflows and durable project context.

Mental Model

FeatureKit has three layers:

1. Project context: the target repo’s AGENTS.md, glossary (CONTEXT.md by default), ADRs, and docs/agents/ files. Setup records where these live, so skills follow the repo’s own layout.
2. Skills: small workflows under skills/ that an agent can follow.
3. Guide: these docs, which teach you when and how to run each skill.

The target product repo owns stack choices. FeatureKit owns the agent workflow.

The Rule

No production code starts until there is a written plan that has been shown to the user and approved.

The one optional exception is set per repo at setup: a small fix you ask for directly may skip the plan, within limits the repo’s Agent skills block records. Without that line the rule applies to every change.

For small work, the plan can be a short note. For larger work, use a PRD and implementation slices. The feature interview asks self-contained questions with plain-language context and consequences, then ends by showing the complete plan and asking a clear final approval question. Earlier answers and accepted recommendations are not approval. After an implementation-ready artifact is approved, focused work continues in the current task without another question. Only substantial work offers a fresh implementation task on the same checkout and branch, the current task, or stopping after planning. If reality changes during implementation, update and approve the plan before continuing.

Accepted ADRs are also part of the plan. If a change needs to violate or replace an accepted ADR, record the new architectural decision before implementation continues.

Every new session should also follow the Agent Operating Principles before coding, refactoring, or verification work: think before coding, keep the solution simple, and make surgical changes only.

Skill Types

User-invoked skills are commands you intentionally run:

• ask-featurekit
• setup-featurekit
• record-adr
• grill-with-docs
• to-prd
• to-slices
• implement
• execute-slices
• security-review
• prototype
• handoff

The agent can also load setup-featurekit, implement and execute-slices itself when routing reaches them; each still waits for your approval before it writes.

Model-invoked skills are reusable disciplines the agent may use when the task fits:

• grilling
• using-featurekit
• adr-guidance
• domain-modeling
• secure-design
• secure-code
• secure-api
• secure-deploy
• tdd
• verify-tests
• diagnosing-bugs
• review-change
• codebase-design
• orchestrate-work
• validate-feature

using-featurekit is the lightweight model-invoked bootstrap. Put it in session-start instructions, use it after context compaction, or let capable agents invoke it automatically. A raw feature request begins the design-tree interview without making you repeat the idea. /grill-with-docs starts the same interview explicitly, and /ask-featurekit begins it for a raw feature or routes other work.

tdd is intentionally model-invoked. Implementation and bug-fix workflows should be able to reach for it automatically whenever behavior can be protected with tests.

The security suite is model-invoked except for security-review. Planning, implementation, and review workflows should reach for secure-design, secure-code, secure-api, and secure-deploy when work touches auth, authorization, sensitive data, APIs, deployment, integrations, generated code, or untrusted input.

verify-tests is also model-invoked. Agents should use it when generated or changed tests look weak, high-risk, or explicitly need mutation testing. It does not run expensive mutation tests by default.

orchestrate-work routes bounded work to a direct tool, native worker, or authenticated CLI when that is useful. validate-feature maps acceptance criteria to runtime evidence; a build or test result alone does not prove every feature criterion. See the Orchestration guide.

Optional misc tooling skills:

• git-guardrails-claude-code
• setup-pre-commit
• scaffold-exercises
• migrate-to-shoehorn

Where To Start

For a fast path from a prepared product repo to the first implemented feature slice, see the Quick Start.

If this is a new repo, install FeatureKit and run:

/setup-featurekit

If FeatureKit is already set up, put using-featurekit in your session-start instructions or let the agent invoke it automatically. A raw feature prompt should begin interviewing immediately. You can also start explicitly with:

/grill-with-docs

If you do not know what to run, ask:

/ask-featurekit