backlog

Files (1)

• SKILL.md

SKILL.md (first lines)

# /backlog

Manage the **rpm backlog** — persisted at `docs/rpm/future/tasks.org`.
All operations read and write this file using org-mode format.

## Project Amendments

At the start of every invocation, check whether
`docs/rpm/skills/backlog.md` exists in the consuming project. If it
does, read it and apply its contents as additional project-specific
instructions for this skill. Amendments may add band orderings,
extra parent groups, or custom triage rules. They cannot remove or
override plugin defaults — on conflict, this SKILL.md wins.

The backlog is sorted in **execution order** (top-to-bottom = the
order in which tasks need to get done). "Take from the top" is the
expected read pattern.

Within each `* Parent` group, keep this band order top-to-bottom:

1. **Actionable** — `** IN-PROGRESS` or `** TODO` with all
   `:BLOCKED_BY:` deps DONE
2. **Blocked** — `** BLOCKED`, or `** TODO` with unresolved
   `:BLOCKED_BY:`
3. **Postponed** — `** TODO` with a `:POSTPONED:` stamp

Closed entries (`** DONE` / `** CANCELLED`) are archived to
`docs/rpm/future/done.org` by `/session-end` and do not live in
tasks.org long-term. `/backlog done` toggles `TODO → DONE` in place;
the archive sweep runs at the next session-end.

Blocked and postponed items drift to the bottom of their band
automatically whenever this file is written (during `add`,
`postpone`, `review`, or session-end Phase 3b). Moves are mechanical
— no user question. Preserve relative order within each band.
New `add` entries land at the bottom of the **actionable band**
(not the absolute bottom); user promotes upward explicitly if
something needs to happen sooner.

**Pivot capture (automatic, no user question).** When the user
redirects mid-session to new multi-step work that meets the
`TaskCreate` bar, the LLM must insert a `** TODO` at the **top** of
the actionable band AND update `docs/rpm/~rpm-session-start` to set
the `task:` field to the new work. The ask IS the confirmation —
don't prompt. Skip for tactical single-step follow-ups. Rationale:
the backlog should always represent current state, so a dropped
session (without `/session-end`) still hands off accurately. Full
rule lives in `plugin/hooks/_directives.sh`.

## Routing

Parse `$ARGUMENTS`:

- `add <description>` → **Add** below
- `list` → **List** below
- `review` → **Review** below
- `postpone <task text or number>` → **Postpone** below
- `done <task text or number>` → **Done** below
- empty or natural language → infer intent from context. If unclear,
  show usage:

  ```
  /backlog add <description>   — add a backlog entry
  /backlog list                — show all entries with statuses
  /backlog review              — evaluate and reorganize
  /backlog postpone <task>     — defer to the bottom of its group
  /backlog done <task>         — mark an entry complete
  ```

---

## Add

**Do NOT call `TaskCreate` for backlog additions.** Your rpm backlog
is long-term; native tasks (`TaskCreate`/`TaskList`) are reserved for
work actually happening *this session*. Adding to your rpm backlog
without a mirrored native task is the correct, intended behavior.

**3 body lines max per entry, plus the org `:PROPERTIES:` drawer.**
The drawer is its own thing — it doesn't count toward the body
budget. Body content (heading + any inline notes) caps at 3 lines;
default is just the heading.

Standard shape:

```
** TODO <description> [[file:YYYY-MM-DD-slug.md]]
   :PROPERTIES:
   :ID: <slug>
   :END:
```

Add `:BLOCKED_BY: <other-slug>` inside the drawer when there's a
dependency. Add up to 2 inline body lines (under the drawer) only
when something can't reasonably live in the detail file — most of
the time the detail file is the right home for everything beyond
the heading.

What does **not** belong inline in tasks.org:
- Bullet lists describing the task
- Prose explaining "why", "how", or "defer until"
- Implementation notes, links to related files, status commentary

All of that goes in the detail file at
`docs/rpm/future/YYYY-MM-DD-slug.md` — never as 5+ lines of body
under the heading. Subagents dispatched by `/next` actionable-
backlog read the detail file, so information isn't lost — it's
just not in the line-scannable index. Multi-line entries turn
the backlog into prose-reading and break the SessionStart menu
+ `/next` priority scan, both of which need "topmost unblocked"
to fit a glance.

1. Read `docs/rpm/future/tasks.org` to see existing parent headings
   and task structure.
2. Determine the parent heading:
   - If an existing heading fits, suggest it (or ask when ambiguous).
   - If none fits, **create a new `* Parent` group**. When the new
     group names a coherent objective (a deliverable, capability, or
     area of work with a demonstrable done-state), **propose a

From dppdppd/rpm, MIT.

More from dppdppd/rpm