ITSOL Self Review

Resolve and validate artifact authorization through itsol-workflow-mode. Preserve all seven workflow-state fields in review handoffs.

Run a concise final self-review before saying work is complete. Use isolated Rubber Duck review for Business and Technical Plans only when required by policy or when the main agent judges it proportionate to scale, uncertainty, novelty, and material risk.

Process

1. Re-read the artifact under review: plan file, diff, PR, patch, migration, deployment config, or generated artifact.
2. If .itsol.md exists, load itsol-repo-memory and check whether the artifact respects matched project policy.
3. For plans, act as a pragmatic teammate: challenge only omissions that could materially change scope, acceptance, correctness, safety, feasibility, rollout, or verification. Do not demand exhaustive detail for a small conventional task.
4. In governed, treat Approved without evidence that the user saw and explicitly approved that specific plan as a blocker. In autonomous-planned, accept a material-blocker-free Ready for execution artifact with delegated authorization and reject any false user-approval claim. In direct, accept not-required without plan paths and review the implementation evidence instead.
5. For Technical Plans with Execution Mode: Subagent-driven, verify the Subagent Plan reinforces itsol-subagent-workflow as the canonical contract and names task packets, write scope, concurrency, review split, response evidence, partial/blocked handling, unverified items, coverage gaps, and conflict handling.
6. For code changes, check requirements, edge cases, permissions, validation, data consistency, errors, logs, rollout risk, and invalid scope expansion beyond approved plans or task packet write scope.
7. Confirm RED/GREEN evidence for code changes, or explain why a TDD test was not practical and what replaced it. If .itsol.md says TDD is limited or not supported, verify the required replacement checks were performed.
8. For subagent-driven work, validate task results against the canonical response contract before handoff: status, changed files or inspected scope, evidence, assumptions, unverified items, coverage gap notes, risks, blockers, and next review target when files changed.
9. Load focused domain review skills only when the touched risk justifies their cost; do not fan out by default.
10. Report blockers, important gaps, optional suggestions, verification commands, partial, blocked, or failed items, meaningful unverified items, coverage gaps, and remaining risks. A blocker requires concrete impact and a plausible failure path introduced by the task.