@hanzlaa/rcode 2.2.0 → 2.3.2

package/rihal/references/karpathy-guidelines.md

@@ -1,79 +1,11 @@
-# Karpathy Coding Guidelines
+# Karpathy Guidelines — Quick Reference
 
-Behavioral guidelines derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls. Every rihal agent that writes, reviews, or refactors code must internalize these four principles.
+Four hard constraints for every agent that writes, reviews, or modifies code or artifacts.
+Full text with Rihal-specific application notes: `@.rihal/references/karpathy-guidelines-full.md`
 
-**Tradeoff:** These bias toward caution over speed. For trivial tasks, use judgment.
+1. **Think first (P1)** — State assumptions explicitly before acting. If scope is ambiguous, ask. Never guess silently.
+2. **Simplicity (P2)** — Minimum code/scope that solves the problem. No speculative features, abstractions, or error handling for impossible cases.
+3. **Surgical (P3)** — Touch only what the task requires. Don't improve adjacent code, don't refactor what isn't broken.
+4. **Goal-driven (P4)** — Define a verifiable success criterion before starting. "Done when: X can be verified externally."
 
-## 1. Think Before Coding
-
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
-
-Before implementing:
-- State assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them — don't pick silently.
-- If a simpler approach exists, say so. Push back when warranted.
-- If something is unclear, stop. Name what's confusing. Ask.
-
-**Rihal application:** In Round 1 of council/chain, every agent's response must include an `## Assumptions` block listing load-bearing assumptions. rihal-planner must ask via AskUserQuestion before writing a plan when scope is ambiguous. rihal-executor must stop on Rule 4 deviations and return a checkpoint, not silently guess.
-
-## 2. Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios.
-- If you write 200 lines and it could be 50, rewrite it.
-
-Test: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
-
-**Rihal application:** rihal-planner tasks must be single-purpose. rihal-executor must not add abstractions during task execution (deviation Rule 2 applies only to missing critical functionality, not speculative flexibility). rihal-code-review explicitly flags overengineering.
-
-## 3. Surgical Changes
-
-**Touch only what you must. Clean up only your own mess.**
-
-When editing existing code:
-- Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it — don't delete it.
-
-When your changes create orphans:
-- Remove imports/variables/functions that YOUR changes made unused.
-- Don't remove pre-existing dead code unless asked.
-
-The test: Every changed line should trace directly to the user's request.
-
-**Rihal application:** rihal-executor commits must only include files its tasks touched. The deviation scope boundary (out-of-scope warnings logged to deferred-items.md, not fixed) enforces this. rihal-code-review-fix must not change style in files it's auditing.
-
-## 4. Goal-Driven Execution
-
-**Define success criteria. Loop until verified.**
-
-Transform tasks into verifiable goals:
-- "Add validation" → "Write tests for invalid inputs, then make them pass"
-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
-- "Refactor X" → "Ensure tests pass before and after"
-
-For multi-step tasks, state a brief plan:
-```
-1. [Step] → verify: [check]
-2. [Step] → verify: [check]
-```
-
-Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
-
-**Rihal application:** Every task in a SPRINT.md must have a "Done when:" clause that's externally verifiable. rihal-executor self-check loop verifies Done-when conditions were met. rihal-sprint-checker rejects plans where tasks have vague success criteria.
-
-## Enforcement
-
-Agents that write or modify code (rihal-executor, rihal-planner, rihal-tech-writer, rihal-codebase-mapper when producing code docs) must:
-1. @-include this file
-2. Apply the 4 principles as hard constraints, not suggestions
-3. Reference the specific principle when refusing to make a change (e.g., "Declining per Karpathy #3: that's adjacent to the requested change but not part of it")
-
-## Credit
-
-Original principles by Andrej Karpathy. Reference implementation by Forrest Chang at github.com/forrestchang/andrej-karpathy-skills. Adapted and extended for rihal's multi-agent architecture.
+When refusing a change, cite the principle: `"Declining per Karpathy P3 — that's adjacent to the requested change."`

package/rihal/references/model-profile-resolution.md

@@ -0,0 +1,8 @@
+# Model Profile Resolution
+
+Workflows pick a model via `node .rihal/bin/rihal-tools.cjs resolve-model
+<role>`, which reads `.rihal/config.yaml` `model_profile` and returns the
+concrete model id for that role per `rihal/config/model-profiles.json`.
+
+If `model_profile` is unset, default is `balanced`. Unknown profile falls
+back to `balanced` with a stderr warning.

package/rihal/references/phase-argument-parsing.md

@@ -0,0 +1,11 @@
+# Phase Argument Parsing
+
+Workflows accept a phase argument in two forms:
+
+- **Numeric**: `01`, `2`, `02.1` — resolved via
+  `node .rihal/bin/rihal-tools.cjs init phase-op "$ARG"` to the matching
+  phase directory under `.planning/phases/`.
+- **Path**: a direct `.planning/phases/<slug>/PLAN.md` path — used as-is.
+
+If the resolver returns `phase_found: false`, workflows must STOP with a
+"phase not found" message rather than fabricating a target.

package/rihal/references/revision-loop.md

@@ -0,0 +1,11 @@
+# Plan Revision Loop
+
+When `workflow.plan_checker` is enabled (`/rihal:settings`), `/rihal:plan`
+runs the rihal-plan-checker after the planner. Findings drive a bounded
+revision loop:
+
+1. Planner produces PLAN.md.
+2. Plan-checker scores against goal-backward criteria.
+3. If BLOCK / FLAG: planner revises with the findings as added input.
+4. Up to 2 revision rounds. After that, surface to user for manual
+   confirmation rather than loop indefinitely.

package/rihal/references/universal-anti-patterns.md

@@ -0,0 +1,15 @@
+# Universal Anti-Patterns (Discuss-Phase)
+
+Common failure modes the discuss workflow checks for:
+
+- **Solution-first framing**: jumping to implementation before constraints
+  are explicit.
+- **Hidden binary choice**: presenting a "decision" that has only one
+  viable option.
+- **Unowned action**: a "we should X" with no owner or deadline.
+- **Sunk-cost continuation**: defending an existing plan instead of
+  evaluating fresh evidence.
+- **Scope inflation**: bundling new work into the current decision.
+
+Discuss-phase flags any of these and asks for explicit framing before
+proceeding.

package/rihal/skills/actions/1-analysis/research/rihal-domain-research/SKILL.md

@@ -7,8 +7,19 @@ description: >
   me understand X industry", or "domain research for". Do NOT use for market
   analysis (use rihal-market-research) or technical feasibility (use
   rihal-technical-research).
+triggers:
+  - "research this domain"
+  - "domain deep dive"
+  - "explain this industry"
+  - "help
+  me understand X industry"
+  - "domain research for"
 ---
 
+## Overview
+
+Conduct industry domain deep-dive research to build subject matter expertise on a specific business domain.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/1-analysis/research/rihal-market-research/SKILL.md

@@ -6,8 +6,19 @@ description: >
   "competitive analysis", "market analysis for", "size the market",
   "competitor scan", or "analyze the market for X". Do NOT use for domain
   deep-dives (use rihal-domain-research) or technical feasibility.
+triggers:
+  - "market research"
+  - "competitive analysis"
+  - "market analysis for"
+  - "size the market"
+  - "competitor scan"
+  - "analyze the market for X"
 ---
 
+## Overview
+
+Analyze market size, competitive landscape, customer needs, and trends for a product or industry.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/1-analysis/research/rihal-technical-research/SKILL.md

@@ -7,8 +7,21 @@ description: >
   options", "how would we build X", "what stack for", or "technical
   feasibility for". Do NOT use for final architecture decisions (use
   rihal-create-architecture) or market analysis.
+triggers:
+  - "technical research"
+  - "feasibility study"
+  - "research implementation
+  options"
+  - "how would we build X"
+  - "what stack for"
+  - "technical
+  feasibility for"
 ---
 
+## Overview
+
+Research technical feasibility, architecture options, and implementation approaches for a proposed product or feature.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/1-analysis/rihal-document-project/SKILL.md

@@ -6,8 +6,19 @@ description: >
   "document this project", "analyze this codebase", "generate docs for
   existing code", "brownfield analysis", or "create LLM-friendly docs". Do
   NOT use for writing net-new docs (use write-document prompt).
+triggers:
+  - "document this project"
+  - "analyze this codebase"
+  - "generate docs for
+  existing code"
+  - "brownfield analysis"
+  - "create LLM-friendly docs"
 ---
 
+## Overview
+
+Analyze an existing codebase and produce documentation for both human and LLM consumption (brownfield analysis).
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/1-analysis/rihal-prfaq/SKILL.md

@@ -1,8 +1,20 @@
 ---
 name: rihal-prfaq
 description: Working Backwards PRFAQ challenge to forge product concepts. Use when the user requests to 'create a PRFAQ', 'work backwards', or 'run the PRFAQ challenge'.
+triggers:
+  - "prfaq"
 ---
 
+## Do NOT use this skill for
+
+- **Refining an existing PRD** — use `rihal-create-prd` or `rihal-edit-prd`.
+- **Brainstorming raw ideas** before there's a concept — use `rihal-brainstorming` first; PRFAQ assumes a candidate concept exists.
+- **Sprint or phase planning** — use `rihal-sprint-planning` / `rihal-create-milestone`.
+- **Pure market research with no product hypothesis** — use a research workflow.
+- **Single-question Q&A** — PRFAQ runs a multi-stage gauntlet; for a one-off answer, just answer.
+
+If the user asks to "validate" or "polish" an existing PRD, redirect to `rihal-validate-prd`.
+
 ## Workflow
 
 

package/rihal/skills/actions/1-analysis/rihal-product-brief/SKILL.md

@@ -6,6 +6,13 @@ description: >
   brief", "draft a brief for", "product briefing", or "create the brief". Do
   NOT use for full PRD (use rihal-create-prd) or market analysis alone (use
   rihal-market-research).
+triggers:
+  - "create a product brief"
+  - "write a product
+  brief"
+  - "draft a brief for"
+  - "product briefing"
+  - "create the brief"
 ---
 
 ## Workflow

package/rihal/skills/actions/2-plan/rihal-create-epics-and-stories/SKILL.md

@@ -6,8 +6,20 @@ description: >
   the epic list", "epic and story breakdown", "decompose the PRD", or
   "create the backlog". Do NOT use to prepare a single story for dev (use
   rihal-create-story).
+triggers:
+  - "create epics"
+  - "break this into stories"
+  - "generate
+  the epic list"
+  - "epic and story breakdown"
+  - "decompose the PRD"
+  - "create the backlog"
 ---
 
+## Overview
+
+Break a PRD into epics and user stories that drive development.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.
@@ -15,9 +27,11 @@ Follow the instructions in ./workflow.md.
 ## Output Format
 
 - Produces .rihal/phases/{phase}/epics.md with hierarchical structure
-- Each epic has: Title | Goal | Stories (list) | Priority | Estimate
+- Each epic has: Title | Goal | Assumptions | Stories (list) | Priority | Estimate
 - Each story is independently testable and under 4-hour estimate
 - Do NOT create epics larger than 10 stories — split further
+- Every epic must include an `Assumptions` line — at minimum one entry; "none" is not acceptable
+- Every story must have a one-line verifiable AC before being listed — vague stories get flagged and blocked
 
 ## Examples
 

package/rihal/skills/actions/2-plan/rihal-create-milestone/SKILL.md

@@ -8,17 +8,37 @@ description: >
   lifecycle (use rihal-new-milestone / rihal-complete-milestone), for
   decomposing one milestone into epics (use rihal-create-epics-and-stories),
   or for single-phase planning (use rihal-plan-phase).
+triggers:
+  - "create milestones"
+  - "plan milestones"
+  - "create roadmap"
+  - "what milestones do I need"
+  - "break this project into
+  milestones"
+  - "roadmap for this product"
 ---
 
+## Overview
+
+Design the milestone roadmap (M1..Mn) for a project from an approved PRD.
+
 Follow the instructions in ./workflow.md.
 
 ## Output Format
 
 - Output: ROADMAP.md in `{planning_artifacts}/`
-- Structure: per milestone — Name, Window (dates), Goal (one sentence), Acceptance criteria, Kill criteria (binary), Phases (stub list), then a trailing Backlog / parking lot section
+- Structure: per milestone — Name, Window (dates), Goal (one sentence), Assumptions, Acceptance criteria, Kill criteria (binary), Phases (stub list), then a trailing Backlog / parking lot section
 - Each kill criterion must be binary (number + threshold), not adjectival
 - Every milestone has an explicit window with start + end dates
+- Every milestone must include an `Assumptions` block — decisions that, if wrong, invalidate this milestone's scope
 - Do NOT include: unquantified success language ("grow the user base"), open-ended milestones without dates, or more than 6 active milestones in one roadmap (split into v1/v2 if needed)
+- If a milestone goal cannot be expressed as a single verifiable sentence, split it into two milestones
+
+## Workflow
+
+1. Read the user request and extract key parameters.
+2. Execute the skill logic as described in the Overview.
+3. Return output in the format specified below.
 
 ## Examples
 

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-10-complete.md

@@ -33,7 +33,7 @@ Hard deadline:  {deadline or "none specified"}
 [{completedAt}]
 ```
 
-### 3. Next-step menu (intent-based, mirrors the GSD /progress Route A/B/C pattern)
+### 3. Next-step menu (intent-based Route A/B/C pattern)
 
 ```
 What's next?

package/rihal/skills/actions/2-plan/rihal-create-prd/SKILL.md

@@ -7,8 +7,21 @@ description: >
   "draft requirements for", "new product spec", or "start a PRD". Do NOT use
   for updating an existing PRD (use rihal-edit-prd), or validating an
   existing PRD (use rihal-validate-prd).
+triggers:
+  - "create a PRD"
+  - "write product
+  requirements document"
+  - "lets make a PRD"
+  - "I want to create a new PRD"
+  - "draft requirements for"
+  - "new product spec"
+  - "start a PRD"
 ---
 
+## Overview
+
+Create a new Product Requirements Document from scratch through guided facilitation.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.
@@ -21,6 +34,19 @@ Follow the instructions in ./workflow.md.
 - Every section has explicit owner and deadline
 - Do NOT include: vague verbs ("optimize"), unquantified metrics, or requirements without owners
 
+## Fast-path detection
+
+If `$ARGUMENTS` or the opening message contains ALL FOUR of these fields, skip the discovery interview and go straight to drafting:
+
+| Field | Signal words |
+|-------|-------------|
+| Product / feature name | explicit name or noun |
+| Problem statement | "problem is", "users can't", "currently X fails" |
+| Target user | "for X users", "persona is", "audience is" |
+| Scope signal | "must have", "v1 only", "just need", "MVP" |
+
+When fast-pathing: confirm detected fields in one line ("Got it — building {name} for {user} to solve {problem}. Starting PRD draft."), then generate without asking further questions. If any of the four are absent, run the normal interview.
+
 ## Examples
 
 ### Happy Path

package/rihal/skills/actions/2-plan/rihal-create-story/SKILL.md

@@ -6,8 +6,20 @@ description: >
   story {id}", "write the story for", "get next story ready for dev", or
   "assemble story context". Do NOT use to execute a story (use
   rihal-dev-story).
+triggers:
+  - "create the next story"
+  - "prepare a story"
+  - "create
+  story {id}"
+  - "write the story for"
+  - "get next story ready for dev"
+  - "assemble story context"
 ---
 
+## Overview
+
+Prepare a dev-ready user story with full implementation context.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.
@@ -15,10 +27,12 @@ Follow the instructions in ./workflow.md.
 ## Output Format
 
 - Story file at .rihal/phases/{phase}/stories/story-{id}.md
-- Fixed sections: Goal | Context | Tasks (checklist) | Acceptance Criteria | Dependencies | File List (empty) | Dev Agent Record (empty)
+- Fixed sections: Goal | Assumptions | Context | Tasks (checklist) | Acceptance Criteria | Dependencies | File List (empty) | Dev Agent Record (empty)
 - Each task is ≤4 hours, in execution order
-- Acceptance criteria in Given/When/Then
+- Acceptance criteria in Given/When/Then — no criterion is valid unless a test can be written against it
+- `## Assumptions` block is mandatory: list every assumption that, if wrong, would change the story scope
 - Do NOT include implementation details in the story — those emerge during dev
+- If AC cannot be stated in Given/When/Then, stop and ask the user to clarify before generating the story
 
 ## Examples
 

package/rihal/skills/actions/2-plan/rihal-create-ux-design/SKILL.md

@@ -6,8 +6,20 @@ description: >
   when the user says "create UX design", "design the user flow", "wireframe
   this", "UX plan", "design this screen", or "create the design for". Do NOT
   use for UI code (use rihal-dev-story) or visual code review.
+triggers:
+  - "create UX design"
+  - "design the user flow"
+  - "wireframe
+  this"
+  - "UX plan"
+  - "design this screen"
+  - "create the design for"
 ---
 
+## Overview
+
+Guide through realizing a UX design that informs architecture and implementation — user flows, wireframes, design system updates.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/2-plan/rihal-edit-prd/SKILL.md

@@ -6,8 +6,19 @@ description: >
   PRD", "edit the PRD", "add a section to the PRD", "revise requirements",
   or "change the scope in the PRD". Do NOT use to create a new PRD (use
   rihal-create-prd) or to validate quality (use rihal-validate-prd).
+triggers:
+  - "update the
+  PRD"
+  - "edit the PRD"
+  - "add a section to the PRD"
+  - "revise requirements"
+  - "change the scope in the PRD"
 ---
 
+## Overview
+
+Update an existing Product Requirements Document with new sections, revisions, or clarifications.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/2-plan/rihal-frontend-design/SKILL.md

@@ -14,6 +14,19 @@ description: >
   and rihal-agent-zahra (branding expert) for brand alignment. Do
   NOT use for: cloning existing sites (use rihal-clone-website
   instead), pure backend work, or documentation.
+triggers:
+  - "AI slop"
+  - "design this UI"
+  - "build a beautiful frontend"
+  - "distinctive design"
+  - "creative UI"
+  - "unforgettable interface"
+  - "award-winning design"
+  - "not generic"
+  - "bold aesthetic"
+  - "brutalist"
+  - "editorial"
+  - "maximalist"
 license: Adapted from Anthropic's frontend-design skill
 ---
 

package/rihal/skills/actions/2-plan/rihal-validate-prd/SKILL.md

@@ -5,8 +5,20 @@ description: >
   and internal consistency. Activates when the user says "validate the PRD",
   "review the PRD", "check the PRD", "is the PRD ready", "PRD quality
   check", or "audit the PRD". Do NOT use to create or edit a PRD.
+triggers:
+  - "validate the PRD"
+  - "review the PRD"
+  - "check the PRD"
+  - "is the PRD ready"
+  - "PRD quality
+  check"
+  - "audit the PRD"
 ---
 
+## Overview
+
+Validate an existing PRD for comprehensiveness, leanness, organization, and internal consistency.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/3-solutioning/rihal-check-implementation-readiness/SKILL.md

@@ -6,8 +6,20 @@ description: >
   "check implementation readiness", "is this ready for dev", "verify
   alignment", "readiness check", "IR check", or "can we start building". Do
   NOT use during active implementation (use rihal-correct-course instead).
+triggers:
+  - "check implementation readiness"
+  - "is this ready for dev"
+  - "verify
+  alignment"
+  - "readiness check"
+  - "IR check"
+  - "can we start building"
 ---
 
+## Overview
+
+Verify that PRD, UX designs, architecture decisions, and epics/stories are all aligned and ready for implementation.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/3-solutioning/rihal-create-architecture/SKILL.md

@@ -7,8 +7,22 @@ description: >
   architecture record", "lock this technical decision", or "record the
   decision to use X". Do NOT use for implementation code (use
   rihal-dev-story) or sprint planning (use rihal-sprint-planning).
+triggers:
+  - "write an ADR"
+  - "create
+  architecture decision"
+  - "document this architectural choice"
+  - "write an
+  architecture record"
+  - "lock this technical decision"
+  - "record the
+  decision to use X"
 ---
 
+## Overview
+
+Write an Architecture Decision Record (ADR) to lock a significant technical decision.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/3-solutioning/rihal-generate-project-context/SKILL.md

@@ -7,8 +7,20 @@ description: >
   file", "document project conventions", "setup AI context", or "create
   project-context.md". Do NOT use for full project documentation (use
   rihal-document-project).
+triggers:
+  - "generate project context"
+  - "create context
+  file"
+  - "document project conventions"
+  - "setup AI context"
+  - "create
+  project-context.md"
 ---
 
+## Overview
+
+Generate a project-context.md file that summarizes project standards, conventions, tech stack, and key patterns for AI agents to reference.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/4-implementation/rihal-checkpoint-preview/SKILL.md

@@ -1,8 +1,24 @@
 ---
 name: rihal-checkpoint-preview
 description: 'LLM-assisted human-in-the-loop review. Make sense of a change, focus attention where it matters, test. Use when the user says "checkpoint", "human review", or "walk me through this change".'
+triggers:
+  - "checkpoint preview"
 ---
 
+## Overview
+
+Checkpoint preview skill for Rihal Code.
+
+## Do NOT use this skill for
+
+- **Automated code review without a human** — use `/rihal:karpathy-audit` or a code-reviewer agent directly.
+- **Approving a deploy or merge** — this skill explains a change; it does not authorize git push, deploys, or PR merges.
+- **Bug investigation** from scratch — use `/rihal:debug` or the diagnose-issues workflow.
+- **Architecture review of an undelivered design** — this skill reviews delivered code/diffs, not specs.
+- **Sprint retros or milestone closure** — use `rihal-retrospective` or `rihal-complete-milestone`.
+
+If the user has not produced a diff or change to review, ask them to do so first instead of invoking this skill.
+
 ## Workflow
 
 

package/rihal/skills/actions/4-implementation/rihal-code-review/SKILL.md

@@ -6,8 +6,20 @@ description: >
   code review", "do a PR review", "review the diff", "critique this
   implementation", or "CR". Do NOT use for documentation review (use
   rihal-validate-prd or editorial skills).
+triggers:
+  - "review this code"
+  - "run
+  code review"
+  - "do a PR review"
+  - "review the diff"
+  - "critique this
+  implementation"
 ---
 
+## Overview
+
+Review code changes using parallel adversarial review layers and produce actionable findings.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.

package/rihal/skills/actions/4-implementation/rihal-correct-course/SKILL.md

@@ -6,8 +6,21 @@ description: >
   the scope mid-sprint", "we need to pivot", "correct course", "handle scope
   change", or "change story mid-way". Do NOT use for normal sprint updates
   (use rihal-sprint-status).
+triggers:
+  - "course correct"
+  - "change
+  the scope mid-sprint"
+  - "we need to pivot"
+  - "correct course"
+  - "handle scope
+  change"
+  - "change story mid-way"
 ---
 
+## Overview
+
+Course-correct when major change is discovered mid-sprint or mid-implementation.
+
 ## Workflow
 
 Follow the instructions in ./workflow.md.