Stats
Actions
Tags
From paxos-planning
Track a feature that ships across multiple PRs and (often) multiple parallel Claude sessions. Use this skill when the user wants to design a feature once, break it into PR-sized steps, execute each step in its own session (often via Conductor workspaces), and keep a single living markdown plan that reflects current shipping state. Triggers include "multi-PR plan", "feature plan", "Conductor workspace plan", "track this feature across PRs", or any reference to /plan, /plan-new, or /plan-sync.
How this skill is triggered — by the user, by Claude, or both
Slash command
/paxos-planning:multi-pr-planningThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A feature often spans several PRs, each shipped from its own Claude session. The user already has good tooling for *one feature in one session* (`superpowers:brainstorming` → `superpowers:writing-plans` → `superpowers:executing-plans`). This skill adds the layer above: a single markdown plan per feature that tracks every PR's shipping state, can be pasted into any new session as starting contex...
A feature often spans several PRs, each shipped from its own Claude session. The user already has good tooling for one feature in one session (superpowers:brainstorming → superpowers:writing-plans → superpowers:executing-plans). This skill adds the layer above: a single markdown plan per feature that tracks every PR's shipping state, can be pasted into any new session as starting context, and updates on demand to stay current.
Plans live at /Users/pd/Developer/claude/plans/<feature-slug>.md. They share the paxos repo's git history.
This skill does not replace superpowers:writing-plans. When an individual step is complex enough to warrant its own task breakdown, link a writing-plans doc from the step.
One markdown file per feature. YAML frontmatter, then a body of steps.
---
plan: sentiment-tracking
created: 2026-04-29
default_repo: entirehq/curitiba-v2 # optional; steps inherit unless they override
last_synced: 2026-04-29T14:30Z # updated by /plan-sync
---
# Sentiment Tracking
**Goal:** Track sentiment across blog posts and surface in admin.
**Architecture:** New column + backfill + API + dashboard chart.
---
## Steps
### Step 1: Add sentiment_score column ✅ shipped
- **Repo:** entirehq/curitiba-v2
- **Branch:** paxos/sentiment-column
- **PR:** [#1750](https://github.com/entirehq/curitiba-v2/pull/1750) (merged 2026-04-26)
- **Depends on:** —
Add nullable `sentiment_score FLOAT` to `blog_posts`. Migration only.
**What shipped:** as planned.
---
### Step 2: Backfill CLI 🚧 in progress
- **Repo:** entirehq/curitiba-v2
- **Branch:** paxos/sentiment-backfill
- **PR:** [#1755](https://github.com/entirehq/curitiba-v2/pull/1755) (open)
- **Depends on:** Step 1
One-off script under `scripts/` that pages posts and calls the sentiment API.
Status (in heading) — required. One of ⏳ pending, 🚧 in progress, ✅ shipped, ❌ abandoned. Both emoji and word: emoji is scannable, word is parseable.
Repo — required. <owner>/<repo> form. Falls back to default_repo from frontmatter if omitted.
Branch — required once a step is started. Used by /plan-sync to infer which step a workspace is on.
PR — required once opened. Markdown link to the PR. Append (merged YYYY-MM-DD) after merge.
Depends on — required. Comma-separated step references, or — for none. Parallelism is implicit: any pending step whose deps are all ✅ is unblocked. Two pending steps with disjoint dependency chains are safe to run in parallel; do not add a redundant "Parallel-safe with" field.
Description — required. One or two paragraphs of intent.
What shipped — optional. Filled by /plan-sync only when the merged PR diverges meaningfully from the planned description; otherwise omitted or as planned.
Plan doc — optional. Link to a superpowers:writing-plans doc if the step is complex enough to warrant one.
/plan-new <name>Guided creation of a new plan. Elicits goal, architecture, and a rough step list (lightweight brainstorming; can leverage superpowers:brainstorming if available, but does not require it). Writes /Users/pd/Developer/claude/plans/<name>.md using the format above.
Does NOT auto-commit. Stages the new file (git add) and shows the diff. The user's CLAUDE.md requires explicit approval for every commit, so the command ends with: "Plan staged. Run git commit when ready."
/plan <name>Resume / load a plan into the current session. Reads the plan, dumps the full content into context, computes the next unfinished step (first ⏳ pending whose Depends on is all ✅; lists all if multiple are unblocked), and closes with: "Next up: Step N — <title>. Want me to start it?"
If <name> is ambiguous, fuzzy-match. If no match, list available plans.
/plan-sync [<name>]Refresh status from GitHub.
If <name> is omitted, infer from the current workspace's branch name by scanning plans for a matching Branch: field.
For each step with a PR field, run gh pr view <num> --repo <repo> --json state,mergedAt,title,body,closedAt. Map OPEN → 🚧 in progress, MERGED → ✅ shipped (append merge date), CLOSED (not merged) → ❌ abandoned.
For newly-shipped steps, read PR title + body, compare to the planned step description. Heuristic: propose a one-line **What shipped:** note only if there's a clear difference (planned sub-task dropped, different approach taken, scope expanded). Otherwise write as planned. Never invent divergence — when in doubt, leave as planned and let the user edit manually.
Update last_synced in frontmatter.
Does NOT auto-commit. Stages changes (git add) and shows the diff. End with a one-line summary: "Step 2 shipped (PR #1755 merged). Next unblocked: Step 3. Run git commit when ready."
When a working session has just run gh pr create and the workspace's branch matches a Branch: field in some plan, end the turn with:
"Want me to update plan
<name>with this PR?"
If the user confirms, run /plan-sync for that plan. No hooks, no background sync, no other auto-triggers. The user can always invoke /plan-sync manually.
paxos-planning:multi-pr-planning → feature-scope (multiple PRs)
↓ (each step is the seed for…)
superpowers:writing-plans → PR-scope (one feature, many tasks) — optional, only when step is complex
↓ (executed via…)
superpowers:executing-plans / subagent-driven-development → session-scope
Each layer is opt-in. A simple step does not need its own writing-plans doc; a complex one creates one and the plan-step links to it.
Never commit without explicit approval. This skill and the /plan-* commands stage changes only. The user's CLAUDE.md is explicit: every commit needs in-the-moment approval, even on the plans repo. Show the diff, ask, wait.
Never push. Plans are local-only by default. The user can git remote add later if they want backups; pushing is out of scope.
Never invent divergence in /plan-sync. If you cannot articulate a clear difference between planned and shipped, write as planned. The plan is more useful when the diffs it reports are real.
Plan files are personal working artifacts, not collaboration tools. Teammates read PRs; this skill is for the operator.
plans/ as historical record. No archive directory yet.external_deps frontmatter field./plan-sync from two workspaces. Git handles non-overlapping edits; conflicts in the same step must be resolved manually. Acceptable risk for a personal tool.❌ abandoned. Revisit if the user often closes-and-reopens.Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub paxos/claude --plugin paxos-planning