Illustrative workflow. Actual results depend on your inputs, configured tools, provider and review.
The goal
Investigate a small product change, propose an implementation, and review the result.
Who does what
- Planner: clarify the behavior, acceptance criteria and affected parts.
- Builder: work in the configured execution environment with only approved tools.
- Reviewer: check the change against the goal and report test evidence and remaining risks.
A useful owner checkpoint
“Should this change preserve the existing behavior or introduce the proposed new flow?”
The team can save this as a question and wait. Your answer becomes guidance for the continuation; it does not grant new account or server access.
The result to review
A proposed change or plan, relevant verification evidence and a short review of unresolved decisions.
What stays under your control
A model’s completion message is not proof that a deployment or test succeeded. Inspect tool results and artifacts. Production SSH work needs an approved server, directory, capability and exact procedure; not an unrestricted shell.
What can carry forward
Approve a narrow, demonstrated procedure such as “review a small UI change” rather than a skill that claims to ship anything without review.
Development-review starter · Current capabilities and limits