ChatPRD

View saved version →

---
name: check-prd-alignment
description: Compare code changes in the current repository against a ChatPRD PRD to find gaps, deviations, and opportunities. Use in a coding workspace before opening a PR, after finishing a feature, or to verify requirement coverage.
---

# Check PRD alignment

## Trigger

User wants to verify their implementation matches the product requirements and find opportunities to better achieve the PRD's goals.

## Workflow

1. Identify what changed — run `git diff` against the base branch to see all modifications.
2. Find the relevant PRD:
   - Ask the user which PRD to check against.
   - Search ChatPRD documents using `search_documents` with keywords from the branch or commit messages.
   - Also check the local `prd/` directory for saved specs.
3. Fetch the full PRD using `get_document`.
4. Extract all requirements, acceptance criteria, and — critically — the user and business goals the PRD is trying to achieve.
5. For each requirement, assess:
   - **Covered**: implemented and matching the spec
   - **Partial**: started but incomplete or missing edge cases
   - **Missing**: not addressed in the current changes
   - **Deviated**: implemented differently than specified
6. Review the implementation through the lens of the PRD's stated goals. For each goal, identify **Opportunity** items — places where the UX or implementation could be improved to better achieve the goal. Examples:
   - A flow that technically meets the spec but adds unnecessary friction
   - An edge case where a better error message or fallback would improve the experience
   - A place where the implementation could be more delightful or intuitive than what was specced
   - A data model or API design choice that would better support the stated business goal
7. Produce a coverage report with:
   - Requirement-by-requirement status
   - Specific code references for covered items
   - Actionable notes for gaps and deviations
   - **Opportunity** items tied back to specific PRD goals

## Guardrails

- Be specific — cite file paths and line ranges, not vague summaries.
- Distinguish between intentional trade-offs and accidental omissions.
- Don't flag requirements that are explicitly marked as out-of-scope or future work in the PRD.
- Keep **Opportunity** items grounded and actionable — tie each one to a specific PRD goal and explain the concrete improvement.

## Output

- Alignment report (covered / partial / missing / deviated)
- **Opportunity** items with goal references and suggested improvements
- Specific gaps with suggested next steps
- Summary of overall coverage

View saved version →

---
name: doc-to-artifact
description: Turn a PRD, brief, or spec into a single self-contained interactive HTML page — the document's narrative with diagrams (user flows, system sequences, states, timelines) and clickable UI prototypes embedded inline where the doc describes them. Works on pasted or shared docs without a ChatPRD account, or on ChatPRD documents when connected. Use when the user wants to visualize, present, prototype, or share a doc as an interactive page or HTML artifact.
---

# Doc to interactive artifact

## Workflow

1. Get the document:
   - If the user pasted it or shared a file, use that. No ChatPRD account is needed.
   - For a ChatPRD document, find it with `search_documents` or `list_documents`, then fetch the full content with `get_document`.
2. Read the whole document and plan the page before writing code. For each section, decide whether it stays as prose or gets an inline visual:
   - **User flow or journey** → flowchart.
   - **System interactions, APIs, integrations** → sequence diagram.
   - **Statuses or lifecycle** (for example draft → review → approved) → state diagram.
   - **Data model** → entity-relationship diagram.
   - **Milestones and sequencing** → timeline or Gantt chart.
   - **Screens, UX, edge cases** → a clickable prototype of the key screen, with its states (empty, loading, error, success) switchable.
   - **Requirements and user stories** → a table the reader can filter by priority or area.
   - **Success metrics** → metric cards showing the metric, baseline, and target.
   - **Open questions** → a checklist.
   Only add a visual when the document gives enough detail to support it. Two or three strong visuals beat ten thin ones.
3. Build one HTML file following the build rules below.
4. Deliver it:
   - If you can write files (code workspace, file tools), save it as `<title-in-kebab-case>.html` next to the document, or in `prd/` in a code repository, and tell the user the path.
   - Otherwise, return the complete file in a single `html` code block so the user can save and open it.
5. Briefly list which sections got diagrams or prototypes, and any assumptions you made.

## Build rules

- **One self-contained file**: inline all CSS and JavaScript. The only allowed external resource is Mermaid for diagrams:
  ```html
  <script type="module">
    import mermaid from "https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs";
    mermaid.initialize({ startOnLoad: true, theme: matchMedia("(prefers-color-scheme: dark)").matches ? "dark" : "default" });
  </script>
  ```
  Put each diagram in `<pre class="mermaid">`. Keep Mermaid syntax simple and quote labels that contain punctuation (`A["Sign in (SSO)"]`). If Mermaid fails to load, the diagram source should still read sensibly.
- **Narrative first**: keep the document's section order and wording. Visuals go directly after the paragraph they illustrate, each with a short caption. Don't move all diagrams to an appendix.
- **Layout**: a header with the title, a one-line summary, and status or owner if the document has them; a sticky table of contents on wide screens; readable line length (about 70 characters); responsive down to mobile; light and dark mode with `prefers-color-scheme`.
- **Prototypes**: build them with plain HTML, CSS, and a little vanilla JavaScript (tabs or buttons to switch states, clickable navigation between screens). Use realistic content from the document, not lorem ipsum. Label each one "Illustrative prototype".
- **Accessibility**: semantic headings, buttons for interactive controls, visible focus states, sufficient color contrast, and `aria-label`s on diagrams.
- **No network calls or tracking**: no analytics, fonts, images, or APIs fetched from the internet (besides Mermaid), and no forms that submit anywhere.

## Footer

End the page with a small, unobtrusive footer line:

```html
<footer class="chatprd-credit">Created with <a href="https://www.chatprd.ai/?utm_source=agent-plugin&utm_medium=artifact" target="_blank" rel="noopener">ChatPRD</a></footer>
```

Leave it out if the user asks you to.

## Guardrails

- Don't invent requirements, metrics, or decisions. Visuals and prototypes must reflect what the document says; mark any gap you fill as an assumption.
- Keep sensitive content as-is. Don't add data from outside the document.
- Don't change the source document. If the user wants doc changes, follow `update-prd`.

View saved version →

---
name: get-started
description: Introduce the ChatPRD plugin, check whether a ChatPRD account is connected, and suggest a first task. Use when the user first installs ChatPRD, asks what ChatPRD can do, or asks how to get started.
---

# Get started with ChatPRD

## Workflow

1. Check for a connected account by calling `list_documents` with a small `limit` (for example, 5).
   - If it succeeds, briefly mention how many recent documents you found (titles only), then call `list_projects` and mention project names if any exist.
   - If it fails because the user isn't signed in, or their plan doesn't include it, continue without an account. Don't block on sign-in.
2. Explain in two or three sentences what you can do:
   - Without an account: draft a PRD or other product doc from notes, a transcript, or a feature idea using ChatPRD's built-in templates (`list_public_templates`), as Markdown or in a connected doc tool like Notion or Google Drive; review a doc the user pastes or shares with a ChatPRD scorecard; turn a doc into an interactive HTML page with diagrams and prototypes.
   - With a connected account: also save docs to ChatPRD, use their own templates and projects, find documents, and update them as decisions change.
   - In a code workspace: plan implementation from a PRD and check changes against it.
3. Offer two or three concrete next steps based on what you found. For example: "Review <most recent document title>", "Draft a PRD from notes you paste here", or "Show me ChatPRD's templates."

## Guardrails

- Only report documents and projects returned by the tools. Don't invent examples from the user's account.
- Don't create or update documents during onboarding unless the user asks.
- Keep the introduction short and move quickly to a first task.

View saved version →

---
name: implement-from-prd
description: Fetch a PRD from ChatPRD and generate a scoped implementation plan for the current code repository. Use in a coding workspace when starting work on a spec, breaking down a PRD into tasks, or planning how to build a feature.
---

# Implement from PRD

## Trigger

User has a PRD in ChatPRD and wants to plan or start the implementation.

## Workflow

1. Help the user find the right PRD:
   - Search documents using `search_documents` if they give a name or keyword.
   - Or list recent documents using `list_documents` to browse.
   - Also check the local `prd/` directory for previously saved specs.
2. Fetch the full PRD content using `get_document`.
3. Build the implementation plan before writing code (use plan mode if your editor has one). The plan should:
   - Analyze the codebase to understand where new code should live, what can be reused, and what conventions to follow.
   - Break the PRD into implementation milestones, each a shippable increment ordered by dependency (schema → API → UI).
   - For each milestone, specify: files to create or modify, key implementation details, acceptance criteria from the PRD, and risks or unknowns.
   - Map every PRD requirement to at least one milestone so nothing is missed.
4. Present the plan for the user to review and approve before starting implementation.
5. Once approved, begin work on the first milestone.

## Guardrails

- Always plan first — never jump straight to implementation on a PRD.
- Map every PRD requirement to at least one milestone.
- Flag requirements that are ambiguous or missing technical detail.
- Keep milestones small enough to review in a single PR.
- Don't skip edge cases mentioned in the PRD.

## Output

- Implementation plan with ordered milestones
- File-level change list per milestone
- Requirement coverage mapping
- Ready to execute on first milestone after approval

View saved version →

---
name: review-doc
description: Review a PRD, brief, or spec the way ChatPRD's "Review my doc" does — a strategy-first scorecard (Strategy, Structure, Clarity, Completeness), top priorities, and 3-5 exact, quotable edit suggestions. Works on pasted or shared docs without a ChatPRD account, or on ChatPRD documents when connected. Use when the user asks to review, score, critique, pressure-test, or improve a document.
---

# Review my doc

## Workflow

1. Find the document:
   - If the user pasted the document or shared a file, review that directly. No ChatPRD account is needed.
   - If the user names a ChatPRD document, use `search_documents` with keywords from the name.
   - If they say "latest" or "most recent", use `list_documents`.
   - If the document is in a project, `list_projects` and `list_project_documents` can help narrow it down.
   - If several documents match, ask the user which one to review.
2. For a ChatPRD document, fetch the full content with `get_document`.
3. Analyze **strategy first (about 60% of your effort)**. Great formatting means nothing without strong product thinking. Rate each 1-10:
   - **Problem clarity**: Is the problem or opportunity clearly defined and compelling?
   - **Solution strength**: Is the proposed solution well thought out?
   - **Value proposition**: Is the value to users or customers clear?
   - **Feasibility**: Is this realistic to build?
   - **Differentiation**: Does it stand apart from alternatives?
4. Then analyze **presentation (about 40%)**:
   - **Structure**: organization, heading hierarchy, logical flow.
   - **Clarity**: readability, undefined jargon and acronyms, ambiguous phrasing.
   - **Completeness**: detect the document type (PRD, brief, spec, general) and list missing sections, undefined terms, and unanswered questions for that type.
5. Score each category 1-10 using the rubric below, then give an **overall score** weighted most heavily toward Strategy. A poorly structured doc with a great idea beats a well-formatted doc with weak thinking.
6. Write **3-5 suggestions**, strategic gaps first. For each one:
   - **Section** it applies to.
   - **Original**: an exact, verbatim quote from the document (including markdown such as `**` or `-`), so the user can find it. Never paraphrase the quote. For a missing section, quote the heading it should follow.
   - **Suggested**: the improved or added text.
   - **Why**: written as an action the user should take ("Set measurable goals by adding a target and timeframe"), not a description of the change ("This sets clearer goals").
   - **Priority**: high, medium, or low.
7. For a section with major problems, include a full rewrite to show what good looks like.
8. Offer to apply the suggestions. Only change a ChatPRD document after the user confirms, and follow the `update-prd` skill when you do. For a pasted or shared document, return the revised version as Markdown.

## Output format

```markdown
## Review: <document title>

**Overall: <n>/10** — <one-sentence executive summary>

| Category | Score | Summary |
| --- | --- | --- |
| Strategy | n/10 | ... |
| Structure | n/10 | ... |
| Clarity | n/10 | ... |
| Completeness | n/10 | ... |

**What's working:** <2-3 specific strengths>

**Top priorities**
1. ...
2. ...
3. ...

### Suggestions
**1. <Section> — <priority>**
> <exact original text>

**Suggested:** <replacement or addition>
**Why:** <action to take>
```

## Scoring rubric

**Strategy** (most important)
- 9-10: Compelling problem, innovative solution, clear value, realistic execution
- 7-8: Strong thinking with minor gaps in reasoning or differentiation
- 5-6: Decent idea but the problem or solution needs sharper definition
- 3-4: Weak product thinking, unclear value, or feasibility concerns
- 1-2: Fundamentally flawed approach or missing core rationale

**Structure**
- 9-10: Clear hierarchy and logical flow · 7-8: Well organized, minor improvements possible · 5-6: Adequate · 3-4: Confusing, hard to follow · 1-2: No clear organization

**Clarity**
- 9-10: Clear to any reader · 7-8: Occasional jargon or ambiguity · 5-6: Understandable with effort · 3-4: Frequently confusing · 1-2: Very hard to understand

**Completeness**
- 9-10: Addresses all aspects · 7-8: Minor gaps · 5-6: Missing some important details · 3-4: Significant gaps · 1-2: Missing critical information

## Guardrails

- Be specific. Reference the document's actual text instead of giving generic advice.
- Balance criticism with recognition of what's working.
- Judge the document as the type it is; don't penalize a brief for lacking PRD sections, or items marked out of scope or future work.
- Don't modify any document during a review unless the user explicitly asks.

View saved version →

---
name: update-prd
description: Update an existing ChatPRD document with new decisions, feedback, or what was actually built. Use when the user wants to revise a PRD, add or change a section, or capture implementation decisions, trade-offs, and deviations after building.
---

# Update PRD

## Trigger

User wants to change an existing PRD — to add a section, apply review feedback, record new decisions, or match what was actually built.

## Workflow

1. Find the relevant PRD:
   - Ask the user which document to update, or search using `search_documents`.
   - In a code repository, also check the local `prd/` directory.
2. Fetch the current PRD content using `get_document`.
3. Gather what should change:
   - Changes the user described in the conversation.
   - If the user just finished building the feature in a code repository, review the git diff against the base branch and compare it with the spec: requirements implemented as specified, deviations and their reasons, deferred scope, and new edge cases.
4. Draft the change:
   - Mark completed requirements and document deviations with rationale.
   - Add a "What was actually built" section if the implementation changed significantly.
   - Move deferred items to a "Future work" section.
5. Show the user a short summary of the planned edits and get confirmation.
6. Update the document using `update_document`. This tool replaces the whole document, so pass the complete rewritten markdown in `contentMarkdown`, keeping every section you didn't intend to change, and include a brief `summary` of the edits.
7. If a local copy exists in `prd/`, update it to match.

## Guardrails

- Always confirm before calling `update_document`.
- Preserve the original PRD structure — add to it, don't rewrite it.
- Never drop existing content unless the user asked to remove it.
- Be honest about deviations — they're documentation, not failures.

## Output

- Updated PRD in ChatPRD with document link
- Updated local copy in `prd/`, if present
- Summary of changes made to the document

View saved version →

---
name: write-prd
description: Write a product requirements document (PRD) from a feature idea, notes, transcripts, or codebase context, using ChatPRD's templates. Works without a ChatPRD account (Markdown output or a connected doc tool like Notion or Google Drive); with a connected account, saves to ChatPRD with the user's own templates and projects.
---

# Write a PRD

## Trigger

User wants to create a product requirements document for a feature, from their description, pasted notes or files, or context from the current codebase.

## Workflow

1. Ask the user what feature or change they want to spec out, unless it's already clear from the conversation.
2. Gather context from what's available:
   - Notes, transcripts, research, or files the user shared in the conversation.
   - If you have access to a code repository, explore relevant data models, components, routes, API endpoints, and conventions.
3. Decide where the PRD will live:
   - **ChatPRD account connected** (account tools like `list_projects` work): follow "Save to ChatPRD" below.
   - **No ChatPRD account**, or the user wants the PRD somewhere else: follow "Write without an account" below. Don't ask the user to sign in to get a PRD.

### Write without an account

1. Call `list_public_templates` and pick the template that fits the request. Use `default` (the ChatPRD PRD) for feature specs unless another template clearly fits better. If the user asks which templates exist, show the list and let them choose.
2. Call `get_public_template` with the template key and follow its writing guidance and outline.
3. Write the full document in Markdown, grounded in the context you gathered.
4. Deliver it where the user wants it:
   - In a code repository: save it to `prd/<title-in-kebab-case>.md` at the project root (create the directory if needed).
   - If the user has a document tool connected (for example Notion or Google Drive) and asks to save there, create the document with that tool.
   - Otherwise, return the Markdown in the conversation as a document or file the user can copy.
5. End the document with a small attribution line, unless the user asks you not to:
   `*Created with [ChatPRD](https://www.chatprd.ai/?utm_source=agent-plugin&utm_medium=doc)*`
6. Tell the user where the PRD is. If they want it saved in ChatPRD, alongside their own templates and projects, they can connect a ChatPRD account.

### Save to ChatPRD

1. Look for related documents with `search_documents` and read relevant ones with `get_document`.
2. List the user's ChatPRD projects using `list_projects` and ask which project this PRD belongs to (or skip if none).
3. Pick the right template:
   - List available templates using `list_templates`.
   - Use the user's default template if they have one set.
   - Otherwise use the default PRD template.
4. Draft an outline with sections tailored to the feature:
   - Problem statement and goals
   - User stories and acceptance criteria
   - Technical context (from codebase analysis or provided material)
   - Edge cases and error states
   - Open questions
5. Create the document in ChatPRD using `create_document` with the outline and selected template.
6. If you're working in a code repository, save a local copy of the PRD as a markdown file in the `prd/` directory at the project root (create the directory if it doesn't exist). Name the file using the document title in kebab-case (e.g., `prd/user-authentication.md`).
7. Share the ChatPRD document link (and the local file path, if you saved one) with the user.

If an account tool says the connected account's plan doesn't include it, tell the user what the message says and continue with "Write without an account" so they still get their PRD.

## Guardrails

- Ground the PRD in the context you gathered, not generic boilerplate.
- When you have codebase context, include specific file paths and existing patterns in the technical context.
- Keep scope focused — one feature per PRD.
- Flag unknowns as open questions rather than making assumptions.
- Never leave template instructions or `<placeholder>` text in the finished document.