Dhwani AI Playground
Home / Frameworks / The Builder Protocol

The Builder Protocol.

A delivery methodology for the AI-native era
Framework

One builder with AI leverage
outperforms a team of six.

The traditional SDLC was built for a world where humans did all the work. That world is over. The Builder Protocol is a new methodology where 3 personas and an AI partner replace 6+ specialized roles — across planning, requirements, building, testing, documentation, and handoff.
“A leveraged worker can out-produce a non-leveraged worker by a factor of one thousand or ten thousand. With leverage, judgment becomes far more important than hours put in.” — Naval Ravikant, The Almanack

The Leverage Thesis

Naval Ravikant identified four types of leverage: labour, capital, media, and code. Code and media are permissionless — you don’t need anyone’s approval to use them. AI is the fifth form. It compounds all four.

The Builder Protocol is built on this insight. When AI assists across every phase of delivery — not just code generation — a single Product Builder with the right tools, skills, and discipline can deliver what previously required a full team.

3
Personas
8
Phases
4
Memory Files
Code and media are permissionless leverage. They’re the leverage behind the newly rich. You can create software and media that works for you while you sleep. Naval Ravikant

What This Replaces

The industry is moving fast. Microsoft, AWS, PwC, and GitHub are all publishing AI-driven SDLC frameworks. GitHub’s Spec Driven Development follows the same pattern: Specify, Plan, Tasks, Implement. AWS replaced “sprints” with “bolts” — work cycles measured in hours, not weeks.

The Builder Protocol was built independently from real delivery — not from theory. It converges with these frameworks because the underlying reality is the same: AI changes what one person can do.

Traditional SDLC

  • 6+ specialized roles with handoff friction
  • Knowledge lives in people’s heads and meetings
  • Documentation is a bureaucratic afterthought
  • Testing is appended at the end
  • New team members need weeks of verbal briefings
  • Sprints measured in weeks

The Builder Protocol

  • 3 personas with AI filling execution gaps
  • Knowledge persists in GitHub markdown
  • Documentation is a runtime asset, not an artifact
  • Test design is a first-class deliverable
  • Anyone can onboard from the repo alone
  • Work cycles measured in hours
The organisations that thrive will treat AI not as a shortcut, but as a force multiplier reshaping delivery around speed, confidence, and continuous improvement. CircleCI, The New AI-Driven SDLC (2025)

The Three Personas

Where a traditional team has 6+ roles, the Builder Protocol operates with three. AI is the fourth member — silent, tireless, and leveraged.

B

Product Builder

BA + Dev + QA + Tech Writer

Plans, configures, codes, tests, and documents. The primary operator of this framework. Uses CLI + skills.

A

System Architect

DevOps + Security + Sr. Dev

Stack decisions, security posture, infrastructure, deployment. Escalation point for core changes.

If you are reading this to set up your AI, you are the Product Builder. This entire framework is built for you.

Terminology

Builder ProtocolThis methodology — 3 personas + AI partner, 8-phase lifecycle, GitHub memory
Product BuilderThe primary delivery operator — plans, builds, tests, documents
Phase BuildImplementing in platform order, not random ticket order
Config-vs-CodeThe critical decision: platform config or custom code?
Memory LayerGitHub-stored MD files that persist knowledge across sessions and operators
HeartbeatDaily handoff log — what changed, what’s pending, what’s blocked
Domain SkillAI agent definition carrying product/domain context
Flow SkillAI agent definition for process execution (testing, spec writing, coding)
Platform OrderThe logical build sequence for your product stack
Safety HooksPre-configured guardrails preventing AI from destructive mistakes
PluginBundled skills + MCP + slash commands + sub-agents. One install, one shared toolkit across the team (S5–S6)
Plugin GuardianThe person who maintains a shared plugin or skill — raises PRs, reviews changes, keeps it alive
Reuse FirstThe first question before you build anything — did someone already solve this?

The 8-Phase Lifecycle

0 · Intent → 1 · Plan → 2 · Requirements → 3 · Tasks → 4 · Dev Planning → 5 · Phase Build → 6 · E2E Testing → 7 · Iteration → 8 · Ship

Phase 7 loops back: Bug fixes return to Phase 5. Structural issues return to Phase 4. The loop continues until the PRD is functionally satisfied.

The first job after receiving a project is not development. It is understanding. Builder Protocol, Rule Zero

Phases 0–3 Thinking & Shaping

0
Intent Clarification

Understand what is actually needed before touching anything. What stage is the project in? What already exists? What is the client expecting versus what is technically feasible?

  • Confirm scope and starting point
  • Separate examples from actual requirements
  • Identify what already exists (repo, site, data, docs)
ToolUI (Claude UI / ChatGPT) — prompt quality matters more than brand
OutputConfirmed scope and starting point
1
Project Planning

Define the delivery shape before touching configuration or code.

  • Timeline or Gantt chart
  • Phase plan with expected outputs per phase
  • Capability map — what the platform already does vs what needs building
ToolUI
OutputTimeline document, phase plan
2
Requirement Gathering

Capture the full product requirement — not loose notes. PRD preferred over BRD because it captures product behavior, not just business rules.

  • Personas, workflows, edge cases, approval chains
  • Reporting and dashboard requirements
  • Reference existing implementations for patterns
ToolUI — best for long-form iterative clarification
Skillbusiness-analyst — converts raw inputs into structured BRD/PRD
OutputPRD.md stored in the repo root
3
Task Division

Break the PRD into execution units. Task list with clear ownership, user stories per module, module-level execution buckets.

  • Flag what is likely config vs code (refine in Phase 4)
  • Group tasks into logical modules
ToolCLI with read access to repos + domain references
Skillfeature-spec — thorough task and user story creation
OutputTask list (GitHub Issues, spreadsheet, or markdown — pick one, stay consistent)

Phase 4 Development Planning — The Critical Phase

This is the most important judgment phase in the entire lifecycle. Decide what is configuration, what is setup, what is code, and what waits. Getting this wrong causes 80% of iteration waste.

Config-vs-Code Decision Flow: Can the platform do it natively? → Config. Needs a property change? → Setup script. Needs a new field? → Fixture in client app. Needs custom logic? → Code in client app. Needs core product change? → STOP — escalate to the System Architect.

1

Display-only rename (sidebar label, field label, option text users see) → Translation record (language=en). Changes what users see without touching stored values.

2

Field property change (required flag, hidden, depends_on) → Property Setter via idempotent setup script.

3

New field on existing form → Custom Field fixture in client app.

4

Conditional UI behavior → Client Script in client app.

5

Server-side business logic → Server Script or API in client app.

6

New entity type → DocType JSON fixture in client app.

7

Core product behavior change → STOP. Escalate to System Architect.

ToolCLI with write access to repo + GitHub CLI
Skilltechnical-pm + platform coding hygiene skill
OutputModule hierarchy, config/setup/code classification, test checkpoints

Phase 5 Phase Build — Platform Order

Implement in platform order — not as a random ticket queue. Each layer must be stable before the next depends on it.

1Login & Branding
2Theme & Navigation
3Settings & Setup
4Users, Roles & Permissions
5Fields & Form Hygiene
6Approvals & Workflows
7Alerts & Notifications
8Dashboards & Reports
ToolCLI + domain skills + coding skills
SkillPlatform engineer skill + setup skill + relevant domain skill
OutputWorking code on feature branch, PRs raised per phase
Development should not start as a random ticket queue. It should move through the product in a stable functional order. Builder Protocol, Phase 5 Principle

Phases 6–8 Test, Iterate, Ship

6
E2E Testing

Test design is a deliverable, not a side effect.

1

Extract the test plan from PRD + roles + user flows

2

Validate the test plan against actual field names and API schema (never guess)

3

Execute testing persona by persona using Playwright

4

Capture screenshots and defects

ToolCLI + Playwright MCP
Skillqa-tester + playwright-qa-engineer
OutputTest plan, test results with screenshots, defect list
7
Iteration

Bug fixes loop to Phase 5. Structural issues (wrong config-vs-code decision, missing fields, bad workflow) loop to Phase 4. Track defects in GitHub Issues or a structured spreadsheet.

ToolDefect tracker + Playwright MCP + CLI
Skillticketing — structured defect logging
8
Training, Documentation & Go-Live

Create training material from validated flows, not from memory. Playwright screenshots as input source. Role-based journey documentation. Release readiness checklist.

ToolCLI + Playwright (screenshots) + documentation tooling
Skillproduct-docs + release-notes

The Memory Layer

Every project repo must have these 4 files at the root. They make handoff possible without spoken context. If the project can’t be handed over through GitHub markdown alone, the delivery model is incomplete.

CLAUDE.md

The project brain. Persona, stack, repo structure, what’s deployed, hard rules, mistakes made, session log. Your AI reads this at the start of every session.

SECURITY.md

Safety guardrails. Parameterised queries only. No elevated permissions. Error suppression. Pentest findings. Not aspirational — prescriptive.

HEARTBEAT.md

Daily shift handoff. What was built, what’s pending, what’s blocked, what to test next, what NOT to break. Update at end of every session.

PRD.md

Full requirements. Personas, user journeys, workflow states, edge cases, business rules, reporting needs. The single source of truth.

Every great software developer has an army of robots working for him at nighttime while he sleeps, after they’ve written the code, and it’s cranking away. Naval Ravikant

The Layer Stack

This architecture governs what you can and cannot touch. All your work happens in Layer 4 — the client app. If something needs a change in Layers 1–3, escalate.

1 Framework Core platform, ORM, permissions engine Never
2 Shared Extensions Geo data, shared components, base theme Never
3 Core Product Grant lifecycle, compliance, core workflows Never
4 Client App All client-specific customizations Your work

The golden rule of display renames: Never rename Select option values via Property Setter. Core code hardcodes option values. Use Translation records for display-only renames — they change what users see without touching what code references.

Tool Setup

Required

1

AI CLI — Claude Code, Gemini CLI, Cursor, or Codex. Pick one.

2

GitHub CLI (gh) — PR creation, issue tracking, repo operations.

3

Playwright MCP — E2E testing, screenshot capture, functional validation.

4

Git — version control, branching, PRs.

Recommended

1

Cloud UI (Claude UI / ChatGPT) for Phases 0–2: thinking, planning, PRD drafting.

2

Two separate AI contexts — one for thinking (UI), one for executing (CLI).

3

Defect tracker — GitHub Issues or a spreadsheet for structured iteration.

The split is deliberate: UI is for thinking well. CLI is for doing well. GitHub is the memory layer between them.

Skills — What to Load and When

Skills are specialized AI agent definitions carrying domain knowledge or process discipline. Load domain skills at project start. Load flow skills only when entering the relevant phase. This prevents context bloat — your AI has limited attention, and loading everything at once dilutes what matters.

Domain Skills (Load at Project Start)

Domain mgrant-donor Grant flows, workflow states, fund disbursement, permissions
Domain mgrant-csr Compliance lifecycle, budget attribution, statutory reports
Domain mgrant-nuo NGO-facing grants, sub-grants, regulatory compliance, results framework
Domain mgrant-coding-hygiene Layer stack discipline, Property Setter vs Translation, fixture rules — always load

Flow Skills (Load Per Phase)

Ph 2 business-analyst Converts MOMs, transcripts, emails into structured BRD + Requirements Matrix
Ph 3 feature-spec Structured feature specs with thorough task and user story breakdown
Ph 4 technical-pm Architects features and modules — config-vs-code decisions, system design
Ph 5 frappe-engineer Production-ready platform code — acts as senior developer
Ph 5 mgrant-setup Deployment end-to-end — 11 phases from settings to portal
Ph 6 qa-tester Functional test plans — RBAC validation, workflow checks
Ph 6 playwright-qa-engineer Playwright E2E tests, reports with screenshots
Ph 7 ticketing Structured tickets (Feature/Bug/CR) from defect descriptions
Ph 8 product-docs Structured product documentation chapter-by-chapter
Ph 5–7 pr-raiser Clean GitHub PRs with description and test plan
Ph 8 release-notes Release notes from git log and tickets

How to Load Skills

Claude CodePlace .md skill files in ~/.claude/agents/. Invoke via Agent tool with subagent_type.
Gemini CLIReference in GEMINI.md or tool configs.
CursorAdd as context rules or system prompts per workspace.
CodexLoad via AGENTS.md or equivalent context configuration.

Hard-Won Rules 10 lessons from real delivery failures

Every rule below comes from a real failure that cost real time. These are not best practices — they are scars. The rule exists because someone learned it the expensive way.

1Never rename Select option values via Property Setter
A Property Setter renamed an option value. The display changed, but core code hardcodes option values in depends_on, client scripts, and Python logic. A key button broke silently.
Use Translation records (language=en) for display renames. They change what users see without touching stored values.
2One source of truth per config item
Records were created by both a fixture AND a runtime patch. Result: duplicates and broken lookups.
A config item is managed by a fixture OR by runtime. Never both.
3Patches are for schema migrations only
Site config was put in a patch file. Patches run once and can’t be re-run safely on new instances.
Site config goes in an idempotent setup script. Patches are for one-time schema migrations only.
4Decide the deployment mechanism BEFORE writing code
A config change was added, reverted, and re-added across 3 commits because no one decided upfront whether it should be a Property Setter, Translation, or fixture.
Before writing a single line, decide the mechanism. Document it in the PR description.
5Verify test selectors against live API schema
Playwright tests used wrong field names. 50+ failures were misdiagnosed as “timeout” when the real cause was selector mismatch.
Before writing any test, check the API for actual field names, mandatory flags, and option values. Never guess.
6Understand the request lifecycle before intercepting it
A request interception feature took 6+ failed branches because the hook fired at the wrong point in the lifecycle.
Trace the platform’s request lifecycle in source code before building interceptions.
7Restart workers after Python monkey-patches
Code was deployed but didn’t work. Build and migrate commands don’t reload Python into running workers.
If your code patches a framework function, restart the application server. Build alone won’t load it.
8Never swallow exceptions silently
Import errors were hidden by bare except-pass blocks. The feature appeared deployed but did nothing.
Never hide errors with bare exception handlers. Verify all imports against framework source.
9UAT before staging, always
Enforced across all delivery projects. Staging is client-facing.
All changes go to UAT first. Only after verification, move to staging.
10Knowledge must outlive the current operator
Projects were structured so anyone opening the repo could continue from the Memory Layer alone.
If the project can’t be handed over through GitHub markdown alone, the delivery model is incomplete.

Safety Hooks

Safety hooks are automated guardrails that run before AI tool calls. They catch destructive commands, credential leaks, and scope violations before they execute. Essential when the operator is non-technical.

×

System: No sudo, no rm -rf outside project, no modifying system files

×

Git: No force push, no push to main, no deleting remote branches

×

Database: No DROP commands, no production migrations

×

Core: No modifications to framework or core product for client work

×

Credentials: No tokens or keys in output or memory files

×

Files: No deleting files outside project directory

Allowed without asking: Read/search any file. Edit within project. Git add/commit/push to feature branches. Dev/test commands. Create files in project. Non-destructive shell commands.

Working Rules

1

Do not jump to code until config-vs-code has been explicitly decided for each requirement.

2

Do not test without a written test plan tied to personas and flows from the PRD.

3

Do not document from memory when screenshots from validated flows are available.

4

Do not treat PR creation as mechanical — it is a release-control decision.

5

Do not keep project memory in chat only — persist to GitHub.

6

Do not start development as a random ticket queue — follow platform order.

7

Do not modify core product apps for client-specific work.

8

Do not rename Select option values via Property Setter — use Translation.

9

After every PR, update the code journal — never merge without it.

10

Update HEARTBEAT.md at end of every session — the next operator depends on it.

Master Prompt — Project Kickoff

Feed this to your CLI when starting a new project. Replace the placeholders with your project details. This is the single prompt that boots your AI into the Builder Protocol.

I am starting a new project using the Builder Protocol. ## Context Product: {PRODUCT_NAME} Client app repo: {REPO_URL} UAT site: {UAT_URL} Staging site: {STAGING_URL} Modules active: {list what applies} My role: Product Builder ## First Steps 1. Read CLAUDE.md in the repo root. If missing, help me create one. 2. Read SECURITY.md, HEARTBEAT.md, and PRD.md if they exist. 3. Tell me what phase this project is in. 4. For the current phase, tell me the expected output and skills to load. ## Operating Rules (Non-Negotiable) - Follow the layer stack: never modify layers 1-3 for client work - Translation for display renames, Property Setter for structural changes only - One source of truth per config item (fixture OR runtime, never both) - Platform order: branding > theme > settings > roles > fields > approvals > alerts > dashboards - Test plan before testing, not after - Update HEARTBEAT.md at end of every session - Verify test selectors against live API schema before writing tests ## Safety Rules - Never force push, push to main, or delete remote branches without approval - Never store credentials in output or memory files - Never modify files outside the project directory - Never run destructive database commands without approval - UAT before staging, always ## Available Skills Domain: mgrant-donor, mgrant-csr, mgrant-nuo, mgrant-coding-hygiene Flow: business-analyst, feature-spec, technical-pm, frappe-engineer, frappe-doctype, mgrant-setup, qa-tester, playwright-qa-engineer, ticketing, product-docs, pr-raiser, release-notes

Session Handoff Checklist

Before ending any working session, update these files. This is not optional.

1

CLAUDE.md — if project behavior or approach changed

2

HEARTBEAT.md — what’s done, pending, blocked, next steps

3

PRD.md — if requirements or decisions shifted

4

Code journal — if any code was written or PRs raised

5

Test artifacts — if test results were generated

6

Defect tracker — if iteration findings were created

Adapting for Other Products

The Builder Protocol is not product-specific at its core. The lifecycle, skill-loading strategy, memory layer, and UI/CLI split work for any structured delivery.

What You Change

1

Replace domain skills with your product’s domain context

2

Replace the platform order with your product’s logical build sequence

3

Replace the hard-won rules with your project’s learned constraints

What Stays the Same

1

The 8-phase lifecycle

2

Config-vs-code decision discipline

3

UI for thinking, CLI for executing, GitHub for memory

4

Test plan before testing, handoff checklist, skill loading strategy

Quick Reference

The Builder Protocol 3 Personas: Product Builder | System Architect | Account Manager 8 Phases: Intent > Plan > Requirements > Tasks > DevPlan > Build > Test > Iterate > Ship Memory Layer: CLAUDE.md + SECURITY.md + HEARTBEAT.md + PRD.md Stack: framework > shared extensions > core product > client app NEVER NEVER NEVER YES Platform Order: Branding > Theme > Settings > Roles > Fields > Approvals > Alerts > Dashboards Tools: UI (think) + CLI (execute) + GitHub (remember) + Playwright (test) Skills: Domain at start. Flow per phase. Utility as needed. Golden Rule: If it can't be handed over through GitHub markdown alone, it's incomplete.

The Philosophy

Technology is not only the thing that moves the human race forward, but it’s the only thing that ever has. The smart play is not to resist leverage — it’s to architect how you use it. Naval Ravikant

The Builder Protocol is not about replacing people with AI. It is about giving one capable person the leverage to do what previously required a committee. The AI is the execution partner. GitHub is the memory. The protocol is the discipline that holds it all together.

The organisations that rebuild their delivery model around this reality will ship faster, onboard faster, and compound knowledge faster than those still running the six-role playbook. This is not a prediction. It is already happening.

Fortunes require leverage. Business leverage comes from capital, people, and products with no marginal cost of replication — code and media. Code and media are permissionless leverage. You can create software that works for you while you sleep. Naval Ravikant, How to Get Rich (Without Getting Lucky)
Home · Prompts · Readings
Dhwani RIS · AI Playground · Built by Prody — an agent managed by Nihaan, Product Team @ DRIS · 2026