Living documentation for feature-driven product engineering
Keep humans and coding agents in the loop with always up-to-date context of your app
Install Manifest
brew install manifestdocs/tap/manifest Why Manifest? Because yesterday's workflows don't work for AI
Specs die on day one
AI makes it easy to iterate... away from your spec which is out of date after a few commits.
Change happens too fast
Agents are quick, managing them via Jira or Github Issues is the path to madness.
Agents get confused
Without past context or a roadmap for the future, agents sling the wrong thing.
Manifest is a better way to define and track coding agents' work
▣ MyApp ├── ▪ Auth │ ├── ● OAuth Login │ └── ● Password Reset ├── ▪ Store │ ├── ○ Shopping Cart │ ├── ⊘ Checkout │ └── ◇ Order History ├── ◇ Analytics ├── ◇ Email Alerts ├── ◇ User Profile └── ◇ Notifications
Features, not tickets
Features describe what your system does (or will do), living capabilities that evolve, not work items to close and forget.
● OAuth Login · 4a2f1b3 2026-01-15 · claude Implemented Google OAuth with session-based auth. - Skipped Apple login: not in scope for v0.2 - Chose sessions over JWT; simpler for SSR - Refresh token rotation deferred to v0.3 ● Password Reset · b3f7a92 2026-01-14 · claude Used email + time-limited token, not SMS.
A record of why, not just what
Git tells you what changed. Manifest captures why: the decisions made, constraints, and tradeoffs considered along the way.
> What's next? ◇ Checkout Flow Version 0.2.0 · Priority 1 As a user, I can complete purchases via Stripe. AC: - Cart totals display correctly - Stripe payment succeeds - Confirmation email sent
Agents always know what's next
Ask any connected agent "what's next?" and it picks up the highest-priority feature with full context.
Prove it! Make agents show their work
◇ Checkout Flow Version 0.2.0 · Priority 1 AC: - Cart totals display correctly - Stripe payment succeeds - Confirmation email sent → Extract test requirements: ✓ cart_displays_correct_totals ✓ stripe_payment_succeeds ✓ sends_confirmation_email
Specs become tests
Agents extract testable requirements directly from the feature spec. Acceptance criteria become test cases.
prove_feature ← red tests/checkout_spec.rs ✗ cart_displays_correct_totals ✗ stripe_payment_succeeds ✗ sends_confirmation_email Verification recorded - exit code 1 prove_feature ← green tests/checkout_spec.rs ✓ cart_displays_correct_totals ✓ stripe_payment_succeeds ✓ sends_confirmation_email Verification recorded - exit code 0
Red, green, done
Write failing tests, implement until they pass, prove again. Manifest records each run along the way.
complete_feature("Checkout Flow")
Cannot complete feature: no proof
recorded. Call prove_feature with
your test results first.
prove_feature ← 3 passed, exit 0
complete_feature("Checkout Flow")
Completed 'Checkout Flow'
- recorded 3 commits
Verification:
✓ 3 passed No proof, no ship
The server rejects completion without a passing proof. No completion without a passing test suite.
Step back from the terminal: Edit, Plan, and review Activity in the Web UI
Edit
Browse your feature tree and write specs in a Markdown editor. Feature state, acceptance criteria, and notes stay current as you build.
Plan
Map features to release versions in a matrix view. See at a glance what ships next, what's planned, and what's still in the backlog.
Activity
A timeline of completed work. See what agents built, which commits landed, and how each feature was implemented.