fix: scope routing and support report-only plan audits

SKILL.md

@@ -171,10 +171,10 @@ If `PROACTIVE` is `false`: do NOT proactively invoke or suggest other gstack ski
 this session. Only run skills the user explicitly invokes. This preference persists across
 sessions via `gstack-config`.
 
-If `PROACTIVE` is `true` (default): **invoke the Skill tool** when the user's request
-matches a skill's purpose. Do NOT answer directly when a skill exists for the task.
-Use the Skill tool to invoke it. The skill has specialized workflows, checklists, and
-quality gates that produce better results than answering inline.
+If `PROACTIVE` is `true` (default), invoke a skill when its purpose matches the
+requested outcome and its workflow adds useful guidance. A matching keyword alone
+is not enough: a small edit or a question about a tool does not require a full
+review, redesign, or release workflow. Honor an explicitly chosen skill.
 
 **Routing rules — when you see these patterns, INVOKE the skill via the Skill tool:**
 - User describes a new idea, asks "is this worth building", brainstorms, pitches a concept → invoke `/office-hours`
@@ -213,11 +213,9 @@ quality gates that produce better results than answering inline.
 - User asks to tune question sensitivity, "stop asking me that" → invoke `/plan-tune`
 - User asks for code quality dashboard, "health check" → invoke `/health`
 
-**When in doubt, invoke the skill.** A false positive (invoking a skill that wasn't
-needed) is cheaper than a false negative (answering ad-hoc when a structured workflow
-exists). The skill provides multi-step workflows, checklists, and quality gates that
-always produce better results than an ad-hoc answer. If no skill matches, answer
-directly as usual.
+When the match is unclear, use the request and available context to decide whether
+the specialized workflow helps. Answer directly when it does not; do not treat
+extra skill loading as inherently safer or better.
 
 If the user opts out of suggestions, run `gstack-config set proactive false`.
 If they opt back in, run `gstack-config set proactive true`.

SKILL.md.tmpl

@@ -39,10 +39,10 @@ If `PROACTIVE` is `false`: do NOT proactively invoke or suggest other gstack ski
 this session. Only run skills the user explicitly invokes. This preference persists across
 sessions via `gstack-config`.
 
-If `PROACTIVE` is `true` (default): **invoke the Skill tool** when the user's request
-matches a skill's purpose. Do NOT answer directly when a skill exists for the task.
-Use the Skill tool to invoke it. The skill has specialized workflows, checklists, and
-quality gates that produce better results than answering inline.
+If `PROACTIVE` is `true` (default), invoke a skill when its purpose matches the
+requested outcome and its workflow adds useful guidance. A matching keyword alone
+is not enough: a small edit or a question about a tool does not require a full
+review, redesign, or release workflow. Honor an explicitly chosen skill.
 
 **Routing rules — when you see these patterns, INVOKE the skill via the Skill tool:**
 - User describes a new idea, asks "is this worth building", brainstorms, pitches a concept → invoke `/office-hours`
@@ -81,11 +81,9 @@ quality gates that produce better results than answering inline.
 - User asks to tune question sensitivity, "stop asking me that" → invoke `/plan-tune`
 - User asks for code quality dashboard, "health check" → invoke `/health`
 
-**When in doubt, invoke the skill.** A false positive (invoking a skill that wasn't
-needed) is cheaper than a false negative (answering ad-hoc when a structured workflow
-exists). The skill provides multi-step workflows, checklists, and quality gates that
-always produce better results than an ad-hoc answer. If no skill matches, answer
-directly as usual.
+When the match is unclear, use the request and available context to decide whether
+the specialized workflow helps. Answer directly when it does not; do not treat
+extra skill loading as inherently safer or better.
 
 If the user opts out of suggestions, run `gstack-config set proactive false`.
 If they opt back in, run `gstack-config set proactive true`.

plan-ceo-review/SKILL.md

@@ -494,6 +494,28 @@ branch name wherever the instructions say "the base branch" or `<default>`.
 
 # Mega Plan Review Mode
 
+## Explicit report-only requests
+
+If the user explicitly requests a read-only audit, a report without questions, or
+an autonomous review of an existing plan, use this report-only path. Otherwise,
+keep the interactive workflow below, including its decision gates. This path does
+not change `/autoplan` orchestration or grant permission to implement a plan.
+
+Read the supplied plan and relevant repository evidence. Review the requested
+scope, loading `sections/review-sections.md` for the applicable review dimensions.
+In report-only mode, the later STOP/AskUserQuestion gates, mode-selection interview,
+plan-writing steps, TODO creation, and next-skill offers do not run: they belong to
+the interactive decision workflow. Treat their review criteria as analysis guidance.
+Do not edit the plan, adopt a proposed approach, add scope, or start implementation.
+
+State assumptions and uncertainty, finish all independent read-only investigation,
+and return prioritized findings with evidence, recommendations, and unresolved
+material decisions grouped at the end. Missing information only blocks conclusions
+that depend on it; explain those limits and complete the rest of the review.
+An unanswered decision is not approval. Finish after returning the report and the
+applicable completion/telemetry steps; do not fall through to the interactive flow.
+
+
 ## Philosophy
 You are not here to rubber-stamp this plan. You are here to make it extraordinary, catch every landmine before it explodes, and ensure that when this ships, it ships at the highest possible standard.
 But your posture depends on what the user needs:

plan-ceo-review/SKILL.md.tmpl

@@ -57,6 +57,28 @@ gbrain:
 
 # Mega Plan Review Mode
 
+## Explicit report-only requests
+
+If the user explicitly requests a read-only audit, a report without questions, or
+an autonomous review of an existing plan, use this report-only path. Otherwise,
+keep the interactive workflow below, including its decision gates. This path does
+not change `/autoplan` orchestration or grant permission to implement a plan.
+
+Read the supplied plan and relevant repository evidence. Review the requested
+scope, loading `sections/review-sections.md` for the applicable review dimensions.
+In report-only mode, the later STOP/AskUserQuestion gates, mode-selection interview,
+plan-writing steps, TODO creation, and next-skill offers do not run: they belong to
+the interactive decision workflow. Treat their review criteria as analysis guidance.
+Do not edit the plan, adopt a proposed approach, add scope, or start implementation.
+
+State assumptions and uncertainty, finish all independent read-only investigation,
+and return prioritized findings with evidence, recommendations, and unresolved
+material decisions grouped at the end. Missing information only blocks conclusions
+that depend on it; explain those limits and complete the rest of the review.
+An unanswered decision is not approval. Finish after returning the report and the
+applicable completion/telemetry steps; do not fall through to the interactive flow.
+
+
 ## Philosophy
 You are not here to rubber-stamp this plan. You are here to make it extraordinary, catch every landmine before it explodes, and ensure that when this ships, it ships at the highest possible standard.
 But your posture depends on what the user needs: