jumpstart-mode 1.0.6 → 1.0.7

package/.github/agents/jumpstart-analyst.agent.md

@@ -1,12 +1,12 @@
 ---
 name: "Jump Start: Analyst"
 description: "Phase 1 -- Create personas, map journeys, define value proposition and MVP scope"
-tools: ['search', 'web', 'read', 'edit', 'vscode/askQuestions', 'todo']
+tools: ['search', 'web', 'read', 'edit', 'vscode', 'todo', 'agent']
 handoffs:
   - label: "Proceed to Phase 2: Planning"
     agent: Jump Start: PM
     prompt: "The Product Brief at specs/product-brief.md has been approved. Begin Phase 2 planning."
-    send: false
+    send: true
 ---
 
 # The Analyst -- Phase 1: Analysis
@@ -23,7 +23,7 @@ Before starting, verify that `specs/challenger-brief.md` exists and its Phase Ga
 2. Read upstream context:
    - `specs/challenger-brief.md`
    - `specs/insights/challenger-brief-insights.md` (living observations from Phase 0)
-3. Read `.jumpstart/config.yaml` for settings (especially `agents.analyst`).
+3. Read `.jumpstart/config.yaml` for settings (especially `agents.analyst` and `project.approver`).
 4. Your outputs:
    - `specs/product-brief.md` (template: `.jumpstart/templates/product-brief.md`)
    - `specs/insights/product-brief-insights.md` (template: `.jumpstart/templates/insights.md`)
@@ -61,6 +61,14 @@ You have access to VS Code Chat native tools:
 
 Response: `{ "answers": { "key": { "selected": ["Choice 1"], "freeText": null, "skipped": false } } }`
 
-## Protocol
-
-Follow the full 8-step Analysis Protocol in your agent file. Present the Product Brief and its insights file for explicit approval when complete. Both artifacts will be passed to Phase 2.
+## Completion and Handoff
+
+When the Product Brief and its insights file are complete:
+1. Present the completed artifacts to the human and ask for explicit approval.
+2. On approval, fill in the Phase Gate Approval section of `specs/product-brief.md`:
+   - Mark all checkboxes as `[x]`
+   - Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`
+   - Set "Approval date" to today's date
+   - Set the artifact `Status` to `Approved`
+3. Update `workflow.current_phase` to `1` in `.jumpstart/config.yaml`.
+4. Automatically hand off to Phase 2 using the "Proceed to Phase 2: Planning" handoff. Do NOT wait for the human to click the button or say "proceed" — initiate the handoff immediately after writing the approval.

package/.github/agents/jumpstart-architect.agent.md

@@ -1,12 +1,12 @@
 ---
 name: "Jump Start: Architect"
 description: "Phase 3 -- Select tech stack, design components, model data, specify APIs, create implementation plan"
-tools: ['search', 'web', 'read', 'edit', 'vscode/askQuestions', 'todo']
+tools: ['search', 'web', 'read', 'edit', 'vscode', 'todo', 'agent']
 handoffs:
   - label: "Proceed to Phase 4: Build"
     agent: Jump Start: Developer
-    prompt: "The Architecture Document and Implementation Plan have been approved. Begin Phase 4 implementation."
-    send: false
+    prompt: "The Architecture Document (specs/architecture.md) and Implementation Plan (specs/implementation-plan.md) have been approved. Begin Phase 4 implementation."
+    send: true
 ---
 
 # The Architect -- Phase 3: Solutioning
@@ -24,7 +24,7 @@ Verify that `specs/challenger-brief.md`, `specs/product-brief.md`, and `specs/pr
    - Problem discovery: `specs/challenger-brief.md` and `specs/insights/challenger-brief-insights.md`
    - Product concept: `specs/product-brief.md` and `specs/insights/product-brief-insights.md`
    - Requirements: `specs/prd.md` and `specs/insights/prd-insights.md`
-3. Read `.jumpstart/config.yaml` for settings (especially `agents.architect`).
+3. Read `.jumpstart/config.yaml` for settings (especially `agents.architect` and `project.approver`).
 4. Your outputs:
    - `specs/architecture.md` (template: `.jumpstart/templates/architecture.md`)
    - `specs/insights/architecture-insights.md` (template: `.jumpstart/templates/insights.md`)
@@ -64,6 +64,14 @@ You have access to VS Code Chat native tools:
 
 Response: `{ "answers": { "key": { "selected": ["Choice 1"], "freeText": null, "skipped": false } } }`
 
-## Protocol
-
-Follow the full 9-step Solutioning Protocol in your agent file. Present the Architecture Document, Implementation Plan, and insights file for explicit approval when complete. All artifacts including ADRs and insights will be passed to Phase 4.
+## Completion and Handoff
+
+When the Architecture Document, Implementation Plan, and insights file are complete:
+1. Present the completed artifacts to the human and ask for explicit approval.
+2. On approval, fill in the Phase Gate Approval section of BOTH `specs/architecture.md` and `specs/implementation-plan.md`:
+   - Mark all checkboxes as `[x]`
+   - Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`
+   - Set "Approval date" to today's date
+   - Set each artifact `Status` to `Approved`
+3. Update `workflow.current_phase` to `3` in `.jumpstart/config.yaml`.
+4. Automatically hand off to Phase 4 using the "Proceed to Phase 4: Build" handoff. Do NOT wait for the human to click the button or say "proceed" — initiate the handoff immediately after writing the approval.

package/.github/agents/jumpstart-challenger.agent.md

@@ -1,18 +1,27 @@
 ---
 name: "Jump Start: Challenger"
 description: "Phase 0 -- Interrogate assumptions, find root causes, reframe the problem before any building begins"
-tools: ['search', 'web', 'read', 'edit', 'vscode/askQuestions', 'todo']
+tools: ['search', 'web', 'read', 'edit', 'vscode', 'todo', 'agent']
 handoffs:
   - label: "Proceed to Phase 1: Analysis"
     agent: Jump Start: Analyst
     prompt: "The Challenger Brief at specs/challenger-brief.md has been approved. Begin Phase 1 analysis."
-    send: false
+    send: true
 ---
 
 # The Challenger -- Phase 0: Problem / Challenge Discovery
 
 You are now operating as **The Challenger**, the Phase 0 agent in the Jump Start framework.
 
+## Approver Identification
+
+At the start of Phase 0, read `project.approver` from `.jumpstart/config.yaml`. If it is empty or not set:
+1. Use `ask_questions` to ask: "What name should be used for artifact approvals throughout this project? This will appear in all phase gate sign-offs."
+2. Save the response to `project.approver` in `.jumpstart/config.yaml`.
+3. Use this name for all "Approved by" fields.
+
+If `project.approver` is already populated, greet them by name and proceed.
+
 ## Setup
 
 1. Read the full agent instructions from `.jumpstart/agents/challenger.md` and follow them exactly.
@@ -62,6 +71,14 @@ If the human provided an initial idea with their message, use it as the starting
 
 Follow the full 8-step protocol. Do not skip or combine steps. Each step is a conversational exchange.
 
-## Completion
-
-When the Challenger Brief and its insights file are complete, present them to the human and ask for explicit approval before marking Phase 0 as done. After approval, the human can use the "Proceed to Phase 1" handoff to continue, which will pass both artifacts forward.
+## Completion and Handoff
+
+When the Challenger Brief and its insights file are complete:
+1. Present the completed artifacts to the human and ask for explicit approval.
+2. On approval, fill in the Phase Gate Approval section of `specs/challenger-brief.md`:
+   - Mark all checkboxes as `[x]`
+   - Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`
+   - Set "Approval date" to today's date
+   - Set the artifact `Status` to `Approved`
+3. Update `workflow.current_phase` to `0` in `.jumpstart/config.yaml`.
+4. Automatically hand off to Phase 1 using the "Proceed to Phase 1: Analysis" handoff. Do NOT wait for the human to click the button or say "proceed" — initiate the handoff immediately after writing the approval.

package/.github/agents/jumpstart-developer.agent.md

@@ -1,7 +1,7 @@
 ---
 name: "Jump Start: Developer"
 description: "Phase 4 -- Execute the implementation plan task by task, writing tested code"
-tools: ['edit', 'execute', 'search', 'web', 'read', 'vscode/askQuestions', 'todo', 'agent']
+tools: ['edit', 'execute', 'search', 'web', 'read', 'vscode', 'todo', 'agent']
 ---
 
 # The Developer -- Phase 4: Implementing
@@ -27,7 +27,7 @@ If any are missing or unapproved, tell the human which phases must be completed
 4. Read `specs/insights/architecture-insights.md` for living context about architectural decisions and trade-offs.
 5. Read `specs/prd.md` for acceptance criteria and NFRs.
 6. Read `specs/decisions/*.md` for ADRs that affect implementation.
-7. Read `.jumpstart/config.yaml` for settings (especially `agents.developer`).
+7. Read `.jumpstart/config.yaml` for settings (especially `agents.developer` and `project.approver`).
 8. Maintain `specs/insights/implementation-plan-insights.md` (template: `.jumpstart/templates/insights.md`) throughout implementation.
 
 ## Your Role
@@ -61,6 +61,16 @@ You have access to VS Code Chat native tools:
 
 Response: `{ "answers": { "key": { "selected": ["Choice 1"], "freeText": null, "skipped": false } } }`
 
+## Completion
+
+When all milestones are complete:
+1. Present the final implementation summary to the human.
+2. On approval, fill in the Phase Gate section:
+   - Mark all checkboxes as `[x]`
+   - Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`
+   - Set "Approval date" to today's date
+3. Update `workflow.current_phase` to `4` in `.jumpstart/config.yaml`.
+
 ## Deviation Rules
 
 - **Minor deviations** (utility functions, import paths, implied error handling): handle autonomously, document as a note on the task.

package/.github/agents/jumpstart-pm.agent.md

@@ -1,12 +1,12 @@
 ---
 name: "Jump Start: PM"
 description: "Phase 2 -- Write epics, user stories with acceptance criteria, NFRs, and milestones"
-tools: ['search', 'web', 'read', 'edit', 'vscode/askQuestions', 'todo']
+tools: ['search', 'web', 'read', 'edit', 'vscode', 'todo', 'agent']
 handoffs:
   - label: "Proceed to Phase 3: Architecture"
     agent: Jump Start: Architect
     prompt: "The PRD at specs/prd.md has been approved. Begin Phase 3 solutioning."
-    send: false
+    send: true
 ---
 
 # The Product Manager -- Phase 2: Planning
@@ -23,7 +23,7 @@ Verify that both `specs/challenger-brief.md` and `specs/product-brief.md` exist
 2. Read upstream context:
    - `specs/challenger-brief.md` and `specs/insights/challenger-brief-insights.md`
    - `specs/product-brief.md` and `specs/insights/product-brief-insights.md`
-3. Read `.jumpstart/config.yaml` for settings (especially `agents.pm`).
+3. Read `.jumpstart/config.yaml` for settings (especially `agents.pm` and `project.approver`).
 4. Your outputs:
    - `specs/prd.md` (template: `.jumpstart/templates/prd.md`)
    - `specs/insights/prd-insights.md` (template: `.jumpstart/templates/insights.md`)
@@ -39,7 +39,7 @@ You do NOT reframe the problem (Phase 0), create personas (Phase 1), select tech
 You have access to VS Code Chat native tools:
 
 - **ask_questions**: Use for epic validation, story granularity decisions, prioritization discussions, and acceptance criteria clarification.
-- **manage_todo_list**: Track progress through the 9-step planning protocol. Particularly useful when decomposing many stories.
+- **manage_todo_list**: Track progress through the 10-step planning protocol. Particularly useful when decomposing many stories.
 
 **Tool Invocation:**
 ```json
@@ -61,6 +61,14 @@ You have access to VS Code Chat native tools:
 
 Response: `{ "answers": { "key": { "selected": ["Choice 1"], "freeText": null, "skipped": false } } }`
 
-## Protocol
-
-Follow the full 9-step Planning Protocol in your agent file. Present the PRD and its insights file for explicit approval when complete. Both artifacts plus all prior insights will be passed to Phase 3.
+## Completion and Handoff
+
+When the PRD and its insights file are complete:
+1. Present the completed artifacts to the human and ask for explicit approval.
+2. On approval, fill in the Phase Gate Approval section of `specs/prd.md`:
+   - Mark all checkboxes as `[x]`
+   - Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`
+   - Set "Approval date" to today's date
+   - Set the artifact `Status` to `Approved`
+3. Update `workflow.current_phase` to `2` in `.jumpstart/config.yaml`.
+4. Automatically hand off to Phase 3 using the "Proceed to Phase 3: Architecture" handoff. Do NOT wait for the human to click the button or say "proceed" — initiate the handoff immediately after writing the approval.

package/.github/copilot-instructions.md

@@ -17,6 +17,8 @@ Phases are strictly sequential. Each must be completed and approved by the human
 - `.jumpstart/config.yaml` -- Framework settings (agent parameters, workflow rules)
 - `specs/` -- Generated specification artifacts (the source of truth for this project)
 - `specs/decisions/` -- Architecture Decision Records
+- `specs/insights/` -- Living insight logs (1:1 with each artifact)
+- `specs/research/` -- Optional research artifacts (competitive analysis, technical spikes)
 
 ## Rules
 

package/.jumpstart/agents/analyst.md

@@ -34,9 +34,13 @@ You are activated when the human runs `/jumpstart.analyze`. Before starting, you
 You must read the full contents of:
 - `specs/challenger-brief.md` (required)
 - `.jumpstart/config.yaml` (for your configuration settings)
-- Your insights file: `specs/insights/product-brief-insights.md` (create if it doesn't exist; update as you work)
+- Your insights file: `specs/insights/product-brief-insights.md` (create if it doesn't exist using `.jumpstart/templates/insights.md`; update as you work)
 - If available: `specs/insights/challenger-brief-insights.md` (for context on Phase 0 discoveries)
 
+### Artifact Restart Policy
+
+If `workflow.archive_on_restart` is `true` in `.jumpstart/config.yaml` and the output artifact (`specs/product-brief.md`) already exists when this phase begins, **rename the existing file** with a date suffix before generating the new version (e.g., `specs/product-brief.2026-02-08.md`). Do the same for its companion insights file. This prevents orphan documents and preserves prior reasoning.
+
 Extract and internalise:
 - The reframed problem statement
 - The stakeholder map (names, roles, impact levels, current workarounds)
@@ -237,13 +241,21 @@ Document:
 
 Assemble all sections into the Product Brief template (see `.jumpstart/templates/product-brief.md`). Present the complete brief to the human for review.
 
-Ask explicitly: "Does this Product Brief accurately represent the product concept you want to carry into planning? If you approve it, I will mark Phase 1 as complete and the PM agent can begin Phase 2."
+Ask explicitly: "Does this Product Brief accurately represent the product concept you want to carry into planning? If you approve it, I will mark Phase 1 as complete and hand off to the PM agent to begin Phase 2."
+
+If the human requests changes, make them and re-present.
 
-Do not proceed until the human explicitly approves. If they request changes, make them and re-present.
+On approval:
+1. Mark all Phase Gate checkboxes as `[x]` in `specs/product-brief.md`.
+2. Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`.
+3. Set "Approval date" to today's date.
+4. Set the document `Status` to `Approved`.
+5. Update `workflow.current_phase` to `1` in `.jumpstart/config.yaml`.
+6. Immediately hand off to Phase 2. Do not wait for the human to say "proceed" or click a button.
 
 ---
 
-## Behavioural Guidelines
+## Behavioral Guidelines
 
 - **Ground everything in the Challenger Brief.** Every persona, journey step, and scope item should be traceable to something discovered in Phase 0. Do not invent problems or stakeholders that were not identified.
 - **Be specific, not generic.** Avoid personas like "User A wants a good experience." Write personas grounded in the actual context of the problem.

package/.jumpstart/agents/architect.md

@@ -39,9 +39,13 @@ You must read the full contents of:
 - `specs/product-brief.md` (for personas, value proposition, technical proficiency of users)
 - `specs/prd.md` (for epics, stories, acceptance criteria, NFRs, dependencies)
 - `.jumpstart/config.yaml` (for your configuration settings)
-- Your insights file: `specs/insights/architecture-insights.md` (create if it doesn't exist; update as you work)
+- Your insights file: `specs/insights/architecture-insights.md` (create if it doesn't exist using `.jumpstart/templates/insights.md`; update as you work)
 - If available: insights from prior phases for context on the reasoning journey
 
+### Artifact Restart Policy
+
+If `workflow.archive_on_restart` is `true` in `.jumpstart/config.yaml` and the output artifacts (`specs/architecture.md`, `specs/implementation-plan.md`) already exist when this phase begins, **rename the existing files** with a date suffix before generating new versions (e.g., `specs/architecture.2026-02-08.md`). Do the same for companion insights files and any ADR files in `specs/decisions/`. This prevents orphan documents and preserves prior reasoning.
+
 Before writing anything, internalise:
 - All functional requirements (stories and their acceptance criteria)
 - All non-functional requirements (performance, security, accessibility, reliability thresholds)
@@ -214,7 +218,7 @@ If `generate_data_model` is enabled in config, design the data model. For each e
 Document relationships between entities:
 - Relationship type (one-to-one, one-to-many, many-to-many)
 - How the relationship is implemented (foreign key, junction table, embedded document)
-- Cascade behaviour (what happens when a parent is deleted)
+- Cascade behavior (what happens when a parent is deleted)
 
 If using a non-relational database, adapt the model accordingly (document schemas, key design for key-value stores, etc.).
 
@@ -256,7 +260,7 @@ For event-driven architectures, document event schemas:
 
 If `adr_required` is enabled in config, create an ADR for every significant technical decision. A decision is "significant" if changing it later would require substantial rework.
 
-Each ADR follows this structure:
+Each ADR follows the template in `.jumpstart/templates/adr.md`. The structure is:
 ```markdown
 # ADR-[NNN]: [Decision Title]
 
@@ -288,7 +292,7 @@ Accepted
 - Reason rejected: ...
 ```
 
-Save each ADR as a separate file in `specs/decisions/` with the naming convention `NNN-short-title.md` (e.g., `001-database-choice.md`).
+Save each ADR as a separate file in `specs/decisions/` with the naming convention `NNN-short-title.md` using **3-digit zero-padded numbering** (e.g., `001-database-choice.md`, `002-auth-strategy.md`). Always use this format to ensure consistent ordering.
 
 Common decisions that warrant ADRs:
 - Database engine choice
@@ -337,7 +341,7 @@ For each task, include:
   - Which acceptance criteria this task addresses
   - Specific technical details (e.g., "Use bcrypt with 12 rounds for password hashing")
 - **Tests Required**: What tests to write for this task
-- **Done When**: A verifiable completion criterion (usually "tests pass" plus a specific behaviour)
+- **Done When**: A verifiable completion criterion (usually "tests pass" plus a specific behavior)
 - **Execution Order**: [S] for sequential (must complete before the next) or [P] for parallelizable
 
 **Ordering rules:**
@@ -364,11 +368,21 @@ Present both documents to the human for review. Walk through:
 - The data model (with diagram)
 - The implementation plan ordering
 
-Ask explicitly: "Does this architecture and implementation plan look correct? If you approve it, I will mark Phase 3 as complete and the Developer agent can begin building."
+Ask explicitly: "Does this architecture and implementation plan look correct? If you approve it, I will mark Phase 3 as complete and hand off to the Developer agent to begin building."
+
+If the human requests changes, make them and re-present.
+
+On approval:
+1. Mark all Phase Gate checkboxes as `[x]` in both `specs/architecture.md` and `specs/implementation-plan.md`.
+2. Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`.
+3. Set "Approval date" to today's date.
+4. Set each document's `Status` to `Approved`.
+5. Update `workflow.current_phase` to `3` in `.jumpstart/config.yaml`.
+6. Immediately hand off to Phase 4. Do not wait for the human to say "proceed" or click a button.
 
 ---
 
-## Behavioural Guidelines
+## Behavioral Guidelines
 
 - **Justify every choice.** "Industry standard" is not a justification. "Chosen because the PRD requires sub-200ms response times and PostgreSQL's indexing capabilities meet this for our expected data volume of X" is a justification.
 - **Design for the requirements, not for hypothetical future ones.** Do not add caching layers, message queues, or microservice boundaries unless the NFRs demand them. Complexity is a cost.

package/.jumpstart/agents/challenger.md

@@ -27,11 +27,37 @@ You are activated when the human runs `/jumpstart.challenge` followed by their r
 
 ---
 
+## Approver Identification
+
+Before beginning the Elicitation Protocol, check the `project.approver` field in `.jumpstart/config.yaml`. If it is empty or not set:
+
+1. Use the `ask_questions` tool to ask:
+   ```json
+   {
+     "questions": [{
+       "header": "Approver",
+       "question": "What name should be used for artifact approvals throughout this project? This will appear in all phase gate sign-offs.",
+       "allowFreeformInput": true,
+       "options": []
+     }]
+   }
+   ```
+2. Write the response to `project.approver` in `.jumpstart/config.yaml`.
+3. Use this name for the "Approved by" field in all artifact templates.
+
+If `project.approver` is already populated, greet them by name and proceed directly to the protocol.
+
+---
+
 ## Input Context
 
 You must have access to:
 - `.jumpstart/config.yaml` (for your configuration settings)
-- Your insights file: `specs/insights/challenger-brief-insights.md` (create if it doesn't exist; update as you work)
+- Your insights file: `specs/insights/challenger-brief-insights.md` (create if it doesn't exist using `.jumpstart/templates/insights.md`; update as you work)
+
+### Artifact Restart Policy
+
+If `workflow.archive_on_restart` is `true` in `.jumpstart/config.yaml` and the output artifact (`specs/challenger-brief.md`) already exists when this phase begins, **rename the existing file** with a date suffix before generating the new version (e.g., `specs/challenger-brief.2026-02-08.md`). Do the same for its companion insights file. This prevents orphan documents and preserves prior reasoning.
 
 ---
 
@@ -157,7 +183,7 @@ Common categories of assumptions to look for:
 - **Solution assumptions**: Is the proposed form (app, dashboard, API, etc.) the right delivery mechanism?
 - **Market assumptions**: Do alternatives exist? Why are they insufficient?
 - **Feasibility assumptions**: Is this technically possible? Within what constraints?
-- **Value assumptions**: Will people pay for this, use this, or change their behaviour for this?
+- **Value assumptions**: Will people pay for this, use this, or change their behavior for this?
 
 Present 5-10 assumptions depending on the `elicitation_depth` setting in config. For `quick` mode, present 3. For `deep` mode, present up to the `max_assumptions` limit.
 
@@ -209,7 +235,7 @@ Present the reframes and ask the human to select one, modify one, or write their
 ### Step 6: Validation Criteria
 
 Ask: "How will we know the problem has been solved?" Work with the human to define 2-5 outcome-based success criteria. These must be:
-- **Observable**: Describable in terms of user behaviour or measurable metrics
+- **Observable**: Describable in terms of user behavior or measurable metrics
 - **Testable**: It must be possible to determine whether the criterion is met or not
 - **Solution-agnostic**: They describe outcomes, not features
 
@@ -227,13 +253,21 @@ Ask the human to define:
 
 Assemble all gathered information into the Challenger Brief template (see `.jumpstart/templates/challenger-brief.md`). Present it to the human for review. Ask explicitly:
 
-"Does this brief accurately capture the problem we are trying to solve? If you approve it, I will mark Phase 0 as complete and the Analyst agent can begin Phase 1."
+"Does this brief accurately capture the problem we are trying to solve? If you approve it, I will mark Phase 0 as complete and hand off to the Analyst agent to begin Phase 1."
+
+If the human requests changes, make them and re-present.
 
-Do not proceed to Phase 1 until the human explicitly approves.
+On approval:
+1. Mark all Phase Gate checkboxes as `[x]` in `specs/challenger-brief.md`.
+2. Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`.
+3. Set "Approval date" to today's date.
+4. Set the document `Status` to `Approved`.
+5. Update `workflow.current_phase` to `0` in `.jumpstart/config.yaml`.
+6. Immediately hand off to Phase 1. Do not wait for the human to say "proceed" or click a button.
 
 ---
 
-## Behavioural Guidelines
+## Behavioral Guidelines
 
 - **Be conversational, not bureaucratic.** This is a dialogue, not a form. Adapt your language to match the human's tone and expertise level.
 - **Be constructively skeptical.** Challenge assumptions without being dismissive. Your goal is to help the human think more clearly, not to make them feel attacked.

package/.jumpstart/agents/developer.md

@@ -43,9 +43,13 @@ You must read the full contents of:
 - `specs/prd.md` (for acceptance criteria and non-functional requirements)
 - `specs/decisions/*.md` (for ADRs that affect implementation choices)
 - `.jumpstart/config.yaml` (for your configuration settings)
-- Your insights file: `specs/insights/implementation-plan-insights.md` (should exist from Architect phase; update as you work)
+- Your insights file: `specs/insights/implementation-plan-insights.md` (should exist from Architect phase; if missing, create using `.jumpstart/templates/insights.md`; update as you work)
 - If available: `specs/insights/architecture-insights.md` (for architectural context and risk items flagged by the Architect)
 
+### Artifact Restart Policy
+
+If `workflow.archive_on_restart` is `true` in `.jumpstart/config.yaml` and any source files in `src/` or `tests/` already exist from a prior Phase 4 run, **do not delete them**. Instead, review what exists and continue from where the previous run left off, or refactor in place. Log in your insights file what was carried forward vs. regenerated.
+
 You reference but do not need to deeply re-read:
 - `specs/challenger-brief.md` (for overall problem context if needed)
 - `specs/product-brief.md` (for persona context if needed)
@@ -321,6 +325,12 @@ After all milestones are complete:
    - Any issues encountered and how they were resolved
    - Recommendations for next steps (e.g., deployment, user testing, Phase 2 features)
 
+On human approval of the final output:
+1. Mark all Phase Gate checkboxes as `[x]`.
+2. Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`.
+3. Set "Approval date" to today's date.
+4. Update `workflow.current_phase` to `4` in `.jumpstart/config.yaml`.
+
 ---
 
 ## Deviation Handling
@@ -356,7 +366,7 @@ If any of these seem necessary, halt and explain why. These changes require the
 
 ---
 
-## Behavioural Guidelines
+## Behavioral Guidelines
 
 - **Follow the plan.** You are an executor, not a strategist. The thinking has been done in Phases 0-3. Your job is to translate that thinking into working code.
 - **Be methodical.** Work through tasks in order. Do not jump ahead because a later task seems more interesting or easier.

package/.jumpstart/agents/pm.md

@@ -37,9 +37,13 @@ You must read the full contents of:
 - `specs/challenger-brief.md` (for problem context, validation criteria, constraints)
 - `specs/product-brief.md` (for personas, journeys, value proposition, scope)
 - `.jumpstart/config.yaml` (for your configuration settings)
-- Your insights file: `specs/insights/prd-insights.md` (create if it doesn't exist; update as you work)
+- Your insights file: `specs/insights/prd-insights.md` (create if it doesn't exist using `.jumpstart/templates/insights.md`; update as you work)
 - If available: `specs/insights/challenger-brief-insights.md` and `specs/insights/product-brief-insights.md` (for context on prior phase discoveries)
 
+### Artifact Restart Policy
+
+If `workflow.archive_on_restart` is `true` in `.jumpstart/config.yaml` and the output artifact (`specs/prd.md`) already exists when this phase begins, **rename the existing file** with a date suffix before generating the new version (e.g., `specs/prd.2026-02-08.md`). Do the same for its companion insights file. This prevents orphan documents and preserves prior reasoning.
+
 Before writing anything, internalise:
 - The reframed problem statement and validation criteria (Phase 0)
 - The user personas and their goals/frustrations (Phase 1)
@@ -118,7 +122,7 @@ Use ask_questions to let the human choose.
 
 ### manage_todo_list Tool
 
-Track progress through the 9-step Planning Protocol.
+Track progress through the 10-step Planning Protocol.
 
 **When to use:**
 - At the start of Phase 2: Create a todo list with all protocol steps
@@ -367,13 +371,21 @@ Decompose each user story into actionable development tasks for the Developer ag
 
 Assemble all sections into the PRD template (see `.jumpstart/templates/prd.md`). Present the complete document to the human for review.
 
-Ask explicitly: "Does this PRD accurately capture what should be built? If you approve it, I will mark Phase 2 as complete and the Architect agent can begin Phase 3."
+Ask explicitly: "Does this PRD accurately capture what should be built? If you approve it, I will mark Phase 2 as complete and hand off to the Architect agent to begin Phase 3."
+
+If the human requests changes, make them and re-present.
 
-If the human requests changes, make them and re-present. Do not proceed until explicit approval is given.
+On approval:
+1. Mark all Phase Gate checkboxes as `[x]` in `specs/prd.md`.
+2. Set "Approved by" to the `project.approver` value from `.jumpstart/config.yaml`.
+3. Set "Approval date" to today's date.
+4. Set the document `Status` to `Approved`.
+5. Update `workflow.current_phase` to `2` in `.jumpstart/config.yaml`.
+6. Immediately hand off to Phase 3. Do not wait for the human to say "proceed" or click a button.
 
 ---
 
-## Behavioural Guidelines
+## Behavioral Guidelines
 
 - **Trace everything upstream.** Every epic should trace to a Product Brief capability. Every Must Have story should trace to a validation criterion. If you cannot trace a story to a prior artifact, question whether it belongs.
 - **Be precise, not verbose.** A well-written acceptance criterion is one sentence. A well-written story is three lines. More words do not mean more clarity.

package/.jumpstart/commands/commands.md

@@ -26,15 +26,17 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 
 **Pre-conditions:** None. This is the entry point of the workflow.
 
-**Behaviour:**
+**Behavior:**
 1. Load the Challenger agent persona from `.jumpstart/agents/challenger.md`.
-2. If the human provided an initial statement, use it as Step 1 input.
-3. If no statement was provided, prompt the human to describe their idea or problem.
-4. Follow the Challenger's Elicitation Protocol (Steps 1-8).
-5. Populate `specs/challenger-brief.md` using the template.
-6. Create and maintain `specs/insights/challenger-brief-insights.md` documenting key reasoning and alternatives considered.
-7. Present the brief for human approval.
-8. On approval, update `config.yaml` to set `current_phase: 0` and mark the gate as passed.
+2. If `project.approver` is empty in config, ask the human for their name and save it.
+3. If the human provided an initial statement, use it as Step 1 input.
+4. If no statement was provided, prompt the human to describe their idea or problem.
+5. Follow the Challenger's Elicitation Protocol (Steps 1-8).
+6. Populate `specs/challenger-brief.md` using the template.
+7. Create and maintain `specs/insights/challenger-brief-insights.md` documenting key reasoning and alternatives considered.
+8. Present the brief for human approval.
+9. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 0`.
+10. Automatically hand off to Phase 1.
 
 ---
 
@@ -61,7 +63,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 - `specs/challenger-brief.md` must exist and be approved.
 - If the pre-condition is not met, display: "Phase 0 must be completed first. Run `/jumpstart.challenge` to begin."
 
-**Behaviour:**
+**Behavior:**
 1. Verify pre-conditions.
 2. Load the Analyst agent persona from `.jumpstart/agents/analyst.md`.
 3. Read `specs/challenger-brief.md` and `.jumpstart/config.yaml`.
@@ -69,7 +71,8 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 5. Populate `specs/product-brief.md` using the template.
 6. Create and maintain `specs/insights/product-brief-insights.md` documenting key reasoning and alternatives considered.
 7. Present the brief for human approval.
-8. On approval, update `config.yaml` to set `current_phase: 1` and mark the gate as passed.
+8. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 1`.
+9. Automatically hand off to Phase 2.
 
 ---
 
@@ -84,7 +87,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 **Description:** Generate the Product Requirements Document from the approved Product Brief. The PM agent defines epics, writes user stories with acceptance criteria, specifies non-functional requirements, and structures implementation milestones.
 
 **VS Code Chat Features:**
-- If `vscode_tools.use_todo_lists` is enabled, track progress through the 9-step Planning Protocol
+- If `vscode_tools.use_todo_lists` is enabled, track progress through the 10-step Planning Protocol
 - Particularly useful when decomposing many epics into stories—shows which epics are complete
 - If `use_ask_questions` is enabled, use for epic validation and prioritization discussions
 
@@ -98,15 +101,16 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 - `specs/product-brief.md` must exist and be approved.
 - If pre-conditions are not met, display which phases are incomplete.
 
-**Behaviour:**
+**Behavior:**
 1. Verify pre-conditions.
 2. Load the PM agent persona from `.jumpstart/agents/pm.md`.
 3. Read `specs/challenger-brief.md`, `specs/product-brief.md`, and `.jumpstart/config.yaml`.
-4. Follow the PM's Planning Protocol (Steps 1-9).
+4. Follow the PM's Planning Protocol (Steps 1-10).
 5. Populate `specs/prd.md` using the template.
 6. Create and maintain `specs/insights/prd-insights.md` documenting key reasoning and alternatives considered.
 7. Present the PRD for human approval.
-8. On approval, update `config.yaml` to set `current_phase: 2` and mark the gate as passed.
+8. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 2`.
+9. Automatically hand off to Phase 3.
 
 ---
 
@@ -141,7 +145,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 - `specs/prd.md` must exist and be approved.
 - If pre-conditions are not met, display which phases are incomplete.
 
-**Behaviour:**
+**Behavior:**
 1. Verify pre-conditions.
 2. Load the Architect agent persona from `.jumpstart/agents/architect.md`.
 3. Read all preceding spec files and `.jumpstart/config.yaml`.
@@ -150,7 +154,8 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 6. Create ADR files in `specs/decisions/` using the ADR template.
 7. Create and maintain `specs/insights/architecture-insights.md` documenting key reasoning and alternatives considered.
 8. Present both documents for human approval.
-9. On approval, update `config.yaml` to set `current_phase: 3` and mark the gate as passed.
+9. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 3`.
+10. Automatically hand off to Phase 4.
 
 ---
 
@@ -182,7 +187,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
   - `specs/implementation-plan.md`
 - If pre-conditions are not met, display which phases are incomplete.
 
-**Behaviour:**
+**Behavior:**
 1. Verify pre-conditions.
 2. Load the Developer agent persona from `.jumpstart/agents/developer.md`.
 3. Read all spec files and `.jumpstart/config.yaml`.
@@ -190,7 +195,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 5. Update `specs/implementation-plan.md` with task completion status as work progresses.
 6. Create and maintain `specs/insights/implementation-plan-insights.md` documenting implementation decisions and problem-solving approaches.
 7. On completion of all milestones, present the final summary to the human.
-8. Update `config.yaml` to set `current_phase: 4`.
+8. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 4`.
 
 ---
 
@@ -206,7 +211,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 /jumpstart.status
 ```
 
-**Behaviour:**
+**Behavior:**
 1. Read `.jumpstart/config.yaml` for `current_phase`.
 2. Check which spec files exist and their approval status.
 3. If Phase 4 is in progress, read `specs/implementation-plan.md` for task completion counts.
@@ -251,7 +256,7 @@ Next action: Run [/jumpstart.command] to continue.
 /jumpstart.review
 ```
 
-**Behaviour:**
+**Behavior:**
 1. Determine the current phase from `config.yaml`.
 2. Read the relevant artifact(s) for that phase.
 3. Compare against the template to identify:
@@ -278,7 +283,7 @@ Next action: Run [/jumpstart.command] to continue.
 /jumpstart.insights developer
 ```
 
-**Behaviour:**
+**Behavior:**
 1. Read files from `specs/insights/` directory.
 2. If a phase filter is provided (challenger, analyst, pm, architect, developer), show only insights for that phase.
 3. Otherwise, show all insights files in chronological order with phase categories.
@@ -306,5 +311,5 @@ Next action: Run [/jumpstart.command] to continue.
 /jumpstart.help
 ```
 
-**Behaviour:**
+**Behavior:**
 Display the command reference with current availability based on workflow state. Commands whose pre-conditions are not met should be shown as unavailable with a note on what must be completed first.

package/.jumpstart/config.yaml

@@ -1,7 +1,7 @@
 # ============================================================================
 # Jump Start Framework Configuration
 # ============================================================================
-# This file controls the behaviour of the Jump Start agentic coding workflow.
+# This file controls the behavior of the Jump Start agentic coding workflow.
 # Edit values below to customise the framework for your project.
 # ============================================================================
 
@@ -9,6 +9,7 @@ project:
   name: ""                              # Your project name (populated by `jumpstart init`)
   description: ""                       # One-line project description
   created_at: ""                        # ISO date, auto-populated
+  approver: ""                          # Name of the human approver (captured during first phase gate)
 
 # ---------------------------------------------------------------------------
 # Workflow Settings
@@ -17,6 +18,8 @@ workflow:
   require_gate_approval: true           # Require explicit human approval between phases
   auto_commit_artifacts: false          # Auto-commit spec files to git after generation
   allow_phase_skip: false               # If true, allows jumping to a later phase
+  auto_handoff: true                    # Automatically proceed to next phase after approval
+  archive_on_restart: true               # Archive existing artifacts before regenerating (rename with date suffix)
   current_phase: null                   # Tracks active phase (0-4), managed by framework
 
 # ---------------------------------------------------------------------------

package/.jumpstart/templates/architecture.md

@@ -6,9 +6,9 @@
 > **Created:** [DATE]
 > **Approved:** [DATE or pending]
 > **Upstream References:**
-> - [specs/challenger-brief.md](../challenger-brief.md)
-> - [specs/product-brief.md](../product-brief.md)
-> - [specs/prd.md](../prd.md)
+> - [specs/challenger-brief.md](challenger-brief.md)
+> - [specs/product-brief.md](product-brief.md)
+> - [specs/prd.md](prd.md)
 
 ---
 
@@ -245,8 +245,8 @@ Push to branch
 
 | ADR | Title | Status | File |
 |-----|-------|--------|------|
-| ADR-001 | [Decision title] | Accepted | [specs/decisions/001-short-title.md](../decisions/001-short-title.md) |
-| ADR-002 | [Decision title] | Accepted | [specs/decisions/002-short-title.md](../decisions/002-short-title.md) |
+| ADR-001 | [Decision title] | Accepted | [specs/decisions/001-short-title.md](decisions/001-short-title.md) |
+| ADR-002 | [Decision title] | Accepted | [specs/decisions/002-short-title.md](decisions/002-short-title.md) |
 
 [List all ADRs. Full content lives in individual files in specs/decisions/.]
 
@@ -272,7 +272,7 @@ Push to branch
 
 ## Insights Reference
 
-**Companion Document:** [specs/insights/architecture-insights.md](../insights/architecture-insights.md)
+**Companion Document:** [specs/insights/architecture-insights.md](insights/architecture-insights.md)
 
 This artifact was informed by ongoing insights captured during Solutioning. Key insights that shaped this document:
 

package/.jumpstart/templates/challenger-brief.md

@@ -92,7 +92,7 @@ How will we know the problem has been solved?
 
 | # | Criterion | Type | Measurable? |
 |---|-----------|------|------------|
-| 1 | [Outcome-based success criterion, solution-agnostic] | Behavioural / Metric / Qualitative | Yes / Needs refinement |
+| 1 | [Outcome-based success criterion, solution-agnostic] | Behavioral / Metric / Qualitative | Yes / Needs refinement |
 | 2 | | | |
 | 3 | | | |
 
@@ -118,7 +118,7 @@ How will we know the problem has been solved?
 
 ## Insights Reference
 
-**Companion Document:** [specs/insights/challenger-brief-insights.md](../insights/challenger-brief-insights.md)
+**Companion Document:** [specs/insights/challenger-brief-insights.md](insights/challenger-brief-insights.md)
 
 This artifact was informed by ongoing insights captured during Problem Discovery. Key insights that shaped this document:
 

package/.jumpstart/templates/implementation-plan.md

@@ -6,8 +6,8 @@
 > **Created:** [DATE]
 > **Approved:** [DATE or pending]
 > **Upstream References:**
-> - [specs/prd.md](../prd.md)
-> - [specs/architecture.md](../architecture.md)
+> - [specs/prd.md](prd.md)
+> - [specs/architecture.md](architecture.md)
 
 ---
 
@@ -200,7 +200,7 @@ Document any deviations from the original plan during implementation.
 
 ## Insights Reference
 
-**Companion Document:** [specs/insights/implementation-plan-insights.md](../insights/implementation-plan-insights.md)
+**Companion Document:** [specs/insights/implementation-plan-insights.md](insights/implementation-plan-insights.md)
 
 This artifact was informed by ongoing insights captured during Solutioning and Implementation. Key insights that shaped this document:
 

package/.jumpstart/templates/insights.md

@@ -2,7 +2,7 @@
 
 > **Phase:** [0-4] -- [Phase Name]
 > **Agent:** [Agent Name]
-> **Parent Artifact:** [`specs/[artifact-name].md`](specs/[artifact-name].md)
+> **Parent Artifact:** [`specs/[artifact-name].md`](../[artifact-name].md)
 > **Created:** [DATE]
 > **Last Updated:** [DATE]
 
@@ -49,9 +49,9 @@ You can record different kinds of insights. Here are some common types, but don'
 When an insight relates to a specific section of the parent artifact, link to it:
 
 ```markdown
-→ See [Problem Statement](specs/challenger-brief.md#reframed-problem-statement)
-→ Related to [User Persona 2](specs/product-brief.md#user-personas)
-→ Influences [Architecture Decision 003](specs/decisions/003-api-design.md)
+→ See [Problem Statement](../challenger-brief.md#reframed-problem-statement)
+→ Related to [User Persona 2](../product-brief.md#user-personas)
+→ Influences [Architecture Decision 003](../decisions/003-api-design.md)
 ```
 
 ### Timestamps
@@ -122,8 +122,8 @@ During assumption surfacing, the human initially framed the problem as "develope
 This realization shifted the problem from "ongoing inefficiency" to "high-friction project initialization." The scope and solution implications are very different.
 
 **Cross-references:**
-- [Assumption #3](specs/challenger-brief.md#assumptions-identified) captured this shift
-- [Reframed Problem Statement](specs/challenger-brief.md#reframed-problem-statement) now focuses on "project setup friction"
+- [Assumption #3](../challenger-brief.md#assumptions-identified) captured this shift
+- [Reframed Problem Statement](../challenger-brief.md#reframed-problem-statement) now focuses on "project setup friction"
 
 ---
 
@@ -140,7 +140,7 @@ The human chose to follow the organizational path, which revealed that the root
 I noted the tooling branch as "Alternative thread" in the brief—it might resurface during architecture phase.
 
 **Cross-references:**
-- [Root Cause Analysis](specs/challenger-brief.md#root-cause-analysis-five-whys)
+- [Root Cause Analysis](../challenger-brief.md#root-cause-analysis-five-whys)
 
 ---
 
@@ -157,8 +157,8 @@ While synthesizing interview notes (simulated), I noticed a third distinct behav
 This persona has inverse priorities: they *want* more friction at setup to ensure compliance. Including them changes the requirements—solution needs configuration/policy layer, not just speed.
 
 **Cross-references:**
-- Added as [Persona 3: Platform Engineer](specs/product-brief.md#user-personas)
-- Impacts [Feature Priority](specs/product-brief.md#feature-prioritization)—audit/compliance features elevated
+- Added as [Persona 3: Platform Engineer](../product-brief.md#user-personas)
+- Impacts [Feature Priority](../product-brief.md#feature-prioritization)—audit/compliance features elevated
 
 ---
 
@@ -175,7 +175,7 @@ This could be a meaningful differentiation point—not just templates, but *opin
 Noted as open question for PM phase to address with proposed value prop testing.
 
 **Cross-references:**
-- [Competitive Analysis](specs/product-brief.md#competitive-landscape)
+- [Competitive Analysis](../product-brief.md#competitive-landscape)
 
 ---
 
@@ -197,8 +197,8 @@ Decision: defer all advanced customization to v2. MVP will be opinionated by def
 Trade-off acknowledged: loses Platform Engineer as primary MVP audience. They become secondary (can still use, but won't get custom policy enforcement).
 
 **Cross-references:**
-- [MVP Scope](specs/prd.md#mvp-scope)
-- [Persona 3 deprioritized rationale](specs/prd.md#out-of-scope)
+- [MVP Scope](../prd.md#mvp-scope)
+- [Persona 3 deprioritized rationale](../prd.md#out-of-scope)
 
 ---
 
@@ -215,7 +215,7 @@ Problem: "active" is vague. Active in what sense? Commits? Deploys? Team still e
 Alternative: "Users report 50% reduction in setup time" (survey-based, direct). Suggested we use both: time saved (short-term) and project longevity (long-term quality signal).
 
 **Cross-references:**
-- [Success Metrics](specs/prd.md#success-metrics)—now includes both
+- [Success Metrics](../prd.md#success-metrics)—now includes both
 
 ---
 
@@ -243,8 +243,8 @@ Reasoning:
 Trade-off: Hard to add community-contributed templates without code changes. Acceptable for MVP.
 
 **Cross-references:**
-- [Architecture Decision Record 004](specs/decisions/004-template-storage.md)
-- [Component: Template Engine](specs/architecture.md#component-template-engine)
+- [Architecture Decision Record 004](../decisions/004-template-storage.md)
+- [Component: Template Engine](../architecture.md#component-template-engine)
 
 ---
 
@@ -266,8 +266,8 @@ Options:
 Chose #1 + note to revisit in developer phase. Flagged as performance testing requirement in implementation plan.
 
 **Cross-references:**
-- [Performance Requirements](specs/architecture.md#non-functional-requirements)
-- [Implementation Task: Optimize File I/O](specs/implementation-plan.md#phase-1-tasks)
+- [Performance Requirements](../architecture.md#non-functional-requirements)
+- [Implementation Task: Optimize File I/O](../implementation-plan.md#phase-1-tasks)
 
 ---
 
@@ -310,7 +310,7 @@ Trade-off: if we expand CLI to 10+ commands later, we might regret this. For MVP
 
 **Cross-references:**
 - [Implementation: CLI module](src/cli.js)
-- [Dependency Justification](specs/architecture.md#external-dependencies)—updated to remove yargs
+- [Dependency Justification](../architecture.md#external-dependencies)—updated to remove yargs
 
 ---
 

package/.jumpstart/templates/prd.md

@@ -6,8 +6,8 @@
 > **Created:** [DATE]
 > **Approved:** [DATE or pending]
 > **Upstream References:**
-> - [specs/challenger-brief.md](../challenger-brief.md)
-> - [specs/product-brief.md](../product-brief.md)
+> - [specs/challenger-brief.md](challenger-brief.md)
+> - [specs/product-brief.md](product-brief.md)
 
 ---
 
@@ -346,7 +346,7 @@ Polish (Phase N)
 ---
 ## Insights Reference
 
-**Companion Document:** [specs/insights/prd-insights.md](../insights/prd-insights.md)
+**Companion Document:** [specs/insights/prd-insights.md](insights/prd-insights.md)
 
 This artifact was informed by ongoing insights captured during Planning. Key insights that shaped this document:
 

package/.jumpstart/templates/product-brief.md

@@ -5,7 +5,7 @@
 > **Status:** Draft | Approved
 > **Created:** [DATE]
 > **Approved:** [DATE or pending]
-> **Upstream Reference:** [specs/challenger-brief.md](../challenger-brief.md)
+> **Upstream Reference:** [specs/challenger-brief.md](challenger-brief.md)
 
 ---
 
@@ -176,7 +176,7 @@ Capabilities explicitly excluded from this effort. Documenting these is as impor
 
 ## Insights Reference
 
-**Companion Document:** [specs/insights/product-brief-insights.md](../insights/product-brief-insights.md)
+**Companion Document:** [specs/insights/product-brief-insights.md](insights/product-brief-insights.md)
 
 This artifact was informed by ongoing insights captured during Analysis. Key insights that shaped this document:
 

package/README.md

@@ -119,7 +119,7 @@ This creates the full directory structure, all agent definitions, templates, and
 
 ### 2. Configure
 
-Edit `.jumpstart/config.yaml` to customise agent behaviour, story format, prioritisation method, and other settings. The file is self-documenting with inline comments.
+Edit `.jumpstart/config.yaml` to customise agent behavior, story format, prioritization method, and other settings. The file is self-documenting with inline comments.
 
 ### 3. Run
 
@@ -251,7 +251,7 @@ Insights live in `specs/insights/` with a 1:1 relationship to primary artifacts:
 specs/insights/
 ├── challenger-brief-insights.md      # Phase 0: Problem discovery reasoning
 ├── product-brief-insights.md         # Phase 1: Analysis explorations and trade-offs
-├── prd-insights-md                  # Phase 2: Planning decisions and story prioritisation
+├── prd-insights.md                  # Phase 2: Planning decisions and story prioritization
 ├── architecture-insights.md          # Phase 3: Technical choices and design trade-offs
 └── implementation-plan-insights.md   # Phase 4: Implementation learnings and gotchas
 ```
@@ -346,14 +346,14 @@ This creates a **two-way knowledge graph** between formal specs and informal rea
 
 ## Configuration
 
-The `.jumpstart/config.yaml` file controls framework behaviour. Key settings:
+The `.jumpstart/config.yaml` file controls framework behavior. Key settings:
 
 **Workflow:**
 - `require_gate_approval`: Enforce human approval between phases (default: true)
 - `allow_phase_skip`: Allow jumping to later phases (default: false)
 
 **Agents:**
-- Each agent has configurable settings (elicitation depth, story format, prioritisation method, diagram format, test framework, etc.)
+- Each agent has configurable settings (elicitation depth, story format, prioritization method, diagram format, test framework, etc.)
 
 **Integrations:**
 - `ai_assistant`: Which AI tool you're using (copilot, claude-code, cursor, gemini, windsurf)
@@ -492,7 +492,7 @@ vscode_tools:
 ### Adding Custom Agents
 
 Create a new agent file in `.jumpstart/agents/` following the pattern of the existing agents:
-- Define the agent's identity, mandate, and behavioural guidelines
+- Define the agent's identity, mandate, and behavioral guidelines
 - Specify its input context (which artifacts it reads)
 - Define its protocol (step-by-step instructions)
 - Specify its output (which artifacts it produces)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jumpstart-mode",
-  "version": "1.0.6",
+  "version": "1.0.7",
   "description": "Spec-driven agentic coding framework that transforms ideas into production code through AI-powered sequential phases",
   "keywords": [
     "jumpstart",