/goal should define how goal mode interacts with inherited approval policies

Summary

The main issue is that /goal did not make its execution semantics explicit with respect to standing repo/AGENTS approval policy.

Thread id: b0a36c35-4e7e-4141-8392-266e6d305d52

What happened

My standing repo/AGENTS workflow policy distinguishes commit-ready from commit-approved and normally requires explicit approval before staging/committing a unit.

In the original task, I asked the agent to create a goal for itself to complete the docs/plans all the way through. In ordinary language, that is already a goal-scoped execution directive: continue implementing the provided plans until the final work unit is complete, making closed units durable as needed, unless something materially unsafe or out of scope appears.

However, even after /goal was active, the agent still treated the inherited repo-local “explicit commit approval required” policy as a separate hard gate requiring another user message. So the goal runner kept telling the agent to continue toward completion, while the agent kept preserving a standing approval gate that required absent user input.

That created an ambiguous middle state: /goal kept running, but the agent would not take the normal durable action required to progress the goal. The result was repeated blocked-state messages and token usage without progress.

Expected behavior

/goal should define how goal mode interacts with inherited repo/AGENTS approval policies. It should not leave the agent to infer whether ordinary repo-local approval gates still require a separate user message.

A goal should establish one of these modes explicitly:

1. Goal grants scoped autonomy: continue through routine repo-local approval gates needed to complete the goal, as long as checks/reviews pass and no forbidden/destructive action is involved; or
2. Goal preserves approval gates: treat any repo-local “requires user input/approval” gate as an automatic pause/completion condition for the goal, report once, and stop.

Either default would be better than the current implicit conflict.

Why this matters

The conflict was not an obvious user-authored contradiction in the immediate goal prompt. The approval behavior came from standing repo/AGENTS workflow policy. When /goal is activated, the feature should make its policy precedence clear to the agent and user.

If /goal preserves approval gates, then “blocked awaiting user approval” should become a goal pause condition automatically. If /goal overrides routine approval gates, that should also be explicit.

The key request is not simply “users should avoid conflicting instructions.” The /goal feature should define how goal mode interacts with standing repo/AGENTS approval policy, especially when the user’s goal prompt already asks for autonomous completion of the plan/work through durable closure.