auto-rolling-roadmap

Files (1)

• SKILL.md

SKILL.md (first lines)

# DietCode Skill: Auto-Rolling Roadmap Checkpoint System

## Skill Purpose

Maintain an evolving `ROADMAP.md` file that acts as the project's living product, architecture, and long-horizon development checkpoint.

This skill exists to prevent code soup, preserve project coherence, and keep long-running development aligned around a clear center of gravity.

The roadmap is not a wishlist.

The roadmap is not a backlog.

The roadmap is not a promise.

The roadmap is the project's steering surface.

It should help humans and agents answer:

* What is this project becoming?
* What matters now?
* What should happen next?
* What should remain deferred?
* What changed recently?
* What risks are accumulating?
* Is the system becoming more coherent or more fragmented?

## Primary Output

This skill must create or update:

```text
ROADMAP.md
```

`ROADMAP.md` is the canonical checkpoint file for long-horizon project steering.

If the file does not exist, create it.

If the file exists, evolve it carefully.

Do not replace useful history with generic text.

Do not append endlessly.

Do not turn the roadmap into a backlog dump.

Each update should make the roadmap more useful, more current, and easier to navigate.

## Prime Directive

Every roadmap pass must answer:

```text
Did the latest work strengthen or weaken the project's center of gravity?
```

If the answer is unclear, the skill must investigate before adding or promoting roadmap items.

A roadmap item that does not connect to the project's center of gravity should remain in Discovery, be reframed, or be archived.

## Definition: Center of Gravity

The project's center of gravity is the smallest set of concepts, workflows, abstractions, and operational paths that explain how the system fundamentally works.

A strong center of gravity means:

* there is one obvious way to perform core operations
* agents can predict where changes belong
* contributors can understand the system without reading everything
* new features attach to existing architecture instead of creating parallel systems
* operational behavior is inspectable
* maintenance burden stays bounded
* long-term development feels navigable

A weak center of gravity means:

* duplicate abstractions appear
* multiple workflows compete
* state ownership becomes unclear
* debugging paths fragment
* agents invent local patterns
* hidden orchestration grows
* roadmap direction becomes disconnected from implementation reality

## Core Philosophy

Centralization does not mean giant files, giant classes, or rigid architecture.

Centralization means clear authority.

Modules may be distributed.

Authority should not be.

The roadmap should continuously protect:

* canonical workflows
* canonical mutation paths
* canonical runtime inspection
* canonical state ownership
* canonical terminology
* canonical architectural intent

The system should feel extensible without becoming incoherent.

## Required Inputs

When invoked, inspect available project context before editing `ROADMAP.md`.

Use any available sources such as:

* existing `ROADMAP.md`
* README files
* architecture docs
* recent commits
* changed files
* tests
* scripts
* issue notes

From CardSorting/HEAV3NS-CODE, Apache-2.0.

More from CardSorting/HEAV3NS-CODE