What is ForgeSDLC?
ForgeSDLC is a software delivery methodology designed for teams that build software alongside AI agents. It combines three elements:
- A discipline lens layer — lightweight, decision-focused Versonas (discipline-focused virtual personas) invoked in sessions when stakes warrant
- A body-of-knowledge system — reusable discipline blueprints that encode engineering best practices
- A lean process philosophy — four core principles for AI-native trade-offs, plus execution principles and lean tenets that keep delivery lean and constitutional (see Forge principles (full list))
How it works
The work cycle
Forge uses a lean default cadence: a short daily sync (Charge, blockers, inspect/adapt) and a regular retrospective for improvement—alongside the prescriptive iteration ceremonies in Blueprints. Discipline Versonas layer on when stakes warrant; they are not a replacement for that rhythm.
- A Spark is created — the atomic work unit, mapped 1:1 to your WBS task hierarchy
- Work proceeds — humans and AI agents collaborate on the Spark
- When a decision point arises, relevant Versonas are invoked — applying the discipline's body of knowledge
- The decision is logged, the journal updates automatically, and work continues
- When the Spark completes, the Charge view reflects the new state
No overhead when none is needed
The key insight: not every task needs a Versona. A straightforward code change doesn't need a DevOps Versona. But a deployment architecture decision does. ForgeSDLC applies process where it matters and stays out of the way everywhere else.
Core vocabulary
| Term | Meaning |
|---|---|
| Spark | The atomic unit of work. Maps 1:1 to a WBS task. One identity — not a "ticket" and a "task" separately. |
| Versonas | Discipline virtual personas (not org roles). In a session they apply discipline knowledge—often including a structured challenge pass or §5-shaped output when the team wants that contract—at decision points; humans own binding decisions. |
| Charge | The live view of work state. Not a Kanban board — a decision-oriented lens on what's active, blocked, or pending review. |
| Blueprint | A reusable package of policies, templates, and bodies of knowledge for a specific discipline (DevOps, Testing, Architecture, etc.). |
| Forge Principles | Four core principles (blog); execution and lean detail on Forge principles. |
Lifecycles and bridges (canonical map)
Forge delivery runs inside SDLC phases (A–F) and product work runs on PDLC (P1–P6), with SDLC nested as the build engine. Start with the product lifecycle and SDLC overview; the full relationship—including phase alignment and handoffs—is in the PDLC–SDLC bridge. Forge’s own cross-lifecycle map is the Forge SDLC–PDLC bridge. For meetings, ownership, and artifacts, see the Forge meetings model, the artifact and decision model on the Blueprints handbook, and the Forge naming reference. For term disambiguation (Versona vs user persona, meetings vs sessions), see CONCEPT-MAP.md in the Blueprints repo. The handbook mirrors the same sources with templates and deeper discipline navigation.
Who is ForgeSDLC for?
- Teams using AI coding assistants (Cursor, Copilot, Windsurf) who find that traditional ceremonies don't account for AI-generated output
- Engineering leaders looking for a methodology that scales without adding process weight
- Startups and scale-ups that want structure without bureaucracy
- Enterprise teams transitioning from heavyweight frameworks (SAFe, PRINCE2) to something leaner
How ForgeSDLC relates to Blueprints
ForgeSDLC is a methodology. Blueprints are the engineering framework that powers it. You can use Blueprints without ForgeSDLC (they work with any methodology). But when combined, the ceremony structure maps directly to blueprint areas — each Versona knows which body of knowledge to apply because the blueprint defines it.