UNPKG

task-pigeon

Version:

Small local task queue CLI backed by SQLite.

93 lines (68 loc) 3.26 kB
--- name: pigeon-babysit description: Keep a Pigeon task or PR actively moving by monitoring the board, following up on messages, and looping until the work is done or blocked. --- # Pigeon Babysit Use this skill when you need to keep a task or pull request moving without stalling out between turns. ## Goal Keep one named Pigeon task or PR in motion until it is finished, clearly blocked, or handed back to a human. ## Start 1. Claim the work if it is yours to own. 2. Run `pigeon status` and `pigeon whoami` before you trust the board. 3. Confirm you are on the shared project queue or the explicitly configured remote queue. 4. Open the monitor for your agent name only after queue identity is confirmed. 5. Confirm the board, unread messages, and current task state before doing anything else. ```sh pigeon status pigeon whoami pigeon claim --by codex pigeon monitor --by codex --mentions-only ``` ## Shared Queue Contract Use one queue per project. - Every worktree for the same project must point at the same `PIGEON_DB` or the same remote URL unless you intentionally set `PIGEON_WORKTREE_LOCAL=1`. - Do not switch queues mid-run. - If `status` or `whoami` shows the wrong queue, stop immediately instead of pretending the board is empty. - A shared queue example looks like `PIGEON_DB=~/shared/pigeon/project.db pigeon status`. - If you intentionally want per-worktree isolation, make that explicit and do not use babysit flows that assume a shared board. - If the board looks stale, re-read it before taking any action. ```sh PIGEON_DB=~/shared/pigeon/project.db pigeon status PIGEON_DB=~/shared/pigeon/project.db pigeon monitor --by codex ``` ## Loop While the work is open: 1. Check `pigeon monitor --by <agent> --mentions-only` or `pigeon wait --by <agent> --mentions-only`. 2. After every wake-up, re-read `status`, `list`, `whoami`, and unread messages before acting. 3. If another agent says the board is stale or out of sync, refresh the queue state before making any update. 4. Update the task or post a message whenever there is a real change. 5. Keep the goal tied to the active task or PR. 6. Do not exit just because a single command finished. 7. If `status` or `whoami` changes queue identity during the run, stop and re-start from the correct queue. ```sh pigeon wait --by codex --mentions-only pigeon status --by codex pigeon whoami pigeon list --output normal pigeon message list --by codex --unread ``` ## Communication Use messages for coordination that should not become tasks. - Post a short update when you start. - Post the blocker when you cannot move forward. - Resolve your own messages after the other side has acknowledged or acted. - Mention the counterpart when the message needs a response. ```sh pigeon message add "@claude still working on the publish path" --by codex --to claude pigeon message add "Blocked on repository permissions" --by codex ``` ## Stop Stop looping when one of these is true: - the task is done - the task is blocked and the blocker has been recorded - a human takes over - the owner explicitly tells you to stop When stopping, leave the board in a readable state: - update the task status - resolve messages you owned - leave one final note if the next step is not obvious