quick-implement — Claude Code skill for small, safe edits

---
name: quick-implement
description: Rapid implementation for small, low-risk, well-defined changes. Use when the task is narrow in scope, has clear acceptance criteria, and can be completed safely without a formal multi-phase plan.
argument-hint: "[brief description of the change to implement]"
license: MIT
---

# Quick Implement

## Scope Gate (Required Before Coding)

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

1. **Clear requirement**
   - Expected behavior is explicit
   - No major product/architecture ambiguity

2. **Small change surface**
   - Usually touches a small number of files (rough guideline: <= 5 files)
   - No broad cross-module refactor

3. **Low architectural risk**
   - No foundational redesign
   - No migration-heavy change
   - No multi-phase rollout dependency

4. **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:

1. Stop all coding activities immediately.
2. Output the exact message: "This change exceeds rapid-implementation safety limits. Recommend `write-plan` first to define phased execution and risk controls."
3. 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

1. Understand the user request and define acceptance criteria.
2. 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.
3. Inspect only the minimum necessary code paths.
4. Confirm the task still passes the Scope Gate.
5. If ambiguity remains, ask clarifying questions before coding.

### Step 2: Implement

1. Make the smallest correct change to satisfy requirements.
2. Reuse existing patterns and conventions.
3. Avoid opportunistic refactors unrelated to the request.
4. Keep changes idempotent and safe to rerun when applicable.

### Step 3: Verify

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

1. Targeted tests related to modified behavior
2. Relevant lint/type checks for touched areas
3. 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

1. Summarize what changed and why.
2. List modified files.
3. Report verification commands and outcomes.
4. 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