gpd-revise-phase

Supersede a completed research phase and create a decimal-numbered replacement with inherited context.

Updated Mar 18, 2026
One-click install
npx skills add https://github.com/MichaelsEngineering/sentinel-multiscale-field-dynamics --skill gpd-revise-phase-michaelsengineering
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: gpd-revise-phase
Source: https://github.com/MichaelsEngineering/sentinel-multiscale-field-dynamics/tree/main/.agents/skills/gpd-revise-phase
Command: npx skills add https://github.com/MichaelsEngineering/sentinel-multiscale-field-dynamics --skill gpd-revise-phase-michaelsengineering

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Research projects are non-linear: a completed phase may later turn out to contain flawed assumptions, sign errors, or invalidated results. This Skill lets you formally supersede a finished phase without deleting its history, while creating a replacement phase that carries forward what is still valid. ## Core Features & Use Cases - Supersession with history preserved: Marks the original phase as superseded in ROADMAP.md and writes a SUPERSEDED.md record instead of deleting artifacts. - Replacement phase creation: Creates a decimal-numbered phase (e.g., 3.1) pre-populated with a CONTEXT.md describing what worked, what failed, and what to change. - Downstream dependency management: Greps for references to the superseded phase, updates dependency pointers, and flags phases that may also need revision. - Use Case: After referee feedback invalidates a derivation in Phase 3, run the revision workflow to mark Phase 3 superseded, create Phase 3.1 with inherited decisions, and commit the change as a historical record. ## Quick Start Ask the AI to revise phase 3 with the reason "Sign error in vertex correction propagated to all subsequent phases" using the gpd-revise-phase workflow.

Frequently Asked Questions about gpd-revise-phase

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I revise a completed research phase without losing history?▼

Run the revise-phase workflow with the phase number and a reason. It marks the original phase as superseded in ROADMAP.md, adds a SUPERSEDED.md record, and creates a decimal-numbered replacement phase while keeping all original artifacts intact.

How are replacement phases numbered when revising a phase?▼

Replacement phases use decimal numbering: revising Phase 3 creates Phase 3.1, and subsequent revisions create 3.2, 3.3, and so on. Existing phases are never renumbered.

Can I revise a phase that has not been completed yet?▼

No. Revision only applies to completed phases with executed plans. For future unstarted phases, use the remove-phase or plan-phase commands instead, since there are no results to supersede.

What happens to downstream phases that depend on a superseded phase?▼

The workflow searches phase directories and ROADMAP.md for references to the superseded phase, updates dependency pointers to the replacement, and warns about completed downstream phases that may also need revision due to invalidated results.

Why does the workflow use the gpd runtime CLI instead of editing STATE.md directly?▼

State changes go through gpd state commands so STATE.md and state.json stay synchronized. Direct edits to STATE.md would break that sync, so decisions, blockers, and activity updates are recorded via the CLI.