Applying the AI SDLC Framework to Existing Projects
Retrofit the artifact chain onto a project that’s already mid-flight.
Module Overview
Module 8 is the follow-on that takes the framework from a clean greenfield build to the messy reality of existing projects — code already written, documentation scattered or missing, decisions made without ADRs. You learn to assess what exists, reverse-engineer the missing artifacts with AI, prioritize which gap to retrofit first, and re-establish traceability so the framework can run forward from where the project actually is.
| At a glance | |
|---|---|
| Covers | Auditing an existing codebase; reverse-engineering BRD/PRD/Architecture/ADRs with AI; retrofit prioritization; rebuilding traceability; role-specific entry points; applying quality gates mid-flight |
| When it runs | Follow-on — after the core program, for real billable work |
| Builds on | The full framework (Modules 1–7) |
| Leads into | Day-to-day AI-augmented delivery on live client projects |
What you'll produce
A retrofit plan for a real existing project: an assessment of which artifacts exist versus which are missing, the reverse-engineered artifacts that close the highest-priority gaps, and a restored traceability chain you can carry forward.
The Retrofit Principle
The training taught the framework going forward: BRD → PRD → Architecture → Dev Tasks → Code → Tests. On an existing project, you work backward first: reverse-engineer what exists into the artifact format the framework expects, validate it with the team, then use the framework going forward.
The framework does not require a clean start
The artifact chain works the same whether you build it forward from a brief or backward from an existing codebase. The entry point changes. The framework doesn’t.
When you walk into an existing project, the first question is not “how do I use AI on the next feature.” The first question is “where is the artifact chain broken, and what do I retrofit first?”
Never retrofit everything at once
Pick the highest-priority gap, close it, validate with the team, then move to the next. Each retrofitted artifact makes the next one easier. One solid BRD the team trusts is worth more than five rushed artifacts nobody reads.
Lean on Module 3
Every reverse-engineering prompt in this handbook is still a prompt. Module 3 (Prompt Engineering Fundamentals) is the craft underneath them — structure, chain of thought, and least-to-most decomposition for breaking a large codebase audit into manageable passes. When an audit or reverse-engineered artifact comes back thin, refine the prompt using Module 3 before assuming the code lacks the information.
Part 1 — The Artifact Audit
Before retrofitting anything, assess what exists. Load the project’s codebase and existing documentation as context.
What to Check
| Artifact | Where to look | What “exists” means |
|---|---|---|
| BRD | Confluence, Google Docs, SOWs, contracts, email threads | Business objectives written down somewhere |
| PRD | JIRA epics/stories, Notion, spreadsheets, design specs | User stories with acceptance criteria, even if scattered |
| Architecture Document | README, wiki pages, draw.io diagrams, Slack threads | Stack decisions and data models documented somewhere |
| ADRs | Almost always missing | Major technical decisions have written rationale |
| Dev Tasks | JIRA tickets, Trello cards, GitHub issues | Work items exist but may not trace to user stories |
| Tests | Test directories, CI pipelines | Automated tests exist and run |
| Traceability | Cross-references between the above | Requirements trace to code to tests — almost always missing |
The Audit Prompt
[EVALUATE]
Load: project codebase + any existing documentation
(README, wiki exports, SOW, design docs, backlog export)
You are auditing an existing project for AI SDLC framework
compliance. The framework expects this artifact chain:
BRD → PRD → Architecture Document → ADRs → Dev Tasks
→ Code → Tests
Report:
1. Which artifacts exist? (even partially or scattered)
2. Which are completely missing?
3. Where is traceability broken?
4. What is the current test coverage situation?
5. Top 3 gaps to close first, ranked by impact.
Priority Matrix
After the audit, decide where to start:
| Project situation | Start here | Why |
|---|---|---|
| New features, no clear requirements | Retrofit the PRD first | Developers need acceptance criteria before building |
| Architecture unclear or causing tech debt | Retrofit Architecture + ADRs | Team must agree on what the system IS |
| Recurring bugs, unknown expected behavior | Retrofit the BRD first | Without a source of truth, every fix is a guess |
| Code exists but no tests | Retrofit Dev Tasks, then tests from ACs | Tests from code verify what IS, not what SHOULD BE |
| Everything in someone’s head | BRD + PRD + Architecture in parallel | Bus factor of 1 — document before they leave |
Part 2 — Reverse-Engineering Artifacts
Each artifact type has a specific retrofit prompt. The pattern is consistent: load the right inputs, prompt for the artifact in framework format, then validate with the team. One artifact per session — don’t combine.
Code tells you what IS, not what SHOULD BE
A BRD reverse-engineered from code captures current behavior — including bugs. Known bugs should not become documented requirements. The team must review and correct. This review step is not optional.
Retrofit a Business Requirements Document (BRD)
Load: README, existing docs, database schema, API routes or page structure, SOW/contract/project charter.
[APPLY]
Here is an existing project’s codebase and documentation.
Generate a Business Requirements Document (BRD) that captures:
1. Business objectives — what problem does this system solve?
2. Scope — what is in and out of scope based on what exists?
3. Stakeholders — who uses this system and in what capacity?
4. Business rules — what rules does the code enforce?
5. Constraints — technical or business constraints evident
Use numbering BR-01, BR-02, etc.
Flag areas where intent is ambiguous from code alone.
[VALIDATE]
Review this BRD with the team. For each requirement:
- Is this what the system SHOULD do, or just what it currently does?
- Are any bugs documented as requirements? Remove them.
- Are any requirements missing that the team knows about
but the code doesn’t reflect?
Retrofit a Product Requirements Document (PRD)
Load: Retrofitted BRD (do BRD first), JIRA/Trello/GitHub backlog, frontend pages/components, API endpoints.
[APPLY]
Here is the BRD for an existing system and its backlog/codebase.
Generate a PRD with:
1. User stories: "As a [role], I want [action] so that [value]"
2. Acceptance criteria (Given/When/Then or checklist)
3. BRD reference — which BR-XX each story addresses
4. Priority — implemented vs planned
Mark implemented features.
Flag backlog items without BRD traceability.
Retrofit an Architecture Document
Load: BRD and PRD, project structure, package files, database schema, API routes, existing diagrams.
[APPLY]
Here is an existing project’s codebase and documentation.
Generate an Architecture Document covering:
1. System overview
2. Technology stack (with versions)
3. Component architecture
4. Data model (tables, relationships, indexes)
5. API design (routes, methods, auth)
6. Security model
7. Infrastructure and deployment
Reference PRD user stories where applicable.
Flag architectural concerns or inconsistencies.
Retrofit Architecture Decision Records (ADRs)
ADRs are almost always missing. They capture WHY a decision was made, not just what was decided. Even documenting decisions made years ago prevents re-litigation.
[APPLY]
Based on this Architecture Document, identify the 5 most
significant technical decisions (database choice, auth approach,
framework, deployment target, API pattern).
For each, generate an ADR with:
- Title
- Status: Accepted
- Context: what situation prompted the decision
- Decision: what was chosen
- Alternatives: what else was considered
- Consequences: what follows from this decision
Flag inconsistencies between implementation and stated decision.
Retrofit Dev Tasks from Existing Code
Load: Retrofitted PRD with acceptance criteria, codebase, existing tickets/issues.
[APPLY]
Here is a PRD with user stories and acceptance criteria,
and the codebase that implements them.
For each user story, generate Dev Tasks that:
1. Map to what was actually implemented
2. Are atomic and hour-estimated
3. Reference the user story ID (US-XX)
4. Note which tasks are implemented vs have gaps
Output as CSV matching our task schema:
task_id, issue_type, summary, user_story, description,
acceptance_criteria, priority, estimate, story_points,
role, assignee, status, labels, epic_link, dependencies
Part 3 — Establishing Traceability
Once the artifacts exist, connect them. For existing code, build a traceability matrix. For new code, enforce full traceability from Day 1.
The Traceability Matrix Prompt
[APPLY]
Load: docs/brd/, docs/prd/, docs/dev-tasks/, codebase
Create a traceability matrix for this project.
Map each chain link:
Code file/function → Dev Task ID → User Story ID
→ BRD Requirement
For existing code: fill in what you can trace.
For gaps: mark "untraced".
Output as a table with columns:
Code File | Function | Dev Task | User Story | BRD Req | Status
Status = Traced / Partial / Untraced
Enforcement Rules Going Forward
| Rule | Applies to |
|---|---|
| Every commit message references a Dev Task ID (T-XXX) | All new commits from today |
| Every Dev Task references a user story (US-XX) | All new Dev Tasks |
| Every user story references a BRD requirement (BR-XX) | All new user stories |
| Every test references a Dev Task or acceptance criterion | All new tests |
| Don’t re-commit old code with task IDs — use the matrix for existing code | Existing codebase |
Part 4 — Establishing Quality Gates
Three steps: document the current state honestly, enforce gates on all new work, close existing gaps incrementally.
Baseline Assessment Prompt
[EVALUATE]
Load: project codebase, existing docs, CI/CD config
Assess this project against the quality gate checklist:
Artifact chain:
- BRD exists with numbered requirements?
- PRD exists with traceable user stories?
- Architecture document exists?
- ADRs exist for major decisions?
- Dev Tasks exist with acceptance criteria?
Code quality:
- Tests exist and pass in CI?
- Code review process in place?
- Commit messages reference task IDs?
- Error handling follows a consistent pattern?
For each item: PASS / FAIL / PARTIAL / NOT APPLICABLE.
Identify the top 3 gaps to close in the first sprint.
Convergence, not compliance
The existing project will never be “fully compliant” retroactively — and it doesn’t need to be. Every change from this point forward follows the framework. Within 3–4 sprints, the most actively maintained parts will be framework-compliant. The rest converges as it gets touched.
Part 5 — Where Each Role Starts
Your first action on an existing project depends on your role. Each role owns a specific part of the retrofit.
| Role | First action | Artifact owned |
|---|---|---|
| Solutions Designer | Audit existing documentation. Retrofit the BRD. Identify business rules in code but not documented. | BRD |
| Product Manager / Designer | Audit the backlog. Retrofit the PRD from existing stories/tickets + codebase. | PRD |
| Solutions Architect | Audit the codebase and infrastructure. Retrofit the Architecture Document and ADRs. | Architecture + ADRs |
| Tech Lead | Audit existing Dev Tasks/tickets. Retrofit with proper traceability and sizing. | Dev Tasks |
| Developer | Audit test coverage. Map existing code to Dev Tasks. Write tests from acceptance criteria. | Code + Tests |
| QA | Audit what’s testable. Map test coverage to acceptance criteria. Identify critical gaps. | Test coverage |
| DevOps | Audit deployment and infrastructure. Document the deployment process as a runbook. | Infrastructure |
| Project Manager | Coordinate the retrofit priority. Ensure the team isn’t retrofitting everything at once. | Process |
Part 6 — Context Engineering for Retrofit
Existing projects have more context than any AI tool can hold at once. Load deliberately.
| Principle | What it means |
|---|---|
| Don’t load everything | Load the specific subsystem you’re retrofitting, not the entire codebase. |
| Separate sessions per artifact | Retrofit the BRD in one session, the PRD in another. Don’t pivot mid-session. |
| Watch for poisoning | Old documentation may contradict current code. Code is truth for what IS; the team is truth for what SHOULD BE. |
| Use long-context tools for large docs | Confluence dumps and SOWs that exceed context windows belong in tools that support 1M+ token contexts. |
| Fresh session per artifact | BRD generation fills the context with BRD-specific reasoning that may bias PRD output. Start fresh. |
The Full Retrofit Cycle
Putting it all together. This is the E→P→A→V cycle applied to retrofitting an existing project.
[EVALUATE]
Load: project codebase + existing documentation
Run the artifact audit (Part 1 prompt).
Produce the inventory: what exists, what’s missing,
where traceability is broken. Identify top 3 gaps.
[PLAN]
Based on the audit, decide:
- Which artifact to retrofit first (use priority matrix)
- What inputs to load for that specific artifact
- Who on the team reviews the output
- What “done” looks like for this artifact
[APPLY]
Fresh session. Load only the inputs for the target artifact.
Run the appropriate retrofit prompt from Part 2.
One artifact per session. Full output in framework format.
[VALIDATE]
Review the retrofitted artifact with the team.
- Is this what the system SHOULD do, or just what it does?
- Are bugs captured as requirements? Remove them.
- Are requirements missing that the team knows about?
- Does it trace correctly to adjacent artifacts?
Correct inaccuracies. Commit to the project repo.
Then: move to the next artifact in the priority list.
Self-Check
- I can run an artifact audit on an existing project and identify what’s missing, outdated, and where traceability is broken.
- I know how to prioritize which artifact to retrofit first based on the project’s situation.
- I can use AI to reverse-engineer a BRD, PRD, Architecture Document, ADRs, and Dev Tasks from an existing codebase.
- I understand that code tells you what IS, not what SHOULD BE — and that team review is not optional.
- I can create a traceability matrix mapping existing code back to requirements.
- I know how to establish quality gates going forward without retroactively gating existing code.
- I understand convergence over compliance — incremental improvement, not massive retrofit.
- I can apply Evaluate → Plan → Apply → Validate to the retrofit process itself.