workflow

Turn a pile of raw notes (bugs, UI nits, feature ideas, a walkthrough dump) into verified, scoped task briefs, partitioned by the files each task writes into as many parallel git worktree lanes as the work needs, with setup commands, a coverage ledger that proves nothing was dropped, and a serial merge order. Use when someone pastes a list of six or more work items, a bug list, or asks to split work across sessions, windows, or lanes.

Write a short end-of-work note (where things stand, what is next, what is blocked, what to watch out for) and commit only that note, so the next session or the next person picks up without re-explaining. On an integration branch it updates the shared handoff (docs/HANDOFF.md by default); on any other branch it updates that branch's task record. Use when finishing a stretch of work, stepping away, when the conversation has grown large, or when the user says "hand off", "save where we are", "wrap up for now", or "I'm done for today".

Bring the repo's living documents up to date (handoff and resume marker, status, backlog, changelog, decisions, lessons), reconciled against git history and against what happened in this conversation, then commit them. Use at the end of a work session, before stepping away from a large context, after merging a batch of lanes, or when the user says "update the docs", "get ready for compaction", "wrap up", or "maintain".

Review the uncommitted changes in plain English for someone who is not a developer. Says what changed, flags what could break (deleted or weakened tests, config and environment files, migrations, dependencies, auth code, secret-looking files, very large files, debug leftovers), reports what was actually tested, and gives a verdict of READY TO COMMIT, NEEDS ATTENTION, or STOP. Use before committing or opening a pull request, or when the user asks "is this safe to commit", "what did we change", or "review my changes". It never commits.

Keep a project's security evidence current and honest - explain what has and has not been assessed, decide which controls apply with a named person, gather real evidence with the built-in collectors or from actual test and scan results, record observations that go stale when their sources change, and turn gaps into backlog items. Use when the user asks about security, before a release or review, when the session start shows missing or stale evidence, or when asked "is this secure" or "are we compliant".

Turn a plain-language request into a tracked piece of work, then keep it moving and recoverable - a task record with acceptance criteria, the right branch, checkpoints as things are decided or verified, and an honest final state. Use when the user describes something to build, fix or change ("can you make...", "add...", "the page is broken..."), when resuming work after a break or a new session, or when asked "where are we on this".