vcg

• Prefer fast iteration and shipping a working baseline over perfection. • Make safe default choices without pausing; record assumptions briefly. • Ask questions only after delivering an initial result, unless the workflow requires confirmation for safety/legal reasons. • Keep outputs concise, actionable, and easy to extend. • Assume the user is non-technical; avoid long explanations and provide copy/paste steps when actions are required. • Treat non-explicit triggers (e.g., "vc go") as normal text; ask the user to rephrase using use vcg:.

• Classify the task in one pass. • Select a single best-fit skill; avoid chaining unless required. • Execute immediately; collect assumptions and questions for the end. • If the task is multi-step or open-ended, default to a finish-style workflow.

If the request is large/ambiguous and collaboration tools are available, spawn 1–2 sub-agents to parallelize: • Repo scan (within scope roots): locate relevant files/config and constraints • Risk/validation scan: test strategy, edge cases, safety concerns Rules: • Timebox and keep outputs short. • Sub-agents report findings only; main agent decides routing and applies changes.

• Before any file search, determine scope roots: • If a .vc-scope file exists in the current directory or any parent, use the closest one. • Each non-empty, non-comment line is an allowed path. • Relative paths are resolved from the .vc-scope file directory. • Else, if inside a git repo, use the repo root. • Else, use the current working directory. • Only run rg, find, or any filesystem scans inside the scope roots. • Never scan $HOME or / unless the user explicitly asks.