Quick Implement

Scope Gate (Required Before Coding)

Treat a task as quick-implement eligible only if all conditions below are true:

-

Clear requirement

• Expected behavior is explicit

• No major product/architecture ambiguity

-

Small change surface

• Usually touches a small number of files (rough guideline: <= 5 files)

• No broad cross-module refactor

-

Low architectural risk

• No foundational redesign

• No migration-heavy change

• No multi-phase rollout dependency

• Straightforward verification

• Can validate with targeted tests/checks quickly

• No long exploratory debugging loop required

If any condition fails, escalate to write-plan.

Hard Stop Escalation Criteria

Immediately stop quick implementation and switch to planning when any of these appear:

• Requirement ambiguity that needs design decisions

• Unexpected coupling across multiple subsystems

• Significant data model or schema changes

• Security-sensitive or compliance-critical changes

• Performance work requiring benchmarks/design trade-offs

• Refactor growing beyond original small scope

• Repeated failed attempts without a clear root cause

• Need for phased delivery, feature flags, or migration strategy

Escalation action:

• Stop all coding activities immediately.

• Output the exact message: "This change exceeds rapid-implementation safety limits. Recommend write-plan first to define phased execution and risk controls."

• Use input/question to ask the user if they want to initiate a handoff to the write-plan skill.

Workflow

Step 1: Analyze and Contextualize

• Understand the user request and define acceptance criteria.

• Load only the project context relevant to the request:

• If docs/SUMMARY.md exists, read it first.

• Load only task-relevant detail docs.

• Prioritize Code Standard docs for implementation conventions.

• If docs conflict with code or user intent, use the available input/question before broad changes.

• Inspect only the minimum necessary code paths.

• Confirm the task still passes the Scope Gate.

• If ambiguity remains, ask clarifying questions before coding.

Step 2: Implement

• Make the smallest correct change to satisfy requirements.

• Reuse existing patterns and conventions.

• Avoid opportunistic refactors unrelated to the request.

• Keep changes idempotent and safe to rerun when applicable.

Step 3: Verify

Run proportional validation for the change using the appropriate execution tools:

• Targeted tests related to modified behavior

• Relevant lint/type checks for touched areas

• Build or runtime verification if applicable

If verification fails unexpectedly:

• Attempt focused fixes if clearly local.

• If failures suggest broader impact, recommend escalate to write-plan.

Step 4: Complete

• Summarize what changed and why.

• List modified files.

• Report verification commands and outcomes.

• Update documentation if minor behavior or domain rules changed

Execution Boundaries

• Do not expand scope without explicit user approval.

• Do not assume unspecified behavior; clarify instead.

• Do not force completion when risk increases—escalate early.

• Escalate to write-plan when complexity or risk exceeds quick-implement limits.

• Use fix when the task is primarily debugging an issue.

Output Checklist

Before final response, confirm:

• Scope Gate was satisfied

• No hidden architectural changes were introduced

• Verification was run and reported

• Escalation was used if safety limits were exceeded