a-green-hand-jack/project-pivot-planner

Project Pivot Planner

Decide what to do when the original research direction is not working. This skill is for mid-project decisions — after enough evidence exists to rule out engineering bugs and still the core claim is not holding.

Use this skill when:

• multiple experiments consistently fail to support the core claim despite fixing engineering bugs
• an adversarial reviewer successfully argues that the main contribution is not novel
• the primary baseline unexpectedly closes the gap to the proposed method
• a related work publication makes the original contribution redundant
• advisor/committee feedback consistently questions the project's direction
• the project has been in result-diagnosis for more than 2–3 cycles without resolution

Do not use this skill for per-experiment debugging — use experiment-debugger. Do not use this skill when the issue is a specific surprising result — use result-diagnosis. Do not use this skill for new project validation — use research-idea-validator.

Pair this skill with:

• research-idea-validator when a pivot produces a substantially new research direction that needs fresh validation
• result-diagnosis to confirm the pattern of failures that triggers a pivot decision
• research-project-memory to record pivot decisions and update phase dashboard, claims, and actions
• paper-positioning-planner when a pivot changes the paper's primary contribution or archetype
• experiment-design-planner when the pivot requires a new experiment plan

Skill Directory Layout

<installed-skill-dir>/
├── SKILL.md

Core Principles

• A pivot decision requires evidence, not just frustration. Distinguish engineering failures from scientific failures.
• Narrow before killing: most failed ML projects have a defensible narrower claim.
• The cost of staying on a dead direction is often higher than the cost of pivoting.
• A pivot should be made once with full information, not incrementally under pressure.
• Document the pivot decision with the evidence that drove it — this protects the project in future advisor meetings and rebuttals.
• A kill decision is a valid research outcome when it is evidence-based and documented.

Step 1 — Gather Evidence of Failure

Read:

• memory/claim-board.md: which claims are challenged, weakened, or unresolved
• memory/risk-board.md: open high-severity risks
• memory/action-board.md: repeated failed actions
• memory/evidence-board.md: evidence that contradicts or fails to support main claims
• recent experiment reports in docs/reports/ or code/docs/reports/
• result-diagnosis outputs when available

Summarize:

• how many experiments have been run on the main claim
• what the strongest result is and how far it is from the claimed contribution
• whether the failure pattern is consistent (same direction) or noisy (sometimes works)
• whether advisor/reviewer feedback explicitly challenges the core direction

Step 2 — Classify the Failure Pattern

Choose one primary pattern:

• insufficient-gap: method works, but the performance gap over baselines is too small to be a contribution
• claim-not-supported: the method does not actually do what the paper claims (mechanistically or empirically)
• novelty-challenged: the contribution exists but is not novel enough for the target venue
• baseline-closed: a baseline or related work published during the project closes the original gap
• method-failure: the method does not work reliably under realistic conditions
• scope-too-broad: the original scope is too ambitious but a subset would work

Record the evidence for this classification.

Step 3 — Evaluate Pivot Options

For each of the following options, record whether it is viable given the current evidence:

Option A: Narrow the Claim

Reduce the scope to a setting, dataset, regime, or sub-problem where the method reliably works.

• What is the narrowest defensible claim?
• Is the narrowed claim still publishable at the target venue?
• What additional experiments (if any) are needed to support the narrowed claim?

Option B: Change the Angle

Reframe the contribution as a different kind of claim: change from performance to insight, from method to analysis, or from empirical to negative result.

• What story does the existing evidence support?
• Does the angle change require a new paper archetype?
• What is the cost in writing and repositioning?

Option C: Pivot to a New Direction

Use existing infrastructure (code, data, baselines) for a related but different research question.

• What new question can the existing assets answer?
• Does the new direction need fresh idea validation?
• What is the timeline cost of switching?

Option D: Kill the Project

Stop active development and document findings as a negative result or technical report.

• Is there a publishable negative result (methodologically sound null result with clear implications)?
• What assets can be reused in future work?
• What should be documented for the team or for future reference?

Step 4 — Make the Pivot Decision

Recommend one option with a rationale. The recommendation should include:

• the chosen option (narrow / angle / new direction / kill)
• the evidence that drove this choice
• the new primary claim (or statement that no publishable claim is available)
• what stops (experiments, writing tasks, compute) after this decision
• what starts next (experiments, repositioning, new paper contract)
• a target venue reassessment if the archetype or scope changes

Step 5 — Update Project Memory

After the pivot decision is made:

• Update memory/claim-board.md: mark old claims as pivoted, add new narrowed claims
• Update memory/phase-dashboard.md: update current phase and milestone
• Update memory/decision-log.md: record the pivot decision with evidence and rationale
• Update memory/action-board.md: close actions that are no longer relevant, add new actions
• Update memory/risk-board.md: resolve risks that are no longer active, add pivot-triggered risks
• Update research-project-memory if used: update the project direction and phase

Route to:

• paper-positioning-planner: if angle or archetype changes
• experiment-design-planner: if new experiments are needed for the narrowed claim
• research-idea-validator: if pivoting to a substantially new direction

Final Sanity Check

Before finalizing:

• the failure pattern is documented with specific evidence, not just impressions
• all four pivot options were evaluated (not just the preferred one)
• the chosen option has a specific new primary claim or a kill decision
• memory updates cover claims, decisions, actions, and phase dashboard
• next steps are concrete and assigned