idea

/idea — Clarify Before Planning

Step 0: Escape Hatch

If the user says 别走流程, 直接做, 简单点, or 不走地图, do not run /idea. Acknowledge once and do the smallest direct action.

Exception: do not bypass safety gates for destructive, secret, public-upload, deploy, database, force-push, or irreversible work.

Step 0.5: Project Goal Check

If PROJECT_GOAL.md exists in the current project root, read it before shaping the idea. If the request conflicts with current_phase, exit_criteria, or out_of_scope, stop and ask whether to update the goal or narrow the request. Do not edit PROJECT_GOAL.md automatically.

Contract

Create a one-page idea brief. Do not write an execution plan, do not edit code, and do not automatically continue to /plan.

Process

1. Clarify the idea into:
   • Problem
   • User / Job
   • Success signal
   • Not Doing
   • Open Questions
   • Next: /plan or stop
2. Save only if the user asks for a written brief. Use ${BDC_HOME:-$HOME/.bdc}/ideas/ for shared ideas or project docs/ideas/ when the project already has that convention.

Output

Keep the response short. The default output is the brief in chat, not a file.

Verification

• The output includes Problem, User / Job, Success signal, Not Doing, Open Questions, and Next.
• The output does not include implementation steps unless the user explicitly asks to continue to /plan.

Red Flags

• The brief silently chooses scope for the owner.
• The response creates a plan or edits files without being asked.
• PROJECT_GOAL.md exists and was ignored.

Common Rationalizations

Rationalization	Response
"The idea is clear enough; go straight to plan."	Do not skip clarification when the user invoked /idea. Incident: standards/skill-frontmatter.md cites trigger misuse as a known skill failure mode; /idea exists to avoid scope assumptions before /plan.
"I should write PROJECT_GOAL.md for the owner."	Do not edit it automatically. This is advisory from core/templates/PROJECT_GOAL.md: owner goals are owner-controlled.