sequant 2.1.1 → 2.2.0

package/templates/skills/assess/SKILL.md

@@ -110,18 +110,21 @@ Surface red flags. Only track signals that change the recommendation.
 
 **Phase selection from labels:**
 
-| Labels | Workflow |
-|--------|----------|
-| bug, fix, hotfix, patch | `exec → qa` |
-| docs, documentation, readme | `exec → qa` |
-| ui, frontend, admin, web, browser | `spec → exec → test → qa` |
-| security, auth, authentication, permissions | `spec → security-review → exec → qa` |
-| complex, refactor, breaking, major | `spec → exec → qa` + `-q` |
-| enhancement, feature (default) | `spec → exec → qa` |
+| Labels | Category | Workflow |
+|--------|----------|----------|
+| security, auth, authentication, permissions | Domain | `spec → security-review → exec → qa` |
+| ui, frontend, admin, web, browser | Domain | `spec → exec → test → qa` |
+| complex, refactor, breaking, major | Modifier | `spec → exec → qa` + `-q` |
+| (ui/frontend) + (enhancement/feature), or testable-AC signals | Modifier | inserts `testgen` before `exec` (see Testgen detection below) |
+| enhancement, feature (default) | Generic | `spec → exec → qa` |
+| bug, fix, hotfix, patch | Generic | `exec → qa` |
+| docs, documentation, readme | Generic | `exec → qa` |
+
+**Label priority:** Domain labels take precedence over generic labels. When an issue has both a domain label and a generic label (e.g., `bug` + `auth`), use the domain-specific workflow. Example: an issue labeled `bug` + `auth` gets `spec → security-review → exec → qa`, not `exec → qa`. Similarly, `bug` + `ui` gets `spec → exec → test → qa`.
 
 **Valid phases (from `PhaseSchema` in `src/lib/workflow/types.ts`):** `spec`, `security-review`, `exec`, `testgen`, `test`, `verify`, `qa`, `loop`, `merger`
 
-**Skip spec when:** bug/docs label, OR spec comment already exists on issue.
+**Skip spec when:** (bug/docs label AND no domain labels like security/auth/ui/frontend), OR spec comment already exists on issue.
 
 **Resume detection:** Branch exists with commits ahead of main → mark as resume (`◂`).
 
@@ -129,10 +132,24 @@ Surface red flags. Only track signals that change the recommendation.
 
 **Quality loop (`-q`):** Recommend for everything except simple bug fixes and docs-only.
 
-**Other flags:**
-- `--chain` — Chain issues: each branches from previous (implies --sequential)
-- `--qa-gate` — Pause chain on QA failure, preventing downstream issues from building on broken code (requires --chain)
-- `--base <branch>` — Issue references a feature branch
+**Testgen detection:** Add `testgen` to the workflow when any apply:
+- Labels include (`ui` or `frontend`) AND (`enhancement` or `feature`)
+- ACs reference "unit test", "integration test", or list "Automated Test" as a verification method
+
+Skip when: only `bug`/`fix` labels present, only `docs` label present, or a prior `testgen` phase marker exists in issue comments.
+
+**Chain detection (suggest-only, never auto-apply):** When 2+ assessed issues have a detected dependency, emit a `Chain:` line alongside (not replacing) the default per-issue commands. False dependency inference produces silently-wrong branch topology, so the user decides.
+
+Triggers (any one):
+- Issue body or comments mention `"depends on #N"`, `"blocked by #N"`, or `"after #N"`
+- One issue's described output is another issue's input (e.g., A changes a function signature that B consumes)
+
+Format: `Chain: npx sequant run <N1> <N2> --chain --qa-gate -q <phases>   # alternative — <one-line reason>`
+
+Flag references:
+- `--chain` chains issues (each branches from previous; implies `--sequential`)
+- `--qa-gate` pauses chain on QA failure (requires `--chain`)
+- `--base <branch>` — issue references a feature branch
 
 ### Step 5: Conflict Detection
 
@@ -150,23 +167,28 @@ For each active worktree, check `git diff --name-only main...HEAD` for file over
 
 **Design principle:** Dashboard first. Copy-pasteable commands. Silence means healthy.
 
+**Table column rules:** The "Reason" column must not be truncated mid-word. If a row's reason text would exceed the column width, prefer abbreviating the reason to a shorter synonym rather than cutting a word in half. Column widths should adapt to content — do not force a fixed table width.
+
 ```
- #    Action     Reason                              Run
-<N>   <ACTION>   <short reason>                       <workflow or symbol>
-<N>   <ACTION>   <short reason>                       <workflow or symbol>
+ #    Action     [ACs]  Reason                              Run
+<N>   <ACTION>   [N]    <short reason>                       <workflow or symbol>
+<N>   <ACTION>   [N]    <short reason>                       <workflow or symbol>
 ...
 ────────────────────────────────────────────────────────────────
-
-╭──────────────────────────────────────────────────────────────╮
-│  npx sequant run <N1> <N2> <flags>                           │
-│  npx sequant run <N3> <flags>              # resume          │
-╰──────────────────────────────────────────────────────────────╯
-
+Commands:
+  npx sequant run <N1> <N2> <flags>
+  npx sequant run <N3> <flags>              # resume
 ────────────────────────────────────────────────────────────────
-Order: <N> → <N> (<shared file>) · <N> → <N> (<dependency>)
+Order: <N> → <N> (<dependency reason>)
 
 ⚠ #<N>  <warning>
 ⚠ #<N>  <warning>
+
+Chain: npx sequant run <N1> <N2> --chain --qa-gate -q <phases>   # alternative — <reason>
+
+Flags:
+  <flag>                <one-line reason>
+  <flag>                <one-line reason>
 ────────────────────────────────────────────────────────────────
 Cleanup:
   <executable command>                 # reason
@@ -179,6 +201,8 @@ Cleanup:
 <!-- assess:quality-loop=<bool> -->
 ```
 
+**`ACs` column (conditional):** Include the `ACs` column only when every assessed issue has at least one explicit `- [ ]` checkbox AC in its body. Otherwise omit the column entirely — do not show partial values. The counter prevents eroding table trust when some issues use implicit/narrative ACs.
+
 #### Run Column Symbols
 
 | Symbol | Meaning | Example |
@@ -193,24 +217,50 @@ Cleanup:
 | `‖` | Blocked/deferred | Dependency or manual |
 | `—` | No action needed | Already closed/merged |
 
-#### Command Block Rules
+#### Commands Block Rules
+
+The commands block is headed by `Commands:` — no box-drawing, no character counting. The header label is the visual anchor.
 
 1. Only PROCEED and REWRITE issues get commands
 2. Group by identical phases + flags → same line
 3. Resume issues get `# resume` comment
 4. Rewrite issues get `# restart` comment
-5. Chain mode issues use `--chain` flag
+5. Chain mode issues use `--chain` flag (see `Chain:` annotation rules below)
 6. If ALL issues share the same workflow, emit a single command
+7. **Line splitting:** When a single command would contain more than 6 issue numbers, split into multiple commands of at most 6 issues each, grouped by compatible workflow. Example: 11 issues → two commands (6 + 5)
 
 #### Annotation Rules
 
-- **`Order:`** — Only when sequencing matters (shared files or dependencies). Format: `A → B (reason)` joined by ` · `
-- **`⚠` warnings** — Only non-obvious signals (complexity, staleness, dual concerns). One line each. Prefix with issue number.
+Emit annotations in this order between the separators that follow `Commands:`:
+`Order:` → `⚠` warnings → `Chain:` → `Flags:`. `Cleanup:` goes in its own block after. Omit any section (and its surrounding blank line) when it has no content.
+
+- **`Order:`** — Only when sequencing matters. Include the **reason** for the ordering, not just `(<filename>)`. Prefer dependency reasoning over filename.
+  - Good: `Order: 185 → 186 (185 changes fetchApi error format that 186 consumes)`
+  - Good: `Order: 460 → 461 (460 adds batch-executor tests that 461's label matching depends on)`
+  - Avoid bare filenames when a reason is clearer.
+
+- **`⚠` warnings** — Only non-obvious signals (complexity, staleness, dual concerns, partial-AC satisfaction). One line each, prefixed with issue number. Warnings can note when part of an AC is already satisfied in the codebase:
+  - `⚠ #185  Domain errors already exist in repository layer — scope may be smaller than expected`
+  - `⚠ #412  bug + auth labels — domain label (auth) takes priority over bug`
+
+- **`Chain:`** — Only when 2+ PROCEED issues have a detected dependency (see "Chain detection" in Step 4). Suggests an alternative execution topology. Does not replace the default per-issue commands. Format:
+  `Chain: npx sequant run <N1> <N2> --chain --qa-gate -q <phases>   # alternative — <one-line reason>`
+
+- **`Flags:`** — Only when non-default flags appear in the commands and the reason isn't obvious. One line per **distinct** flag used across all commands. Omit entire section when `-q` is the only non-default flag AND its reason is obvious (e.g., all issues are enhancements). Format:
+  ```
+  Flags:
+    -q                   9+ ACs or multi-file scope
+    --testgen            testable ACs detected (UI hooks + API integration)
+    --phases ...,test    ui label → browser verification
+  ```
+
 - **`Cleanup:`** — Only when actionable (stale branches, merged-but-open issues, label changes). Show as executable commands with `# reason` comments.
-- **Omit entire section** (including its separator) when no annotations of that type exist.
+
 - **"All clear" is silence** — no annotation means no issues.
 
-#### Batch Example (mixed states)
+#### Batch Example (mixed states, with label priority)
+
+Not all issues have explicit `- [ ]` checkboxes, so the `ACs` column is omitted.
 
 ```
  #    Action     Reason                              Run
@@ -220,22 +270,26 @@ Cleanup:
  458  PROCEED    Parallel UX + race condition          spec → exec → qa
  447  CLOSE      PR #457 merged                        —
  443  PROCEED    Consolidate gh calls                  spec → exec → qa
- 412  PROCEED    Auth token refresh                    ◂ exec → qa
+ 412  PROCEED    Auth bug (domain: auth overrides bug) spec → security-review → exec → qa
+ 411  PROCEED    Config path normalization              ◂ exec → qa
  405  REWRITE    PR #380 200+ commits behind           ⟳ spec → exec → qa
 ────────────────────────────────────────────────────────────────
-
-╭──────────────────────────────────────────────────────────────╮
-│  npx sequant run 461 460 -q --phases exec,qa                      │
-│  npx sequant run 458 443 -q                                  │
-│  npx sequant run 412 -q --phases exec,qa     # resume        │
-│  npx sequant run 405 -q                      # restart       │
-╰──────────────────────────────────────────────────────────────╯
-
+Commands:
+  npx sequant run 461 460 -q --phases exec,qa
+  npx sequant run 458 443 -q
+  npx sequant run 412 -q --phases spec,security-review,exec,qa
+  npx sequant run 411 -q --phases exec,qa     # resume
+  npx sequant run 405 -q                      # restart
 ────────────────────────────────────────────────────────────────
-Order: 460 → 461 (batch-executor.ts)
+Order: 460 → 461 (460 adds batch-executor tests that 461's label matching depends on)
 
 ⚠ #458  Dual concern (UX + race) across 4 files
 ⚠ #405  Stale 30+ days, ACs still valid
+⚠ #412  bug + auth labels — domain label (auth) takes priority over bug
+
+Flags:
+  -q                   multi-file scope across most PROCEED issues
+  --phases spec,...    spec phase added for 458/443/412/405 (standard features)
 ────────────────────────────────────────────────────────────────
 Cleanup:
   git worktree remove .../447-...      # merged, stale worktree
@@ -249,13 +303,44 @@ Cleanup:
 <!-- #458 assess:action=PROCEED assess:phases=spec,exec,qa assess:quality-loop=true -->
 <!-- #447 assess:action=CLOSE -->
 <!-- #443 assess:action=PROCEED assess:phases=spec,exec,qa assess:quality-loop=true -->
-<!-- #412 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
+<!-- #412 assess:action=PROCEED assess:phases=spec,security-review,exec,qa assess:quality-loop=true -->
+<!-- #411 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
 <!-- #405 assess:action=REWRITE assess:phases=spec,exec,qa assess:quality-loop=true -->
 ```
 
+#### Batch Example (dependent issues with testgen, chain suggestion)
+
+All issues have explicit checkbox ACs, so the `ACs` column is shown. A dependency is detected (185 → 186), so a `Chain:` suggestion appears alongside the default commands.
+
+```
+ #    Action    ACs  Reason                           Run
+ 185  PROCEED    6   Domain error standardization      spec → exec → qa
+ 186  PROCEED    9   React Query hooks migration       spec → testgen → exec → test → qa
+────────────────────────────────────────────────────────────────
+Commands:
+  npx sequant run 185 -q
+  npx sequant run 186 -q --phases spec,testgen,exec,test,qa
+────────────────────────────────────────────────────────────────
+Order: 185 → 186 (185 changes fetchApi error format that 186 consumes)
+
+⚠ #185  Domain errors already exist in repository layer — scope may be smaller than expected
+⚠ #186  @tanstack/react-query not installed; large scope (9 hooks + optimistic updates)
+
+Chain: npx sequant run 185 186 --chain --qa-gate -q --phases spec,testgen,exec,test,qa
+       # alternative — use if 186 should branch from 185's work
+
+Flags:
+  --testgen             #186 has testable ACs (UI hooks + API integration)
+  --phases ...,test     #186 ui label → browser verification
+────────────────────────────────────────────────────────────────
+
+<!-- #185 assess:action=PROCEED assess:phases=spec,exec,qa assess:quality-loop=true -->
+<!-- #186 assess:action=PROCEED assess:phases=spec,testgen,exec,test,qa assess:quality-loop=true -->
+```
+
 #### Batch Example (all clean)
 
-When every issue is PROCEED with no warnings, the output is minimal:
+When every issue is PROCEED with no warnings, no dependencies, and no non-default flags beyond an obvious `-q`, the output is minimal. The `Flags:` section is omitted because `-q` is obvious here (all PROCEED enhancements).
 
 ```
  #    Action     Reason                              Run
@@ -263,12 +348,9 @@ When every issue is PROCEED with no warnings, the output is minimal:
  460  PROCEED    batch-executor tests                  exec → qa
  443  PROCEED    Consolidate gh calls                  spec → exec → qa
 ────────────────────────────────────────────────────────────────
-
-╭──────────────────────────────────────────────────────────────╮
-│  npx sequant run 461 460 -q --phases exec,qa                      │
-│  npx sequant run 443 -q                                      │
-╰──────────────────────────────────────────────────────────────╯
-
+Commands:
+  npx sequant run 461 460 -q --phases exec,qa
+  npx sequant run 443 -q
 ────────────────────────────────────────────────────────────────
 
 <!-- #461 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
@@ -276,6 +358,63 @@ When every issue is PROCEED with no warnings, the output is minimal:
 <!-- #443 assess:action=PROCEED assess:phases=spec,exec,qa assess:quality-loop=true -->
 ```
 
+Silence means clean — no `Order:`, no `⚠`, no `Chain:`, no `Flags:`, no `Cleanup:`.
+
+#### Batch Example (large batch, 13 issues with Rule 7 split)
+
+When assessing 9+ issues, commands are split per Rule 7 (max 6 issue numbers per line), and the table adapts to content width. Mixed AC styles across issues → `ACs` column omitted.
+
+```
+ #    Action     Reason                                   Run
+ 503  PROCEED    Fix typo in error output                   exec → qa
+ 502  PROCEED    Update deprecated API call                 exec → qa
+ 501  PROCEED    Add retry logic to API client              exec → qa
+ 500  PROCEED    Fix token refresh race condition           spec → security-review → exec → qa
+ 499  PROCEED    Dashboard chart rendering bug              spec → exec → test → qa
+ 498  PROCEED    Update error messages                      exec → qa
+ 497  PROCEED    Refactor batch executor                    spec → exec → qa
+ 496  PARK       Blocked on #490 schema migration           ‖
+ 495  PROCEED    CLI help text improvements                 exec → qa
+ 494  PROCEED    Assess batch formatting fix                exec → qa
+ 493  CLOSE      Duplicate of #491                          —
+ 492  PROCEED    Add export command                         spec → exec → qa
+ 491  PROCEED    Normalize config paths                     exec → qa
+────────────────────────────────────────────────────────────────
+Commands:
+  npx sequant run 503 502 501 498 495 494 -q --phases exec,qa
+  npx sequant run 491 -q --phases exec,qa
+  npx sequant run 499 -q --phases spec,exec,test,qa
+  npx sequant run 500 -q --phases spec,security-review,exec,qa
+  npx sequant run 497 492 -q
+────────────────────────────────────────────────────────────────
+Order: 497 → 492 (497 refactors batch-executor internals that 492's export command uses)
+
+⚠ #500  bug + auth labels — domain label takes priority
+⚠ #499  bug + ui labels — domain label triggers test phase
+
+Flags:
+  --phases ...,security-review   #500 auth label → security review required
+  --phases ...,test              #499 ui label → browser verification
+────────────────────────────────────────────────────────────────
+Cleanup:
+  gh issue close 493                   # duplicate of #491
+────────────────────────────────────────────────────────────────
+
+<!-- #503 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
+<!-- #502 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
+<!-- #501 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
+<!-- #500 assess:action=PROCEED assess:phases=spec,security-review,exec,qa assess:quality-loop=true -->
+<!-- #499 assess:action=PROCEED assess:phases=spec,exec,test,qa assess:quality-loop=true -->
+<!-- #498 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
+<!-- #497 assess:action=PROCEED assess:phases=spec,exec,qa assess:quality-loop=true -->
+<!-- #496 assess:action=PARK -->
+<!-- #495 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
+<!-- #494 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
+<!-- #493 assess:action=CLOSE -->
+<!-- #492 assess:action=PROCEED assess:phases=spec,exec,qa assess:quality-loop=true -->
+<!-- #491 assess:action=PROCEED assess:phases=exec,qa assess:quality-loop=true -->
+```
+
 ---
 
 ### Single Mode (1 issue)
@@ -291,11 +430,13 @@ More context since you're focused on one issue. Separators between every section
 
 → PROCEED — <one-line reason>
 
-╭──────────────────────────────────────────────────────────────╮
-│  npx sequant run <N> <flags>                                 │
-╰──────────────────────────────────────────────────────────────╯
+Commands:
+  npx sequant run <N> <flags>
 
-<phases> · <N> ACs · <flag reasoning>
+<phases> · <N> ACs
+
+Flags:
+  <flag>        <one-line reason>
 ────────────────────────────────────────────────────────────────
 ⚠ <warning if any>
 ⚠ Conflict: #<N> also modifies <path>
@@ -306,7 +447,9 @@ More context since you're focused on one issue. Separators between every section
 <!-- assess:quality-loop=<bool> -->
 ```
 
-If no warnings exist, omit the warning section and its separator:
+**`Flags:` (single mode):** Indented list of each enabled non-default flag with a one-line reason. Omit the entire `Flags:` section when `-q` is the only non-default flag AND the reason is obvious (e.g., a straightforward enhancement). Do not repeat obvious flags.
+
+Example with `Flags:` (non-obvious `-q` + `--testgen`):
 
 ```
 #458 — Parallel run UX freeze + reconcileState race condition
@@ -315,11 +458,33 @@ Open · bug, enhancement, cli
 
 → PROCEED — Both root causes confirmed in codebase
 
-╭──────────────────────────────────────────────────────────────╮
-│  npx sequant run 458 -q                                      │
-╰──────────────────────────────────────────────────────────────╯
+Commands:
+  npx sequant run 458 -q
+
+spec → exec → qa · 8 ACs
 
-spec → exec → qa · 8 ACs · -q (dual concern)
+Flags:
+  -q     dual concern across 4 files
+────────────────────────────────────────────────────────────────
+
+<!-- assess:action=PROCEED -->
+<!-- assess:phases=spec,exec,qa -->
+<!-- assess:quality-loop=true -->
+```
+
+Example omitting `Flags:` (obvious `-q` for a standard enhancement):
+
+```
+#443 — Consolidate gh CLI calls
+Open · enhancement
+────────────────────────────────────────────────────────────────
+
+→ PROCEED — Codebase matches spec, 5 ACs
+
+Commands:
+  npx sequant run 443 -q
+
+spec → exec → qa · 5 ACs
 ────────────────────────────────────────────────────────────────
 
 <!-- assess:action=PROCEED -->
@@ -397,9 +562,8 @@ Need: <specific information required>
 
 → REWRITE — <reason>
 
-╭──────────────────────────────────────────────────────────────╮
-│  npx sequant run <N> <flags>                 # fresh start   │
-╰──────────────────────────────────────────────────────────────╯
+Commands:
+  npx sequant run <N> <flags>                 # fresh start
 
 <phases> · <N> ACs
 ────────────────────────────────────────────────────────────────
@@ -417,27 +581,19 @@ Need: <specific information required>
 
 | Section | Show when |
 |---------|-----------|
-| Command block | At least one PROCEED or REWRITE issue |
+| `ACs` column (batch) | Every assessed issue has ≥1 explicit `- [ ]` checkbox AC |
+| `Commands:` block | At least one PROCEED or REWRITE issue |
 | `Order:` | File conflicts or dependencies require sequencing |
-| `⚠` warnings | Non-obvious signals exist |
+| `⚠` warnings | Non-obvious signals exist (complexity, staleness, dual concerns, partial-AC satisfaction) |
+| `Chain:` | 2+ PROCEED issues with detected dependency (suggest-only) |
+| `Flags:` | Non-default flags appear AND `-q` is not the sole flag with an obvious reason |
 | `Cleanup:` | Stale branches, merged-but-open issues, or label changes |
 | Separators | Between sections that are both shown; omit if adjacent section is omitted |
 
-Every separator and section is conditional. If there are no warnings and no cleanup, the output is just: table → separator → command block → separator → markers.
+Every separator and section is conditional. If there are no warnings, no chain, no flags, and no cleanup, the output is just: table → separator → `Commands:` block → separator → markers.
 
 ---
 
-## State Tracking
-
-Initialize state for each assessed issue:
-
-```bash
-TITLE=$(gh issue view <N> --json title -q '.title')
-npx tsx scripts/state/update.ts init <N> "$TITLE"
-```
-
-Note: `/assess` only initializes issues — actual phase tracking happens during workflow execution.
-
 ## Persist Analysis
 
 After displaying output, prompt the user to save using `AskUserQuestion` with options "Yes (Recommended)" and "No".
@@ -467,10 +623,16 @@ If confirmed, post a structured comment to each issue via `gh issue comment`. Ea
 
 - [ ] Every issue has exactly one action in the table
 - [ ] Run column uses correct symbol for the action/state
-- [ ] Command block only contains PROCEED and REWRITE issues
-- [ ] Commands are grouped by compatible workflow
-- [ ] Separators appear between every shown section
-- [ ] Annotations omitted when not applicable (silence = healthy)
+- [ ] `ACs` column included only when every issue has explicit `- [ ]` checkboxes
+- [ ] Commands appear under a `Commands:` header (no bare indented block, no box-drawing)
+- [ ] Commands block only contains PROCEED and REWRITE issues, grouped by compatible workflow
+- [ ] `testgen` included when ui/frontend + enhancement/feature labels OR testable-AC signals
+- [ ] `Chain:` suggested (not auto-applied) when 2+ PROCEED issues have a detected dependency
+- [ ] `Flags:` section present when non-default flags appear (unless only obvious `-q`)
+- [ ] `Order:` annotations carry dependency **reasoning**, not bare filenames
+- [ ] `⚠` warnings include partial-AC satisfaction where applicable
+- [ ] Separators appear between every shown section; omitted when adjacent section is omitted
+- [ ] Annotations/sections omitted when not applicable (silence = healthy)
 - [ ] HTML markers present for every assessed issue
 - [ ] Batch mode: table is the primary output, no per-issue detail sections
 - [ ] Single mode: focused summary with separators between sections

package/templates/skills/exec/SKILL.md

@@ -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:
@@ -1837,40 +1827,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.
 
 ---
 
@@ -1944,42 +1914,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`