Quantem
A junior developer built an MCP layer in one day from written acceptance criteria and it passed end-to-end testing. The agent asked far fewer product questions than usual.
Spec Kit with Claude Code
Spec Kit tells the agent how. Feature1 tells it why.
GitHub Spec Kit organises the spec, plan and tasks in the repository. Feature1 holds the product strategy, roadmap and acceptance criteria above it, and serves them to Claude Code over MCP. Use both.
Teams adopting Spec Kit with Claude Code, Codex or Cursor hit the same wall: the spec describes the feature well, and nothing says where the feature came from, which customer it serves, or what the product already does. That context lives one layer up, with the people who decide. Feature1 is that layer, and it is where your PM works while your developer works in Spec Kit.
The POC: your PM, your developer, read-only GitHub access, two features shipped spec-first in one to two weeks. Keep Spec Kit.
Sound familiar?
- Spec Kit is installed. The specs are good. Nobody outside the repository can see them.
- The PM writes in a document, the developer writes a spec, and the two drift by the second feature.
- Tasks sync to Jira or Linear, but the status flows one way and the reasons stay in a markdown file.
- The agent does what the spec says. The spec said the wrong thing.
- You want to know which spec a customer request touches before you write a new one.
- You want SDD across the team without every PM learning the CLI.
Where Spec Kit stops and Feature1 starts
Spec Kit, in the repository
- Constitution, spec, plan and tasks as files next to the code.
- Slash commands for Claude Code, Codex, Cursor and others.
- Community extensions for Jira, Linear, Azure DevOps and GitHub Projects sync, status views and review gates.
- Developer-owned: it lives where the developer works.
Feature1, above the repository
- Product strategy narrative, roadmap, features, stories and acceptance criteria, decided with the PM.
- A read-only picture of what the product can already do, kept current on merge.
- Acceptance criteria served to the agent over MCP, so the spec starts from a decision, not a prompt.
- Adoption and error signals attached to the feature after it ships.
The handoff is simple: the PM decides and writes criteria in Feature1; the developer runs Spec Kit and the agent reads the criteria over MCP while it plans. No sync, no second copy of the spec. We do not ship a Spec Kit extension today; if you want one, say so on the call.
A feature, end to end, with both
Decide in Feature1
The initiative comes from the roadmap. The PM plans it into a feature with user stories and acceptance criteria.
Specify with Spec Kit
The developer runs the specify step. Claude Code reads the feature and its criteria from Feature1 over MCP and writes the spec against them.
Plan and build
Plan and tasks as usual. The agent builds; the developer owns the pull request.
Verify against the criteria
Review checks the pull request against the acceptance criteria, not the prompt.
Reality updates
On merge, Feature1 rescans the repository and the capability picture moves. The roadmap is now about the product that exists.
Next decision
Adoption and error signals land on the feature. The PM picks the next initiative from evidence.
What it looked like in three teams
SatoriXR
Delivery got faster and the constraint moved to deciding. They hired a second product manager, and the roadmap in Feature1 became the queue developers pull from.
Jarshare
A Replit store with one unintegrated server file became a real product once its capabilities were written down and the next features were specified against them.
Paid proof of concept
Spec Kit plus Feature1, on two real features. $500.
A fixed-scope proof of concept with your own PM and developer. Your developer keeps Spec Kit and Claude Code; your PM gets the layer above it. Two features shipped in one to two weeks.
You give
- One product manager, or the founder who decides what gets built
- One developer with a coding agent (Claude Code, Codex or Cursor)
- GitHub access, read-only. Feature1 reads the repository and never writes to it
- An NDA, signed before anything is read
You get, in one to two weeks
- A one-page product strategy narrative
- A roadmap built on what the product can already do
- Two features shipped by your developer and their agent, from acceptance criteria held in Feature1 and read over MCP
- Your team working spec-first, without a course or a migration
$500Flat. Paid once the scope is agreed on the call.Book the POC callOr sign up and start on your own, free
Abdulrahman, founder of Feature1, runs the POC with your team. He does not write the code. Your developer does, with the agent, which is the point: the process has to work with the people you have.
Questions people ask
Is Feature1 a Spec Kit alternative?
No. Spec Kit organises the spec, plan and tasks inside the repository for the developer. Feature1 is the product layer above it, where the strategy, roadmap and acceptance criteria are decided and held. Teams use both: Feature1 for the why and the what, Spec Kit for the how.
How does Claude Code get the acceptance criteria from Feature1?
Over MCP. Feature1 exposes features, stories and acceptance criteria as MCP tools. Claude Code, Codex or Cursor reads them while it specifies and plans, so the spec starts from a decision rather than a prompt.
Does Feature1 sync with Spec Kit files or Jira?
Feature1 does not write spec files and does not replace the community sync extensions. The agent reads criteria from Feature1 over MCP at the moment it needs them, which avoids keeping a second copy of the spec. If you want a packaged Spec Kit extension, tell us on the POC call.
Which agents does this work with?
Claude Code, Codex, Cursor and any MCP-compatible agent, which covers every agent Spec Kit supports.
What is in the $500 POC?
One to two weeks with your PM and one developer: a product strategy narrative, a roadmap built on what the product already does, and two features shipped spec-first with Spec Kit and Claude Code, from acceptance criteria held in Feature1. NDA first, read-only GitHub access, your developer writes the code.
Is there a free way to start?
Yes. Sign up, no credit card, and write the first Product Strategy Narrative yourself. The POC is for teams that want it done with them, on their product, in a fixed window.
Keep Spec Kit. Add the reason.
Two features, your team, one to two weeks. Or sign up and write the first narrative yourself, free.