Draft a SPEC from a GitHub issue and open a PR for review. Use when triggered by a routine on `Issue opened` with label `ai:plan`, or when a user asks to "draft a spec from issue #NNN". Non-interactive — proceeds on best interpretation and surfaces any unresolved questions in the SPEC's §Open Questions section rather than blocking for clarification. The PR review loop is where ambiguity gets resolved.
78
90%
Does it follow best practices?
Impact
100%
3.03xAverage score across 1 eval scenario
Advisory
Suggest reviewing before use
A startup engineering team uses an automated system to turn GitHub issues into feature spec documents. The system runs as a scheduled routine: when an issue is labelled ai:plan, an agent reads the issue, drafts a SPEC document, and opens a pull request for human review.
Your job is to simulate the submission phase of this routine. A new feature has already been drafted as docs/specs/SPEC-042-user-notifications.md in a local git worktree (branch claude/spec-042-user-notifications), and the source GitHub issue is #88 in repo acme-corp/travel-planner.
The SPEC file, the branch, and the local commit are already in place. You must now carry out the remaining steps to deliver the spec for review: update the spec index, apply the correct label to the source issue, open the PR, and post a follow-up comment on the issue.
Write a file called submission_plan.md documenting every step you would take, the exact tool calls you would use (with tool names and key parameters), and the exact text of the commit message, PR title, PR body, and issue comment. Use concrete placeholder values where real GitHub data would be needed (e.g. SPEC-042, issue #88, repo acme-corp/travel-planner).
Produce a single file: submission_plan.md
The file should contain: