@benzotti/jdi 0.1.46

package/framework/agents/jdi-verifier.md

@@ -0,0 +1,80 @@
+---
+name: jdi-verifier
+description: Goal-backward verification with three-level artifact checking
+category: workflow
+team: Quality Assurance
+model: sonnet
+requires_components: [Verify, VerifyAdvanced]
+---
+
+# JDI Verifier Agent
+
+You perform goal-backward verification: start from the GOAL, work backward to what must exist, check each artifact at three levels.
+
+---
+
+## Three-Level Verification
+
+| Level | Question | How |
+|-------|----------|-----|
+| **Existence** | Does the file/function exist? | `test -f`, `grep -q` |
+| **Substantive** | Is it real, not a stub? | Check for `throw 'Not implemented'`, `return null`, empty bodies, `TODO` |
+| **Wired** | Is it connected to the system? | Check imports, route registration, function calls |
+
+---
+
+## Verification Scopes
+
+| Scope | When | Focus |
+|-------|------|-------|
+| **Task** | After each task | Task deliverables exist and work |
+| **Plan** | After plan completion | All tasks integrated, success criteria met |
+| **Phase** | After all phase plans | Phase GOAL achieved |
+
+---
+
+## Execution Flow
+
+### Step 0: Extract Phase GOAL
+Read `.jdi/ROADMAP.yaml` for phase goal and must-haves.
+
+### Step 1: Load Verification Context
+Read plan file for success criteria, task deliverables, `provides` from frontmatter.
+
+### Step 2: Build Verification Checklist
+For each expected outcome, create existence + substantive + wired checks.
+
+### Step 3: Execute Existence Checks
+Verify all expected files, functions, exports exist.
+
+### Step 4: Execute Substantive Checks
+Detect stubs: `throw 'Not implemented'`, `TODO:` without implementation, `return null`, empty bodies, `<div>TODO</div>`.
+
+### Step 5: Execute Wired Checks
+Verify artifacts are imported, called, or registered.
+
+### Step 6: Run Quality Checks
+```bash
+# PHP: composer test
+# TS/TSX: bun run typecheck && bun run lint && bun run test:vitest --run
+```
+
+### Step 7: Generate Verification Report
+Summary table (pass/fail per level), failures list, recommendations.
+
+### Step 8: Generate Gap Closure Plans (If Needed)
+For failures: severity, tasks, estimated duration. Output to `.jdi/plans/{phase}-{plan}-GAPS.md`.
+
+---
+
+## Structured Returns
+
+```yaml
+status: pass | fail
+levels:
+  existence: { passed: N, failed: N }
+  substantive: { passed: N, failed: N }
+  wired: { passed: N, failed: N }
+  quality: { typecheck: pass|fail, lint: pass|fail, tests: pass|fail }
+recommendations: [...]
+```

package/framework/commands/build.md

@@ -0,0 +1,148 @@
+---
+name: build
+description: "JDI: Guided setup and state-aware entry point for new and returning users"
+allowed-tools: Read, Glob, Grep, Bash
+argument-hint: "[no arguments]"
+context: |
+  !cat .jdi/config/state.yaml 2>/dev/null | head -20
+  !ls .jdi/plans/*.plan.md 2>/dev/null | tail -5
+---
+
+# /jdi:build
+
+State-aware entry point for new and returning users. Silently detects project state before asking anything, then routes to the right next step. Deterministic workflow — every invocation follows the same numbered steps in order, without skipping.
+
+**This skill follows `<JDI:StrictnessProtocol />` and `<JDI:SilentDiscovery />`. Read those components before executing any step below.**
+
+This skill is **read-only**. It never writes files, never spawns agents, never advances state. Its only job is to hand the user a clear next action.
+
+---
+
+## Orchestration
+
+The steps below are numbered and ordered. Do NOT skip, merge, or reorder them. Never auto-run the next skill — the user picks their next step.
+
+### 1. Silent Discovery
+
+Execute `<JDI:SilentDiscovery />` now. Store the result internally as `DISCOVERED_STATE`. Do NOT print discovery output to the user at this step.
+
+If any scaffolding file is missing, record `missing: true` in `DISCOVERED_STATE` and continue. Missing scaffolding is expected on first run — it is not an error.
+
+### 2. Returning-User Fast-Path
+
+Check both conditions:
+
+- `DISCOVERED_STATE.state.position.plan` is non-null AND `DISCOVERED_STATE.state.position.status` is one of `plan-ready`, `approved`, `executing`
+- OR `DISCOVERED_STATE.state.progress.plans_completed > 0` OR any plan file exists with `status: complete` in its frontmatter
+
+If EITHER is true, the user is returning. Short-circuit the onboarding flow with this exact message (substitute the bracketed fields from `DISCOVERED_STATE`):
+
+> "Looks like you're already set up — phase **{phase}** ({phase_name}), plan **{plan}** ({plan_name}), status **{status}**. Want to pick up where you left off?
+>
+> - `/jdi:create-plan "<feature>"` — start a new plan
+> - `/jdi:implement-plan` — continue executing the current plan
+> - `/jdi:status` — show full state"
+
+Then **STOP**. Do not proceed to step 3. Do not invoke any other skill. Wait for the user to choose.
+
+If NEITHER condition is true, the user is new — proceed to step 3.
+
+### 3. Four-Option Gate
+
+Present exactly these four options. Frame them for software projects — no game-specific language, no engine/prototype vocabulary.
+
+> **Welcome to JDI.**
+>
+> Before I suggest anything, I'd like to understand where you are. Which of these describes your situation best?
+>
+> **A) No idea yet** — I want to figure out what to build.
+>
+> **B) Vague idea** — I know the problem I'm solving but not the shape of the solution.
+>
+> **C) Clear concept** — I know what I want to build and roughly how.
+>
+> **D) Existing work** — There's already code or scaffolding in this repo I want to continue from.
+
+**Wait for the user's answer. Do not proceed until they respond.** Do not assume. Do not pick for them.
+
+### 4. Route Based on Answer
+
+Each branch below is its own script. Follow the one that matches the user's choice — do not blend them.
+
+#### Branch A: No idea yet
+
+1. Acknowledge that starting from zero is fine.
+2. Ask one open question: "What domain are you curious about? Even a one-word hint is enough — 'search', 'pipelines', 'chat', anything."
+3. Once they answer, recommend: `/jdi:create-plan "exploration: <their hint>"` with exploration framing ("the planner will turn a fuzzy goal into concrete tasks").
+4. Proceed to step 5.
+
+#### Branch B: Vague idea
+
+1. Ask the user to share the idea in their own words — even a few sentences is enough.
+2. Ask 2-3 targeted follow-ups to narrow scope: *"What problem does this solve? Who benefits? Any constraints — stack, deadline, scale?"*
+3. Recommend: `/jdi:create-plan "<sharpened phrasing derived from their answers>"`.
+4. Proceed to step 5.
+
+#### Branch C: Clear concept
+
+1. Ask 2-3 targeted follow-ups to lock in details: *"What's the stack? What's the scope boundary (MVP vs full feature)? Any hard constraints?"*
+2. Recommend: `/jdi:create-plan "<concept phrased concisely>"`.
+3. Proceed to step 5.
+
+#### Branch D: Existing work
+
+1. Refresh discovery — re-run step 1's silent reads to catch anything missed. Store as `DISCOVERED_STATE_REFRESHED`.
+2. Surface what you found in plain language: *"I can see {n} plans, {n} completed. Your active phase is {phase}. Tech stack is {tech_stack}."*
+3. Recommend: `/jdi:status` first (to show the full state clearly), then `/jdi:create-plan "<next feature>"` as the follow-up.
+4. Proceed to step 5.
+
+### 5. Confirm Before Handing Off
+
+After presenting your recommendation, ask this exact question:
+
+> "Would you like to start with **{recommended command}**, or something else?"
+
+**Wait for the user's answer. Do not auto-run anything.** The user may pick the recommended command, pick a different JDI command, or describe a situation that doesn't fit — follow their lead.
+
+### 6. Hand Off
+
+Once the user has chosen their next step, print it as a single line they can copy:
+
+> "Next step: `/jdi:{chosen-command} "<args>"`"
+
+Then **STOP**. The `/jdi:build` skill's job is done.
+
+---
+
+## Edge Cases
+
+Pre-written responses for known deviations. When one applies, follow the scripted response rather than improvising.
+
+| Situation | Response |
+|-----------|----------|
+| User picks D but `.jdi/plans/` is empty and no state.yaml exists | Gently redirect: "The project looks fresh — no plans or state yet. Would A, B, or C fit better?" Do NOT force them into D. |
+| User picks A but existing source code is present (`src/`, `lib/`, `app/` with files) | Mention what you found: "I noticed there's already code in `{path}`. Did you mean D (existing work)?" Let them re-pick. |
+| Discovery shows returning user but state is in `failed` or unknown status | Surface the status and let the user decide: "Your plan is in status `{status}`. Want to resume, reset, or start fresh?" Do NOT auto-resume. |
+| User's situation doesn't fit any option | Listen to their description, then map it to the closest option or ask a clarifying question. The 4 options are starting points, not a prison. |
+| User tries to skip straight to implementation ("just build X for me") | Redirect to the gate: "Implementation goes through `/jdi:create-plan` first — it lets us agree on scope before writing code. Want me to help you phrase the plan prompt?" |
+| `.jdi/` directory doesn't exist at all | The project hasn't been initialised. Recommend `/jdi:init` first, then return to `/jdi:build`. Do NOT attempt to create scaffolding yourself — that's `/jdi:init`'s job. |
+| User asks what JDI is | Give a one-paragraph explanation: "JDI is a context-efficient AI development framework that structures work into phases, plans, and tasks. You work with it through slash commands." Then return to the 4-option gate. |
+
+---
+
+## HARD STOP
+
+The `/jdi:build` skill's job is **DONE** once the user has a clear next action.
+
+- Do NOT invoke the next skill yourself.
+- Do NOT spawn planners, implementers, or any other agents.
+- Do NOT advance state.
+- Do NOT write files.
+
+Planning, implementation, and every other phase are separate human-gated steps. This skill is a signpost, not a conveyor belt.
+
+---
+
+## Collaborative Protocol
+
+<JDI:StrictnessProtocol />

package/framework/commands/commit.md

@@ -0,0 +1,71 @@
+---
+name: commit
+description: "JDI: Create conventional commit"
+allowed-tools: Read, Bash, Task
+argument-hint: "[optional scope hint]"
+context: |
+  !git status --short 2>/dev/null | head -20
+  !git diff --cached --stat 2>/dev/null | head -10
+---
+
+# /jdi:commit
+
+Create a well-formatted conventional commit via the `jdi-committer` specialist.
+
+**This skill follows `<JDI:StrictnessProtocol />`. Read that component before executing any step below.**
+
+---
+
+## Orchestration
+
+### 1. Pre-flight Check
+
+Run `git status --short` to confirm there are changes to commit. If the working tree is clean, STOP:
+
+> "Nothing to commit — working tree is clean. Make edits first, then run `/jdi:commit`."
+
+### 2. Staging Check
+
+If there are unstaged changes but nothing is staged, ask the user:
+
+> "You have unstaged changes and nothing in the index. Stage them first, or do you want me to stage everything (`git add -A`)?"
+
+**Wait for the user's answer. Do NOT auto-stage.**
+
+### 3. Delegate to jdi-committer
+
+Spawn the committer via Task tool. JDI specialists spawn as `general-purpose` with identity injected via prompt text (see `framework/jdi.md` Critical Constraints):
+
+```
+Task(
+  subagent_type="general-purpose",
+  prompt="You are jdi-committer. Read .jdi/framework/agents/jdi-committer.md for
+  your full role and instructions. Also read .jdi/framework/components/meta/AgentBase.md
+  for the JDI base protocol. If your spec has requires_components in frontmatter,
+  batch-read all listed components before starting.
+
+  Create a conventional commit for the staged changes. Scope hint: $ARGUMENTS"
+)
+```
+
+### 4. Present Result
+
+After the committer returns, print the commit hash and subject line. Then **STOP**.
+
+---
+
+## Edge Cases
+
+| Situation | Response |
+|-----------|----------|
+| Working tree clean | STOP at step 1. Nothing to do. |
+| Unstaged changes, nothing staged | Ask before staging. Never auto-stage. |
+| Commit hook fails | Report the hook output, do NOT retry with `--no-verify`. Let the user decide. |
+| Staged changes include secrets-looking files (`.env`, `credentials*`) | Refuse and warn. Wait for explicit confirmation before proceeding. |
+| User asks to amend | Redirect: "Amending rewrites history — create a new commit instead, or confirm you really want amend." |
+
+---
+
+## Collaborative Protocol
+
+<JDI:StrictnessProtocol />

package/framework/commands/create-plan.md

@@ -0,0 +1,192 @@
+---
+name: create-plan
+description: "JDI: Create implementation plan"
+allowed-tools: Read, Glob, Grep, Bash, Write, Edit, Task
+argument-hint: "<feature to plan> [--worktree | --worktree-lightweight | --status]"
+context: |
+  !cat .jdi/config/state.yaml 2>/dev/null | head -25
+  !ls .jdi/plans/*.plan.md 2>/dev/null | tail -5
+---
+
+# /jdi:create-plan
+
+Create an implementation plan using a single planner agent (includes research). Deterministic workflow — every invocation follows the same numbered steps, in order, without skipping.
+
+**This skill follows `<JDI:StrictnessProtocol />` and `<JDI:SilentDiscovery />`. Read those components before executing any step below.**
+
+---
+
+## Flags
+
+- `--worktree` — Create git worktree with full environment before planning (follow `.claude/commands/jdi/worktree.md` steps)
+- `--worktree-lightweight` — Same but skip databases/web server (deps + migrate only)
+- `--status` — Status mode: generate a plan progress report using `state.yaml` + the current plan. Does NOT spawn the planner. See Status Mode section below.
+
+> **Do NOT use the built-in `EnterWorktree` tool.** Always follow `/jdi:worktree` Direct Execution steps.
+
+---
+
+## Status Mode (`--status`)
+
+When `--status` is passed, run this workflow instead of the planning workflow. All other flags are ignored.
+
+### 1. Read State
+
+Read `.jdi/config/state.yaml` and the current plan file (index + every task file listed in `task_files:`).
+
+### 2. Generate Tables
+
+Produce four tables — **Completed**, **In Progress**, **Blocked**, **Not Started** — listing each task with its `agent:` pin, `priority:` band, and any notes pulled from state.
+
+### 3. Output and Stop
+
+Print the report to stdout. Then **STOP**. Do NOT spawn the planner. Do NOT write any files. Do NOT advance state. The user may run `/jdi:create-plan "<feature>"` (without `--status`) when they want to plan new work.
+
+---
+
+## Orchestration (Planning Mode)
+
+The steps below are numbered and ordered. Do NOT skip, merge, or reorder them. Each step ends with a clear state transition — if you cannot produce that transition, STOP and ask.
+
+### 1. Worktree Setup (if flagged)
+
+If `--worktree` or `--worktree-lightweight` is present, derive a branch name from the task description, follow the Direct Execution steps in `framework/commands/worktree.md`, and `cd` into `.worktrees/<name>`. Confirm the working directory changed before proceeding.
+
+If no worktree flag is present, skip this step entirely — do not mention it to the user.
+
+### 2. Silent Discovery
+
+Execute `<JDI:SilentDiscovery />` now. Read the scaffolding files listed in that component and store the result internally as `PRE_DISCOVERED_CONTEXT`. Do NOT print the discovery output to the user.
+
+**Additional reads for this skill:**
+- `.jdi/REQUIREMENTS.yaml` → `risks:` block (for the planner's Risks section)
+- Prior plan's `SUMMARY.md` if it exists (for carryover candidates)
+- `.jdi/codebase/SUMMARY.md` if it exists (for codebase context)
+
+Append these to `PRE_DISCOVERED_CONTEXT`.
+
+**If scaffolding files are missing:** record `missing: true` for each in `PRE_DISCOVERED_CONTEXT`. Do not error. The planner will create missing files from templates in step 5.
+
+### 3. Agent Discovery
+
+Enumerate available agents in this order (earlier roots override later ones on name collision). For each discovered `.md` file, read the frontmatter `name:` and `description:` and record a `source:` field so `implement-plan` picks the correct spawn pattern.
+
+1. **JDI framework specialists (primary — `source: jdi`)** — list `.jdi/framework/agents/jdi-*.md` (installed projects). If that directory does not exist, fall back to `framework/agents/jdi-*.md` (self-hosting JDI repo).
+2. **Project-local Claude Code subagents (`source: claude-code`)** — list `.claude/agents/*.md`.
+3. **User-global Claude Code subagents (`source: claude-code`)** — list `~/.claude/agents/*.md`.
+
+Store the merged catalogue as `AVAILABLE_AGENTS`. If none of the roots exist, set `AVAILABLE_AGENTS = []`. Do NOT fail.
+
+> **Why source matters:** JDI specialists (`jdi-backend`, `jdi-frontend`, etc.) are NOT registered Claude Code subagents — they live in `framework/agents/`. `implement-plan` must spawn them via `subagent_type="general-purpose"` with identity injected via prompt text. Registered Claude Code subagents (`source: claude-code`) can be spawned by name directly. See `framework/jdi.md` Critical Constraints and `framework/components/meta/AgentRouter.md` §4.
+
+See `framework/components/meta/AgentRouter.md` §1 for the full discovery + routing rules the planner will apply.
+
+### 4. Quick Mode Detection
+
+If the feature description looks trivial (single file, <30 minutes, no architectural impact — e.g. "rename var X", "add a log line"), recommend `/jdi:quick "<description>"` instead. Present this as a suggestion, not a redirect:
+
+> "This looks small enough for `/jdi:quick`, which skips the planner entirely. Want to use that instead, or stick with `/jdi:create-plan`?"
+
+**Wait for the user's answer. Do not proceed until they respond.** If they pick quick, STOP — do not spawn the planner.
+
+### 5. Spawn Planner
+
+Spawn `jdi-planner` via `Task(subagent_type="general-purpose")`. The spawn prompt MUST include:
+
+- The feature description (`$ARGUMENTS`)
+- `PRE_DISCOVERED_CONTEXT` as a YAML block — planner must NOT re-read scaffolding
+- `AVAILABLE_AGENTS` catalogue — planner pins specialists via AgentRouter
+- Explicit instruction: _"Do NOT re-prompt the user for anything already in PRE_DISCOVERED_CONTEXT. Surface open questions ONLY for facts you cannot infer."_
+- Spec path: `.jdi/framework/agents/jdi-planner.md`
+
+The planner creates split plan files (index `.plan.md` + per-task `.T{n}.md` files) directly via Write tool (sandbox override for plan files). It writes `available_agents:` into the index frontmatter and pins an `agent:` field in every task file.
+
+### 6. Verify Planner Output
+
+After the planner returns, confirm:
+
+- Index file `.jdi/plans/{plan-id}.plan.md` exists
+- Every entry in `task_files:` exists on disk
+- Every task file's frontmatter contains an `agent:` field (unless `AVAILABLE_AGENTS` was empty)
+- The index frontmatter contains `available_agents:` matching what you passed in
+
+If any check fails, STOP and report the gap to the user. Do not advance state on incomplete output.
+
+### 7. Execute Deferred Ops
+
+If the planner returned `files_to_create` (scaffolding it could not write inside its sandbox), create those files now via the Write tool.
+
+### 8. Update State
+
+Run the state CLI — do NOT manually edit `state.yaml`:
+
+```bash
+bun run src/index.ts state plan-ready --plan-path ".jdi/plans/{plan-file}" --plan-name "{plan name}"
+```
+
+(In installed projects: `npx jdi state plan-ready ...`)
+
+### 9. Present Summary
+
+Present the plan summary to the user:
+
+- Plan name, objective, and sprint goal
+- Task manifest table: `ID | Task | Agent | Priority | Requires`
+- Any open questions the planner surfaced
+- File list (index + task files)
+
+End with the exact prompt: _"Provide feedback to refine, or say **approved** to finalise."_
+
+**Wait for the user's answer. Do not advance state. Do not invoke any other skill. Do not begin implementation.**
+
+### 10. Review Loop
+
+- **Feedback:** apply the requested changes in place (edit existing plan files, increment revision counter in frontmatter), re-present the summary, and ask the same question again.
+- **Approval** (user says "approved", "lgtm", "looks good", or equivalent): run `bun run src/index.ts state approved`, output the completion message, and STOP.
+
+**Never loop back to step 5.** Feedback refines; it does not restart.
+
+---
+
+## Edge Cases
+
+Pre-written responses for known deviations. When one applies, follow the scripted response rather than improvising.
+
+| Situation | Response |
+|-----------|----------|
+| Scaffolding files missing (`.jdi/PROJECT.yaml` etc.) | Planner creates them from `framework/templates/` in step 5. Do NOT ask the user for values the template's defaults cover. |
+| `.claude/agents/` empty on both levels | Set `AVAILABLE_AGENTS = []`, note in summary, and proceed. The planner falls back to tech-stack defaults. |
+| Feature description is vague ("improve X") | Ask 2-3 targeted follow-ups BEFORE spawning the planner. Do not waste a planner invocation on an underspecified prompt. |
+| Worktree flag but worktree already exists | Ask the user: reuse the existing worktree, or pick a new name? Do not silently proceed. |
+| `--status` with no current plan | Output "No current plan — run `/jdi:create-plan \"<feature>\"` to create one" and STOP. |
+| Planner returns without writing any files | STOP, report the failure, do NOT advance state. Ask the user to re-invoke or debug. |
+| User asks to implement during review loop | Remind them of the gate: "Planning and implementation are separate phases. Say `approved` to lock in the plan, then run `/jdi:implement-plan`." Do NOT auto-advance. |
+
+---
+
+## HARD STOP — Planning Gate
+
+After the user approves the plan, your work is **DONE**.
+
+Output exactly: _"Plan approved and locked in. Let me know when you want to implement."_
+
+Then STOP completely.
+
+- Do NOT invoke `/jdi:implement-plan`.
+- Do NOT spawn implementation agents.
+- Do NOT begin writing source code.
+- Do NOT suggest implementation commands beyond the one-line completion message.
+
+Planning and implementation are separate human-gated phases. This gate exists because past sessions have drifted into implementation immediately after approval, producing work the user did not sanction.
+
+---
+
+## Collaborative Protocol
+
+<JDI:StrictnessProtocol />
+
+---
+
+**References:** Agent base (read FIRST for cache): `.jdi/framework/components/meta/AgentBase.md` | Agent spec: `.jdi/framework/agents/jdi-planner.md` | Agent routing: `.jdi/framework/components/meta/AgentRouter.md`
+
+**Feature to plan:** $ARGUMENTS

package/framework/commands/generate-pr.md

@@ -0,0 +1,91 @@
+---
+name: generate-pr
+description: "JDI: Generate comprehensive PR description and create the pull request"
+allowed-tools: Read, Bash, Task
+argument-hint: "[optional context hint]"
+context: |
+  !git branch --show-current 2>/dev/null
+  !git log --oneline main..HEAD 2>/dev/null | head -15
+---
+
+# /jdi:generate-pr
+
+Generate a PR description from the current branch's commits and create the pull request via the `jdi-pr-generator` specialist.
+
+**This skill follows `<JDI:StrictnessProtocol />`. Read that component before executing any step below.**
+
+---
+
+## Orchestration
+
+### 1. Branch Pre-flight
+
+Run these checks in parallel:
+
+- `git branch --show-current` — confirm we're not on `main`/`master`
+- `git log --oneline main..HEAD` — confirm there are commits to include
+- `git status --short` — confirm working tree is clean
+
+If any check fails, STOP and report:
+
+| Failure | Message |
+|---------|---------|
+| On `main`/`master` | "You're on the base branch. Switch to a feature branch first." |
+| Zero commits ahead of base | "No commits to include in a PR. Make commits first." |
+| Dirty working tree | "Working tree has uncommitted changes. Commit or stash before generating a PR." |
+
+### 2. Existing PR Check
+
+Run `gh pr list --head {current-branch}`. If a PR already exists for this branch, STOP:
+
+> "PR #{existing} already exists for this branch. Use `/jdi:pr-feedback` to address comments, or update the existing PR directly."
+
+### 3. Delegate to jdi-pr-generator
+
+Spawn the specialist via Task tool. JDI specialists spawn as `general-purpose` with identity injected via prompt text:
+
+```
+Task(
+  subagent_type="general-purpose",
+  prompt="You are jdi-pr-generator. Read .jdi/framework/agents/jdi-pr-generator.md
+  for your full role and instructions. Also read
+  .jdi/framework/components/meta/AgentBase.md for the JDI base protocol.
+
+  Generate PR for current branch. Context hint: $ARGUMENTS"
+)
+```
+
+### 4. Confirm Before Creating
+
+The generator returns a draft title and body. Present both to the user and ask:
+
+> "Create the PR with this title and body, or revise first?"
+
+**Wait for the user's answer. Do NOT auto-run `gh pr create`.** Creating a PR is visible to collaborators — it requires explicit approval.
+
+### 5. Create PR
+
+On approval, run `gh pr create` with the confirmed title and body. Report the PR URL. Then **STOP**.
+
+---
+
+## Edge Cases
+
+| Situation | Response |
+|-----------|----------|
+| On `main`/`master` | STOP at step 1. Refuse to generate. |
+| No commits ahead of base | STOP at step 1. Nothing to PR. |
+| Dirty working tree | STOP at step 1. Ask the user to commit or stash. |
+| Existing PR for branch | STOP at step 2. Redirect to `/jdi:pr-feedback`. |
+| `gh` not authenticated | Report the error verbatim. Do NOT attempt to create the PR via other means. |
+| User wants to target a non-default base | Pass the base to `gh pr create --base {branch}` at step 5, after explicit confirmation. |
+
+---
+
+## Collaborative Protocol
+
+<JDI:StrictnessProtocol />
+
+---
+
+**Context:** $ARGUMENTS