ContractorKeith my July takeoff article promised a post about the AI crew. the draft sat long enough for the workflow in it to become obsolete.
very efficient documentation system.
the work kept moving through Ködade, contractor apps, and upstream SlowBooks fixes. this is the September version of how i manage it, with the retired memory setup left out.
give the task an end
i spent 37 years in construction. “make it better” was not a useful instruction to a crew then, and it does not become one because the crew can generate TypeScript.
ContractorCRM’s September work had a concrete end: put today’s follow-ups in front of the user, shorten lead capture, and make personal-agent access usable. a reviewer could check those behaviors against the issue instead of deciding whether the app felt improved.
so i start with the observable result and the constraints around it. the agent needs the repository’s instructions and a way to verify the result, plus a clear account of what belongs outside the task.
my public skills repository contains reusable pieces of that planning-to-shipping flow. the current personal setup also keeps shared rules and skills in dotfiles, with project instructions beside the code.
split work that can actually be split
separate tasks can run in separate branches and worktrees when their file ownership and interfaces are clear. shared edits and unresolved design choices are reasons to do the work sequentially.
Ködade desktop and Ködade CLI help keep sessions attached to their projects. the sidebar can tell me an agent needs attention; it cannot tell me the feature is correct.
and writing code is only part of the assignment. i want the result checked against the original requirement, and i want a separate look at whether the implementation follows the repository’s standards.
two different questions.
reproduce the failure, then trust the fix
the SlowBooks job-costing review is a better example than a count of generated lines. labor was affecting the P&L twice. the review reproduced it in a fresh company, corrected the offset, and added a test for the accounting behavior.
but a green suite has boundaries. the Pioneer Trail browser work needed a development-server regression after the production tests missed a cold-start bug. packaging and real installed-app checks answer questions a browser fixture cannot.
i keep those limits in the handoff so the next session does not turn “Linux build passed” into “all platforms verified.”
leave a place to resume
the durable context needs to be readable outside the conversation. project state and decisions belong with the mapped project notes, while code, issues, and release evidence remain the authority for what actually shipped.
the projects-vault integration is still being developed. automatic KödMem checkpoints are currently disabled in my setup, so i do not describe memory capture as a finished background service that always saves the day.
after review fixes and the relevant checks pass, the scoped changes get committed and pushed. a merged change still needs packaging before i call it a downloadable feature.
that last distinction is why the projects page now separates releases from development. i can run a lot of agents. i still have to read what they built.