Cline rules

1# AI-DLC Adaptive Workflow Rule
2 
3> Inspired by the [AI-Driven Development Life Cycle (AI-DLC)](https://github.com/awslabs/aidlc-workflows) methodology. This rule embeds adaptive software development practices into every Cline session.
4 
5## Core Philosophy
6 
7**The workflow adapts to the work, not the other way around.**
8 
9Not every request needs a full development lifecycle. A one-line bug fix shouldn't go through requirements analysis. But a new multi-service application shouldn't start with code either. This rule ensures the right level of rigor is applied automatically.
10 
11---
12 
13## 🚨 Mandatory: Complexity Assessment
14 
15**Before starting ANY software development task**, you MUST perform a silent complexity assessment. This takes seconds and determines how much process to apply.
16 
17### Assessment Criteria
18 
19Evaluate the request against these dimensions:
20 
21| Dimension | Low (1) | Medium (2) | High (3) |
22|-----------|---------|------------|----------|
23| **Scope** | Single file/function | Multiple files/components | Multiple services/systems |
24| **Risk** | No breaking changes | Could break existing features | Affects production data/users |
25| **Ambiguity** | Crystal clear intent | Some questions needed | Significant unknowns |
26| **Architecture** | Fits existing patterns | Minor new patterns | New architecture needed |
27| **User Impact** | Internal/developer only | Indirect user impact | Direct user-facing changes |
28 
29### Complexity Tiers
30 
31**Sum the scores across all 5 dimensions:**
32 
33- **Score 5–7 → FAST TRACK**: Proceed directly to implementation. No ceremony needed.
34- **Score 8–11 → STANDARD**: Lightweight planning, then implement with approval gates.
35- **Score 12–15 → FULL LIFECYCLE**: Execute the complete Inception → Construction flow.
36 
37---
38 
39## Fast Track (Score 5–7)
40 
41For simple, clear, low-risk requests. Get in, build it, get out.
42 
43**Process:**
441. Confirm understanding of the request with a brief summary.
452. Implement the change.
463. Verify it works (run tests, lint, build).
474. Present the result.
48 
49**Examples:** Bug fixes, small features, config changes, dependency updates, documentation updates, refactoring within a single module.
50 
51---
52 
53## Standard Track (Score 8–11)
54 
55For moderate complexity work that benefits from a plan but doesn't need full lifecycle treatment.
56 
57**Process:**
58 
59### 1. Lightweight Planning (2–5 minutes)
60- Summarize the requirements in 3–5 bullet points.
61- Identify the components/files that will be affected.
62- Note any risks or dependencies.
63- Present the plan to the user for approval.
64 
65### 2. Implementation with Gates
66- Create a code generation plan (checklist of files to create/modify).
67- Get user approval on the plan.
68- Implement the approved plan.
69- Write tests alongside the implementation.
70 
71### 3. Verification
72- Run build and tests.
73- Present results with a summary of what was done.
74 
75**Examples:** New feature with 2–3 components, API integration, database schema changes, moderate refactoring across multiple files.
76 
77---
78 
79## Full Lifecycle (Score 12–15)
80 
81For complex, high-risk, or ambiguous work that needs the full AI-DLC treatment.
82 
83**Process:**
84 
85### 🔵 Inception Phase
86Execute these stages, adapting depth to the specific project:
87 
881. **Workspace Detection** — Scan the codebase, determine greenfield/brownfield, identify tech stack.
89 
902. **Requirements Analysis** — Gather and document requirements:
91   - Functional requirements (what should it do?)
92   - Non-functional requirements (performance, security, scalability)
93   - Constraints and assumptions
94   - Write to `aidlc-docs/inception/requirements/requirements.md`
95 
963. **User Stories** (if user-facing) — Generate stories with acceptance criteria:
97   - Personas, stories in As-a/I-want/So-that format
98   - Acceptance criteria in Given-When-Then format
99   - Write to `aidlc-docs/inception/user-stories/user-stories.md`
100 
1014. **Application Design** (if new architecture needed) — Design the system:
102   - Component architecture and relationships
103   - Data models and API contracts
104   - Technology decisions with rationale
105   - Write to `aidlc-docs/inception/application-design/`
106 
1075. **Units of Work** (if multi-component) — Break down into buildable units:
108   - Define scope, dependencies, and build order for each unit
109   - Write to `aidlc-docs/inception/units-of-work.md`
110 
111**Each stage has an approval gate.** Present findings, get user approval, then proceed.
112 
113### 🟢 Construction Phase
114For each unit of work:
115 
1161. **Functional Design** (if complex logic) — Design data models, business rules, interfaces before coding.
117 
1182. **NFR Assessment** (if performance/security/scale matters) — Identify requirements and design patterns.
119 
1203. **Code Generation** (always) — Two parts:
121   - **Plan**: Checklist of files, functions, dependencies → get approval
122   - **Execute**: Build the approved plan, writing tests alongside code
123 
1244. **Build & Test** — After all units: verify build, run tests, report results.
125 
126**Each stage has an approval gate.** Present work, get approval, then proceed.
127 
128---
129 
130## Approval Gates
131 
132At every significant decision point, you MUST pause and get explicit user approval before proceeding. This is non-negotiable at all complexity tiers.
133 
134**Approval gate format:**
135 
136```
137[Stage] Complete — [Brief Summary]
138 
139Key outputs: [what was produced]
140Key decisions: [what was decided]
141 
142How would you like to proceed?
143```
144 
145Present clear options (approve / request changes / discuss further).
146 
147**Rules:**
148- NEVER proceed to the next stage without approval.
149- NEVER silently skip a stage — always explain why a stage is being skipped and confirm.
150- If the user wants to override the recommended tier (e.g., "just build it"), respect their choice but note what's being skipped.
151 
152---
153 
154## Progress Tracking
155 
156For Standard and Full Lifecycle tracks, maintain an `aidlc-docs/aidlc-state.md` file that records:
157 
158```markdown
159# AI-DLC State
160 
161## Project Context
162- Request: [original user request]
163- Complexity: [Fast Track / Standard / Full Lifecycle] (Score: N)
164- Workspace: [Greenfield / Brownfield]
165- Started: [timestamp]
166 
167## Stage Progress
168- [x] Complexity Assessment
169- [x/⏭️] Stage Name — [Completed / Skipped: reason]
170- [ ] Next Stage
171...
172```
173 
174Update this file after each stage completion. This enables session continuity — if the conversation resets, read this file to resume where you left off.
175 
176---
177 
178## Audit Trail
179 
180For Full Lifecycle track, maintain an `aidlc-docs/audit.md` that logs every significant interaction:
181 
182```markdown
183## [Stage Name]
184**Timestamp**: [ISO 8601]
185**User Input**: "[exact user input]"
186**AI Action**: "[what was done]"
187**Decision**: "[what was decided and why]"
188---
189```
190 
191This creates accountability and traceability for complex projects.
192 
193---
194 
195## Key Principles
196 
1971. **Adapt, don't impose.** Match the process to the work. Never apply heavy process to simple tasks.
1982. **Plan before you code** — but only as much as the situation demands.
1993. **The human is always in control.** Propose, don't dictate. Every gate needs approval.
2004. **Document decisions, not just code.** Future-you (or future-Cline) needs to understand WHY, not just WHAT.
2015. **Complete each unit fully** before starting the next. Don't scatter partial implementations across the codebase.
2026. **Test alongside code.** Tests are not an afterthought — they're part of code generation.
2037. **Fail fast, iterate.** If something isn't working at the design stage, catch it there — not after 500 lines of code.
204