Use after verify passes for the future maintainer's audit — sit in the chair of the person who'll touch this code in 3-6 months and ask "what will bite us later?" at the decision level. Surfaces wrong abstractions, load-bearing-but-unobvious shapes, next-change traps, drift from surrounding code. Raises a Scope flag if the whole change looks like the wrong call. Delegates an independent, critical review and fills the task file's `## Conclusion`.
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Find choices that will make the next change difficult: wrong abstractions, implicit constraints, checks in the wrong layer, or drift from surrounding code. Question the scope when the completed work exposes a wrong premise, but leave redesign to the user and udesign.
In the full make workflow, run after verification passes and before merge or a pull request, regardless of task size. Save the outcome in ## Conclusion.
Read the brevity rules. Keep the outcome to one sentence plus the commit ID. Omit empty findings, deviations, risks, scope flags, and future work. Retain invariant evidence and assumption or unknown outcomes whenever the task defined them.
Keep ## Code smells separate from the conclusion. Delete it if empty. Promote a recorded smell to future work only when scheduling its fix, without duplicating the entry.
The reviewer is critical and reports concrete issues at confidence 80 or above, classified by severity. The dispatcher verifies each finding before accepting or rejecting it.
On Claude Code, dispatch up:reviewer. On Codex or Pi, use an independent child with the same review contract: check design constraints, plan alignment, bugs, future-maintenance risks, and questionable scope. Do not replace independent review with your own inspection.
Determine the task's branch point and current commit:
BASE_SHA=$(git merge-base HEAD main)
HEAD_SHA=$(git rev-parse HEAD)
Use the actual branch point if the task did not branch from main. Pass:
Task file: <absolute path>
BASE_SHA: <branch point>
HEAD_SHA: <current commit>
Working directory: <absolute worktree path>
The reviewer's evidence is the task contract and diff. Do not pass session history or the controller's rationale. On Codex or Pi, include the review contract above in the prompt.
Classify findings as critical, important, or a problem with the plan. For each:
Do not blindly accept findings, batch unrelated fixes, or respond to part of a linked finding before understanding the rest. Reject suggestions that break intended behavior, contradict the design, or add unused complexity.
Give one line per finding: the issue, your decision, and the exact change if fixing it. During authorized implementation, announce and apply verified in-scope fixes without another approval pause. Review-only requests remain read-only.
Example: "The parser accepts an empty identifier. Confirmed. Add rejection at the parser boundary and a regression test."
Hands-off decision logging is defined below.
Fix critical and important issues in logical commits. Run uexecute's consistency pass for each changed rule or pattern so sibling paths do not remain inconsistent. If fixes are substantial, dispatch the reviewer again on the new diff.
## Conclusion
Outcome: <goal achieved or remaining validation, plus commit ID>
Invariants:
- IV1 — <verification evidence>
### Assumptions check
- AS1 — held | violated | unverifiable — <evidence or reason>
### Unknowns outcome
- UK1 — resolved | still-open — <answer or blocker>
Plan adherence: <deviations>
Review findings:
- Critical: <resolution>
- Important: <resolution or justified deferral>
Scope flag:
- <reviewer's flag, preserved for the user>
Future work:
- <item and design-scope justification or newly discovered fact>
Verified by: <material manual checks, deferred smokes, or other non-routine evidence>
Omit sections with no content. Do not omit violated assumptions or unresolved unknowns. A violated assumption needs evidence and, if it invalidates the outcome, a revised phase or a user decision. Preserve a scope flag for the user instead of silently redesigning the task.
Read handsoff. Apply only verified, high-confidence fixes within the authorized implementation scope. Log each fix under ### Hands-off decisions as ureview: fixed <finding> — <change>.
Record low-confidence or ambiguous findings under ### Deferred (needs user input) instead of guessing. All fixes retain the contract's safety rules.
Save the conclusion after critical and important findings are resolved or explicitly deferred with justification. Set status to validating and return to make for goal validation. Review does not mark done or choose a finish action.
Do not merge with open critical or important findings, accept a merge-ready verdict without evidence, or skip the independent reviewer or conclusion.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Run a bounded implement-attack-repair loop for a user-specified task. Use when work needs repeated independent criticism: perform the task, dispatch a fresh attacker, verify significant findings, repair them, and stop on a clean attack or the user's round limit.
中文简介正在准备中。当前显示原文说明。
Explain a file, error, design, diff, or concept like a helpful engineering colleague: grounded in evidence, concise, and with useful follow-up threads. Use when the user asks for a clear explanation of the current work or codebase.
中文简介正在准备中。当前显示原文说明。
Turn one user criticism into a principle-level fix: find the violated principle, every similar occurrence, and fix the shared cause. Use only when the user explicitly invokes expand, $expand, /up:expand, or /skill:expand.
中文简介正在准备中。当前显示原文说明。
Use when a task needs an isolated checkout. Verify the worktree location, keep mutable environments and build outputs local, and run only authorized setup and checks.
中文简介正在准备中。当前显示原文说明。
Contract for hands-off mode — the ultrapack workflow variant that minimizes user prompts after Design, takes the safest reversible path, and logs every auto-choice for one end-of-task review. Referenced by the workflow entry point and child skills (udesign, uplan, uexecute, uverify, ureview). Read when the task file's **Mode:** header is `hands-off`.
中文简介正在准备中。当前显示原文说明。
Use when the user explicitly asks to launch and supervise a job. Require an authorized launch, monitoring, recovery, and teardown contract. Detect failures without inventing permission to restart or spend money.
中文简介正在准备中。当前显示原文说明。