# Implement

> Use for general software implementation from a requirement, spec, issue, or plan; use fix-findings instead when validated findings are the primary work queue.

- Skill: `nono911/implement` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add nono911/implement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nono911/implement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nono911 (https://skillmd.com/u/nono911)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nono911/implement

---


# Implement

## Purpose

Deliver the smallest complete change that satisfies the contract, preserves unrelated behavior, and is verified in proportion to risk.

## Workspace protocol

Read `references/workspaces.md` once per agent task before selecting or creating workflow artifacts; reuse it unless repository scope or task authority changes. This skill owns only the task-specific behavior below.

## Inputs

- User request and acceptance criteria
- Applicable repository instructions and live code paths
- Existing spec, plan, decisions, findings, and tests

## Outputs

- Scoped source, test, configuration, migration, or documentation changes
- Updated existing plan status and handoff when those artifacts are in use and work remains
- Acceptance-linked verification evidence and a concise change summary
- A truthful `COMPLETE`, `PARTIAL`, or `BLOCKED` task outcome with remaining work and the next executable action when applicable

## Rules

- Trace current behavior before editing and follow established project patterns unless evidence justifies a change.
- Prefer the smallest coherent vertical slice over speculative infrastructure.
- Keep compatibility unless a breaking change is explicitly authorized.
- Before production edits, map each applicable acceptance criterion or changed observable behavior to its strongest practical proof. Use a compact Behavior-to-Proof table only for multiple criteria or material risk.
- When changed behavior is deterministic through a viable automated harness, prefer red-green-refactor: add the smallest behavioral test, run it and confirm the intended failure, implement the minimum change to pass, then refactor while the focused tests remain green.
- Treat an explicit user request for TDD or test-first development as a requirement. If a meaningful red phase is impossible, stop and explain the evidence gap instead of silently switching workflows.
- Do not manufacture a red phase for documentation, generated output, exploratory prototypes, behavior already covered by a passing test, or work without a viable deterministic harness. Use the strongest safe proof and disclose why test-first was not used.
- Add or update tests only when they provide meaningful proof of changed behavior or regression risk. For a reversible low-impact change, do not add a test that merely mirrors the implementation.
- Run the focused checks required by the change. Broaden or repeat verification only when a failure, subsequent edit, repository requirement, or unresolved material risk justifies it.
- Do not report `COMPLETE` from source edits or a passing subset of required checks. Report `PARTIAL` when requested work or proof remains and `BLOCKED` only for a concrete stopping condition; distinguish executed evidence from inference and name the next executable action.
- Do not silently weaken tests, validation, security, typing, or error handling to make checks pass.

## Decision-log updates

Record material implementation choices, deviations from the plan, assumptions that affect behavior, accepted tradeoffs, and why a simpler or established pattern was not used. Include verification or follow-up consequences.
When durable state is approved, append the decision to the selected work item's `decisions.md` and update its plan or handoff when applicable; otherwise include it in the final response.

## Escalate to the human

Escalate when acceptance criteria conflict, implementation requires a breaking or destructive change, credentials or production data are required, or the only viable approach materially expands scope. Routine code-level choices do not require escalation.