---
name: gpd-remove-phase
description: Remove a future research phase from roadmap and renumber subsequent phases
allowed-tools:
  - read_file
  - write_file
  - shell
  - glob
---
<codex_runtime_notes>
Rust-only repository execution:
- Keep user-facing command names canonical in prose: `gpd ...` for a normal terminal and `$gpd-...` for Codex commands.
- Do not invoke Python, legacy private interpreter bridges, Python package managers/test runners, notebooks, or `.py` helper scripts from this skill in this repository.
- Prefer Rust-native commands: `cargo run --quiet --manifest-path rust/cclab_accel/Cargo.toml --bin cclab -- skill <supported-helper> ...`, `make test TEST_FILTER=<rust_test_name>`, and direct Markdown/JSON edits.
- If a legacy included snippet requires GPD automation that is not yet available in Rust, implement or extend a Rust helper first; otherwise perform the bounded file/state edit directly and record the limitation.
</codex_runtime_notes>



<!-- Managed by Get Physics Done (GPD). -->
## Command Requirements

Command YAML rules. Use this YAML. Closed schema; no extra keys. Strict booleans only. Empty optional fields may be omitted. `command_policy` when present is the typed additive command-policy wrapper; its canonical frontmatter key is `command-policy`; `command_policy.schema_version` must be the integer `1`; `command_policy.subject_policy.explicit_input_kinds`, `command_policy.subject_policy.allowed_suffixes`, `command_policy.subject_policy.supported_roots`, `command_policy.supporting_context_policy.required_file_patterns`, and `command_policy.supporting_context_policy.optional_file_patterns` are lists of strings when present; `command_policy.supporting_context_policy.project_context_mode` and `context_mode` must be `global` or `projectless` or `project-aware` or `project-required` when present; `command_policy.subject_policy.allowed_suffixes` must use dotted suffixes like `.tex` or `.md` when present; Typed command policy is runtime-authoritative for command intake, supporting-context routing, and managed-output surfaces when a command declares it. `allowed_tools` is a list of tool names when present; `requires` is a closed mapping when present; only `files` is supported. `requires.files` is a string or list of strings. `agent` when present must be one of `gpd-bibliographer` or `gpd-check-proof` or `gpd-consistency-checker` or `gpd-debugger` or `gpd-executor` or `gpd-experiment-designer` or `gpd-explainer` or `gpd-literature-reviewer` or `gpd-notation-coordinator` or `gpd-paper-writer` or `gpd-phase-researcher` or `gpd-plan-checker` or `gpd-planner` or `gpd-project-researcher` or `gpd-referee` or `gpd-research-mapper` or `gpd-research-synthesizer` or `gpd-review-literature` or `gpd-review-math` or `gpd-review-physics` or `gpd-review-reader` or `gpd-review-significance` or `gpd-roadmapper` or `gpd-verifier`; `project_reentry_capable` must be `true` or `false` and may be `true` only when `context_mode` is `project-required`. Any user-visible completion, checkpoint, blocked return, failed return, retry gate, or stop that expects later action must end with a concrete `## > Next Up` or `## >> Next Up` section. Include copy-pasteable GPD commands when they exist and `$gpd-suggest-next` for project-backed recovery.

```yaml
context_mode: project-required
project_reentry_capable: false
allowed_tools:
- read_file
- write_file
- shell
- glob
command_policy:
  schema_version: 1
  supporting_context_policy:
    project_context_mode: project-required
    project_reentry_mode: disallowed
```

<objective>
Remove an unstarted future phase from the roadmap and renumber all subsequent phases to maintain a clean, linear sequence.

Purpose: Clean removal of research work you have decided not to pursue, without polluting context with cancelled/deferred markers. Common reasons include:

- A calculation turned out to be analytically tractable, eliminating the need for a planned numerical phase
- A validation step became redundant after finding an exact solution
- Scope reduction after realizing a particular physical regime is outside the problem domain
- Consolidation of multiple small phases into a single phase

Output: Phase deleted, all subsequent phases renumbered, gpd commit as historical record.
</objective>

<execution_context>

<!-- [included: remove-phase.md] -->
<purpose>
Remove an unstarted future phase from the project roadmap, delete its directory, renumber all subsequent phases to maintain a clean linear sequence, and commit the change. The commit serves as the historical record of removal.
</purpose>

<required_reading>
Read all files referenced by the invoking prompt's execution_context before starting.
</required_reading>

<process>

<step name="parse_arguments">
Parse the command arguments:
- Argument is the phase number to remove (integer or decimal)
- Example: `$gpd-remove-phase 17` -> phase = 17
- Example: `$gpd-remove-phase 16.1` -> phase = 16.1

If no argument provided:

```
ERROR: Phase number required
Usage: $gpd-remove-phase <phase-number>
Example: $gpd-remove-phase 17
```

Exit.
</step>

<step name="init_context">
Load phase operation context:

```bash
INIT=$(cargo run --quiet --manifest-path rust/cclab_accel/Cargo.toml --bin cclab -- skill --raw init phase-op "${target}")
if [ $? -ne 0 ]; then
  echo "ERROR: gpd initialization failed: $INIT"
  # STOP — display the error to the user and do not proceed.
fi
```

Extract: `phase_found`, `phase_dir`, `phase_number`, `commit_docs`, `roadmap_exists`.

**If `phase_found` is false:**

```
ERROR: Phase not found: ${target}

Available phases:
$(gpd phase list)

Usage: $gpd-remove-phase <phase-number>
```

Exit.

Also read STATE.md and ROADMAP.md content for parsing current position.
</step>

<step name="validate_future_phase">
Verify the phase is a future phase (not started):

1. Compare target phase to current phase from STATE.md
2. Target must be > current phase number

If target <= current phase:

```
ERROR: Cannot remove Phase {target}

Only future phases can be removed:
- Current phase: {current}
- Phase {target} is current or completed

To abandon current work, use $gpd-pause-work instead.
```

Exit.
</step>

<step name="confirm_removal">
Present removal summary and confirm:

```
Removing Phase {target}: {Name}

This will:
- Delete: GPD/phases/{target}-{slug}/
- Renumber all subsequent phases
- Update: ROADMAP.md, STATE.md, checkpoint shelf artifacts

Proceed? (y/n)
```

Wait for confirmation.
</step>

<step name="execute_removal">
**Delegate the entire removal operation to gpd CLI:**

```bash
RESULT=$(cargo run --quiet --manifest-path rust/cclab_accel/Cargo.toml --bin cclab -- skill phase remove "${target}")
if [ $? -ne 0 ]; then
  echo "Phase removal blocked: $RESULT"
fi
```

If the phase has executed plans (SUMMARY.md files), gpd will error. Use `--force` only if the user confirms:

```bash
RESULT=$(cargo run --quiet --manifest-path rust/cclab_accel/Cargo.toml --bin cclab -- skill phase remove "${target}" --force)
```

The CLI handles:

- Deleting the phase directory
- Renumbering all subsequent directories (in reverse order to avoid conflicts)
- Renaming all files inside renumbered directories (PLAN.md, SUMMARY.md, etc.)
- Updating ROADMAP.md (removing section, renumbering all phase references, updating dependencies)
- Updating STATE.md (decrementing phase count)
- Regenerating `GPD/CHECKPOINTS.md` and `GPD/phase-checkpoints/*.md`

Extract from result: `removed`, `directory_deleted`, `renamed_directories`, `renamed_files`, `roadmap_updated`, `state_updated`.
</step>

<step name="commit">
Stage and commit the removal:

```bash
PRE_CHECK=$(cargo run --quiet --manifest-path rust/cclab_accel/Cargo.toml --bin cclab -- skill pre-commit-check --files GPD/ROADMAP.md GPD/STATE.md GPD/state.json GPD/CHECKPOINTS.md GPD/phase-checkpoints 2>&1) || true
echo "$PRE_CHECK"

cargo run --quiet --manifest-path rust/cclab_accel/Cargo.toml --bin cclab -- skill commit "chore: remove phase {target} ({original-phase-name})" \
  --files GPD/phases/ GPD/ROADMAP.md GPD/STATE.md GPD/state.json GPD/CHECKPOINTS.md GPD/phase-checkpoints
```

The commit message preserves the historical record of what was removed.
</step>

<step name="completion">
Present completion summary:

```
Phase {target} ({original-name}) removed.

Changes:
- Deleted: GPD/phases/{target}-{slug}/
- Renumbered: {N} directories and {M} files
- Updated: ROADMAP.md, STATE.md, checkpoint shelf artifacts
- Committed: chore: remove phase {target} ({original-name})

---

## What's Next

Would you like to:
- `$gpd-progress` -- see updated roadmap status
- Continue with current phase
- Review roadmap

---
```

</step>

</process>

<anti_patterns>

- Don't remove completed phases (have SUMMARY.md files) without --force
- Don't remove current or past phases
- Don't manually renumber -- use `gpd phase remove` which handles all renumbering
- Don't add "removed phase" notes to STATE.md -- the commit is the record
- Don't modify completed phase directories

</anti_patterns>

<success_criteria>
Phase removal is complete when:

- [ ] Target phase validated as future/unstarted
- [ ] `gpd phase remove` executed successfully
- [ ] `GPD/CHECKPOINTS.md` and `GPD/phase-checkpoints/*.md` resynced
- [ ] Changes committed with descriptive message
- [ ] User informed of changes

</success_criteria>

<!-- [end included] -->

</execution_context>

<context>
Phase: $ARGUMENTS

@GPD/ROADMAP.md
@GPD/STATE.md
</context>

<process>
This wrapper runs the remove-phase workflow directly. Any stopping points come from the workflow's own validation gates.

Execute the included remove-phase workflow end-to-end.
Preserve all validation gates (future phase check, work check), renumbering logic, and commit.
</process>

## Scientific Rigor Guardrails

- Use scientific skepticism and critical thinking by default: look for contradictions, missing anchors, overclaims, and failure modes before endorsing a result.
- Stress-test claims, including the user's preferred interpretation and your own first impression, without framing the user as an opponent.
- Agreement is not evidence. Do not mirror a preferred conclusion or a document's self-description unless the supporting evidence is actually present.
- Ground claims in inspected artifacts, cited sources, executed checks, or explicitly labeled background knowledge.
- If information or artifacts cannot be found, produced, read, verified, or reproduced, report that plainly and keep the status missing, failed, blocked, or inconclusive.
- Never fabricate references, numbers, derivations, files, figures, tables, logs, summaries, proofs, or claimed task completion. Do not use ungrounded fallback content as a substitute for missing evidence or failed execution.
- When certainty is not warranted, narrow the claim, lower confidence, and name the weakest anchor or disconfirming check still needed.