| name | plan-ticket |
| description | Read a Jira ticket and produce a written plan saved as a markdown file. No code, no branches, no commits — just a quality plan. Use when the user asks to plan, scope, or think through an OSDEV ticket before building. |
Planning an OS Hub Ticket
The job: read the ticket, do real research, write a quality plan to a markdown file. No code. No branches. No commits. Just the plan.
Step 1 — Confirm the ticket
If the user did not name a ticket, ask:
Which ticket should I plan? Reply with the OSDEV key (e.g., OSDEV-2316).
Step 2 — Read the ticket
Fetch from Jira via the Atlassian MCP. The OS Hub Atlassian site is opensupplyhub.atlassian.net — use this to identify the workspace when calling the MCP.
Extract: summary, description, acceptance criteria, labels.
Step 3 — Name the complexity
State the complexity level and the reason in one sentence. The user decides what to do with that information.
- RED — touches dedupe pipeline, ECS/Terraform, or core DB schema
- YELLOW — new Django model, full-stack change, or touches search
- GREEN — text changes, new field in an existing API, or new UI component
Step 4 — Research
Pull from every source available. The goal is a quality plan, not just any plan.
- The codebase — find similar features, read them as templates. If the OS Hub Codebase Expert sub-agent is available, delegate this; otherwise read directly.
- Confluence — search the OS Hub Development Home space for the feature, related specs, or prior decisions.
- GitHub —
git log --oneline -20 and gh pr list --state merged --limit 15 --json title,number,files for recent similar PRs.
- AGENTS.md and the
.agent/skills/ resources — apply existing conventions, patterns, known gotchas.
- Session context and memory — anything shared earlier or auto-loaded.
- External connectors (optional) — ask once: "Do you have Granola, Google Drive, Monday, HubSpot, or other MCP connectors with context that might help on this ticket?" If yes, pull from them. If no or unsure, skip and continue.
If you can't find something, say so. Don't guess.
Step 5 — Write the plan to a markdown file
Save to ~/.claude/plans/OSDEV-####.md (create the directory if needed).
Length and tone:
- 200-400 words total. The whole plan should be readable in 2-3 minutes.
- Each section: 1-4 bullets or 1-3 sentences. "Files to change" may run longer (it's the most concrete part).
- If a section has nothing real to say, write "None" — don't pad with platitudes.
- Plain English. No jargon a non-engineer reviewer wouldn't get.
Sections:
- Heading:
# Plan: OSDEV-####
**Status:** Draft (created [today's date])**Complexity:** RED / YELLOW / GREEN**Generated by:** /plan## What the ticket asks for — 2 sentences plain English## What Confluence says — specs and context, or "nothing found"## What recent PRs show — patterns to follow## Files to change — bullet list with path and what changes in each## Tests to write — bullet list## RELEASE-NOTES entry (drafted) — [OSDEV-####](https://opensupplyhub.atlassian.net/browse/OSDEV-####) - Description.## Risks — bullet list
Step 6 — Show the plan, then offer to share it
Show the plan inline in the chat. Then ask:
Plan saved to ~/.claude/plans/OSDEV-####.md. Want me to post it where teammates can see it?
- jira — add the plan as a comment on the Jira ticket
- github — add the plan as a comment on the open PR for this ticket (if one exists)
- both — do both
- no — keep it local
If jira or both: use the Atlassian MCP to add the plan content as a comment on the ticket.
If github or both: search for an open PR matching the branch pattern OSDEV-####-*. If found, post the plan as a comment. If no PR exists yet, say so and skip.
If no: end the run — the file is saved locally.
What this skill does NOT do
- Does not write code
- Does not create branches or commits
- Does not create a PR
- Does not file new Jira tickets (the jira-ticket-writer skill handles that)
