l3io-plan

Files (25)

• SKILL.md
• customize.toml
• payload-manifest.json
• ac-dimensions.md · references/
• auto-remediation.md · references/
• calibration-model.md · references/
• config-resolution.md · references/
• metrics-contract.md · references/
• status-files.md · references/
• plan-graph.py · scripts/
• reorg-derive.py · scripts/
• reorg-validate.py · scripts/
• step-lanes.md · steps/lanes/
• step-02-readiness-check.md · steps/plan/
• step-03-story-elaboration.md · steps/plan/
• step-04-load-state.md · steps/plan/
• step-05-dependency-graph.md · steps/plan/
• step-06-plan-output.md · steps/plan/
• step-backlog-intake.md · steps/plan/
• step-reorg-undo.md · steps/reorg/
• step-reorg.md · steps/reorg/
• step-00-activate.md · steps/shared/
• step-00-digest.md · steps/shared/
• step-01-classify-work.md · steps/shared/
• step-estimate.md · steps/shared/

SKILL.md (first lines)

# l3io-plan

Communicate all responses in `{communication_language}`.

## Conventions

- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
- `{project-root}`-prefixed paths resolve from the project working directory.
- Bare paths (e.g. `steps/shared/step-00-activate.md`) resolve from `{skill-root}`.

## On Activation

Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`

If the script fails, resolve the `workflow` block by reading `{skill-root}/customize.toml`, then `{project-root}/_bmad/custom/l3io-plan.toml` (team), then `{project-root}/_bmad/custom/l3io-plan.user.toml` (personal) in order. Scalars override, arrays append.

`setup`, `configure`, and `install` are not recognized arguments here — `/l3io-setup` is the module's setup entry point. Config itself is resolved in step-00-activate per `{skill-root}/references/config-resolution.md`; an absent `modules.l3io-pm` section means the module has no overrides, not that it needs setup.

## Execution

**All modes — load first:**
```
{skill-root}/steps/shared/step-00-activate.md
```

Before reading any further state, apply the once-per-project setup pointer
(`{skill-root}/references/config-resolution.md` §5) — this skill is one of the two skills the
pointer is wired into. It fires only when `{l3io_pm_section_absent}` (bound in step-00-activate
§1, from config already resolved there) is `true` — a configured project gets no pointer at
all:

```bash
if [ "{l3io_pm_section_absent}" = "true" ]; then
  uv run {pm_status} notice --state-root {pm_state_root} --key setup-pointer && \
    echo "l3io-pm currently has no project-level configuration. /l3io-setup configures it if you want to."
fi
```

`notice` is keyed on `--key` alone, not a session — there is no cross-invocation session
identifier available (`{session_id}` is bound fresh per invocation), so this fires **at most
once ever** for this project, not once per invocation. Exit 1 means this key was already
recorded — print nothing further, permanently, for this key. Exit 2 means recording it
actually failed (never conflated with exit 1). Never halt on any branch, and never treat this
as a setup trigger.

```
{skill-root}/steps/shared/step-01-classify-work.md
```

**Mode routing.** Match the argument against this table; everything it does not match is the
full plan mode. Each mode's body lives below or in its own `steps/` file — this file routes
and carries no procedure.

| Keyword | Load | Menu | Notes |
|---|---|---|---|
| `plan` (or no argument) | the full-plan step list below | registered | the default: readiness → elaboration → graph → estimate → snapshot |
| `estimate` | `steps/shared/step-estimate.md` | registered | re-estimate only; optional `E{nnn}` or `E{nnn}-S{nn}` scope |
| `reorg` | `steps/reorg/step-reorg.md` | registered | propose, confirm and apply a better plan shape — writes planned work only |
| `lanes` | `steps/lanes/step-lanes.md` | registered | who owns what when several developers share one plan; inert unless `lane_count` > 1 |

**Undo has no keyword, by design.** A user asks for it in prose — "undo that reorg" — and the
agent resolves which journal entry they mean. Load `steps/reorg/step-reorg-undo.md` on such a
request. There is no flag for it and none of this skill's modes parse one.

**Full plan mode** (default — no args, or args that do not start with `estimate` or `reorg`):

Bind `{scope}` = `all` before loading step-estimate.

```
{skill-root}/steps/plan/step-backlog-intake.md         ← offers backlog → story promotion; never automatic
{skill-root}/steps/plan/step-02-readiness-check.md
{skill-root}/steps/plan/step-03-story-elaboration.md   ← no-op when readiness is green
{skill-root}/steps/plan/step-04-load-state.md
{skill-root}/steps/plan/step-05-dependency-graph.md
{skill-root}/steps/shared/step-estimate.md
{skill-root}/steps/plan/step-06-plan-output.md
```

**Estimate mode** (args start with `estimate`):

Parse scope from arg: `estimate` → `{scope}=all`; `estimate E{nnn}` → `{scope}=E{nnn}`; `estimate E{nnn}-S{nn}` → `{scope}=E{nnn}-S{nn}`. Then load:
```
{skill-root}/steps/shared/step-estimate.md
```
Output estimate summary only. No graph, no elaboration, no plan document.

Estimate mode writes state and **must not touch any plan snapshot** — snapshots are immutable
once written, and `l3io-execute` may be reading one concurrently. Their estimate blocks are a
point-in-time report stamped `estimates_as_of` (see `step-06-plan-output.md` §2); re-estimating
makes that stamp stale, which is the stamp doing its job.

Say so rather than silently leaving a stale report behind. After the summary:

```bash
test -f {planning_artifacts}/plan-output-meta.yaml && \
  grep '^current_plan:' {planning_artifacts}/plan-output-meta.yaml
```

If a pointer exists, print:
```
ℹ️  Estimates updated in state. {current_plan} still shows the estimates from when it was
   generated — run /l3io-plan (full) to produce a snapshot with the new numbers.
   Execution is unaffected: l3io-execute reads estimates from state, not the snapshot.
```

If no pointer exists, print nothing — there is no snapshot to go stale.

**Reorg mode** (arg starts with `reorg`):

```
{skill-root}/steps/reorg/step-reorg.md
```

Proposes one improvement to the shape of the plan, shows it as a plan summary the user can
accept or reject in about a minute, and applies it only on confirmation. It writes **planned
work only**; active and archived work is read-only input. Nothing is deleted — a retired epic
is archived with its reason recorded, and the whole reorg is journaled so it can be undone.

**Undo** (a conversational request, never a flag):

From ravensorb/bmad-extensions, MIT.

More from ravensorb/bmad-extensions