feat(skills): add webjs-ready-for-dev for parallel issue planning - #1303
Merged
Conversation
vivek7405
marked this pull request as ready for review
August 6, 2026 08:27
Getting a batch of tracked issues implementable was an ad-hoc routine: read each issue, verify its claims against current code, settle whatever it left open, and rewrite the body so a cold agent can start without a discovery phase. Doing that serially is the slow part, and doing it from memory is how a plan ends up citing a line anchor that moved. The skill makes it one command. It fans out one autonomous background agent per issue, all spawned together so they run in parallel, each read-only on the repo because they share the working tree and a stray checkout would move HEAD under the others. Each agent rewrites its issue body to a fixed section contract and then moves the card to the new Ready column, which sits between Todo and In progress so the board distinguishes "filed" from "implementable". The conflict pass before spawning is the part that keeps the resulting PRs independent: two issues rewriting the same function get queued rather than planned against code the other is about to change.
The Projects V2 API is GraphQL only and rate-limits on a point budget, so the obvious way to find a card (item-list over the whole board, once per issue) burns it fast: that query paginates every item on the board, now past 500, to read one id. Two rules replace it. The item id comes off the ISSUE node, which is a single lookup that aliases so a whole batch costs one request. And the polling that waiting on background agents implies moves to the issues REST endpoint, which has a separate budget, leaving GraphQL for the two things only it can do. The poll also now checks the section contract by count rather than by eye, so a partial body cannot move a card to Ready.
vivek7405
force-pushed
the
feat/ready-for-dev-skill
branch
from
August 6, 2026 08:28
58a3481 to
1016127
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds the
webjs-ready-for-devskill: given a set of tracked issue numbers, itgets each one implementable in parallel and moves its card to a new Ready
column on the project board.
"Ready for development" is a definition of done for PLANNING. An issue is ready
when a cold AI agent, with no access to the conversation that produced it, can
implement it end to end with no discovery phase and no clarifying question.
How it works
surfaces spawn together, a shared file in different regions spawns together
with a landmine line naming the other issue, and a shared function queues
instead. This is what keeps the resulting PRs independent.
run concurrently,
general-purpose, fully autonomous, never asking the userto settle a design call.
primary checkout, so no git command that mutates state is allowed. Worktree
isolation is deliberately NOT used, because several agents need to run a real
repro against the installed dependency tree that a fresh worktree lacks.
Tests, Docs, Acceptance criteria, Out of scope. Every line anchor re-verified
against current
HEAD, every "consider" resolved into a decision with thething that settled it.
Ready is a promise the plan is implementable.
Board change
The project's Status field gained a
Readyoption betweenTodoandIn progress. The existing options kept their ids, so no item lost its status(verified: 18 Todo, 2 In progress, 557 Done, unchanged across the update).
Routing
.claude/hooks/route-skills.shgains a block so the skill is routeddeterministically rather than left to model judgement. The patterns are
deliberately narrow on the word "ready": every one requires dev, development, or
implementation adjacency, or an explicit plan noun, so "ready to merge" and
"ready for review" stay out.
Tests
test/hooks/route-skills.test.mjsgains two cases, a positive over six triggerphrasings and a negative over three PR-readiness phrasings. The existing
committed-in-repo guard already covers the new skill directory. All 18 tests pass.