Skip to content

Implement

Logical ID: kiyo.implement · Entry: src/kiyo/skills/implement/SKILL.md · Procedure: workflows/implement-flow.md (KIYO-FLOW-002, KIYO-IMPL-001)

Purpose

Section titled “Purpose”

Implement makes authorized code changes: features, bug fixes, and explicitly scoped refactors. Changes stay minimal, tests are relevant, verification is actual, and repair is bounded. It is the only Skill whose default purpose is changing application code.

Preconditions: your actual intent must permit code changes. Review, explanation, and analysis never authorize implementation. A selected Skill, a READY requirement, a found defect, or a copied approval is not by itself permission.

Access contract

Section titled “Access contract”
Effect Boundary
Read Authorized instructions, accepted policy, Memory, and current code, config, and test evidence; no credentials or unrelated bulk exploration
Write Only necessary code, tests, docs, or config changes within the request and policy; no unrelated architecture, library, or cleanup changes
Execute Only inspected commands with evidenced targets, environment, and side effects, plus execution authority; write permission alone does not cover every test, install, or database operation
Memory Assess impact; sync only a necessary evidenced delta within actual Memory-write scope
External / repository No implicit commit, push, PR creation, deployment, publication, global or policy changes, destructive cleanup, or production access

Before editing, Implement records the root, branch or HEAD, and staged, unstaged, and untracked changes. It never initializes Git, resets, stashes, or reverts your work.

The implementation flow

Section titled “The implementation flow”
flowchart LR
accTitle: Shared implementation flow
accDescr: Permission preflight, Memory orientation, understand, inspect and validate, plan, assess risk, human decision when required, implement, verify, review, Memory impact, complete.
A[Permission<br/>preflight] --> B[Memory<br/>orientation] --> C[Understand] --> D[Inspect +<br/>validate Memory]
D --> E[Plan] --> F[Assess risk /<br/>governance] --> G{Human decision<br/>required?}
G -- yes --> H[Request missing<br/>scoped approval] --> I
G -- no --> I[Implement] --> J[Verify] --> K[Review] --> L[Memory impact /<br/>sync] --> M[Complete]
J -- failure --> R[Bounded repair<br/>≤ 2 unsuccessful cycles] --> J

The Skill spells this out as 16 daily obligations. Condensed:

  1. Read the Memory index and only relevant entries; validate material claims against current code.
  2. Establish behavior, acceptance criteria, scope, and unknowns; discover first, ask only blocking questions.
  3. Inspect existing implementation, the closest safe patterns, and relevant tests.
  4. Make a minimal plan with the short plan template when useful. For a tiny task, a scope sentence is enough.
  5. Assess dependency, schema and API compatibility, security and data, and tool effects; obtain only missing scoped approval.
  6. Implement only the authorized delta; preserve human changes.
  7. Add or adapt necessary regression tests using the project’s existing tools.
  8. Inspect commands and environment, then run applicable permitted checks and keep actual final-state evidence.
  9. Separate baseline failures, new regressions, and environment blocks. No fake PASS, and no “all tests pass” with known failures.
  10. Review the final diff, labeled as self-review. Assess Memory impact. Report against the Implement Definition of Done.

Bounded repair

Section titled “Bounded repair”

From workflows/repair-and-handoff.md (KIYO-FLOW-004): the default is at most two unsuccessful repair cycles for the same failure before the agent stops and reports. A cycle is one evidence-based hypothesis, a bounded correction, and a recheck. The agent never disables a failing test, weakens an acceptance criterion, or expands scope to reach PASS. It never renames the issue to reset the count.

Failure classification Evidence needed
Baseline failure Comparable pre-change evidence for the same failure
New regression Evidence connecting the change to a new failure
Environment problem An observed missing tool, service, permission, or unsuitable target
Unresolved cause Cause not established; name the smallest safe diagnostic step
Suspected flakiness Repeated comparable observations; one fail-then-pass is not enough

Sensitive effects

Section titled “Sensitive effects”
  • Writing a migration file is not applying it. Auth and schema work is judged on the actual action, environment, data, and policy, not blanket-blocked or blanket-allowed by keyword.
  • Implement never substitutes a production database, or broadens access, to make verification pass.

Output

Section titled “Output”
  • Material work: the engineering report, with a requirement → implementation → check → evidence trace and a self-review.
  • Tiny work: the compact report.
  • Incomplete work: a handoff with facts, approval scope, repair history, and the next action.

Missing mandatory verification, or a required sync, prevents DONE.

Source and tests

Section titled “Source and tests”
Section titled “Related”