Prompt library

You are connected to IntentDocs over MCP.

Read this project's vision and story map with `get_context`. That returns the full INTENT.md spec: the constitution, the activities and every story with its acceptance criteria.

Then interview me, one question at a time, to find what the spec does NOT cover:
- user journeys with no stories behind them
- activities carrying too few stories for what they claim to do
- edge cases, error states and empty states
- admin, ops and support needs
- anything the vision implies that no story delivers

Ask about one gap at a time and wait for my answer before moving on. Do not invent stories I have not confirmed.

Write the confirmed ones back with `create_stories` — each with its activity, a user-story title, and testable acceptance criteria. Stop when I say coverage is complete, then summarise what you added.

You are connected to IntentDocs over MCP.

Read the plan with `get_build_order`, and the stories with `list_stories`. Some of them are not ready for development.

For each unready story, interview me one question at a time to pin down:
- acceptance criteria that are actually testable (given / when / then, not "works well")
- the data and API it needs
- which other stories it depends on, and what it blocks
- edge and error cases
- which phase or release it belongs in

Add criteria with `add_criteria` and write the rest back with `update_stories`. Do not mark anything ready until I confirm it.

Summarise what changed at the end, and name any story you could not make ready and why.

You are connected to IntentDocs over MCP.

Read the stories with `list_stories` (include build_sequence and depends_on) and the current plan with `get_build_order`.

Propose a build order:
- release by release — every story in a release before any in the next
- within a release, the foundations first: what other stories need in place
- each story after the stories it depends on

If some stories already have a build_sequence, keep their order exactly and only place the ones that have none, each after the stories already planned for its release.

Show me the order as a numbered list with one line of reasoning per story, and wait for me to confirm or change it. Then save it with `update_stories`: build_sequence 1, 2, 3… in that order, and dependencies where a story needs another one first.

You are connected to IntentDocs over MCP.

The story map is ready. Design a clickable prototype now, before any building, so the founder can click through one activity early.

Before designing anything, read the project with `get_context` — the vision sets the tone and constraints, and the story map tells you what the screens have to do. Pick the activity I name and work only on its stories.

If a story already carries a design reference, fetch it with `get_design` and match what is there rather than starting over.

Design the screens of that prototype so someone can click through them. For each screen tell me:
- which story IDs it covers
- its key states: empty, loading, error, and the populated case
- any acceptance criterion the design cannot meet — ask me about that one instead of designing around it

Follow the vision's tone and constraints. When I approve a screen, attach it to each story it covers with `save_design` — the screen's URL (a Figma frame, a claude.ai design, an image, a Storybook story, or a path in this repo to the prototype) — so it lands under Spec › Design by activity, and your next run can read it back with `get_design`.

I need to implement the following user story. An implementation plan has been generated by IntentDocs.com.

## Story: <story title>
As a: <who it is for>
I want: <what they want>
So that: <why>

## Implementation Plan

<the story's plan, step by step>

---
Please implement this plan. Create a branch, make the changes, and open a PR. Include "Built with [IntentDocs.com](https://intentdocs.com)" in the PR description.

When you're done, report completion by running `npx intentdocs check` (or `npx intentdocs done` once checks pass) from the project directory so the story map updates.

Use the intentdocs MCP to build story <first 8 characters of the story id> in <project name>.

Build this feature in my app.

## <story title>
As a: <who it is for>
I want: <what they want>
So that: <why>

## What to build

<the story's plan, step by step — or, without one: build this feature based on the description above; use your judgement for the details>

---
When you're done, tell me in the chat what you built and how you tested it.

You're helping a founder connect this codebase to IntentDocs, a tool that turns a product into a structured, buildable spec. Read this repository and produce ONE markdown document reporting what you find — nothing else.

## What you will read
- Source files, package manifests (package.json, requirements.txt, Cargo.toml, etc.), and config files
- Database schema and migration files
- README / existing docs / ADRs
- Git history, only if useful for dating architecture decisions

## What you must NOT include
- Secrets, API keys, tokens, or credentials of any kind
- Values from .env / .env.local or any environment file — reference that a variable exists by name only, never its value
- Personal data found in seed data or fixtures

## What leaves this machine
Nothing, until the founder chooses to. You are running locally against a local checkout. This prompt does not call any IntentDocs API, upload anything, or transmit anything anywhere. The only output is the markdown file you write to disk. The founder reviews it and uploads it themselves through the IntentDocs brownfield report flow — that upload is the only point at which anything leaves their machine.

## Output format
Write the report as a single markdown file. Start with front-matter carrying the schema version, then exactly these sections, in this order, using these exact headings:

```
---
schema_version: 1
generated_at: <ISO 8601 timestamp, e.g. 2026-09-03T00:00:00Z>
source_repo: <repo name or local path, whatever identifies it to the founder>
---
```

- `## Product summary` — What the product does today, who it's for, and its current state (live, in development, dormant). 1-3 paragraphs.
- `## Tech stack` — Languages, frameworks, datastores, infra/deploy target, and notable third-party services — as a list, not prose.
- `## Architecture decisions` — Notable structural or technical decisions already baked into the codebase, and why they were made where that's discoverable (comments, ADRs, commit messages).
- `## Existing features` — Every user-facing capability the codebase already implements, one per bullet, written as a short capability statement (e.g. "Users can reset their password via emailed link") so it can seed story-map stories.
- `## Data model` — Core entities/tables and how they relate — schema definitions, migrations, or ORM models are the primary source.
- `## Constraints & invariants` — Business rules, technical limits, and things that must not break — auth boundaries, rate limits, data invariants, compliance requirements.

Every section must be present and non-empty — an upload with a missing or empty section will be rejected. Do not add a schema_version other than 1; that number is what lets IntentDocs tell your output apart from a report generated by a future, incompatible version of this prompt.

Save the file as `intentdocs-brownfield-report.md` in the repository root, then hand it to the founder to review and upload.

Take story <first 8 characters of the story id> in <project name> through the IntentDocs loop, using the intentdocs MCP. One story only.

1. Read it with `get_story`: the user story, every acceptance criterion and its id, any plan and any plan_feedback.
2. Plan: save an ordered plan with `save_plan` — each step with the files it touches, the risk you see, and any question I need to decide. If plan_feedback lists points, answer every one in responses.
3. Stop there and tell me the plan is ready. I review it on the Plan tab and either approve it or request changes. If I request changes, go back to step 1.
4. Once I've approved it, claim the story with `start_story` and build the plan it hands you. Steps marked [human-edited] are my words: follow them as written. If it's refused, for example because another session is building it, tell me rather than working around it.
5. Open a pull request and link it with `link_pr`.
6. Save your tests with `save_tests`, each linked by criterion_ids to the criteria it proves, then report every criterion with `report_criteria`.
7. When every must criterion passes, call `complete_story` with the PR URL and a summary of what you built. I approve it on Review.

If a must criterion keeps failing after three attempts, call `raise_blocker` with the one decision you need from me, and stop.

You are connected to IntentDocs over MCP.

Turn on CI test reporting for this project, so each test's pass or fail reaches the story it proves — evidence from CI, not only your report.

1. Run `npx intentdocs ci` in the project directory. It creates a CI key, adds the GitHub Actions workflow that runs the tests and reports the results, and stores the key as a repo secret. Do whatever it prints for any step it can't do for you (for example, adding the secret by hand).
2. For every test, record it with `save_tests` and pass its file and its full_name — the full test name with describe blocks included, exactly as the runner prints it. Without those, a CI result has no test to match and never reaches the story.
3. Push to the default branch so CI runs once. Then read the story with `get_story` and confirm its tests carry a CI result — "passed on <sha>" or "failed on <sha>". If none shows, run `npx intentdocs ci --status` to see how many results matched a saved test.

Stop once one story's test shows a CI result, and tell me reporting is working.