kolbyhalcomb/kolby-workflow
Documentation, change-management, and multiagent workflow discipline for Kolby's repos: the change workflow, CHANGELOG format, shared-brain split, planning conventions, safety-rule authoring, ticket-first, review-before-advance, delegation, and repo setup.
The loop every confirmed real-world change follows before it is committed — surgical edits, a dated CHANGELOG entry, review, then commit. Use when recording a change that has actually happened (a device added, a service moved, a value confirmed), when asked to "update the docs", or when deciding whether something is ready to commit.
How to write an entry in an append-only CHANGELOG — the dated-heading format, the four citation granularities (line, range, section, bare path), and the rule that entries are never edited after the fact. Use when adding a CHANGELOG entry, citing changed files, or correcting an entry that turned out wrong.
How to split work across agents — the planner/worker/judge separation, one ticket per fresh context, parallel agents for independent tickets, subagents for sub-parts of one ticket. Use when deciding whether to parallelize, spinning up multiple agents, delegating a ticket, or when one session is trying to plan and implement at once.
How to plan a multi-step change — spec first, phase it, objective binary gates, rollback defined before starting, default to the durable solution, and land every plan into living docs. Use when planning infrastructure work, anything over ~3 commands, anything touching networking, or when choosing between a quick patch and a scalable fix.
Read every comment and review on an issue or PR before closing, merging, or deploying it — then implement each item or counter it in writing. Use when about to close an issue, merge a PR, mark work done, deploy, or start the next slice while the current one has open feedback.
The pattern for writing an operational safety rule that an agent will actually follow — name the artifact, name the consequence, name the condition for breaking it. Use when adding a rule to a project's safety list, when something just went wrong and the lesson needs recording, or when an existing rule is being ignored or worked around.
Scaffold a repo onto the kolby-workflow conventions — plugin pin, CI gates, triage labels, issue and PR templates, thin agent-file wrappers. Use when setting up a new repository, when asked to "wire up the workflow" or "apply dev-standards" to a repo, or when auditing an existing repo against the conventions.
How to keep one shared project brain with thin per-tool wrappers so CLAUDE.md, AGENTS.md, and other agent entry files never drift apart. Use when adding a fact to a repo's agent instructions, when asked where something belongs, when setting up agent files in a new repo, or when two entry files have diverged.
No implementation starts without an agent-ready issue, and every PR names the issue it closes. Use when starting implementation work, opening a PR, deciding whether a request is ready to build, or when asked to "just quickly" build something with no ticket behind it.