quick-do

Quick Do: understand → do → verify

When this skill applies

• Small, well-understood changes with a known verification path: localized fixes, mechanical edits, config tweaks, short scripts.
• The user's explicit choice wins — never switch workflows silently; if the chosen one cannot fit the task, say why and ask. Stuck on design, compatibility, or acceptance decisions → stop and propose steady-do (if unsure between quick and steady, use steady); a handoff to a separate session → propose plan-brief.
• 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.
• Look at the live site first (seconds, no approval): env active, deps actually importable, files and callers as expected — one glance that prevents a whole round of avoidable errors. Skipping ceremony is the point here; skipping this look is not.
• Fix the root cause, not the reported symptom: grep the callers of what you touch and fix where all of them route through — a guard repeated in every caller is a bigger diff and leaves siblings broken.
• 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.
• Blocked is a legitimate outcome: say so, name what is left and the exact check the user must run; never fake completion and never silently skip a step.
• 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.