Effort
Context Phase effort depends on the solution complexity defined in Phase 2. The relationship is proportional: more complex solutions require more Agents, more Rules, and more Skills — and therefore more depth in design, validation, and iteration.
Effort by complexity
| Scenario | Required activities | Depth |
|---|---|---|
| Bounded solution (Q1-2) | Base Rules + 4-5 Agents + PRD + Architecture Document + 10-20 Skills. 1-2 validation cycles. | Rules cover obvious decisions. The Agent chain is standard. Skills are straightforward and self-contained. |
| Medium solution (Q2-3) | Complete Rules + calibrated Agents + 20-50 Skills. Multiple validations. Active QA at every chain link. | Rules require level calibration. Agents need carefully defined boundaries. Each Skill requires self-containment verification. |
| Complex solution (Q3-4) | Extensive Rules + specialized Agents + 50+ Skills. Iterative validation with stakeholders. QA at every link. | Rules cover cross-subsystem integration. Agents have complex gap protocols. Skills include cross-dependencies requiring rigorous sequencing. |
The quadrant reference (Q1-Q4) corresponds to the complexity assessment from Phase 2's Solution Brief: Q1 is the simplest (low technical + low organizational complexity), Q4 is the most complex.
The proportion that matters
If the effort invested in Context Phase exceeds the construction effort, you're over-specifying. Rules are too detailed, Skills are too prescriptive, and Agents have no room to use judgment.
If the effort is less than a third of construction effort, there are implicit Rules and incomplete Skills. Agents will fill gaps with invention — producing confident, plausible, and wrong outputs.
The optimal proportion is for Context Phase effort to represent between one-third and one-half of total construction effort. A rigorous context system makes construction predictable and fluid.
Effort distribution
Understanding how effort distributes across Phase 3 activities helps plan and detect imbalances. The most common mistake is spending the majority of effort on document generation and insufficient effort on validation.
The optimal proportion: Context Phase should represent between one-third and one-half of total construction effort. A rigorous context system makes construction predictable and fluid. Less than a third means implicit Rules and incomplete Skills. More than equal means over-specification.
| Activity | Proportion of effort | What determines depth |
|---|---|---|
| Establish Rules | 15-20% | Number of global decisions in the Solution Brief. More constraints mean more Rules to make explicit. |
| Design Agent Chain | 10-15% | Number of specialized roles needed. Most projects use the standard 5-Agent chain. |
| Generate PRD | 15-25% | Number of use cases and Solution Brief complexity. More use cases mean a larger PRD. |
| Generate Architecture | 15-25% | Number of technical decisions. More integrations and AI components mean more ADRs. |
| Decompose into Skills | 20-25% | Number of Skills. A well-specified Skill requires defining objective, specific context, acceptance criteria, dependencies, and constraints. |
| Validate through Outputs | 10-20% | Number of validation cycles. First pass rarely succeeds. Budget 2-3 iterations. |
Signals of insufficient effort
- Agents ask frequent questions during Skill execution — the Skills don't contain enough context.
- Outputs are inconsistent across Agents — the Rules don't cover enough ground.
- The QA Agent flags many issues per Skill — the context system has systematic gaps.
- Stakeholders reject outputs as "not what we discussed" — the traceability chain has breaks.
- The team discovers undocumented decisions during construction — there are implicit Rules.
Signals of excessive effort
- The project-context.md exceeds 10 pages — you're likely specifying decisions that should be delegated (Level 1-2).
- Skills include pseudocode or step-by-step implementation details — you're doing the Agent's job instead of defining what needs to be done.
- Validation cycles produce "perfect" outputs on first pass — if nothing needs adjustment, the context system is probably over-specified.
- Agents produce rigid, mechanical output — the Over-Context anti-pattern.
- The team debates Level 1-2 decisions for hours — delegation decisions shouldn't consume significant effort.
Team composition during Phase 3
| Role | Dedication | What they do |
|---|---|---|
| Context Engineer | Full dedication (lead) | Designs Rules, Agents, Skills. Runs validation cycles. Owns the Decision Log. |
| Tech Lead | High dedication | Validates architecture decisions. Reviews the Architect Agent's output. Ensures technical feasibility. |
| Product Lead | Partial dedication | Validates PRD. Participates in output validation. Ensures fidelity to Solution Brief. |
| Stakeholder representatives | On-demand | Participate in output validation (Step 5). Their recognition is the Gate Review criterion. |
The Context Engineer is the full-dedication role. Others contribute at specific moments. The most critical outside participation is stakeholder validation at Step 5 — this is what determines if the Gate Review passes.
Phase 1 (Problem Phase) requires effort centered on research: interviews, synthesis, and validation. Phase 2 (Solution Phase) requires alignment effort: iterations with stakeholders until genuine consensus is reached. Phase 3 (Context Phase) requires systems design effort: Rules, Agents, and Skills that faithfully translate the Problem Statement and Solution Brief. The three discovery-and-design phases together concentrate the majority of the project's intellectual effort — and this is by design. The more effort invested in understanding and structuring, the less rework occurs during construction.