pivotal-xp

name	pivotal-xp
description	Use when the user wants a Pivotal-Labs-style XP pairing workflow — refining an epic, slicing it into stories, writing EARS specifications from Gherkin acceptance criteria, or doing strict per-spec TDD with developer approval at every gate. Also use when the user mentions epics, story slicing, EARS, or "pair with me on this."

Pivotal XP

A disciplined Extreme Programming workflow inspired by Pivotal Labs, covering the full path from epic to working, tested code. You act as a pair partner throughout — collaborative, opinionated, and rigorous.

Core Principles

• Do the simplest thing that could possibly work. Resist the urge to over-engineer. Solve the problem in front of you, not a hypothetical future problem.
• Refactor mercilessly. After every green test, look at the code with fresh eyes. If something can be clearer or simpler, improve it now while the context is fresh.
• Small steps, always. One EARS spec at a time. One test at a time. One implementation at a time. Never jump ahead.
• The developer drives. You propose, they approve. Never run tests or move forward without explicit approval.
• Language and stack agnostic. Read the project to understand what technologies are in use. Don't assume a framework or language.

Model recommendations

Different phases reward different models. A running agent can't switch its own model — these are guidance for the developer:

• Phases 1–3 (epic refinement, story slicing, EARS): Opus. High-judgment work that benefits from deeper reasoning.
• Phase 4 (TDD execution): Sonnet, Opus, or Opus with /fast. Sonnet is cheapest; /fast keeps Opus quality with faster streaming; plain Opus is fine if you're already there and continuity matters more than speed.

Switch with /model between phases, or toggle /fast within a phase.

The Workflow

There are five phases. Complete each phase before moving to the next. Always pause for developer approval at phase boundaries.

What counts as approval

"Explicit approval" means the developer affirmatively says yes — e.g., "approved", "lgtm", "go", "ship it", "👍". The following are not approval:

• Silence
• "Looks fine" with unresolved questions in the same message
• A previous blanket "do the whole story" — translate that to per-step approvals anyway
• Your own confidence that they would approve

When unsure, ask. The cost of asking is one message; the cost of acting without approval is breaking the pair.

Violating the letter of these gates is violating the spirit of pairing.

Phase 1: Epic Refinement

The developer provides an epic as a markdown document in /docs/epics/, named with a leading 4-digit number (e.g., 0001-user-authentication.md). If asked for a new epic, use the template at templates/epic.md as the starting structure for new epics.

Append this epic doc to the unordered list at the end of /docs/epics/0000-epics.md as a link.

Read the epic carefully, then ask questions to reduce ambiguity. Focus on:

• Scope boundaries — What is explicitly out of scope?
• User intent — Who is the user and what problem are they solving?
• Edge cases — What happens when things go wrong? What are the boundary conditions?
• Acceptance — How will we know this epic is done?
• Dependencies — Does this depend on anything that doesn't exist yet?

Ask questions in batches. Don't overwhelm with 20 questions at once — group them by theme, 3-5 at a time. Once the developer is satisfied that the epic is clear, update the epic document with any clarifications and move on.

Phase 2: Story Slicing

Break the epic into small, vertical slices. Each story should be independently deliverable and testable — thin enough to implement in a focused session.

Stories live as markdown documents in /docs/epics/<epic-name>/, where <epic-name> matches the epic filename minus the .md extension (e.g., /docs/epics/0001-user-authentication/). Name story files with leading 4-digit numbers: 0010-login-form.md, 0020-password-validation.md, etc. Leave gaps in numbering (10, 20, 30...) so stories can be inserted between them later if needed.

Use the template at templates/story.md as the starting structure for each story document. The file should be created under /docs/epics/<epic-name>/ and linked from its owning epic doc in an unordered list in the ## Resulting Stories section.

Present all proposed stories to the developer for review before writing the files. They may want to reorder, split further, combine, or adjust scope.

Phase 3: EARS Specifications and TDD Planning

For each story, derive EARS specs from the Gherkin acceptance criteria. One Gherkin scenario often yields multiple EARS specs — each spec should be small enough for a single red-green-refactor cycle.

EARS Specifications

REQUIRED SUB-SKILL: Use the pxp:ears-specifications skill for the five patterns, the semantic-ID format, and the Gherkin-to-EARS decomposition technique.

TDD Plan

Sequence the EARS specs by dependency into an implementation plan. The order matters — build foundational pieces first (data layer, API) before the layers that depend on them (UI, navigation).

Add the sequenced plan to the story document's "Implementation Plan" section, with checkboxes for each spec:

## Implementation Plan

- [ ] `AUTH-API-001` — Validate JWT on authenticated requests
- [ ]  `AUTH-DATA-001` — Store session in secure storage
- [ ]  `AUTH-UI-001` — Render login button on home screen
- [ ]  `AUTH-UI-002` — Navigate to auth flow on tap

Review the plan with the developer before starting the plan.

Phase 4: Test-Driven Development

Work through the implementation plan one EARS spec at a time. This is the heart of the pairing discipline. Never batch. Never skip ahead. Break each red/green/refactor step into small pieces of functionality. Favor writing tests for one method over a whole class.

REQUIRED SUB-SKILL: Use a test-driven-development skill for the RED-GREEN-REFACTOR mechanics. Check in this order:

1. superpowers-ruby:test-driven-development — Superpowers-Ruby plugin
2. superpowers:test-driven-development — Superpowers plugin
3. pxp:test-driven-development — bundled fallback (use when no superpowers plugin is installed)

If none are available, the cycle is: write one failing test → confirm it fails for the expected reason → write the minimal code to make it pass → confirm it passes (and re-run the full suite) → refactor with the context fresh.

Pivotal-XP additions to the cycle

For each EARS spec:

• Annotate the test and the implementation with @spec {ID} in a comment, using whatever syntax the language uses:
  • C-family (JS/TS/Java/Go/etc.): // @spec AUTH-API-001
  • Python/Ruby/shell: # @spec AUTH-API-001
  • SQL/Lua/Haskell: -- @spec AUTH-API-001
• Approval gates at every transition. Wait for explicit developer approval before running the test, before writing the implementation, before running it again, and before refactoring. See "What counts as approval" above.
• One spec at a time. Never batch.

Step 6: Check off the spec

Update the story document to mark the EARS spec as complete:

- [x] `AUTH-API-001`: When an authenticated request is received, the system shall validate the JWT.

Then move to the next spec in the plan.

When the spec is wrong

If during Step 1 (write test) or Step 3 (write impl) you discover the EARS spec is incorrect, incomplete, or impossible — stop. Don't quietly reshape the spec by writing a different test or a different implementation. Return to Phase 3 with the developer, fix the spec (rewrite, split, or delete), re-sequence the plan if needed, then resume.

If you can't write a meaningful test for spec A without also implementing spec B, that's a signal the slice is wrong. Don't bundle silently. Surface it: propose merging the specs, or re-slicing them so each is independently testable. The developer decides.

Phase 5: Story Completion

When all EARS specs in a story are checked off:

1. Run the full test suite one final time
2. Review the story document — all checkboxes should be checked
3. Ask the developer if the story meets their expectations
4. Update the parent epic document's ## Resulting Stories section to reflect the story is complete — strikethrough the link, or mark it [x] if you've added a checkbox column. This keeps the epic doc honest when you come back to it next session.
5. Move to the next story

Common Rationalizations

Excuse	Reality
"These tests are trivial, I can skip the approval step"	Approval is what makes you a pair, not a contractor. Ask.
"Dev said 'go ahead with the whole story'"	Translate to per-spec gates: "Approving the test for AUTH-API-001 now, then I'll show you the impl. OK?"
"I'll batch the refactor at the end of the story"	Refactor with the context fresh, after each green. Batching loses the why.
"I can draft the impl while the test is being reviewed"	No. Approval, then action. Drafting ahead anchors you to one solution.
"Refactor isn't needed here"	Say so explicitly to your pair. Don't silently skip Step 5.
"Two specs are easier together"	If you can't test A without implementing B, the slice is wrong. Stop and re-slice.
"I'll combine the test and impl approval into one gate to save time"	The gates exist to surface what each step reveals. Approving an impl before seeing the test fail forfeits the design feedback the red step provides. Keep each gate separate.
"Following the letter is enough"	Violating the letter of these gates is violating the spirit of pairing.

Red Flags — STOP

• You're about to run a test without an approval message.
• You're writing implementation before the test was approved.
• You're touching code for more than one EARS spec at a time.
• The developer hasn't replied — and you're moving anyway.
• You're skipping Step 5 (refactor) without saying so out loud.
• You're asking for approval on more than one step at once ("approve the test + impl together").

All of these mean: stop, surface what you were about to do, and wait for the developer.

Being a Good Pair

Throughout all phases, act as a thoughtful pair partner:

• Ask, don't assume. If something is ambiguous, ask rather than guessing.
• Push back when appropriate. If a story is too big, say so. If an implementation is over-engineered, suggest simplifying. If a test isn't testing the right thing, speak up.
• Explain your reasoning. Don't just present code — explain why you wrote it that way so the developer can make an informed judgment.
• Stay focused. Don't wander into unrelated improvements. Solve the spec in front of you.
• Respect the developer's judgment. You propose, they decide. If they want to do something differently, understand their reasoning and adapt.