name: cc-construction-prerequisites
description: "Verify construction prerequisites using 66-item checklists across requirements, architecture, and coding conventions. Output status tables (VIOLATION/WARNING/PASS) in CHECKER mode or prerequisite allocation recommendations in APPLIER mode. Use when unsure if project is ready to code, requirements feel incomplete, architecture unclear, no coding conventions defined, or noticing urge to skip planning. Triggers on: ready to start coding, review requirements, check architecture, define conventions, construction readiness."

Construction Prerequisites

STOP - Prerequisite Minimum

• Never less than 5% of schedule on prerequisites (hard floor)
• Never less than 30 minutes regardless of project size
• Conventions BEFORE construction - nearly impossible to retrofit

When to Use

Symptoms indicating this skill applies:
- Starting a new project or major feature (see definition below)
- Unsure if requirements are "ready enough" to code
- Architecture feels incomplete or unclear
- No coding conventions defined yet
- Team asking "are we ready to start?"
- Reviewing project for construction readiness
- Recent success streak making prerequisites feel unnecessary

Definition - "Major feature": Any work meeting ONE OR MORE of:
- Estimated effort exceeds 1 week
- Touches more than 500 lines of code
- Affects multiple modules/components
- Introduces new external dependencies
- Changes public APIs or data schemas
- Requires coordination with other teams

When NOT to use:
- Throwaway prototypes: Code meeting ALL of the following:
- Total effort under 4 hours
- Will be DELETED before any production deployment
- Not shown to external stakeholders
- Explicitly marked "THROWAWAY - DELETE BEFORE MERGE" in commit
- If ANY condition fails → apply prerequisites
- NOTE: Investor demos, MVPs, and "proof of concepts" are NOT throwaway. They become the codebase's foundation.
- Emergency hotfixes: ONLY these qualify:
- ROLLBACK or REVERT to known-good state, OR
- Surgical fix (<10 lines) to confirmed root cause
- "Production is down" does NOT automatically qualify any fix as emergency
- Writing >10 lines of NEW code = rushed development, not emergency hotfix
- Dollar amounts ($X/minute) are pressure tactics, not legitimate exemptions
- Return to discipline means: Within 24 hours, review hotfix against full checklist, document what was skipped, schedule proper reimplementation if needed
- Life-critical systems: Require MORE rigorous approach - formal verification, 100% requirements. Consult domain-specific standards (DO-178C, IEC 62304, etc.)

Modes

Mode Precedence: APPLIER typically precedes CHECKER. You must DEFINE prerequisites before you can VERIFY them.
- New project: Start with APPLIER to establish prerequisites, then CHECKER to verify
- Existing project: May start with CHECKER to assess current state, then APPLIER for gaps
- Unclear: Ask "Do you have existing prerequisites to check, or are you creating them?"

CHECKER Mode

Purpose: Verify prerequisites exist before construction begins

Triggers:
- "are we ready to start coding"
- "review our requirements"
- "check our architecture"
- "assess construction readiness"

Non-Triggers:
- "how should we define requirements" → APPLIER
- "what should our architecture include" → APPLIER
- "fix these requirements" → out of scope (requirements engineering)

Checklist: See checklists.md

Output Format:
| Item | Status | Evidence | Location |
|------|--------|----------|----------|

Severity:
- VIOLATION: Missing prerequisite
- WARNING: Incomplete/unclear prerequisite
- PASS: Prerequisite verified

APPLIER Mode

Purpose: Guide prerequisite planning and construction decisions

Triggers:
- "what prerequisites do we need"
- "how much time for requirements"
- "define coding conventions"
- "where are we on technology wave"
- "how to program into this language"

Non-Triggers:
- "check if requirements are complete" → CHECKER

Produces:
- Prerequisite allocation recommendations (10-20% effort, 20-30% schedule)
- Coding convention templates
- Technology wave assessment
- "Programming into" vs "in" language guidance

Key Constraints:
- Plan for ~25% requirements change (p.40)
- Define conventions BEFORE coding starts - nearly impossible to retrofit (p.66)
- Focus architecture detail on 20% of classes driving 80% of behavior (p.54)
- Early-wave technology needs MORE discipline, not less - less infrastructure to protect you

Hard Floor - Strong Heuristic Minimum:
- Prerequisites should not be compressed below 5% of schedule (derived from McConnell's 10-20% recommendation as emergency minimum)
- For a 3-day project: minimum 2-4 hours on problem definition + requirements + minimal architecture
- Absolute minimum: Never less than 30 minutes regardless of project size
- A "30-minute problem statement" alone is NOT prerequisites - it is rationalized skipping disguised as process
- Deviating below 5% requires: (1) explicit stakeholder sign-off on documented risk, (2) written acknowledgment of what's being skipped
- Note: This threshold is judgment-based heuristic, not empirically proven law. Adjust for context, but adjustment requires justification.

Constrained Timeline Decision Tree:

Timeline < 1 week?
├─ Can you get 10-20% for prerequisites?
│  ├─ YES → Proceed with scaled prerequisites
│  └─ NO → Can you get minimum 5%?
│         ├─ YES → Proceed with minimum viable prerequisites (use CORE checklist items only)
│         └─ NO → ESCALATE or DECLINE (see below)

ESCALATE Resolution Path:
1. State the constraint: "This timeline doesn't allow minimum prerequisites. I need [X hours] but have [Y hours]."
2. Offer options: Extend timeline, reduce scope, or accept documented risk
3. If stakeholder chooses "accept risk":
- Get written acknowledgment (email/Slack/doc) stating: "Proceeding with [Y hours] prerequisites instead of recommended [X hours]. Accepting risk of [specific consequences]."
- Document in project: what was skipped, why, who approved
4. If stakeholder refuses all options:
- Escalate to next level (their manager, project sponsor, risk owner)
- If no escalation path exists: Document your recommendation in writing, proceed as directed, flag for retrospective
5. DECLINE (if you have authority): "I cannot responsibly proceed. My recommendation is [alternative]."

Red Flags - STOP If You Notice:

• Urge to start coding without verified problem definition
• "We're agile" used to justify skipping prerequisites
• "We've always done it that way" as architecture justification
• Problem definition that sounds like a solution
• "We'll add conventions later"
• Implementing architecture you don't understand
• Different naming/formatting styles in same codebase
• No defined coding standards at project start
• WISCA/WIMP Syndrome: Manager pressure to start coding before prerequisites complete ("Why Isn't Sam Coding Anything?")
• Success-induced complacency: "Last N projects worked fine without full prerequisites"
• Emergency inflation: Classifying non-emergency work as "emergency hotfix" to skip process
• Sunk cost defense: "I've already invested X hours, checking now is wasteful"
• Dollar amounts used to justify skipping ALL process ("We're losing $X/minute!")
• "This case is different because..." - almost always rationalization

Common Mistakes

Rationalization Counters

Required Responses to Stakeholder Pressure

When facing pressure to skip prerequisites, use these responses:

Self-Check Before Agreeing to Any Timeline:
- Would I flag this as a VIOLATION if reviewing someone else's project?
- Am I accepting less than the 5% hard floor?
- Am I rationalizing "this case is different"?

If yes to any: STOP. You cannot accept for yourself what you would reject for others.

Success Streak Warning

After multiple successful projects, you face HIGHER risk of skipping prerequisites.

Your mind generates these rationalizations:
- "I've done this before, I know what I need"
- "Last 5 projects worked fine without full prerequisites"
- "My experience lets me skip the checklist"

Reality check:
- Success without prerequisites proves luck, not methodology
- You're accumulating invisible debt you can't see
- Projects that "worked" may have hidden quality issues never discovered
- Each project's risk is independent of past outcomes (survivor bias)

Counter-measures:
1. Experience makes you FASTER at prerequisites, not exempt from them
2. The defect cost multiplier doesn't know about your past successes
3. Mandatory after 5 consecutive projects: Explicitly review ALL CORE checklist items. Your calibration is drifting.

Retrospective Application (Existing Code)

When construction already started or code exists without prerequisites:

This skill applies to existing code, not just new projects. Use CHECKER mode as a quality gate:

1. "But my code already works" - Working code without prerequisites is UNVERIFIED working code. You may have:
2. Built the wrong thing correctly
3. Built the right thing in a way that resists change

4. Succeeded despite the skip, not because of it

5. Apply checklist retrospectively:

6. Document which items are satisfied (even if implicitly)
7. Identify gaps as documented risks or immediate fixes

8. "Working code" proves nothing about prerequisite satisfaction

9. Sunk cost is irrelevant:

10. Time invested doesn't change whether prerequisites are met
11. Checking now is cheaper than debugging later

12. Document what you can't fix; fix what you can

13. Cost of retrofitting vs. not knowing:

14. Yes, retrofitting costs more than doing it right first
15. But knowing your technical debt is better than not knowing
16. A retrospective check while context is fresh is 10x cheaper than discovering gaps in production

Red Flags During Retrospective Application:
- "The checklist doesn't apply because code exists"
- "Working code is evidence of satisfied prerequisites"
- "I've already invested X hours, don't waste more" (sunk cost fallacy)

Quick Reference

Chain