Matrix Code
  • English

    • PRD Prompt for Your Demo

    Built a demo with an AI coding tool, but never wrote down what it actually does? Run this prompt in the demo's codebase. Your coding agent reads the code and writes a PRD (product requirements document) to prd.md. It covers target users, the problem and solution, a feature inventory split into built / partly built / planned, the data model, and the external services the product depends on. Every claim cites the file it comes from.

    How to use it

    1. Open the demo project in a coding agent that can read files in the project and write new ones, such as Claude Code, Cursor or Codex.
    2. Copy the prompt below and send it to the agent from the project's root directory.
    3. When it finishes, check prd.md in the project root. Fix anything the code got wrong and answer the Open questions in the appendix where you can.
    4. Send prd.md to hi@thematrixcrop.com or attach it when you contact us. It is the starting point for our requirements assessment.
    For your coding agent
    Reverse-engineer a PRD from this codebase

    Writes prd.md to the project root. It doesn't change your code.

    # Task: Reverse-engineer a PRD from this codebase You are an analyst fluent in both product and engineering. The current directory is a project built largely with AI assistance ("vibecoding"). It likely has no formal documentation, and any README may be outdated or inconsistent with the implementation. Your job is to reconstruct this product's PRD **using the code as the single source of truth**, and write it to `prd.md` in the project root. ## Principles 1. **Evidence first.** Every conclusion must cite its basis: a file path, plus a line number or function name where useful. Anything without direct evidence must be labeled **(Inferred)** with your reasoning. 2. **Code > docs.** README, comments, and marketing copy are leads, not facts. When they conflict with the implementation, trust the implementation and record the conflict. 3. **Separate "built" from "planned."** TODOs, commented-out code, stub routes, mock data, and unreferenced files are planned or abandoned work. Do not present them as existing features. 4. **Don't fill gaps with assumptions.** If the code doesn't tell you, write "Cannot be determined from the code." Don't substitute common sense. ## Exploration steps (in order) 1. **Global scan:** directory structure, dependency manifests (package.json, requirements.txt, go.mod, etc.), README, .env.example, config files, deployment config (Dockerfile, vercel.json, wrangler.toml, etc.). 2. **Find entry points:** frontend routes and pages, API routes, CLI commands, cron jobs and workers, webhook handlers. Together these are the surface users actually touch. 3. **Find data definitions:** DB schemas (Prisma, Drizzle, SQL migrations, ORM models), TypeScript types and interfaces, Zod/Pydantic schemas, state stores. 4. **Find external calls:** SDK imports, `fetch`/`axios` calls to external domains, env var names (`*_API_KEY`, `*_SECRET`, `*_URL`). 5. **Trace the main flows:** pick the 1–3 most important user journeys and follow each from the UI through to data writes and external calls. 6. **Look for monetization signals:** pricing pages, paywalls, usage limits, Stripe or other payment integrations, plan/tier fields, copywriting. ## Output: write `prd.md` with the following structure ### 0. One-line summary One sentence: this product helps **[who]** do **[what]**. ### 1. Target users - Primary user persona (role, context, technical level) - Evidence: UI copy, onboarding flow, pricing tiers, permission roles (user/admin/team), domain terminology, UI language - Are there multiple roles? What can each one do? - Individual or team/enterprise? (Look for workspace, organization, invite, or seat concepts.) ### 2. Problem being solved - Core pain points (1–3) - Likely existing alternatives users rely on today **(Inferred)** - Evidence ### 3. Solution approach - Core mechanism: how does the product solve the problems above? - Core user flow: numbered steps from entry to getting value - Key design trade-offs: technical choices, what is automated, the role AI plays in the flow - Feature inventory, split into: - ✅ Fully implemented - 🚧 Partially implemented / mocked - 💭 TODOs or traces only ### 4. Core data modules and flows - Core entities, each with: name, purpose, key fields, where it's defined - Relationships between entities (1:1, 1:N, N:M) - Two Mermaid diagrams: - `erDiagram` for entity relationships - `flowchart` showing how data is created, transformed, stored, and output along the core flow, including touchpoints with external services - Data lifecycle: what is user input, what is generated by the system or AI, and what is cached or derived ### 5. Core external dependencies | Service | Category | Purpose | Critical? (does the product break without it?) | Evidence | Replaceability | |---|---|---|---|---|---| Categories: LLM/AI, database/storage, auth, payments, email/notifications, third-party data APIs, hosting/infra, analytics/monitoring. Then add: - Which dependencies likely drive the most cost **(Inferred)** - Which carry the highest vendor lock-in risk ### 6. Appendix - **Docs vs. implementation conflicts:** features the README claims that the code lacks, or the reverse - **Open questions:** things the code can't answer that should be asked of the author - **Overall maturity:** MVP / usable product / half-built, with reasoning ## Finishing up 1. Write the complete document to `./prd.md`, overwriting the file if it already exists. Use clean Markdown, and make sure the Mermaid blocks are valid syntax. 2. Before finishing, re-read `prd.md` and check that every cited file path actually exists and that nothing marked ✅ is actually a stub or mock. 3. In your final reply, give a 3–5 line summary of the product and the path to `prd.md`. Don't paste the full document into the chat.

    Before you send it

    • Check for secrets. The agent reads .env.example and config files and may quote variable names. Make sure prd.md contains no real API keys or passwords.
    • It reflects the code, not your plans. If a feature exists only in your head, add it to the document yourself and mark it as planned.
    • Not sure about something? Leave it in. Gaps and "Cannot be determined from the code" entries are useful: they tell us what to ask in the assessment.