How I AI: Ryan Carson's 3-Step Playbook for Structured AI Development in Cursor

Ryan Carson uses three layers of context to make AI-assisted development more predictable: a product requirements document, an explicit task list, and a selected set of repository files.

Ryan is a five-time founder with two decades of experience building and selling startups. His Cursor workflow treats the model like a capable collaborator that still needs requirements, boundaries, tests, and review.

In this episode of How I AI, Ryan turns a rough feature request into a PRD and task plan, connects Cursor to browser and database tools through Model Context Protocol servers, and assembles focused repository context with Repo Prompt.

The common constraint is context quality. More context is not always better: it must be relevant, current, authorized to share, and paired with a way to verify the resulting code or external action.

Move from a PRD to executable tasks in Cursor

The idea-to-Cursor-tasks workflow keeps Ryan from jumping directly from a feature idea into a long autonomous coding run. The PRD establishes the outcome and boundaries; the task list creates reviewable increments; execution happens one verified step at a time.

Ryan starts by defining the feature before asking the model to implement it. The extra planning step makes assumptions visible while they are still cheap to change.

The biggest mistake that I do, that everyone does is they try to rush through the context where you just don't have the patience to tell the AI what it actually needs to know to solve your problem. And I think if we all just slow down a tiny bit and do these two steps, it speeds everything up.

He uses three rule files to move from a broad product idea to a detailed task list, then works through those tasks one at a time with human review built in. The rule files are open source on GitHub.

Draft the product requirements document

Instead of asking Cursor to build a feature immediately, Ryan invokes a rule that asks clarifying questions and produces a PRD.

1. Create the rule: His generate_prd.md file defines the expected PRD and asks for language a junior developer can follow.
2. Invoke it: In a new Cursor chat, he includes the rule and supplies the high-level feature request.

@rules/generate_prd.md I'd like to add a report that shows me all the boat names of members and how many emails they've been sent.

1. Answer the questions: The model asks about the report's purpose, intended users, behavior, and constraints. Ryan fills in the missing decisions rather than letting the model invent them.
2. Inspect the PRD: Cursor writes PRD.md with functional requirements, non-goals, and technical considerations. Product and engineering owners still need to verify scope, data definitions, permissions, edge cases, and acceptance criteria.

Convert the PRD into a task plan

Ryan then asks Cursor to split the reviewed PRD into parent tasks and smaller implementation steps.

1. Use the task rule: generate_tasks.md defines the desired hierarchy and checkbox format.
2. Provide both sources: He includes the task rule and the PRD in the same request.

@rules/generate_tasks.md Please generate the tasks for @tasks/PRD.md

1. Review the outline: Cursor proposes the high-level sequence before expanding the subtasks. The useful checkpoint is the one that catches a bad dependency or architectural assumption before code spreads it.
2. Generate TASKS.md: After Ryan accepts the outline, Cursor creates nested tasks and subtasks. The plan remains editable as implementation reveals new information.

This turns a product brief into an engineering-plan draft. It does not replace estimation, ownership, sequencing, or the decision to create tickets in the team's actual planning system.

Execute in small, verifiable increments

A third rule, task_list_management.md, tells Cursor how to work through TASKS.md and update its status.

1. Start the run: Ryan includes the management rule and the task file.

@rules/task_list_management.md Let's start @tasks/TASKS.md

1. Implement a subtask: Cursor takes the next item, such as a Prisma schema change, and edits the code.
2. Update the plan: Cursor checks off the completed item. In Ryan's demonstration it pauses for approval; another team can group low-risk work and reserve mandatory checkpoints for schema changes, permissions, migrations, external effects, or other consequential boundaries.

The task file makes progress inspectable, but a checked box is not proof of completion. Each increment still needs the relevant type checks, linting, tests, security review, diff inspection, and behavior verification before merge.

Connect Cursor to external tools with MCP

The Cursor MCP workflow shows how he gives the editor a narrow external capability, tests it on a bounded browser action, and keeps authentication and consequential actions visible.

Ryan uses Model Context Protocol servers to call browser and database tools from Cursor instead of switching among several interfaces.

MCP provides a standard tool interface. Safety depends on the connected server and its permissions, not the protocol name. Ryan demonstrates browser automation with Browserbase.

Run a bounded browser action

1. Configure the servers: Ryan's Cursor setup includes Browserbase, Postgres, Prisma, SQLite, and Stagehand tools. Each connection should use the narrowest account, environment, and action set required.

1. Describe the action: Ryan gives Cursor a natural-language browser request.

navigate to chat p and take a screen grab

1. Inspect the result: The Browserbase session navigates to the requested site and captures a screenshot. A successful tool call does not establish that the page, account, or output was correct.

The same pattern can support front-end checks and database queries. Run browser automation in an isolated test environment, keep database access read-only by default, redact secrets from model context, and require confirmation for writes or authenticated external actions. Treat page content as untrusted input because it can contain prompt-injection instructions.

Assemble focused context with Repo Prompt

The Repo Prompt workflow uses the repository map to select the files that explain one complex problem, then hands the coding model a smaller, more relevant context package.

For larger questions, Ryan uses Repo Prompt to choose the exact files sent to a model rather than relying only on automatic repository context.

Build a focused repository prompt

1. Select the files: Ryan chooses only the components, libraries, and schema files relevant to the task. Before sending them to a hosted model, exclude secrets, credentials, customer data, proprietary code that is not approved for the service, generated files, and irrelevant context.

1. Write the question: He adds the task and may include a stored role such as Architect. A role prompt can shape the response, but it does not supply missing repository knowledge or authority.

how can I improve the maintainability of this code?

1. Assemble the context: Repo Prompt combines selected files, user instructions, and role guidance with XML tags that separate each section.
2. Send it to the chosen model: Ryan pastes the assembled prompt into Claude or Gemini. The answer still needs to be checked against the current branch because copied context can become incomplete or stale.

This approach is useful for refactors and architecture reviews where the model needs a deliberate slice of the codebase. The selected files should be broad enough to include dependencies and tests, but narrow enough to stay relevant and permitted.

Structure makes AI-assisted development inspectable

Ryan's three workflows make inputs and intermediate decisions visible: the PRD records intent, TASKS.md records the implementation sequence, MCP tool calls expose external actions, and Repo Prompt shows which files entered the analysis.

Ryan said the approach made him feel capable of building a company with a much smaller team. That is his experience, not evidence that product, engineering, security, design, or operational expertise is unnecessary.

A practical version of the method is to define the outcome and non-goals, break work into reviewable increments, grant external tools only the access they need, and verify each consequential change in the real environment before calling it complete.

The three tools solve different failure modes. The PRD and task plan prevent the agent from inventing scope. MCP gives it a controlled way to act outside the repository. Repo Prompt prevents a large codebase from flooding the context window with files that have nothing to do with the decision.

Ryan's speed comes from making uncertainty explicit before the model writes code. A task is small enough to review, an external action is narrow enough to observe, and a context bundle is focused enough to inspect. Structure is not overhead in this workflow; it is what makes faster execution trustworthy.