sequant 2.3.0 → 2.5.0

package/dist/marketplace/external_plugins/sequant/skills/assess/references/predicted-collision-detection.md

@@ -0,0 +1,109 @@
+# Predicted file-collision detection
+
+`/assess` Step 5 inspects two sources of overlap between PROCEED issues:
+
+1. **Active-worktree overlap.** For each running worktree, `git diff --name-only main...HEAD` is intersected with the assessed issues' likely-touched files. Catches in-flight work.
+2. **Predicted file-collision (this document).** For each pair of unstarted PROCEED issues, the detector reads issue bodies and predicts which pairs will modify the same file once both run in parallel worktrees.
+
+This document is the tunable surface for the predicted-collision heuristic. The skill prose in `SKILL.md` names the detection functions; the patterns and the exclusion list live here so they can change without skill edits.
+
+## Trigger
+
+The detector runs automatically during Step 5 whenever ≥2 PROCEED issues are present in the assessment. Single-issue assessments skip it.
+
+## Path-extraction heuristics
+
+For each issue body, paths are extracted in this order:
+
+### 1. Strip code blocks and HTML comments
+
+Fenced code blocks (```` ``` … ``` ````) and HTML comments (`<!-- … -->`) are removed before any path matching. This is the **AC-5 false-positive guard**: paths quoted as code in prose count, paths inside a code block don't.
+
+### 2. Backtick-quoted source paths (PATH_REGEX)
+
+Backtick-quoted paths starting with one of the tracked roots and ending in a known source extension are extracted verbatim:
+
+```
+`(.claude|templates|skills|src|bin|docs)/<path-segment>+\.(md|ts|tsx|json|sh)`
+```
+
+Examples that match:
+
+- `` `.claude/skills/assess/SKILL.md` ``
+- `` `src/lib/foo.ts` ``
+- `` `templates/scripts/dev/foo.sh` ``
+
+Examples that **don't** match:
+
+- `` `phase-mapper.ts` `` — no directory prefix; too generic to disambiguate
+- `` `.claude/skills/**/*.md` `` — glob, not a literal path
+- `` `references/foo.md` `` — `references` is not a tracked root (it lives under `skills/<name>/`)
+
+### 3. Canonical bare form for skill files
+
+Skill files have three byte-identical mirrors at `.claude/skills/<name>/...`, `templates/skills/<name>/...`, `skills/<name>/...`. Treating the mirrors as separate paths would produce 3× the `Order:` lines and 6× the warnings for one logical conflict.
+
+The detector normalizes all three mirror prefixes to the bare subpath at extraction time:
+
+| Input (in issue body) | Canonical |
+|-----------------------|-----------|
+| `` `.claude/skills/qa/SKILL.md` `` | `qa/SKILL.md` |
+| `` `templates/skills/qa/SKILL.md` `` | `qa/SKILL.md` |
+| `` `skills/qa/SKILL.md` `` | `qa/SKILL.md` |
+| `` `qa/SKILL.md` `` (under 3-dir sync) | `qa/SKILL.md` |
+
+This is the form that appears in `Order:` lines and `⚠` warnings.
+
+### 4. Bare `<name>/SKILL.md` references (gated on 3-dir sync)
+
+When the body also signals "3-dir sync" (regex below), bare skill-file mentions like `` `qa/SKILL.md` `` and `` `spec/SKILL.md` `` are added to the path set in canonical form. The 3-dir-sync gate prevents over-extraction from incidental skill-file references in prose.
+
+3-dir-sync language is matched by:
+
+```
+/3[- ]dir(?:ectory)?\s+sync|across\s+all\s+three\s+skill\s+directories|across\s+(?:the\s+)?three\s+skill\s+directories/i
+```
+
+### 5. Slash-command-skill derivation (gated on 3-dir sync)
+
+When the body signals 3-dir sync, every `/<skill>` slash-command mention is also added as `<skill>/SKILL.md` (canonical bare form) — provided `<skill>` matches a known skill name. This catches issues that describe section changes via `/qa Section 6c`-style notation rather than naming the file path.
+
+The known-skill-name list lives in `KNOWN_SKILL_NAMES` in `src/lib/assess-collision-detect.ts`. Keep it in sync with the actual skill set under `skills/`. Adding a new skill? Append its name here.
+
+Slash-command derivation requires the same fenced-code-block / HTML-comment stripping — `/qa` mentioned only inside a code block does **not** trigger derivation.
+
+## False-positive guards
+
+### Globally excluded paths
+
+These paths are stripped from every issue's path set before pairwise intersection. They are paths that virtually every PROCEED issue tends to touch — including them would flag every batch as colliding and train users to ignore the warning.
+
+- `CHANGELOG.md` — every PROCEED issue updates the unreleased section
+- `package-lock.json` — alphabetically merged in practice; collisions are rare in practice
+- `yarn.lock`
+- `pnpm-lock.yaml`
+
+`EXCLUDED_PATHS` in `src/lib/assess-collision-detect.ts` is the canonical list. To add or remove an entry, edit that constant; this document and the skill prose pick up the change automatically.
+
+### Code block / HTML comment stripping
+
+Step 1 of the extraction (above) removes all fenced code blocks and HTML comments before path matching. A path mentioned **only** inside one of those will not contribute to the issue's path set.
+
+### Path-shape constraints
+
+The PATH_REGEX requires a directory prefix (one of the six tracked roots) and a known source extension. Bare filenames in prose (e.g. "phase-mapper.ts behavior") and glob patterns (`**/*.md`) are not extracted.
+
+## Tuning notes
+
+- **Proximity weighting** is not implemented. The original feature design proposed weighting paths inside `- [ ] **AC-N:**` bullets higher than paths in "Motivation" or "Additional context". Adding it is a follow-up if the false-positive rate becomes a problem in practice; leave it out until evidence demands it.
+- **Cost.** For 13 issues (the realistic batch ceiling), pairwise comparison is 78 pairs — cheap, no real performance concern. Don't optimize prematurely.
+
+## Output rules
+
+The detector returns `CollisionResult[]` from `detectFileCollisions`. The formatter (`formatCollisionAnnotations`) renders annotations in the dashboard format:
+
+- `Order: A → B (path)` per pair (or `Order: A → B → C (path)` for 3+ on the same file). `path` is the canonical bare form (e.g. `qa/SKILL.md`).
+- `⚠ #N  Modifies <path> (overlaps #M); land sequentially` per affected issue.
+- `Chain: npx sequant run A B C --chain --qa-gate -Q   # alternative — N issues modify <path> (chain length≥3 historically 1/6 = 17%; see docs/reference/chain-mode-analysis-2026-05.md)` only when ≥3 issues collide on the same file (suggest-only). The historical-rate annotation comes from the #604 forensic write-up; users see the suggestion alongside the parallel default and can weigh the trade-off.
+
+The bare-filename `Order:` exception (defined in the skill's "Annotation Rules") applies here — predicted collisions are file-collision reasons by definition, so the filename in parentheses is the reason verbatim.

package/dist/marketplace/external_plugins/sequant/skills/docs/SKILL.md

@@ -55,13 +55,63 @@ gh pr list --search "head:feature/<issue-number>" --json number,headRefName
 **Step 3:** Analyze the implementation diff:
 ```bash
 # If PR exists:
-gh pr diff <pr-number> 
+gh pr diff <pr-number>
 
 # If no PR, use git diff from feature branch:
 git diff main...HEAD --name-only
 git diff main...HEAD
 ```
 
+**Step 4:** Detect documentation-only changes:
+```bash
+# Count non-documentation files changed
+non_doc_files=$(git diff main...HEAD --name-only | grep -vE '\.(md|mdx)$|^docs/' | wc -l | xargs || true)
+```
+
+**Decision Logic:**
+```
+IF non_doc_files == 0 THEN
+  # Documentation-only issue detected
+  # Skip template generation, post confirmation comment instead
+  # See Section 2a: Documentation-Only Early Exit
+ELSE
+  # Continue with normal documentation generation
+END IF
+```
+
+### 2a. Documentation-Only Early Exit
+
+When only documentation files (`.md`, `.mdx`, or files in `docs/`) were modified, skip template generation and post a confirmation comment instead.
+
+**Detection criteria - ALL of these must be true:**
+- `git diff main...HEAD --name-only` returns files
+- All changed files match: `*.md`, `*.mdx`, or `docs/*`
+
+**Early exit action:**
+
+1. **Post confirmation comment to GitHub issue:**
+   ```bash
+   gh issue comment <issue-number> --body "$(cat <<'EOF'
+   ## Documentation Review Complete
+
+   This issue contains **documentation-only changes**. No additional documentation generation required.
+
+   ### Files Modified:
+   [List of changed .md/.mdx/docs/ files]
+
+   ### Status:
+   ✅ Documentation changes are ready for review and merge.
+
+   ---
+   Ready to merge!
+   EOF
+   )"
+   ```
+
+2. **Exit without generating template documentation.**
+
+**Skip to end of workflow** - do not proceed to Section 2 (Auto-Detect Documentation Type) or beyond.
+
 ### 2. Auto-Detect Documentation Type
 
 Determine documentation type based on changed files:
@@ -72,25 +122,45 @@ Determine documentation type based on changed files:
 - Files in `lib/admin/`
 - Admin-related API routes
 
-**User-Facing Documentation** (`docs/features/`):
-- Files in `app/[city]/`
-- Files in `components/` (non-admin)
-- Public-facing pages or features
+**Developer Tool Documentation** (`docs/features/`):
+- Files in `src/commands/`, `bin/`, `src/mcp/`
+- CLI commands, MCP tools, scripts
+- Configuration options, SDK integrations
+
+**Infra / Scaffold Documentation** (`docs/features/`):
+- Root config files (`package.json`, `*.config.{ts,js,mjs,cts,cjs,mts}`)
+- TypeScript / JavaScript project config (`tsconfig.json`, `jsconfig.json`)
+- Environment templates (`.env.example`)
+- Next.js layout/page files (`src/app/**/layout.tsx`, `src/app/**/page.tsx`)
+- Middleware (`src/middleware.ts`)
+- Framework config (`payload.config.*`, `drizzle.config.*`, `next.config.*`, `vite.config.*`, `vitest.config.*`)
+
+Everything else (user-facing pages, non-admin components, public-facing features) falls through to the default `developer-tool` template.
 
 **Decision Logic:**
 ```
 IF any file path contains "/admin/" THEN
   type = "admin"
   output_dir = "docs/admin/"
+  template = "admin" (Section 3a)
+ELSE IF any file path matches "src/commands/|bin/|src/mcp/|scripts/" THEN
+  type = "developer-tool"
+  output_dir = "docs/features/"
+  template = "developer-tool" (Section 3b)
+ELSE IF any file path matches "package\.json$|.*\.config\.(ts|js|mjs|cts|cjs|mts)$|(ts|js)config\.json$|\.env\.example$|^src/app/.*(layout|page)\.tsx$|^src/middleware\.ts$|^(payload|drizzle|next|vite|vitest)\.config\." THEN
+  type = "developer-tool"
+  output_dir = "docs/features/"
+  template = "developer-tool" (Section 3b)
 ELSE
-  type = "feature"
+  type = "developer-tool"
   output_dir = "docs/features/"
+  template = "developer-tool" (Section 3b)
 END IF
 ```
 
-### 3. Documentation Template
+### 3a. Admin/UI Documentation Template
 
-Generate documentation using this template:
+Use this template for admin pages and UI features:
 
 ```markdown
 # [Feature Name]
@@ -130,11 +200,6 @@ Generate documentation using this template:
 2. [Step 2]
 3. [Step 3]
 
-### [Workflow 2: e.g., "Bulk Edit Multiple Items"]
-
-1. [Step 1]
-2. [Step 2]
-
 ## Troubleshooting
 
 ### [Common Issue 1]
@@ -143,20 +208,69 @@ Generate documentation using this template:
 
 **Solution:** [How to fix it]
 
-### [Common Issue 2]
+---
 
-**Symptoms:** [What the user sees]
+*Generated for Issue #[number] on [date]*
+```
 
-**Solution:** [How to fix it]
+### 3b. Developer Tool Documentation Template
+
+Use this template for CLI commands, MCP tools, scripts, and developer-facing features. Structure around the user's journey, not the API surface.
+
+```markdown
+# [Feature Name]
+
+[1-2 sentence summary: what it does and why you'd use it.]
+
+## Prerequisites
+
+[Everything needed before this works. Be exhaustive — list tools, auth, config. Include verification commands.]
+
+1. **[Requirement 1]** — `verification command`
+2. **[Requirement 2]** — `verification command`
+
+## Setup
+
+[Step-by-step to go from zero to working. If setup differs per environment/client/platform, show each separately with clear labels.]
+
+## What You Can Do
+
+[Real examples of usage in natural language or command form. Show the most common actions first.]
+
+## What to Expect
+
+[Set expectations: how long things take, what output looks like, where results go. Address "it looks like nothing is happening" if applicable.]
+
+## [Command/Tool] Reference
+
+[Parameter tables, flags, options. Put this AFTER the narrative sections — users need context before reference.]
+
+| Parameter | Type | Required | Default | Description |
+|-----------|------|----------|---------|-------------|
+
+## Troubleshooting
+
+[Real failure scenarios users will hit. Lead with what they see, then the fix.]
+
+### [Problem user sees]
+
+[Cause and solution]
 
 ---
 
 *Generated for Issue #[number] on [date]*
 ```
 
+**Key differences from admin template:**
+- No "Access / URL / Menu / Permissions" section (not applicable to CLI tools)
+- Prerequisites section is mandatory (CLI tools have more dependencies)
+- "What to Expect" section addresses timing, output location, async behavior
+- Setup may vary per environment — show each variant
+- Reference tables come after narrative, not before
+
 ### 4. Content Guidelines
 
-**Focus on operational usage, not technical implementation:**
+**For admin/UI features — focus on operational usage:**
 
 - "Click the 'Approve' button to publish the item"
 - NOT: "The `approveItem` function updates the database"
@@ -164,16 +278,19 @@ Generate documentation using this template:
 - "Wait for the green success message"
 - NOT: "The API returns a 200 status code"
 
+**For developer tools — focus on the user's journey:**
+
+- "Run `sequant serve` to start the MCP server"
+- NOT: "The `serveCommand` function creates an MCP server instance"
+
+- "This takes 10–20 minutes. Your editor will appear idle — that's normal."
+- NOT: "The tool uses `spawnSync` with a 30-minute timeout"
+
 **Be specific and actionable:**
 
 - "Navigate to Admin → Items → Review Queue"
 - NOT: "Go to the review page"
 
-**Include visual cues when relevant:**
-
-- "Look for the blue 'Edit' icon next to each row"
-- NOT: "Click the edit button"
-
 **Document common workflows end-to-end:**
 
 - "To approve an item: 1. Open Review Queue, 2. Click item name, 3. Review details, 4. Click Approve"
@@ -239,6 +356,8 @@ Before completing, verify:
 - [ ] Correct folder (`docs/admin/` vs `docs/features/`)
 - [ ] Summary comment posted to issue
 
+**Note:** For documentation-only issues (detected in Step 4), skip this checklist and use the simplified confirmation comment from Section 2a instead.
+
 ## Workflow Integration
 
 The `/docs` command is the final step before merging:

package/dist/marketplace/external_plugins/sequant/skills/exec/SKILL.md

@@ -27,8 +27,8 @@ allowed-tools:
   - Bash(git push:*)
   - Bash(git worktree:*)
   # Worktree management
-  - Bash(./scripts/dev/new-feature.sh:*)
-  - Bash(./scripts/dev/cleanup-worktree.sh:*)
+  - Bash(./scripts/new-feature.sh:*)
+  - Bash(./scripts/cleanup-worktree.sh:*)
   # GitHub CLI
   - Bash(gh issue view:*)
   - Bash(gh issue comment:*)
@@ -273,7 +273,7 @@ When worktree creation is needed (standalone mode, no existing worktree):
 1. **Start worktree creation as background task:**
    ```bash
    # From main repo, start worktree creation in background
-   ./scripts/dev/new-feature.sh <issue-number> &
+   ./scripts/new-feature.sh <issue-number> &
    WORKTREE_PID=$!
    echo "Worktree creation started (PID: $WORKTREE_PID)"
    ```
@@ -461,8 +461,8 @@ echo "Current branch: $CURRENT_BRANCH"
 
 **If on main/master branch:**
 1. **STOP** - Do not implement directly on main
-2. Create a feature worktree first: `./scripts/dev/new-feature.sh <issue-number>`
-   - For custom base branch: `./scripts/dev/new-feature.sh <issue-number> --base <branch>`
+2. Create a feature worktree first: `./scripts/new-feature.sh <issue-number>`
+   - For custom base branch: `./scripts/new-feature.sh <issue-number> --base <branch>`
 3. Navigate to the worktree before making any changes
 
 **Why this matters:** Work done directly on main can be lost during sync operations (git reset, git pull --rebase, etc.). Worktrees provide isolation and safe recovery through branches.
@@ -484,9 +484,9 @@ echo "Current branch: $CURRENT_BRANCH"
    ```bash
    # Step 1: Start worktree creation in background
    # For default (main) base:
-   ./scripts/dev/new-feature.sh <issue-number> &
+   ./scripts/new-feature.sh <issue-number> &
    # For custom base branch (e.g., feature integration branch):
-   ./scripts/dev/new-feature.sh <issue-number> --base feature/dashboard &
+   ./scripts/new-feature.sh <issue-number> --base feature/dashboard &
    WORKTREE_PID=$!
 
    # Step 2: Gather context while worktree creates (see Section 2)
@@ -517,7 +517,7 @@ echo "Current branch: $CURRENT_BRANCH"
 4. **After implementation is complete:**
    - Push the branch: `git push -u origin feature/<branch-name>`
    - Create PR (manually or via script)
-   - The worktree will be cleaned up after PR merge using `./scripts/dev/cleanup-worktree.sh <branch-name>`
+   - The worktree will be cleaned up after PR merge using `./scripts/cleanup-worktree.sh <branch-name>`
 
 **Important:** Always work in the worktree directory, not the main repository, once the worktree is created.
 
@@ -806,16 +806,6 @@ After implementation is complete and all checks pass, create and verify the PR:
    - If PR exists: Record the URL from `gh pr view` output
    - If PR creation failed: Record the error and include manual creation instructions
 
-6. **Record PR info in workflow state:**
-   ```bash
-   # Extract PR number and URL from gh pr view output, then update state
-   PR_INFO=$(gh pr view --json number,url)
-   PR_NUMBER=$(echo "$PR_INFO" | jq -r '.number')
-   PR_URL=$(echo "$PR_INFO" | jq -r '.url')
-   npx tsx scripts/state/update.ts pr <issue-number> "$PR_NUMBER" "$PR_URL"
-   ```
-   This enables `--cleanup` to detect merged PRs and auto-remove state entries.
-
 **PR Verification Failure Handling:**
 
 If `gh pr view` fails after retry:
@@ -1507,13 +1497,47 @@ Look in the issue comments (especially from `/spec`) for:
 
 **If Parallel Groups exist:**
 
+0. **Check isolation mode (AC-20):**
+   ```bash
+   # Check env var first (set by --isolate-parallel CLI flag via phase-executor),
+   # then fall back to settings.json
+   ISOLATE="${SEQUANT_ISOLATE_PARALLEL:-}"
+   if [ -z "$ISOLATE" ]; then
+     ISOLATE=$(cat .sequant/settings.json 2>/dev/null | grep -o '"isolateParallel":[^,}]*' | grep -o 'true\|false' || echo "false")
+   fi
+   echo "Parallel isolation mode: ${ISOLATE}"
+   ```
+
+   **If isolation is enabled (`isolateParallel: true` or `--isolate-parallel`):**
+   - Create sub-worktrees BEFORE spawning agents (see step 1b below)
+   - Each agent gets its own working directory
+   - After agents complete, merge changes back (see step 5b below)
+
+   **If isolation is disabled (default):**
+   - All agents share the issue worktree (current behavior)
+   - Skip steps 1b and 5b
+
 1. **Create group marker before spawning agents:**
    ```bash
    touch /tmp/claude-parallel-group-1.marker
    ```
 
+1b. **Create sub-worktrees (isolation mode only):**
+   ```bash
+   # Uses the tested TypeScript API via CLI wrapper.
+   # Creates sub-worktree, symlinks node_modules, copies env files from .worktreeinclude.
+   WORKTREE_PATH="[issue worktree path]"
+   for i in 0 1 2; do  # adjust for number of agents
+     result=$(npx tsx scripts/worktree-isolation.ts create "${WORKTREE_PATH}" $i)
+     AGENT_PATH=$(echo "$result" | jq -r '.path')
+     echo "Agent ${i}: ${AGENT_PATH}"
+   done
+   ```
+
 2. **Determine model for each task:**
 
+   <!-- Note: model param inert per anthropics/claude-code#43869; the parsing
+        logic below reactivates automatically when the upstream fix ships. -->
    Check for model annotations in the task line: `[model: haiku]` or `[model: sonnet]`
 
    **Model Selection Priority:**
@@ -1524,15 +1548,22 @@ Look in the issue comments (especially from `/spec`) for:
 3. **Spawn parallel agents with the appropriate model in a SINGLE message:**
    Note: `sequant-implementer` intentionally omits `model` in its agent definition
    so the skill can override per-invocation (e.g., `model="haiku"` for subtasks).
+
+   **Working directory:** Use the sub-worktree path when isolation is enabled,
+   otherwise use the issue worktree path.
+
    ```
    Agent(subagent_type="sequant-implementer",
         model="haiku",
         run_in_background=true,
         prompt="Implement: Create types/metrics.ts with MetricEvent interface.
-                Working directory: [worktree path]
-                After completion, report what files were created/modified.")
+                Working directory: [sub-worktree path or issue worktree path]
+                After completion, commit your changes and report what files were created/modified.")
    ```
 
+   **Important (isolation mode):** Tell agents to commit their changes in the
+   sub-worktree. This is required for merge-back to work.
+
 4. **Wait for all agents to complete:**
    ```
    TaskOutput(task_id="...", block=true)
@@ -1544,6 +1575,31 @@ Look in the issue comments (especially from `/spec`) for:
    npx prettier --write [files modified by agents]
    ```
 
+5b. **Merge back and clean up sub-worktrees (isolation mode only):**
+   ```bash
+   WORKTREE_PATH="[issue worktree path]"
+
+   # Merge all agent branches back into the issue branch.
+   # Uses the tested TypeScript API — handles conflict detection,
+   # partial merges, and structured error reporting.
+   MERGE_RESULT=$(npx tsx scripts/worktree-isolation.ts merge-all "${WORKTREE_PATH}")
+   MERGED=$(echo "$MERGE_RESULT" | jq -r '.merged')
+   CONFLICTS=$(echo "$MERGE_RESULT" | jq -r '.conflicts')
+   echo "Merge-back: ${MERGED} merged, ${CONFLICTS} conflicts"
+
+   if [ "$CONFLICTS" -gt 0 ]; then
+     echo "⚠️ Conflicts detected — flagged for next iteration:"
+     echo "$MERGE_RESULT" | jq -r '.results[] | select(.success == false) | "  Agent \(.agentIndex): \(.error)"'
+   fi
+
+   # Clean up sub-worktrees and orphaned branches
+   npx tsx scripts/worktree-isolation.ts cleanup "${WORKTREE_PATH}"
+   ```
+
+   **If all merges succeed:** Proceed normally.
+   **If conflicts occur:** Report conflicting files. The next `/exec` iteration
+   can resolve them. Non-conflicting agents' changes are preserved.
+
 6. **Proceed to next group or sequential tasks**
 
 **If no Parallel Groups section exists:**
@@ -1773,40 +1829,20 @@ When in doubt, choose:
 
 The goal is to satisfy AC with the smallest, safest change possible.
 
-### 5. Adversarial Self-Evaluation (REQUIRED)
+### 5. Pre-PR Confidence Check (REQUIRED)
 
-**Before outputting your final summary**, you MUST complete this adversarial self-evaluation to catch issues that automated checks miss.
-
-**Why this matters:** Sessions show that honest self-questioning consistently catches real issues:
-- Tests that pass but don't cover the actual changes
-- Features that build but don't work as expected
-- AC items marked "done" but with weak implementation
-
-**Answer these questions honestly:**
-1. "Did anything not work as expected during implementation?"
-2. "If this feature broke tomorrow, would the current tests catch it?"
-3. "What's the weakest part of this implementation?"
-4. "Am I reporting success metrics without honest self-evaluation?"
-5. "For each changed source file, does a corresponding test file exist? If not, why is that acceptable?"
-6. "Did I run `npm run lint` and fix all errors, or am I hoping CI will pass?"
+**Before creating a PR**, state your confidence in 2-3 sentences.
 
 **Include this section in your output:**
 
 ```markdown
-### Self-Evaluation
+### Pre-PR Confidence Check
 
-- **Worked as expected:** [Yes/No - if No, explain what didn't work]
-- **Test coverage confidence:** [High/Medium/Low - explain why]
-- **Weakest part:** [Identify the weakest aspect of the implementation]
-- **Honest assessment:** [Any concerns or caveats?]
+- **Weakest part:** [What's the most fragile aspect of this implementation?]
+- **Coverage gaps:** [Which changed files lack corresponding tests, and why is that acceptable?]
 ```
 
-**If any answer reveals concerns:**
-- Address the issues before proceeding
-- Re-run relevant checks (`npm test`, `npm run build`)
-- Update the self-evaluation after fixes
-
-**Do NOT skip this self-evaluation.** Honest reflection catches issues that automated checks miss.
+**If either field reveals concerns**, address them before creating the PR. Re-run `npm test` and `npm run build` after fixes.
 
 ---
 
@@ -1880,42 +1916,11 @@ You may be invoked multiple times for the same issue. Each time, re-establish co
 
 ---
 
-## State Tracking
-
-**IMPORTANT:** Update workflow state when running standalone (not orchestrated).
-
-### Check Orchestration Mode
-
-The orchestration check happens automatically when you run the state update script - it exits silently if `SEQUANT_ORCHESTRATOR` is set.
-
-### State Updates (Standalone Only)
-
-When NOT orchestrated (`SEQUANT_ORCHESTRATOR` is not set):
-
-**At skill start:**
-```bash
-npx tsx scripts/state/update.ts start <issue-number> exec
-```
-
-**On successful completion:**
-```bash
-npx tsx scripts/state/update.ts complete <issue-number> exec
-```
-
-**On failure:**
-```bash
-npx tsx scripts/state/update.ts fail <issue-number> exec "Error description"
-```
-
-**Why this matters:** State tracking enables dashboard visibility, resume capability, and workflow orchestration. Skills update state when standalone; orchestrators handle state when running workflows.
-
----
-
 ## Output Verification
 
 **Before responding, verify your output includes ALL of these:**
 
-- [ ] **Self-Evaluation Completed** - Adversarial self-evaluation section included in output
+- [ ] **Pre-PR Confidence Check** - Weakest part and coverage gaps stated
 - [ ] **AC Progress Summary** - Which AC items are satisfied, partially met, or blocked
 - [ ] **Files Changed** - List of key files modified
 - [ ] **Test/Build/Lint Results** - Output from `npm run build`, `npm run lint`, and `npm test`