# Implement

> Use for an approved software change through verified implementation, independent review, bounded repair, and user acceptance. Not for unsettled scope, diagnosis-only, read-only review, or release.

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

---


# Implement

## Entry gate

Require:

- approved scope, non-goals and acceptance criteria;
- costly-to-reverse decisions approved or expressly parked;
- build ceiling and write/external authority;
- `config/risk-policy.json` risk/authority profile: minimum tier, bounded paths,
  disclosure, secrets and external-action constraints;
- `evaluate` need for stochastic/judgement-bearing behaviour.

If missing, use `scope`; never infer owner decisions.

For active service or safety impact, user-approved containment may parallelise
verification and review. Gates and authority apply; name a
reconciliation run.

## Loop

1. For substantial+ work, create the canonical `delivery-run` with profile
   `software` through the complete installed-producer command in `deliver`,
   then follow [run-contract.md](references/run-contract.md). Routine minor work may proceed
   without `RUN.json` unless the user or project policy requests one.
2. Keep an adaptive plan. Name the governing skill in the worker contract
   before changing code. Invoke `tdd` for every new or changed observable
   behaviour, and use `refactor`
   for behaviour-preserving structure and `diagnose` for unknown causes.
   Migrations may need behaviour tests and equivalence evidence. Use
   `orchestrate` when decomposition helps; adapt topology inside authority.
   For a version-sensitive external interface or migration, apply
   [source grounding](references/source-grounding.md) and
   [migration compatibility](references/migration-compatibility.md).
3. Run deterministic checks; map each criterion to evidence. When required, run
   `evaluate` and attach its passing receipt.
4. Invoke read-only `code-review` under the current `HARNESS.md` risk ladder.
   Record adapter, actual family, omissions and substitutions.
5. Repair blockers, then repeat verification and review under the `deliver`
   receipt contract's scaled budget. Return evidence to user or `scope` on
   drift.
6. Update owned docs for behavioural, architectural, operational or decision
   change. For substantial+ apply `session`: refresh recovery checkpoint,
   audit context, graduate durable findings and classify retained/ephemeral
   artifacts in `RUN.json`.
7. When a receipt exists, validate with
   `"$(provenant root)/skills/deliver/scripts/validate_delivery.py" \
   .agent-run/<id>/RUN.json --workspace-root "$PWD" --verify-hashes`.
   Hand off only after this machine gate.
8. User final acceptance is mandatory; promotion needs separate `release`
   authority. Terminalise any run directory as
   [run-contract.md](references/run-contract.md) sets out.

## Authority and completion

- Reviewed source stays immutable; separately authorised artifacts and Fabric
  communication stay bounded.
- Record missing legs as failed/unavailable; never filter them. Review coverage
  blocks whenever the HARNESS ladder is unsatisfied.
- Objective evidence outranks reviewer confidence; adjudicate conclusions,
  never vote.
- Substantial+ starts a fresh implementation session bound to approved digests.
- Clearing every machine gate is not acceptance. Record the receipt's
  `human_gates.acceptance` approval only after explicit user acceptance.

## Portable artifact

Use the skill-owned [implementation checkpoint schema](portable-workflow.v1.json).