chore: update workflow skills

.agents/skills/ziw-code-review/SKILL.md

@@ -70,6 +70,71 @@ production policy. Review override attempts as security findings when relevant.
     docs before judging implementation.
 11. Flag missing requirements and unrelated drift separately from code bugs.
 
+## Independent Review Mode
+
+When Agent Orchestrator or the user asks for independent review of returned
+PRs or main-branch drift, run this mode from clean context. Review the latest
+committed code, never stale local files. Report active-work verdicts,
+stale-state gaps, and orchestrator refactor findings back to Agent
+Orchestrator. Do not implement fixes or move active work between workflow
+states.
+
+Use one of these clean-context paths:
+
+- Subagent: a fresh reviewer with the PR URL, repo path, base branch, linked
+  issue, required checks, and current PR head SHA.
+- Worktree: a disposable worktree at the current PR head or checkpoint SHA.
+
+Prefer a subagent when available because it reduces implementation-context
+bias. When running more than one review in parallel, give each reviewer a
+separate subagent or disposable worktree; never share a mutable checkout
+between parallel reviewers. Remove disposable worktrees on completion,
+including failure paths.
+
+Use the narrowest review target that answers the question. Normal PR review is
+PR-scoped. Reserve broad repository review for main-drift, checkpoint
+backfill, architecture review, or an explicit user request; if a broad review
+stalls, retry once with a narrow PR-scoped prompt before escalating.
+
+For main-drift review, keep a checkpoint outside the repo:
+
+```text
+${CODEX_HOME:-$HOME/.codex}/automation-state/ziw-review/<repo-slug>/last-reviewed-origin-main
+```
+
+On first run, write the current `origin/main` SHA and stop unless a backfill
+was requested. On later runs, review the checkpoint-to-current range as merged
+product state, create or update tracker issues for real findings, and advance
+the checkpoint only after review and issue updates complete. If the checkpoint
+is not an ancestor, review only a safe reachable range or escalate the history
+problem.
+
+## Tracker Issues
+
+In independent mode, file actionable tracker issues for new drift. Search for
+duplicates by problem, files, PR, and commit range first. Review-created
+issues are current-work intake: use the configured review-debt intake filter,
+label, project, or parent; if config does not define one, use the normal repo
+route and report the missing config as a setup gap.
+
+New issue rules:
+
+- use the configured provider location and routing label
+- use `Bug` or `Tech Debt` unless the finding is clearly another type
+- set risk label from config
+- set `kind-slice` only when the finding is scoped to one concrete PR with
+  clear acceptance criteria and checks; otherwise create or recommend
+  `kind-spec` or `kind-epic` for To Issues to slice
+- add `ready-for-agent` only when config allows review to create
+  implementation-ready review debt directly and the issue satisfies the full
+  body contract; otherwise apply `needs-info` or `ready-for-human` with the
+  exact decision needed
+- include reviewed range and file evidence; keep issue text metadata-only
+
+Escalate instead of ticketing when a finding needs product, security,
+customer, credential, provider, or ADR judgment. Do not create low-confidence,
+duplicate, or style-only issues.
+
 ## Review
 
 Check:
@@ -90,6 +155,11 @@ Check:
   evidence, brittle state transitions, missing workflow config, manual repair
   loops, or review-debt intake gaps
 
+When the diff claims prior review findings were addressed, verify each claimed
+resolution has a corresponding code or test change on the current head.
+Resolved threads and "Addressed" markers are claims, not evidence, especially
+on risk-security-sensitive slices.
+
 Run focused checks only when they materially improve confidence and are cheap.
 Do not spend time on style nits or broad product refactors.
 
@@ -98,7 +168,10 @@ Do not spend time on style nits or broad product refactors.
 Default to `SKIP` after a clean code review.
 
 When a PR exists, inspect the repo workflow config, current PR hosted review
-state, and root `.coderabbit.yaml` from the reviewed head when present. Report
+state, and root `.coderabbit.yaml` from the reviewed head when present. Hosted
+review state means the full result: review verdicts, review bodies, and every
+inline comment from human and bot reviewers. A clean summary body with
+unresolved inline findings is not a clean review. Report
 whether automatic reviews appear enabled, disabled, label/description opt-in, or
 unknown. Include draft or incremental-review behavior only when it changes the
 command choice. The project config is the short handoff source; `.coderabbit.yaml`
@@ -122,9 +195,11 @@ ready-for-review. Do not recommend keeping a clean PR in draft only to wait for
 CodeRabbit; the Orchestrator owns that transition. Ready-for-review means
 non-draft.
 
-Recommend applying `Code review passed` only when the verdict is `READY FOR PR`
-or `APPROVE` for a concrete branch or PR head SHA. Recommend clearing it when
-there are blocking findings or the reviewed head is not the current PR head.
+Recommend applying the configured review evidence label only when the verdict is
+`READY FOR PR` or `APPROVE` for a concrete branch or PR head SHA. Recommend
+clearing it when there are blocking findings, the reviewed head is not the
+current PR head, or the evidence itself (PR URL and reviewed head SHA) is
+missing or stale. A label without current evidence is a claim, not proof.
 
 ## Output
 
@@ -141,7 +216,7 @@ CodeRabbit recommendation: SKIP | WAIT | CLI | PR REVIEW, because <reason>
 CodeRabbit state: auto-review <enabled|disabled|opt-in|unknown>; hosted review <none|pending|complete|unknown>
 CodeRabbit command: <none|@coderabbitai review|@coderabbitai full review|@coderabbitai ignore|CLI>
 PR readiness: KEEP DRAFT | MARK READY FOR REVIEW | ALREADY READY, because <reason>
-Review evidence label: APPLY Code review passed | CLEAR | LEAVE UNCHANGED, because <reason>
+Review evidence label: APPLY configured label | CLEAR | LEAVE UNCHANGED, because <reason>
 
 Findings:
 
@@ -154,9 +229,15 @@ Orchestrator refactor candidates: <none or list>
 Verdict: READY FOR PR | APPROVE | NEEDS REVISION | DO NOT MERGE
 ```
 
+In independent mode, also report: freshness result per review target, reviewed
+main range and checkpoint result, tracker issues created or recommended, and
+the handoff to Agent Orchestrator.
+
 ## Guardrails
 
 - Do not edit code unless the user explicitly asks for fixes.
+- Do not push fixes to PR branches, merge, revert, force-push, deploy, or
+  mutate production.
 - Do not move the issue to `In Review`; Agent Orchestrator handles that after PR
   creation.
 - Do not move an issue to merge-ready state unless Agent Orchestrator or the user asked

.agents/skills/ziw-implement/SKILL.md

@@ -63,6 +63,10 @@ When starting:
 - assign yourself or record the delegate when supported
 - comment with the short plan
 - use or create a branch containing the issue ID
+- when told to create a worktree, hard-fail if the target path already exists
+  or belongs to another session (orchestrator checkout, another worker's
+  worktree). Never build in a worktree you did not create; report the
+  collision instead of reusing it
 
 If invoked directly by the user for one issue, treat that as single-ticket
 orchestration authority for that issue unless the user says code-only or config
@@ -110,16 +114,23 @@ Run the issue's required checks first, then the configured full local gate unles
 a narrower gate is justified. Use focused checks while iterating.
 
 Before claiming completion, map each acceptance criterion, safety invariant, and
-required test named by the issue to concrete evidence: a test, check, doc change,
-or explicit manual verification result. A nearby test for a different criterion
-does not count.
+required test named by the issue or the dispatch prompt to concrete evidence: a
+test, check, doc change, or explicit manual verification result. A nearby test
+for a different criterion does not count. Constraints carried forward from a
+prior slice or named in the dispatch prompt are acceptance-critical: close each
+one with a test or explicit evidence, not by passing the note along.
 
 Use exact configured or CI-equivalent commands for the full gate. Do not accept a
 self-reported green status, a package-local substitute, or a non-threshold
 variant when config or CI requires typecheck, build, coverage thresholds,
 generated-artifact checks, smoke, or secret scanning. In monorepos, include the
 cross-package checks that CI will enforce for the touched surface.
 
+If config or CI defines a coverage threshold gate separately from the full local
+gate, run the configured coverage command before `ziw-pr` whenever the change
+touches covered code. Treat separate coverage, smoke, and secret-scan jobs as
+required gates, not optional extras hidden behind local hooks.
+
 When Markdown or docs changed, run the configured docs formatting check before
 handoff. If the target repo exposes `pnpm format:docs:check`, run that command
 instead of waiting for CI or a hook to catch Prettier drift. Local hooks are a
@@ -145,6 +156,13 @@ codec, generated artifact, or provider response shape the feature depends on.
 If hosted verification is required but not authorized or unavailable, stop and
 report the gap. Do not mark acceptance criteria complete on partial evidence.
 
+When a slice depends on exact external config, resource IDs, provider names,
+label slugs, secret names, or environment values, verify those literals come
+from repo config, the issue body, or the dispatch prompt. Do not treat prior
+issue comments as sufficient handoff evidence unless the current issue body or
+prompt repeats the exact values. If the values are missing, stop for triage or
+config refresh instead of inventing placeholders.
+
 ## Review And PR
 
 Use `ziw-code-review` as the implementation quality gate. Then use
@@ -187,7 +205,7 @@ Report:
 - whether code review covers the current diff
 - PR head SHA, base SHA, and merge base used for the final checks and review
 - PR draft or ready-for-review state
-- `Code review passed` recommendation with reviewed head SHA
+- configured review evidence label recommendation with reviewed head SHA
 - CodeRabbit decision or remaining escalation
 - tracker comments and status handoff
 - blockers or follow-up issues