Skip to main content

​
task

The task lifecycle: start it, inspect its phase, re-sync its markdown. 
# Declare work is starting (before reading code or writing tests)
tiny-brain task start --task 'Add the behaviour' --prd my-plan --feature my-feature
tiny-brain task start --task 'Update config' --fix my-fix --phase green   # skip RED

# What phase is the task in, per the commit history?
tiny-brain task phase --task 'Add the behaviour' --prd my-plan --feature my-feature

# Project progress state from an edited markdown file
tiny-brain task sync docs/prd/my-plan/features/my-feature.md   # --force for full re-sync
--task takes the exact task description; the work item is addressed with --prd/--feature or --fix. (--spike addresses work on go and run, not on task.)

​
commit

The commit lifecycle surface. validate is what the commit-msg hook runs against your message; progress stages and commits tracking-file updates when your setup keeps any in the tree. 
tiny-brain commit validate .git/COMMIT_EDITMSG
tiny-brain commit progress

​
work add

Creates plan documents and tasks — the authoring command behind the /plan, /feature, and /fix skills. (Not yet listed in tiny-brain help; the skills are its primary caller, but it works directly.) 
tiny-brain work add prd <slug> "Title"
tiny-brain work add feature --prd <slug> <feature-slug> "Title"
tiny-brain work add task --feature <feature-slug> "Exact task description"
tiny-brain work add fix <slug> "Title"
It owns the frontmatter — UUIDs, numbering, dates. See the markdown format for what it writes.

​
pipeline

The single authority for pipeline state: records red/green/refactor/review steps against a task and prints the next instruction. The hooks call this for you — it’s documented so a hook’s output makes sense, not as a daily driver. 
tiny-brain pipeline --task-id 'Add the behaviour' --fix my-fix --agent green --sha abc1234
Hand-driving pipeline writes pipeline state; prefer letting commits and hooks advance it.