quick-do

Quick Do: understand → do → verify

Choose the workflow

• An explicit user choice takes precedence. Do not silently switch workflows; if the chosen one cannot safely fit the task, explain the mismatch and ask about the necessary adjustment.
• Without an explicit choice: use quick-do for clear, bounded changes; steady-do for ordinary feature work or unresolved design decisions; plan-brief for long-horizon work needing a durable plan and separate-session execution.
• Judge by uncertainty, coupling, risk, and handoff needs, not prompt length or file count. If unsure between quick and steady, use steady. If a handoff would help but was not requested, propose it before changing who executes; complexity alone does not authorize a handoff.
• These workflows govern requested development work, not every explanation or read-only question. Skill instructions are in English; replies and deliverables follow the user's language (Chinese by default).

Do the work

• Read the request, applicable project rules, and affected files before editing. Inspect relevant callers when changing shared behavior; avoid unrelated exploration.
• Prefer the obvious interpretation for ordinary implementation details. Ask at most one focused clarification in the normal quick path; if investigation reveals substantial ambiguity or risk, stop and propose steady-do rather than guessing to satisfy the question limit.
• No plan documents, grilling sessions, or sub-agents. Use a todo only when the work or host instructions warrant it; do not create a planning ceremony.
• Keep the smallest working change: reuse existing code, then stdlib/native features, then installed dependencies. No over-encapsulation, speculative abstractions, defensive boilerplate, redundant checks, or unrelated cleanup. Preserve necessary trust-boundary validation, security, accessibility, and data protection.
• Before destructive or irreversible actions, show the impact and obtain explicit authorization. A quick workflow does not permit overwriting secrets or changing unrelated environments.

Verify and finish

• Default to the smallest real execution path plus a reread of the change; check the requested behavior, not merely the absence of errors. For documentation-only changes, inspect content and applicable format checks.
• Do not add tests, TDD, or verification scripts by default. Follow explicit user requests and mandatory project checks; those are not waived by this workflow.
• Report only what actually ran. A static check, successful load, or injected input is not proof of end-to-end behavior. If execution is unavailable, state what remains unverified and the concrete user check.
• Finish in one short line stating the change and verification status, including a blocker or required user check when present. No separate report or summary essay; required product docs and project memory still apply.