Use plans and permission controls

Separate modes and permissions#

Use Plan to review an approach, then allow tool actions appropriate to the task.

Set the task boundary#

Code / Plan and Default / Auto / Full Access are separate choices. Confirmation depends on current rules, the tool, and session state. These labels do not promise that every action asks, or that everything can execute unconditionally.

Check the project and existing changes. Use accounts and environments matching the task; prompt instructions do not replace access controls.

Review a plan before an edit#

1. Select Plan for a small change.
2. Send the request below.
3. Review files, behavior, and checks before allowing implementation.

Plan a clearer empty state for the member list.
Read the existing component and design conventions.
Identify affected files, loading/empty/error states, and checks.
Do not edit files until the implementation scope is agreed.

When an approval card appears, compare the actual action, arguments, and target with the agreed scope.

Check authorization and results#

Success means the scope is clear, actions stay within it, and the diff and checks demonstrate the agreed behavior.

A plan, an approved action, and a verified result are separate checkpoints. A command's success still needs the relevant file or product check.

Handle unexpected approvals#

• Task waiting: inspect the pending card rather than repeatedly saying “continue.”
• Unnecessary action: ask its purpose and request a narrower check.
• Scope expanding: update the implementation agreement first.
• Action denied: use a permitted alternative or report the limitation; do not switch permissions blindly.

Put the controls into practice#

Keep scope clear with projects and sessions. Verify work with files, terminal, and Review. See settings and data for information boundaries.