Most teams do not need another project management product. They need a place where work has a boundary, a definition of done, and a visible state someone can trust. GitHub already has issues, projects, and pull requests. Used carefully, that is enough to plan with AI, execute with AI, and still keep humans in charge of what lands.
The idea is minimal on purpose. Do not invent a second backlog. Do not keep a private queue file the agent maintains. Do not let the model invent scope mid-flight. Put the plan on GitHub, put the work on GitHub, and treat the board as the monitor.
An AI that can write code will happily write too much of it. Without a clear package of work it expands the diff, skips the unglamorous half (migrations, callers, backfills), and marks itself done because the tests it wrote are green. Review then becomes archaeology. The opposite failure is ceremony: giant tickets, phase names pretending to be deliverables, and status nobody updates. The board lies, so monitoring fails. What we want sits between those: enough structure that an agent can pick up a leaf cold, and little enough that a human can still see the whole picture on one epic.
We split the work into two agent skills that share one source of truth on GitHub.
plan-work turns an ask into a plan. It surveys the real codebase (not memory), states the outcome and acceptance criteria, and breaks the work into deliverables. Each leaf gets a stable WBS id in the title, like [1.2.3], plus an explicit predecessor line: Depends on 1.1.1 or (none). That is how sequence is enforced without turning the breakdown into a fake schedule of "Phase 1, Phase 2." Soft ordering still lives on the board. Hard blockers live on the issue. When the plan is approved, it ships as one epic and native sub-issues, not a markdown checklist pretending to be a hierarchy. Follow-ups that are out of scope are linked, not parented, so they do not inflate the epic's progress bar. New leaves start unassigned and without workflow status. Planning creates the backlog. It does not claim it.
do-work consumes that backlog. It loads the parent epic first so decisions and out-of-scope lines still bind. It only picks work that is ready: acceptance criteria present, predecessors declared, blockers closed. It claims by assigning itself, moves the board, implements under gitflow off develop, checks each acceptance criterion with evidence, and opens a PR. It does not merge. It does not close its own issue. Review stays human.
Together they form a loop you can watch: plan on GitHub, execute on GitHub, review on GitHub.
Status is the monitoring surface. The path is simple: Backlog to Ready to In progress to In review to Done. Planning leaves issues quiet. Execution moves them. When a PR opens, the issue goes to In review. When the PR merges, a later run (or a human) marks Done and prunes the branch. If a run aborts, the agent unassigns and puts the card back so the queue does not look busy when it is stuck. You do not need a custom dashboard for this. A GitHub Project with a Status field is enough. Labels work as a fallback. The point is one place that answers: what is ready, what is being built, what is waiting on review, and what is actually done.
Dependencies are the other monitor. Depends on (by WBS id) and Blocked by #N are readable by people and by agents. That stops the classic failure where something easy gets built before the thing it calls exists.
Issues carry the definition of done. Sub-issues carry progress without checkbox theatre. Project status carries flow. Pull requests carry the evidence and the review gate. Comments carry the audit trail when status moves or a run stops. That is the whole stack. No shadow spreadsheet. No agent-only memory. If it is not on GitHub, it is not the plan of record.
Keep ceremony matched to size. A two-hour fix does not need a WBS. A multi-repo rewrite does. Prefer one primary outcome per epic, and a first shippable slice when the epic is large. Call out same-release pairs so half a breaking change does not land alone. Keep the code side boring too: minimal comments, minimal docstrings, no copied logic, no new coupling for convenience. The same discipline that keeps a backlog honest keeps a growing codebase honest.
The skills live in a small open repo: eddiegulay/wbs-monitor. Install them into your Cursor or Claude skills folders, then ask the agent to plan a real issue and, after you approve, to execute the next ready leaf.
You will know it is working when the board moves without a standup reconstruction, when PRs map cleanly to one leaf, and when "done" means a human accepted the criteria against the system, not only against a diff the author wrote.
Top comments (0)