fresh-start

Orient to a scoped execution directory and load context for execution.

Workflow

Nested skill rule: When this workflow invokes another skill (e.g., /configure-verification, /phase-prep, /phase-start), you MUST return to this checklist after the nested skill completes and continue with the next unchecked item. Do not stop or summarize after a nested skill returns.

Copy this checklist and track progress:

Fresh Start Progress:
- [ ] Detect context (greenfield plan vs feature directory)
- [ ] Directory guard (verify AGENTS.md + EXECUTION_PLAN.md exist)
- [ ] Plan status guard (confirm this scoped directory is current)
- [ ] Git initialization (if needed)
- [ ] Feature branch setup (feature mode only)
- [ ] Scoped AGENTS check
- [ ] Read context and summarize
- [ ] Auto-configure verification (first run only)
- [ ] Phase state detection
- [ ] Auto-prep phase (first run only)
- [ ] Branch context detection

Project Directory

Use the current working directory by default.

If $1 is provided, treat $1 as the working directory and read files under $1 instead.

Context Detection

Determine working context before validation.

Convention: Run execution commands from the scoped directory that contains the active EXECUTION_PLAN.md:

• Greenfield: plans/greenfield/
• Feature work: features/<name>/

1. Let WORKING_DIR = $1 if provided, otherwise current working directory

1. If WORKING_DIR matches pattern /features/ (contains /features/ followed by a feature name):

- PROJECTROOT = parent of parent of WORKINGDIR (e.g., /project/features/foo → /project) - SCOPEDIR = WORKINGDIR - MODE = "feature"

1. If WORKING_DIR matches pattern /plans/greenfield:

- PROJECTROOT = parent of parent of WORKINGDIR (e.g., /project/plans/greenfield → /project) - SCOPEDIR = WORKINGDIR - MODE = "greenfield"

1. Otherwise:

- PROJECTROOT = WORKINGDIR - SCOPEDIR = WORKINGDIR - MODE = "greenfield-legacy"

Directory Guard (Wrong Directory Check)

Confirm the required files exist:

• PROJECT_ROOT/AGENTS.md must exist
• EXECUTIONPLAN.md must exist in SCOPEDIR

• If either is missing:

- If WORKINGDIR = PROJECTROOT and PROJECTROOT/plans/greenfield/EXECUTIONPLAN.md exists, tell the user: 1. The greenfield execution plan now lives in plans/greenfield/ 2. cd plans/greenfield 3. Re-run /fresh-start - Tell the user this project is not ready for execution yet - If they are in the toolkit repo (e.g., .toolkit-marker exists), instruct them to: 1. Run /setup <project-path> from the toolkit repo, then /generate-plan from the project (or /feature-plan for features) 2. cd into the project/feature directory 3. Re-run /fresh-start - Otherwise, ask the user for the correct project directory path and re-run /fresh-start <project-path>

Plan Status Guard

Read PROJECTROOT/plans/PLANSTATUS.md if it exists.

• If it exists, compare its Current plan path to SCOPE_DIR relative to

PROJECT_ROOT.

• If Current status is not active, STOP. Report that the current plan is

not implementable and ask the user to choose or reactivate a plan.

• If Current plan points to a different path than SCOPE_DIR, STOP. Tell

the user the current active plan path and instruct them to cd there before running /fresh-start.

• If SCOPE_DIR is under plans/archive/ or features/archive/, STOP.

Archived plans are historical context only.

• If the manifest is missing, continue with legacy directory detection, but

report: "No plans/PLAN_STATUS.md found; proceeding from directory convention."

Git Initialization (First Run)

In PROJECT_ROOT (not the feature directory):

1. Check whether this is already a git repo by running:

``bash git -C PROJECT_ROOT rev-parse --is-inside-work-tree 2>/dev/null `` If this returns "true", it's already a git repo.

1. If not a git repo:

- Ask: "Initialize git in this project now?" (recommended) - If yes: ``bash git init git branch -M main ``

1. If it is a git repo but has no commits yet:

- Ask: "Create an initial commit of the current project state now?" (recommended) - If yes: ``bash git add -A ` Verify with git status that files are staged correctly. `bash git commit -m "chore: initial commit" ` Verify with git log --oneline -1` that the commit was created.

Feature Branch Setup (Feature Mode Only)

If MODE = "feature", create an isolated branch for this feature work:

1. Derive FEATURENAME from the feature directory (basename of SCOPEDIR, e.g., analytics-dashboard)

1. Check current branch:

``bash git branch --show-current ``

1. If already on a feature/FEATURE_NAME branch, skip (already set up)

1. Otherwise, create and switch to the feature branch:

``bash # Commit any uncommitted changes first (preserves user work) git add -A && git diff --cached --quiet || git commit -m "wip: uncommitted changes before feature/FEATURENAME" ` Verify with git status that files are staged correctly. `bash # Create feature branch from current HEAD git checkout -b feature/FEATURENAME ` Verify with git branch` that the new branch is active.

1. Report: "Created branch feature/FEATURE_NAME for isolated feature development"

Scoped AGENTS Check

If SCOPEDIR/AGENTS.md exists and SCOPEDIR != PROJECT_ROOT, report:

• "Scoped AGENTS.md found. Local instructions will layer on top of PROJECT_ROOT/AGENTS.md."

If it does not exist and MODE is feature or greenfield, report:

• "No scoped AGENTS.md found in this directory. Execution will fall back to PROJECT_ROOT/AGENTS.md only."

Auto-Configure Verification (First Run Only)

Silently auto-detect verification commands if not already configured.

1. Read PROJECT_ROOT/.claude/verification-config.json (use Read tool directly).

If the file does not exist (read fails with not found), treat as missing and go to step 4.

1. If the file exists and has a commands key → SKIP. Do not invoke /configure-verification.

Report "Verification config already exists" and go directly to Phase State Detection.

1. If the file exists with {"skipped": true} → SKIP. Same as above.
2. If the file is missing, empty, or malformed (exists but has neither commands nor

skipped), invoke /configure-verification with SCOPE_DIR. This runs silently with no prompts. If it fails, report the error and continue.

→ CONTINUE to Phase State Detection (do not stop after this step).

Phase State Detection

Check for existing phase state to determine if this is a resume or first run:

1. Check if .claude/phase-state.json exists in:

- SCOPEDIR (if feature mode) - PROJECTROOT (if greenfield mode)

1. If valid phase state exists (file exists, parses correctly, has current_phase):

- This is a resume. Skip auto-configure and auto-prep (already done). - Report: `` RESUMING SESSION ================ Current phase: {currentphase} Completed: {count} tasks In progress: Task {inprogresstask} (if any) Last activity: {relative time, e.g., "2 hours ago"} ` - If inprogress_task` exists, offer to continue: - "Continue with Task {id}: {task title}?" [Y/n] - If yes, jump directly to that task after context load - Do not run auto-prep on resume. Go straight to Branch Context Detection.

1. If no phase state exists (or file is invalid/stale):

- This is a first run. Continue to Auto-Prep Phase section.

Auto-Prep Phase (First Run Only)

Skip this section entirely if resuming (phase-state.json exists and is valid).

After context reading and verification config, automatically prepare the next phase:

1. Determine next phase number:

- If no phase state exists → Phase 1 - If phase state exists but is stale/invalid → Phase 1

1. Invoke /phase-prep {next_phase} silently.

- Phase-prep will verify prerequisites and auto-advance to /phase-start if all checks pass (via its existing auto-advance logic). - If phase-prep blocks (human setup needed), it will report what's needed and the user runs /phase-start manually after resolving.

1. Fallback auto-advance check — After /phase-prep returns, read

.claude/phase-prep-result.json. If the file does NOT exist, phase-prep dropped its auto-advance step (known issue with nested Skill tool invocations). In this case: - Check if all phase-prep pre-flight checks passed (read the verification log) - If READY: show a warning and invoke /phase-start {next_phase} directly `` WARNING: phase-prep did not complete auto-advance. Invoking /phase-start directly. `` - If BLOCKED or unclear: report what's known and stop

→ CONTINUE to Branch Context Detection (do not stop after this step).

Branch Context Detection

Detect the current git branch and load relevant context:

1. Get current branch:

``bash git branch --show-current 2>/dev/null ``

1. If branch matches feature/* pattern:

- Extract feature name from branch (e.g., feature/analytics-dashboard → analytics-dashboard) - Look for matching feature directory: PROJECT_ROOT/features/{feature-name}/ - If found and MODE is "greenfield", suggest: "Switch to feature mode? Found feature directory for this branch."

1. Summarize recent branch activity:

``bash git log --oneline -5 2>/dev/null `` Report: "Recent commits on this branch: {summary}"

1. Check for uncommitted changes:

``bash git status --porcelain 2>/dev/null `` If changes exist, report: "Note: {N} uncommitted changes in working tree"

Required Context

Read these files first:

• PROJECT_ROOT/AGENTS.md — Durable project-wide workflow guidelines
• PROJECTROOT/plans/PLANSTATUS.md — Current plan manifest (if exists)
• SCOPEDIR/AGENTS.md — Scoped execution guidance (if SCOPEDIR != PROJECT_ROOT)
• SCOPEDIR/EXECUTIONPLAN.md — Tasks and acceptance criteria

Specification Documents

Check which of these exist and read them:

From PROJECT_ROOT (always check):

• LEARNINGS.md — Discovered patterns and gotchas (if exists)

From plans/greenfield/ (if greenfield mode):

• PRODUCT_SPEC.md — What we're building
• TECHNICAL_SPEC.md — How it's built

From PROJECT_ROOT (if MODE = "greenfield-legacy"):

• PRODUCT_SPEC.md — Legacy greenfield product spec
• TECHNICAL_SPEC.md — Legacy greenfield technical spec

From SCOPE_DIR (if feature mode):

• FEATURE_SPEC.md — Feature requirements
• FEATURETECHNICALSPEC.md — Feature technical approach
• FLOWVERIFICATIONPLAN.md — Agent-runnable flow verification plan (if exists)

Your Task

1. Read all available documents above
2. Summarize your understanding:

- What is being built - Current phase and progress - Tech stack and key patterns - Key learnings to follow (if LEARNINGS.md exists)

1. Confirm you're ready to begin execution

Error Handling

Important: If LEARNINGS.md exists, apply those patterns throughout your work. These are project-specific conventions discovered during development that override general defaults.

Output Format (Programmatic — for calling skills)

When invoked by another skill (e.g., /go), return structured data:

{
  "status": "<Status>",
  "context_loaded": ["AGENTS.md", "EXECUTION_PLAN.md", "FLOW_VERIFICATION_PLAN.md"],
  "blockers": [],
  "next_action": "Continue with Phase 1, Task 1"
}

Status enum — exactly one of:

Field descriptions: