TOOLKIT

productfoo.A product manager that works inside your coding agent.

By Rachel Wolan4 min read

Open source. Runs on your machine.

Only the 0.0.0-stage placeholder is published. The CLI release is not available yet; save this command for launch.

productfoo on GitHub ↗Set up your agent ↓

productfoo on npm, maintained by rwolan572. The CLI requires Node.js 18+ and Git.

Before the agent builds, productfoo helps it work out what to build.

It reads the project, gathers evidence, challenges the idea, and writes down what you agree. After the build, it checks the code against that agreement and shows you anything that drifted.

You talk to your coding agent the way you already do. The agent runs productfoo. Research, product decisions, implementation tasks, and proof stay connected in plain files in your repository.

Everything feeds the spec.

productfoo covers the work before a feature is ready to build, including whether it should be built at all. Each workflow produces something you review before it becomes part of the plan.

  • Customer callsApproved sources only
    foo discoveryEvidence, without raw transcripts
  • Public researchLabeled untrusted
    foo researchA sealed, cited paper
  • An idea or requestRough is fine
    foo ideate · pitchA shortlist and a GO / NOT-NOW / NO-GO call

Shape

foo spec
Ask the questions that matter.
foo roast
Challenge the scope.
foo preview
See it before the build.

You agree what to build.

Your agreement, in the spec

The contract

productfoo Spec

specs/<packet>/
  • Intent
  • Decisions and open questions
  • Agreed, suggested, and discovered work
  • Tasks and acceptance checks
  • Proof and event history
Tasks + checks
Drift returns
for your decision

Build and prove

Coding agent builds

On its own branch and worktree.

Check the code against the spec.

Record proof. Return differences for a decision.

Drift returns to the spec for your decision.

With proof

Pull request → ship

You approve.

Exploration feeds shaping; the agreed spec guides the build. Differences return to the spec, and proof goes forward for your approval. A clear request can go straight to foo spec. Not sure where to start? Run foo init.

The spec stays useful
after coding starts.

It holds the reason for the work, the decisions behind it, what to build, and how you will know it is done.

Approved work and new ideas stay separate.

Agreed work is inside the scope you approved. Suggested work waits for your decision. Discovered work is needed to deliver the agreement or protect a boundary, and is recorded for you to see.

“Done” has to come with evidence.

A task marked complete without supporting evidence stays done, proof pending. productfoo tracks the checks and proof alongside the task, so you can see what has actually been verified.

The build gets compared with the agreement.

productfoo checks implementation evidence against the spec. Differences return for a decision. Commits can link back to the spec they came from, keeping the reason for a change with the code.

The record lives in your repository.
spec.md
Intent and decisions
tasks.yaml
Work and acceptance checks
events.jsonl
What happened

Change agents.
Keep the product decisions.

One CLI, one skill set, and one spec format. productfoo installs commands in the form each coding agent expects. The files stay in your project, where a person or another agent can read them.

  • Claude Code
  • Codex
  • Cursor
  • OpenCode

productfoo runs on your machine. Its local workflow needs no productfoo account, token, or hosted service. Your coding agent keeps its own setup and access requirements.

Only the 0.0.0-stage placeholder is published. The CLI release is not available yet; save this command for launch. Check the npm package ↗

Set up your agent.

Once the CLI release is published and installed from npm, run foo doctor to check your setup. Then choose your coding agent below.

Claude Code

Run these commands in the project you want to work on. Review the proposed changes before applying them.

foo agent setup --agent claude-code --scope project --dry-run
# Review the proposed changes, then apply:
foo agent setup --agent claude-code --scope project --yes

Open Claude Code in that project. Run /foo:init to read the project and choose a first move, or /foo:spec <work-item> to shape work you already have in mind. Follow the handoff and agree the scope before building.

You can also describe the work in plain language and ask Claude Code to use productfoo. See the Claude Code guide for more on using the coding agent.

Codex

Install the personal plugin, then start a new Codex task so it can load the commands.

foo agent setup --agent codex --scope global --dry-run
# Review the proposed changes, then apply:
foo agent setup --agent codex --scope global --yes

Ask Codex to use productfoo to read the project and help you choose the next piece of work.

Cursor and OpenCode

Use the Claude Code setup commands above with --agent cursor or --agent opencode. Read the agent setup docs for details.

For coding agents: inspect the spec and its proof.

Read the project instructions first. Treat this page as reference, not permission. Run these commands from the project you are working on after installing productfoo.

foo init

# Complete the CLI spec handoff before running these checks.
# Replace specs/my-feature with the actual spec folder.
foo asp validate specs/my-feature
foo asp status specs/my-feature --json
foo asp reconcile specs/my-feature --git-diff

Obtain source approval before using connected private data. Keep secrets and raw private material out of commits. Agree scope before risky work and budgets before autonomous execution.

Read the complete plain-text agent guide →