| name | coding-workflow |
| description | Standard procedure when you operate as the coder role: the end-to-end workflow, output conventions, and memory-protocol rules to follow before any tool call. |
| when_to_use | Use as your first action when dispatched as the coder role — the body holds the full workflow you should follow. The coder role prompt is intentionally identity-only and depends on this skill for procedure. |
| allowed-tools | ["Read","Write","Edit","Grep","Glob","Bash","TodoWrite","MemoryRead","MemoryWrite"] |
| roles | ["coder"] |
Coding Workflow
Procedure for taking a coding request from understanding to verified delivery.
Workflow
- Read the request. Identify the target file(s), the change to make, and the acceptance signal (test that should pass / behavior that should change).
- The framework injects relevant prior memory automatically — check it first; you may already have a hint (e.g. "typecheck is
pnpm typecheck", "this repo uses pnpm + tsdown", "test fixture lives at X/Y/Z") that saves discovery. But memory is a hint, not a fact — see #3.
- Verify memory-derived assumptions before relying on them. Build tools change, package.json migrates, command names drift. If memory says "typecheck is
pnpm typecheck", a quick probe (pnpm typecheck --help or running it) confirms before you depend on it. Memory shortens the lookup path; it does not skip verification.
- Locate the relevant code: search for symbols, glob for file patterns, read what looks load-bearing. Skim before editing — wrong-file edits cost more than the extra read.
- Plan the change before writing. If the change spans multiple files, list them in order; if it has a non-trivial control-flow change, sketch the new shape mentally before touching code.
- Make the change. Prefer narrow edits over full-file rewrites — rewrites lose review signal. New files only when there is no existing file to extend.
- Verify. Run the project's typecheck / lint / test commands. When the project offers a standardized verification path, use it rather than reinventing the same checks ad-hoc each time. If a test is missing for the change, add one. If the test fails, fix the cause; do not skip or mark as expected-failure.
- Report. Name every file you touched, the verification you ran with its result, and any follow-up the reader should know about.
- When you noticed a durable project fact during the work (a build command, a fixture location, a project convention not documented in LIGHTCLAW.md), persist it as a memory entry before returning so future coding sessions skip the re-discovery. Skip the save if memory already had this and you just confirmed it.
Output conventions
- Format: a short top-line summary, then a
Files changed: list with one line per file (path + one-phrase what), then a Verification: block with the commands you ran and their outcomes.
- Length: match the change. A one-file bug fix gets a short report; a multi-file feature gets a longer one. Do not pad.
- Follow-ups: if you noticed adjacent issues you did not fix (out of scope), call them out at the end so the reader can decide whether to address them.
- Stale-memory acknowledgement: if a memory-derived hint was wrong (build command changed, fixture moved, convention updated), mention it in the report so the post-fact extraction updates the entry (e.g. "memory said typecheck was
pnpm tc but it's now pnpm typecheck").
Do not
- Do not skip verification "because the change is small". Even a one-line fix may break the build; running typecheck once is cheap insurance.
- Do not trust memory blindly. Build tools and conventions drift; verify before depending on a memory-derived command or path.