Skip to content

L05.md

Latest commit

 

History

History
81 lines (64 loc) · 3.46 KB

L05.md

File metadata and controls

81 lines (64 loc) · 3.46 KB
Raw
id course-kimi-code-l05
type course
title Lesson 5: Take the workflow to your own project
summary The pattern generalizes: contract first, read-only survey, planning lane, bounded edits, written verification — run the same loop on a script you actually own.
lang en-US
content_version 1
status reviewed
reviewed_on 2026-09-13
hints
title body
What this checkpoint tests
Self-attested: you confirm you applied the loop to your own project. The evidence is your contract, your reviewed diffs, and your verification record — not a code we can check.
title body
Carry the shape, not the code
What transfers is the loop: contract first, survey read-only, plan before edits, one bounded change at a time, verification written down. Where your editor supports it, `kimi acp` exposes the same agent over the Agent Client Protocol.
title body
When you are done
Your own script has a contract, one bounded change you can explain, and a verified/not-verified/known-limits record — or a documented reason the loop did not fit.

Lesson 5: Take the workflow to your own project

Objective

You apply the whole loop — contract, read-only survey, plan, bounded edits, written verification — to a script or project you actually own, and record what happened.

Why this lesson exists

A course folder is a safe sandbox; your own codebase is not. The point of the last four lessons was never the report tool — it was a repeatable way to drive an agent that keeps you in charge of what ships. This checkpoint exists to prove the transfer happened. It is self-attested: only you know whether the loop actually ran.

The lesson

Pick a real script you own — one with a bug you have been putting off, or a behavior you want but have not written. Then run the same five moves:

  1. Contract. Write the task contract first: inputs, outputs, error cases, and "done means <command> exits 0". One short paragraph, every sentence testable.
  2. Rules that persist. Put the working rules in the project's AGENTS.md — the files the agent may touch, the verification command, the dependency policy.
  3. Lanes in order. Survey with explore, decompose with plan, then let coder execute one contract line at a time, reviewing each edit before the next.
  4. Verify. Run the verification command, then do the review the suite cannot do — walk one real input end-to-end and check the output by hand.
  5. Record. Write the three lines: verified / not verified / known limits.

If you work in an editor that speaks the Agent Client Protocol, kimi acp exposes the same agent over JSON-RPC — the loop does not change, only the window it runs in does.

If the loop fought you — the task was too small to need a contract, or too vague to test — that is a finding too. Write down where the shape did not fit; that judgment is the actual skill.

Exercise

If your project has more than one boundary worth pinning, draft the next contract line now — you will want it when you open the next session.

Checkpoint

This checkpoint is self-attested: claim it when you can answer:

  1. What was your contract's "done means" command?
  2. Which edit did you push back on?
  3. What is on your "not verified" list that a stranger would assume was covered?

Expected evidence

Your contract paragraph, the rules file you wrote, and the three-line verification record. These are yours — they are the proof the workflow transferred.