Menu
Work planning through GitHub issues. Invoke when: starting new work, planning a feature, or when asked 'let's plan X'. Every session = one issue = one PR.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | planning |
| description | Work planning through GitHub issues. Invoke when: starting new work, planning a feature, or when asked 'let's plan X'. Every session = one issue = one PR. |
| user-invocable | false |
Every unit of work gets a GitHub issue. One session = one issue = one PR.
| Situation | Action |
|---|---|
| Starting new work | Create issue first |
| "Let's plan X" | Create detailed issue |
| Scope creep mid-session | Pause → ask about new issue |
| Quick fix / trivial change | Ask if issue needed |
1. Understand the work
2. Draft issue content (do NOT create yet)
3. Include issue draft in plan file
4. Exit plan mode for approval
5. Create the issue (first step after approval)
6. Track issue as session context
7. Do the work (core-workflow)
8. If scope expands → STOP, ask about new issue
9. Finalize → PR closes the issue
Plan Mode: During planning, draft the issue content and include it in your plan file. Do NOT run
gh issue createuntil after plan approval.
Gather all context needed to do the work:
gh issue create \
--repo <org>/<repo> \
--title "Brief description" \
--body "## Summary
What we're doing and why.
## Approach
How we'll implement this.
- Step 1
- Step 2
- Step 3
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Tests written
## Files/Areas
- \`path/to/file.ts\`
- \`path/to/other.php\`
## Notes
Any additional context, decisions, risks."
In plan mode: Include this draft in your plan file and exit plan mode.
After approval: Run gh issue create as the first execution step.
Once an issue is created, track it as session context:
Active Issue: #123 - Feature description
Repo: <org>/<repo>
This context should be referenced:
If context compaction occurs, the issue contains the full context. Fetch it:
gh issue view <number> --repo <org>/<repo>
Sometimes planning reveals work that should be split into multiple issues.
## Issue Drafts
### Issue 1: Feature A
Summary, approach, acceptance criteria...
### Issue 2: Feature B
Summary, approach, acceptance criteria...
## Execution Order
1. Start with Issue 1 (no dependencies)
2. Issue 2 depends on Issue 1
When additional work is discovered mid-session:
STOP — Don't just do it
Assess — Is this part of the current issue or separate?
Ask:
I've discovered we also need to [X]. This seems outside the scope of #123.
Options:
1. Add to current issue (if small and related)
2. Create new issue for separate work
3. Note it and skip for now
How do you want to handle this?
If new issue: Create it, but don't work on it this session
If adding to current: Update the issue body with new scope
# View current body
gh issue view <number> --repo <org>/<repo>
# Edit to add scope (opens editor)
gh issue edit <number> --repo <org>/<repo>
When work is complete and approved for commit:
PR_URL=$(gh pr create \
--draft \
--repo <org>/<repo> \
--title "feat: clear description" \
--body "## Summary
What was done.
## Changes
- Change 1
- Change 2
## Testing
- [ ] Tests pass
- [ ] Manual testing done
Closes #<issue-number>")
printf '%s' "$PR_URL" | pbcopy # draft PR URL copied to clipboard, ready to paste
echo "$PR_URL"
When presenting the PR:
PR ready to create:
Title: feat: add feature description
Body:
## Summary
Implemented the feature.
## Changes
- Added endpoint
- Added validation
- Added tests
Closes #123
The Closes #123 automatically:
| Action | Command |
|---|---|
| Create issue | gh issue create --repo <org>/<repo> ... |
| View issue | gh issue view <num> --repo <org>/<repo> |
| Edit issue | gh issue edit <num> --repo <org>/<repo> |
| Add comment | gh issue comment <num> --repo <org>/<repo> --body "" |
| Create PR | gh pr create --draft --repo <org>/<repo> ... Closes #N (pbcopy URL) |
Closes #NGitHub CLI patterns for issues, projects, and PRs. Invoke when: creating issues, linking PRs to issues, updating project status, or any GitHub project operations.
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program," or "experiment playbook." Use this whenever someone is comparing two approaches and wants to measure which performs better, or when they want to build a systematic experimentation practice. For tracking implementation, see analytics. For page-level conversion optimization, see cro.
When the user wants to generate, iterate, or scale ad creative — headlines, descriptions, primary text, or full ad variations — for any paid advertising platform. Also use when the user mentions 'ad copy variations,' 'ad creative,' 'generate headlines,' 'RSA headlines,' 'bulk ad copy,' 'ad iterations,' 'creative testing,' 'ad performance optimization,' 'write me some ads,' 'Facebook ad copy,' 'Google ad headlines,' 'LinkedIn ad text,' or 'I need more ad variations.' Use this whenever someone needs to produce ad copy at scale or iterate on existing ads. For campaign strategy and targeting, see ads. For landing page copy, see copywriting.
When the user wants help with paid advertising campaigns on Google Ads, Meta (Facebook/Instagram), LinkedIn, Twitter/X, or other ad platforms. Also use when the user mentions 'PPC,' 'paid media,' 'ROAS,' 'CPA,' 'ad campaign,' 'retargeting,' 'audience targeting,' 'Google Ads,' 'Facebook ads,' 'LinkedIn ads,' 'ad budget,' 'cost per click,' 'ad spend,' or 'should I run ads.' Use this for campaign strategy, audience targeting, bidding, and optimization. For bulk ad creative generation and iteration, see ad-creative. For landing page optimization, see cro.
When the user wants to optimize content for AI search engines, get cited by LLMs, or appear in AI-generated answers. Also use when the user mentions 'AI SEO,' 'AEO,' 'GEO,' 'LLMO,' 'answer engine optimization,' 'generative engine optimization,' 'LLM optimization,' 'AI Overviews,' 'optimize for ChatGPT,' 'optimize for Perplexity,' 'AI citations,' 'AI visibility,' 'zero-click search,' 'how do I show up in AI answers,' 'LLM mentions,' or 'optimize for Claude/Gemini.' Use this whenever someone wants their content to be cited or surfaced by AI assistants and AI search engines. For traditional technical and on-page SEO audits, see seo-audit. For structured data implementation, see schema.
When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers or wants to build systems to prevent it. For post-cancel win-back email sequences, see emails. For in-app upgrade paywalls, see paywalls.