<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AI Driven Development on Focus AI Playbooks</title><link>https://playbook.focusconsulting.io/playbooks/ai-driven-development/</link><description>Recent content in AI Driven Development on Focus AI Playbooks</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://playbook.focusconsulting.io/playbooks/ai-driven-development/index.xml" rel="self" type="application/rss+xml"/><item><title>Generating a PRD</title><link>https://playbook.focusconsulting.io/playbooks/ai-driven-development/generating-a-prd/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://playbook.focusconsulting.io/playbooks/ai-driven-development/generating-a-prd/</guid><description>&lt;h1 id="generating-a-prd"&gt;Generating a PRD&lt;a class="anchor" href="#generating-a-prd"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The PRD is where you slow down before you speed up. Most wasted development time comes from building the wrong thing, not building the right thing slowly. This phase uses the AI to research the codebase, interrogate the requirements, and produce a document that everyone can point to when they need to know what &amp;ldquo;done&amp;rdquo; looks like.&lt;/p&gt;
&lt;h2 id="start-with-the-raw-input"&gt;Start with the raw input&lt;a class="anchor" href="#start-with-the-raw-input"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;You&amp;rsquo;re working from a ticket, user story, Slack thread, meeting notes, or some combination. Paste it all into the AI session. Don&amp;rsquo;t clean it up first. Contradictions and ambiguity in the raw material are exactly what you want to surface now, not during implementation.&lt;/p&gt;</description></item><item><title>Task Breakdown and Planning</title><link>https://playbook.focusconsulting.io/playbooks/ai-driven-development/task-breakdown-and-planning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://playbook.focusconsulting.io/playbooks/ai-driven-development/task-breakdown-and-planning/</guid><description>&lt;h1 id="task-breakdown-and-planning"&gt;Task Breakdown and Planning&lt;a class="anchor" href="#task-breakdown-and-planning"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;You have an approved PRD. Now you need to turn it into work that can actually be executed, ideally as much of it in parallel as the dependencies allow. This phase breaks the PRD into discrete tasks, orders them by dependency, and produces implementation plans detailed enough that the AI (or another developer) can execute them without guessing.&lt;/p&gt;
&lt;h2 id="break-the-prd-into-tasks"&gt;Break the PRD into tasks&lt;a class="anchor" href="#break-the-prd-into-tasks"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Work with the AI to decompose the PRD into tasks. Each task should be a unit of work that can be planned, implemented, and verified independently.&lt;/p&gt;</description></item><item><title>Implementation and Validation</title><link>https://playbook.focusconsulting.io/playbooks/ai-driven-development/implementation-and-validation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://playbook.focusconsulting.io/playbooks/ai-driven-development/implementation-and-validation/</guid><description>&lt;h1 id="implementation-and-validation"&gt;Implementation and Validation&lt;a class="anchor" href="#implementation-and-validation"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;You have approved plans. Now the AI executes them and you verify the results. The key discipline here is separation: the AI that wrote the code should not be the only one checking it. A fresh session running validation has no memory of the implementation, no attachment to the approach, and no tendency to gloss over its own shortcuts.&lt;/p&gt;
&lt;h2 id="implement"&gt;Implement&lt;a class="anchor" href="#implement"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Use &lt;code&gt;/implement_plan&lt;/code&gt; to execute each plan. Run as many in parallel as your dependency graph allows. If tasks A and B are in the same wave with no dependencies between them, run them in separate sessions at the same time.&lt;/p&gt;</description></item><item><title>PR Strategy</title><link>https://playbook.focusconsulting.io/playbooks/ai-driven-development/pr-strategy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://playbook.focusconsulting.io/playbooks/ai-driven-development/pr-strategy/</guid><description>&lt;h1 id="pr-strategy"&gt;PR Strategy&lt;a class="anchor" href="#pr-strategy"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The PR strategy you choose determines whether reviewers can give meaningful feedback or just rubber-stamp a wall of diffs. For AI-driven development, where a single feature can produce a lot of code quickly, this matters more than usual.&lt;/p&gt;
&lt;h2 id="the-approach-prd-branch-with-task-prs"&gt;The approach: PRD branch with task PRs&lt;a class="anchor" href="#the-approach-prd-branch-with-task-prs"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Create a feature branch from main for the overall PRD. Call it something like &lt;code&gt;feature/issue-123-search-filters&lt;/code&gt; or &lt;code&gt;prd/user-authentication&lt;/code&gt;. This is your PRD branch.&lt;/p&gt;
&lt;p&gt;For each task or plan, create a short-lived branch off the PRD branch. Implement, validate, then open a PR back into the PRD branch. Each of these PRs is small, focused, and reviewable.&lt;/p&gt;</description></item></channel></rss>