@jakkrichm/create-nexus-devflow 2.12.2 → 2.12.4

package/template/.claude/skills/audit/SKILL.md

@@ -85,10 +85,15 @@ Optional review mode:
 
 ## Independent mode
 
-`/audit independent current` is a two-session workflow. The builder session
-prepares a request. The selected fresh reviewer session runs the same command
-to complete it. DevFlow verifies the exact target and later staleness. The
-adapter, model, and fresh-session identity remain declared metadata.
+`/audit independent current` is a two-context workflow. The builder prepares a
+request. With `review.independentExecution: "manual"`, the selected fresh
+reviewer session runs the same command to complete it. With `automatic`, the
+current adapter may start a fresh isolated reviewer subagent after preparing the
+request. DevFlow verifies the exact target and later staleness. The adapter,
+model, and fresh-context identity remain declared metadata.
+An explicit invocation uses this execution setting even when the active
+workflow's `independentReview` gate is `manual`; that gate value disables only
+automatic selection by the workflow.
 
 Read `reference/independent-review.md` before either phase.
 
@@ -97,6 +102,11 @@ Read `reference/independent-review.md` before either phase.
 Use this phase when `devflow/context/{xxx-slug}/review.md` has no current `pending`
 request for `HEAD` and the current spec hash.
 
+A current pending request without `Requested execution` is legacy and manual
+only. Never add execution fields to it or run a subagent against it. Stop with
+the fresh-session handoff; Phase B must omit `Actual execution` so the legacy
+request and receipt keep both execution fields absent.
+
 1. Require an active spec with every build step checked and status `verified`, a
    non-default work branch, a reliable merge base, and a clean working tree.
    Independent mode accepts only a locally recorded remote default branch,
@@ -109,22 +119,52 @@ request for `HEAD` and the current spec hash.
 2. Read installed adapters from `.nexus/nexus-devflow.json` or manifest when valid.
    Detect `.agents/skills` as `antigravity`/`codex`/`copilot` and `.claude/skills`
    as `claude`.
-3. Ask which detected adapter and available model should review. Recommend an
-   equal-or-stronger coding model, a different model family when practical, and
-   high reasoning for sensitive work. Offer a fresh session in the current
-   adapter as the fallback.
+3. Resolve the review executor from `review.independentExecution`:
+   - For `manual`, ask which detected adapter and available model should review.
+     Recommend an equal-or-stronger coding model, a different model family when
+     practical, and high reasoning for sensitive work. Offer a fresh session in
+     the current adapter as the fallback. Do not invent available models or
+     offer an adapter that is not installed in the project.
+   - For `automatic`, use only a live child-agent capability in the current
+     adapter that can start with no builder transcript, disclose the exact
+     reviewer adapter and model, and wait for completion. Spawn a generic fresh
+     isolated child through the current runtime. Do not discover, select, or
+     depend on a globally installed role, skill, prompt, or another workflow
+     such as TraversyFlow. If the runtime cannot start that generic child from
+     project-local instructions, or capability, isolation, identity, model, or
+     completion cannot be confirmed, use the manual path.
 4. Record the full target SHA, full merge-base SHA, the exact local base ref
    used to calculate it, exact spec SHA-256, current adapter and model,
-   requested reviewer adapter and model, workflow, and
+   requested reviewer adapter and model, requested execution from
+   `review.independentExecution`, workflow, and
    whether the configured Check gate is required. Write the pending template
    into `devflow/context/{xxx-slug}/review.md`.
-5. Set dashboard activity to `ready` and give the exact handoff command for the
-   selected adapter. Claude Code uses `/audit independent current`; Google Antigravity uses
-   `/audit independent current`; Codex uses `$audit independent current`. Tell
-   the user to open a fresh session with only the handoff, not the builder chat.
-
-Stop after the handoff. The builder never continues into Phase B in the same
-session.
+5. Execute the configured path:
+   - For `manual`, set dashboard activity to `ready` and give the exact handoff
+     command for the selected adapter. Claude Code uses
+     `/audit independent current`; Google Antigravity uses
+     `/audit independent current`; Codex uses `$audit independent current`;
+     Copilot and OpenCode receive the equivalent plain-language instruction.
+     Tell the user to open a fresh session with only the handoff, not the builder
+     chat.
+   - For `automatic`, freeze all parent product, test, spec, and config changes.
+     Start one generic isolated child without the builder transcript. Instruct
+     it to read the project-local Audit skill and
+     `reference/independent-review.md` from the current adapter tree, then
+     execute Phase B against the prepared request. All review instructions come
+     from that installed DevFlow project. The reviewer may write only
+     `devflow/context/{xxx-slug}/findings.md` and `devflow/context/{xxx-slug}/review.md`; it must
+     not repair code, change the spec, commit, or perform external actions. Wait
+     for completion, then reread and validate the normal receipt before
+     continuing. Record `fresh subagent` as its reviewer context.
+
+If automatic execution fails or any required property becomes uncertain, keep
+the pending request intact, set activity to `ready`, and stop with the existing
+manual fresh-session handoff. Never let the builder review its own work or skip
+a selected independent-review gate.
+
+The builder never performs Phase B itself. It may continue only after a manual
+reviewer session or automatic isolated reviewer produced a valid current receipt.
 
 ### Phase B - perform the review
 
@@ -136,8 +176,12 @@ Use this phase when a current pending request exists in `devflow/context/{xxx-sl
    recorded merge base, the exact spec hash matches, and no path differs from
    the target except `devflow/context/{xxx-slug}/review.md` and
    `devflow/context/{xxx-slug}/findings.md`. Stop on any mismatch or stale state.
-2. Proceed only from the fresh reviewer handoff. Record `fresh session` as a
-   declaration. If the reviewer has the builder conversation, stop and request a fresh session.
+2. Proceed only from the fresh reviewer handoff. Record `fresh session` for a
+   manual reviewer or `fresh subagent` for an automatic isolated reviewer. This
+   is a declaration, never cryptographic proof. If the reviewer has the builder
+   conversation or is the builder continuing in place, stop and request a fresh
+   context. For a legacy request with no `Requested execution`, require a fresh
+   reviewer session, record `fresh session`, and omit `Actual execution`.
 3. Run Steps 1 through 3 across `current` with quality, security, performance,
    and tests together. Review the code fresh against the recorded
    `Base commit` and `Target commit`; exclude the request and findings files
@@ -150,6 +194,9 @@ Use this phase when a current pending request exists in `devflow/context/{xxx-sl
    with a completed receipt in `devflow/context/{xxx-slug}/review.md`. Use `passed` only when the whole target was
    reviewed, required checks passed, and no P0 or P1 finding is `open` or
    `fixed`.
+   Record actual `automatic` with `fresh subagent`, or actual `manual` with
+   `fresh session`, including an explicit manual fallback from an automatic
+   request.
 6. Report the receipt target, reviewer adapter and model, commands, evidence,
    findings, remaining risk, and whether the receipt passed. Never repair code
    from the reviewer session.

package/template/.claude/skills/audit/reference/independent-review.md

@@ -11,7 +11,7 @@ work, archived by `/complete`, and then reset.
 
 > **Generated file.** Holds the active independent-review request or latest
 > receipt for the current work item. `/audit independent current` prepares a
-> handoff against an approved checkpoint, a fresh reviewer session completes it,
+> handoff against an approved checkpoint, a fresh reviewer context completes it,
 > and `/complete` refuses stale, pending, or changes-requested review state.
 
 _No independent review requested. Run `/audit independent current` to prepare one._
@@ -30,6 +30,11 @@ review runtime cannot select a specific model before the session starts, use
 `runtime default (exact model not known until reviewer starts)` for Requested
 model and record the exact runtime model in the completed receipt.
 
+A pending request without `Requested execution` is a legacy manual request.
+Never auto-upgrade it or send it to a subagent. Complete it only from a fresh
+reviewer session, keep `Reviewer context: fresh session`, and omit `Actual
+execution` so both execution fields remain absent.
+
 ```markdown
 # Independent Review
 
@@ -42,6 +47,7 @@ model and record the exact runtime model in the completed receipt.
 **Builder model:** <exact model reported by the builder runtime>
 **Requested reviewer:** <adapter>
 **Requested model:** <exact model or user-selected runtime default>
+**Requested execution:** <manual or automatic>
 **Requested at:** <ISO-8601 timestamp>
 **Workflow:** <regular or continuous>
 **Check required:** <yes or no>
@@ -49,7 +55,7 @@ model and record the exact runtime model in the completed receipt.
 ## Handoff
 
 Review the active spec and the complete `<base>..<target>` delta in a fresh
-session without the builder conversation. Run all Audit lenses from scratch.
+session or isolated subagent without the builder conversation. Run all Audit lenses from scratch.
 Run Check when required above. Do not edit product code, accept findings, or
 reuse the existing findings as the review scope.
 ```
@@ -68,7 +74,8 @@ Keep the request fields unchanged and replace `pending` with `passed` or
 ```markdown
 **Reviewer adapter:** <adapter>
 **Reviewer model:** <exact model reported by the reviewer runtime>
-**Reviewer context:** fresh session
+**Reviewer context:** <fresh session or fresh subagent>
+**Actual execution:** <manual or automatic>
 **Reviewed at:** <ISO-8601 timestamp>
 **Scope:** current
 **Lenses:** quality, security, performance, tests
@@ -104,7 +111,14 @@ Use `passed` only when all four lenses covered the complete target delta, every
 required check passed, and no P0 or P1 finding is `open` or `fixed`.
 P2 and P3 findings may remain with their normal ledger status. Use
 `changes-requested` for a blocking finding, failed required check, incomplete
-scope, adapter mismatch, or missing fresh-session declaration.
+scope, adapter mismatch, or missing a valid fresh-context declaration.
+
+Execution and context must agree. A manual request completes only as actual
+`manual` with `fresh session`. An automatic request normally completes as
+actual `automatic` with `fresh subagent`; when automatic capability falls back,
+it may complete as actual `manual` with `fresh session`. Reject every other
+pairing. Legacy receipts with neither execution field remain valid only with
+`fresh session`; a legacy receipt can never claim `fresh subagent`.
 
 ## Freshness
 
@@ -122,7 +136,20 @@ A receipt is current only when all of these hold:
   request explicitly selected the runtime-default sentinel above. In that case,
   `Reviewer model` must still contain the exact model exposed after the reviewer
   session starts, never the sentinel itself.
+- `Reviewer context` is exactly `fresh session` or `fresh subagent`. A subagent
+  receipt is valid only when the runtime started it without the builder
+  transcript and exposed its exact adapter and model. The automatic child is a
+  generic current-runtime child instructed from the project-local Audit skill
+  and this project-local contract. It never depends on a global role, skill,
+  prompt, or another workflow.
+- `Requested execution` and `Actual execution` form one of the allowed pairings
+  above. New requests always record the requested value, and new receipts always
+  record the actual value.
 
 Any other code, test, configuration, spec, or acceptance-criteria change makes
 the receipt stale. A stale receipt never proves the new state. Prepare a new
 request against a new approved checkpoint and review the whole delta again.
+
+The adapter, model, and context fields are declared metadata. DevFlow proves
+the target and staleness, but it cannot cryptographically prove that a separate
+agent or fresh context performed the review.

package/template/.claude/skills/autopilot/SKILL.md

@@ -20,6 +20,11 @@ same quality gates, but it does not stop after every normal review point. A
 single user request is permission to run one bounded loop until the feature is
 ready for review, blocked, or unsafe to continue.
 
+It combines `/feature` or `/fix` with `/implement` and continues through the
+spec-review stop retained by the normal workflow. That human spec approval is
+the main control Autopilot intentionally removes. It does not remove the final
+review packet or the option to walk through the completed code.
+
 It does **not** replace the normal workflow. `/feature`, `/implement`, `/check`,
 and `/complete` remain the conservative default.
 
@@ -103,28 +108,26 @@ declared and capture interactive evidence with `browseros-neo` when available.
 If either path is unavailable, record the limitation in the review packet and do
 not install a runner or claim browser proof implicitly.
 
-## Step 2 - choose or write the spec
+## Step 2 - spec or fix definition
+
+If starting a planned feature:
 
-If `devflow/context/{xxx-slug}/spec.md` already contains an active spec,
-resume it. Read checked steps and continue from the first unchecked step.
+1. Read `devflow/context/project-overview.md` and `devflow/build-plan.md`.
+2. Follow `/feature`'s sizing logic. If the feature is too large for one spec,
+   split it in `devflow/build-plan.md` into `Na`, `Nb`, `Nc` and target only
+   the first sub-feature.
+3. Write the spec to `devflow/context/{xxx-slug}/spec.md` and set its status to
+   `specified`. Fill all required sections, including the small build steps and
+   acceptance criteria.
 
-If there is no active spec:
+If starting an ad-hoc fix:
 
-1. Use the `/feature` behavior for a planned feature, or `/fix` behavior for a
-   requested fix.
-2. Create workspace and write `devflow/context/{xxx-slug}/spec.md`.
-3. Red-team the spec before building:
-   - missing unhappy paths
-   - oversized steps
-   - undefined contracts
-   - missing design reference
-   - scope creep
-   - vague done-whens
-   - missing testing plan when `AGENTS.md` declares a test command
-4. Apply the spec fixes.
+1. Pull the bug description or failure context.
+2. Follow `/fix`'s definition rules and write `devflow/context/{xxx-slug}/spec.md`.
+3. Set `Type: Fix` and write a short, focused task list.
 
-Autopilot may continue past this spec gate because the user explicitly invoked
-Autopilot. Still report what the critique changed in the final packet.
+If resuming an existing feature, verify `devflow/context/{xxx-slug}/spec.md` is
+usable and resume from the first unchecked step.
 
 ## Step 3 - branch
 
@@ -161,6 +164,10 @@ Work through the spec's steps in order:
 Do not batch the whole feature into one large diff. If a step gets too large,
 split the step in `devflow/context/{xxx-slug}/spec.md` and continue with the first smaller step.
 
+Do not pause for user approval after each passing step, regardless of the
+configured `workflow.stepReview` value. The review happens at the final packet
+unless a hard stop is hit.
+
 ## Step 5 - acceptance check
 
 After all implementation steps are checked, run the `/check` behavior for the
@@ -177,6 +184,38 @@ feature audit, not a repository-wide cleanup pass. Findings are recorded in
 `devflow/context/{xxx-slug}/findings.md` with durable IDs and statuses, as `/audit`
 defines; the ledger reports status and never scopes what the audit examines.
 
+Apply `qualityGates.regular.independentReview` before a same-session audit:
+
+- `manual` does not activate the gate.
+- `when-sensitive` requires it only when the work touches authentication,
+  authorization, secrets, payments, personal data, destructive actions, dependencies,
+  deployment, or another sensitive boundary.
+- `always` requires it for every work item.
+
+The selected review runs after all implementation steps, final Verify, required
+Check, and the verified spec, before the final review packet and `/complete`.
+`review.independentExecution` chooses the manual fresh-session handoff or an
+automatic isolated reviewer; it does not change when the gate is selected.
+
+When selected, do not review the builder's work in this session. Ensure all work
+is in an approved clean checkpoint, then follow Phase A of
+`/audit independent current`. With automatic execution, spawn and wait for the
+isolated reviewer, then validate its normal receipt. With manual execution, stop
+with the handoff. Autopilot may use its existing configured checkpoint authority
+when checkpoint commits are enabled; otherwise show the exact review-checkpoint
+candidate and ask before committing. On resume, continue only when a fresh
+reviewer wrote a current `passed` receipt. Repair `changes-requested` P0/P1
+findings within the normal scope and attempt limit, then obtain a new checkpoint
+and prepare a new review. A passing independent receipt satisfies the configured
+Audit gate.
+
+The request records `Requested execution`; the receipt records `Actual
+execution`. Require the execution and reviewer-context pairing defined by the
+project-local review contract, including actual manual plus `fresh session` when
+an automatic request explicitly falls back.
+On resume, a pending request without `Requested execution` is legacy manual-only.
+Never add execution fields or run a subagent against it.
+
 For every finding:
 
 1. Validate it against the actual code, spec, tests, `coding-standards.md`, and
@@ -216,6 +255,11 @@ Stop and produce a concise review packet:
 - unresolved risks or skipped checks
 - exact next action
 
+Always offer a read-only walkthrough of the completed code after the packet.
+Follow the spec's build steps, explain the key files, symbols, flow, and
+non-obvious decisions, then offer a focused deep dive. Keep `/try` distinct as
+the manual product-review path.
+
 If everything is green, the next action is usually: review the diff, then run
 `/try` if you want a manual walkthrough, then `/complete`.
 

package/template/.claude/skills/ci/SKILL.md

@@ -113,6 +113,12 @@ Run the exact documented `Verify` command locally. The individual build, test,
 or typecheck commands may still be run separately for diagnosis, but the final
 proof must use Verify because that is what GitHub will run.
 
+A passing local run proves the recipe against the current working copy. It does
+not prove dependency installation or command behavior from a fresh checkout.
+Until the workflow is pushed and reports green on GitHub, describe the setup as
+prepared locally, not CI verified. The first successful GitHub run is the
+authoritative clean-checkout proof.
+
 If Verify fails, report the failing subcommand and stop. Do not weaken the
 command, remove a legitimate check, or describe CI as ready.
 
@@ -128,7 +134,8 @@ Finish with a concise setup report:
 - checks included and checks omitted
 - test gate status
 - workflow path and triggers
-- local Verify result
+- local Verify result and whether CI is only prepared locally or confirmed by a
+  successful GitHub run
 - files changed
 - any overlap, uncertainty, or follow-up
 

package/template/.claude/skills/complete/SKILL.md

@@ -54,6 +54,31 @@ Use `qualityGates.regular` for this work item:
 - **Check:** `manual` runs only when explicitly requested; `when-behavioral` runs when done-whens need observed runtime behavior; `always` runs for every work item.
 - **Try guide:** `manual` runs only when explicitly requested; `when-user-facing` generates guide when change affects UI/UX; `always` generates one for every work item.
 
+### Independent review execution
+
+After final Verify and required Check pass, set the active spec to `verified`.
+If a selected or previously initiated independent review does not already have a
+current passing receipt:
+
+1. Use an existing current pending request and its immutable target when one is
+   present. Otherwise show the exact product, test, and verified-spec candidate
+   for the immutable review checkpoint. Obtain explicit commit approval under
+   the normal Git rules, then create or use that clean checkpoint. Configuration,
+   including `review.independentExecution: "automatic"`, never grants permission
+   to commit. A pending request without `Requested execution` is legacy and
+   manual-only; never add execution fields or run a subagent against it.
+2. Prepare Phase A of `/audit independent current` when no current request
+   exists. Record `Requested execution` from `review.independentExecution`.
+3. For requested `automatic`, start the generic isolated current-runtime child
+   from the installed project-local Audit skill, wait, and validate the normal
+   receipt. Freeze parent product, test, spec, and config changes while it runs.
+4. For requested `manual`, or when automatic isolation, identity, model, or
+   completion is unavailable, preserve the pending request, set activity to
+   `ready`, and stop with the manual fresh-session handoff.
+5. Continue Complete only with a current passing receipt whose requested and
+   actual execution fields match the allowed review contract. Never self-review
+   or silently skip the gate.
+
 ## Step 0 - final safety pass
 
 Before logging or committing, run a short safety pass and report blockers only:
@@ -82,13 +107,13 @@ Check whether the spec is a feature, fix, or rollback. A fix is marked
 `Type: Fix` and has no build-plan number. A rollback is marked `Type: Rollback`
 and records the exact target feature, archive, commit, and parent.
 
-- **Feature** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/features/{xxx-slug}.md`, check it off in `devflow/build-plan.md` (and its parent item once all sub-items are checked), and record an entry into `devflow/history/HISTORY.md`.
+- **Feature** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/features/{xxx-slug}.md`, check it off in `devflow/build-plan.md` (and its parent item once all sub-items are checked), recompute the overview fingerprint using `/overview`'s checkbox-normalized hash contract and update `devflow:source-hash` in `devflow/context/project-overview.md`, and record an entry into `devflow/history/HISTORY.md`.
 - **Fix** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/fixes/{xxx-slug}.md`, and record an entry into `devflow/history/HISTORY.md`.
 - **Rollback** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/rollbacks/YYYY-MM-DD-{xxx-slug}.md`, preserving the original completed feature archive. Uncheck the target item in `devflow/build-plan.md` and record in `devflow/history/HISTORY.md`.
 
 **Archive resolved findings & review receipts.**
 - If `devflow/context/{xxx-slug}/findings.md` holds findings, append `## Findings` to the archive file with resolved entries.
-- If `devflow/context/{xxx-slug}/review.md` holds a completed passing receipt, append `## Independent Review` to the archive file with the receipt summary.
+- If `devflow/context/{xxx-slug}/review.md` holds a completed passing receipt, append a `## Independent review` section to the archive file with the receipt fields, commands, safe evidence references, findings, and remaining risk from `review.md`. Preserve the full target and base SHAs, spec hash, base ref, builder adapter and model, requested reviewer, model, and execution, actual reviewer adapter, model, and execution, Check result, fresh-context declaration, and review time. Do not archive a stale, pending, changes-requested, or malformed record.
 
 **Clean up run workspace.** Delete the task directory `devflow/context/{xxx-slug}/`. In Pure Multi-Run architecture, completed work leaves zero residual stubs in `devflow/context/`.
 

package/template/.claude/skills/continuous/SKILL.md

@@ -24,6 +24,7 @@ Where this sits in the workflow:
 ### ขอบเขตสิทธิ์ที่ได้รับอนุญาตเฉพาะในเครื่อง Local:
 - สร้างและสลับ Feature Branch ในเครื่อง Local
 - บันทึก Checkpoint Commits ย่อยบน Branch
+- สร้าง required immutable independent-review checkpoints
 - บันทึก Feature Commit สุดท้าย
 - Squash-merge ฟีเจอร์ที่เสร็จสมบูรณ์ลง Default Branch ของ Local
 - ลบ Feature Branch เฉพาะใน Local หลังรวมโค้ดสำเร็จ
@@ -93,10 +94,14 @@ Where this sits in the workflow:
 - **Try Guide**: `manual` (ข้ามอัตโนมัติ), `when-user-facing` (สร้าง Try Guide เมื่อเป็น UI/CLI), `always` (สร้างทุกฟีเจอร์)
 
 ทุก product/spec edit ทำให้ receipt เดิมหมดอายุ เมื่อ Independent Review gate
-ทำงาน ให้รัน Verify และซ่อม audit findings ให้เสร็จก่อนส่ง
-`audit independent current` ไปยัง fresh reviewer context หากไม่สามารถรับ
-receipt ที่ verdict เป็น `passed` และ freshness เป็น `current` ให้หยุด Continuous
-Mode โดยคง workspace/branch ไว้ ห้ามข้ามไป archive หรือ local squash-merge
+ทำงาน ให้รัน Verify และสร้าง immutable checkpoint (ได้รับอนุญาตภายใต้ Continuous Mode authority แม้ checkpointCommits จะ disabled) จากนั้นปฏิบัติตาม `/audit independent current`
+หาก `review.independentExecution` เป็น `automatic` ให้ spawn และรอ isolated reviewer child พร้อมตรวจสอบ receipt ให้ผ่านก่อนดำเนินการต่อ
+หากเป็น `manual` หรือ runtime ไม่สามารถพิสูจน์ isolation, identity, model ได้ ให้ตั้งสถานะเป็น `ready` และหยุดด้วย manual handoff
+Continuous Mode จะไม่ทำการ audit งานของตัวเองโดยเด็ดขาด
+
+คำขอจะบันทึก `Requested execution` และ receipt จะบันทึก `Actual execution`
+การจับคู่ของ execution และ reviewer context จะต้องถูกต้องตามสัญญา review
+หากเป็น legacy request ที่ไม่มี `Requested execution` ให้ถือว่าเป็น legacy manual-only ห้ามเติมฟิลด์หรือรัน subagent กับมัน
 
 สำหรับฟีเจอร์ browser-facing ให้รัน `npm run test:browser` เมื่อมี
 `test:browser` script และเก็บ interactive evidence ผ่าน `browseros-neo` เมื่อ

package/template/.claude/skills/doctor/SKILL.md

@@ -58,10 +58,14 @@ Gather these, then summarize. Do not dump file contents.
    - Read `devflow/config.json` when present. Missing is healthy and means
      built-in defaults. When present, require a regular non-symbolic-link JSON
      file with `schemaVersion: 1`. Reject unknown keys and unsupported values.
-     Report the effective workflow, git, verification, regular quality-gate,
-     Continuous quality-gate, and Continuous Mode settings. Confirm each audit,
-     independent-review, check, and try-guide gate uses its supported values and
-     defaults to `manual`.
+     Report the effective workflow, git, verification, review execution, regular
+     quality-gate, Continuous quality-gate, and Continuous Mode settings. Confirm each audit,
+     independent-review, check, and try-guide gate uses its supported values.
+     Independent review defaults to `when-sensitive` for both workflows; audit,
+     check, and try guide default to `manual`. Confirm
+     `review.independentExecution` is `manual` or `automatic` and defaults to
+     `automatic`. Do not claim automatic capability is available from installed
+     project files alone.
      An invalid config is a setup blocker for mutating workflow skills because
      they must not guess which policy to follow.
 2. **Tool adapters**

package/template/.claude/skills/feature/SKILL.md

@@ -127,7 +127,15 @@ build plan starts high-level.
 ## Step 3 - write the spec
 
 For the one (sub-)feature being built now, allocate sequential ID (`xxx-slug`) and create a dedicated workspace at `devflow/context/{xxx-slug}/`. Write the full living spec to
-`devflow/context/{xxx-slug}/spec.md`, following `reference/feature-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. Fill every section:
+`devflow/context/{xxx-slug}/spec.md`, following `reference/feature-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. The first heading and build-plan identity must use this canonical form:
+
+```markdown
+# Feature: <title>
+
+**From build-plan:** feature <id>
+```
+
+Fill every section:
 - Goal, Problem Statement, and In/Out of scope
 - Acceptance Criteria (AC-1, AC-2, ...)
 - Small build steps as atomic 2-5 min checklist items (`- [ ]`, supporting `[TDD-Red]`, `[TDD-Green]`, `[TDD-Refactor]` triplets for functional logic)

package/template/.claude/skills/fix/SKILL.md

@@ -32,7 +32,8 @@ or with a description, for example `/fix F-03`.
 
 Pull context from `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`,
 calculate the next sequential running ID (e.g. `059-fix-slug`),
-then write a short spec to `devflow/context/{xxx-slug}/spec.md`. Also initialize `stage.md` and `findings.md` in that folder. Keep it lighter than a feature spec:
+then write a short spec to `devflow/context/{xxx-slug}/spec.md`. Also initialize `stage.md` and `findings.md` in that folder. Its first heading must be exactly
+`# Fix: <title>`, and it must retain the `**Type:** Fix` contract below. Keep it lighter than a feature spec:
 
 - **Title** - the bug or change in a few words.
 - **Type:** Fix  (so `/complete` logs it to `devflow/history/fixes/`, not `devflow/history/features/`).

package/template/.claude/skills/implement/SKILL.md

@@ -153,6 +153,29 @@ Never batch the whole thing into one diff. If a step's diff is too big to read,
 split it. The documented `Verify` command, or the fallback build and tests, must
 pass before any commit.
 
+After final Verify and required Check pass, set the active spec to `verified`
+with every completed box checked. Then resolve independent review before the
+final packet:
+
+1. If `qualityGates.regular.independentReview` does not select review and no
+   request already exists, proceed directly to the final review packet.
+2. Otherwise show the exact product, test, and verified-spec candidate for the
+   immutable review checkpoint. Obtain explicit commit approval when the exact
+   checkpoint does not already exist, then create or use it. Configuration,
+   including `review.independentExecution: "automatic"`, never grants commit
+   permission, even when normal checkpoint commits are disabled.
+3. Follow `/audit independent current` to prepare or reuse the request and record
+   `Requested execution`. For requested `automatic`, start and wait for the
+   generic isolated current-runtime child instructed from the project-local
+   Audit skill, then validate the receipt. For requested `manual`, or when
+   automatic capability is unavailable, preserve the request and stop with the
+   manual fresh-session handoff. Treat an existing request without `Requested
+   execution` as legacy manual-only: never add execution fields or run a
+   subagent against it.
+4. Continue to the final packet only with a current passing receipt whose
+   requested execution, actual execution, and reviewer context form an allowed
+   pairing. Never self-review or silently skip a selected gate.
+
 ## Step 3 - hand off to /complete
 
 Before handing off, check `devflow/context/{xxx-slug}/findings.md`. A P0 or P1 finding
@@ -182,9 +205,30 @@ When every step is built and `Verify`, or the fallback build and tests, passes
 - known risks, skipped checks, or follow-up notes
 - next action, usually `/complete`
 
-Then tell the user `/complete` makes the one work-level commit, logs it (archive,
-update the build plan for a feature or rollback, reset), and merges with
-approval. This skill does not touch main.
+After the final packet, always offer these choices:
+
+1. Walk me through the implementation.
+2. Request changes.
+3. Continue to the exact next workflow command.
+
+The final walkthrough is available with either `workflow.stepReview` value and
+regardless of `workflow.checkpointCommits`. It is a read-only code tour, not the
+manual product-review path produced by `/try`, and it is not verification.
+
+When the user chooses the walkthrough, begin with a short map of the completed
+feature, then follow the spec's build steps. For each step, explain its purpose,
+key files and symbols, important data or control flow, and non-obvious decisions.
+Use file and line links when the client supports them. Do not narrate every line
+or reload broad project context. End by offering a focused deep dive into one
+named area. If the feature spans too many distinct areas for one useful pass,
+name the sections first and let the user choose where to begin. Remain read-only
+unless the user separately requests changes.
+
+Never create an ordinary step, product, or work-level commit from this skill.
+The sole exception is exactly one immutable independent-review checkpoint after
+showing its exact candidate and receiving current explicit commit approval.
+Configuration never supplies that approval. Never merge, push, deploy, publish,
+or start unrelated work from this skill.
 
 ## Rules