CCT SDLC Framework

An AI-driven SDLC framework — it runs the full software development life cycle (requirements → design → implementation → verification) through structured AI commands, rules, skills, and sub-agents. Built on a docs-first principle: documentation is the source of truth at every stage, code is its output.

Inspired by the feature-dev Claude plugin.

---

Pipeline

Client request → /business → /specification → /implement → Verification
                    BRD          Design+Spec      Code+Tests

Each stage produces an artifact in docs/ that serves as the contract for the next.

---

Module vs Bundle

Two different axes — do not confuse them.

	Module	Bundle
Nature	Business / administrative domain	Technical code unit
Answers	What area of the business this serves	How the code is organized
Examples	administration, billing, analytics	UserBundle, PaymentBundle, ReportBundle
Lives in	docs/business/{module}/, docs/design/{module}/	docs/bundles/{bundle}/, src/Bundles/{Bundle}/
Defined by	Client requirements and business grouping	Source code structure and dependencies

A single module (e.g. analytics) may be implemented across several bundles (ReportBundle, TemplateBundle, ExportBundle). Conversely, one bundle can serve features from multiple modules.

Module structure (docs/business/ + docs/design/)

docs/business/{module}/
├── {module}.md        # BRD index for the module
└── {slug}.md          # individual BRD (one per feature request)

docs/design/{module}/
├── {module}.md        # design index for the module
└── {slug}.md          # business rules, user flows, decisions

Bundle structure (docs/bundles/ + code)

docs/bundles/{bundle}/
├── {bundle}.md        # bundle overview: entities, services, API, frontend
└── {feature}.md       # feature-level spec (code map, contracts, sub-tasks)

src/Bundles/{Bundle}/
├── Entity/  Repository/  Service/  Controller/  DTO/
├── ...                # backend layers
└── frontend/          # pages, components, composables, styles

---

Commands

.claude/commands/

Command	Purpose
/business	Generate a BRD from a client description (Create) or update an existing one (Update)
/specification	BRD → technical design (docs/design/) + feature spec (docs/bundles/) with sub-task breakdown
/implement	Implement from ready docs — gated sub-tasks, tests, review, API docs sync
/feature	Full pipeline in one session (business → spec → implement) without separate approval stages
/improvement	Change existing functionality — delta analysis, backward compatibility, in-place doc updates

---

Rules

.claude/rules/ — always-loaded standards.

Rule	Contents
workflow.md	Development pipeline, docs-first principle
ai.md	AI strategy: MCP order (qmd → Serena → fallback), token efficiency
documentation.md	docs/ layout, when to read/update
architecture.md	Structure, layers, naming
coding-standards.md	Strict types, SOLID, conventions

---

Skills

.claude/skills/ — loaded by context.

Skill	Trigger
docs	Compare code to documentation, classify mismatches
review	Code review — checklist, confidence scoring
security	Security checklist — authorization, injection, XSS, data leaks
commit	Generate commit messages

---

Agents

.claude/agents/ — sub-agents for pipelines: code-explorer, code-architect, code-implementer, code-reviewer, test-author, docs-author, api-docs-author.

---

Docs vault

docs/ — an Obsidian vault. Entry point: docs/VAULT.md.

Layer	Answers
business/	What the client asked for — BRDs, risks
design/	What the feature does and why — business rules
bundles/	How a bundle is built — entities, services, APIs
architecture/	System-level — cross-cutting concerns, decisions (ADR)
testing/	How quality is validated
infrastructure/	How to run and operate

Templates live in docs/_templates/.

---

Entry point

CLAUDE.md — loaded automatically every session; links to the core rules.