Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,38 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0

## [Unreleased]

### Changed
- **`/make-no-mistakes:prioritize` is now workspace-agnostic.** Drops four hard
couplings from the original dogfood design while preserving full backward
compatibility with `pillars.<slug>` configs:
- **Scope**: the first positional arg is now optional. Resolution order is
`pillars.<slug>` (legacy) → `projects.<slug>` (agnostic) → Linear MCP
`list_projects` exact-name match → interactive. Two new alternative
scope flags: `--label <name>` and `--filter <query>`.
- **Evidence anchor**: the required PIBER+IDCF sub-spike is now optional via
`--evidence <path-or-issue-id>`. Accepts a Linear issue ID OR a local
markdown path. Without it, evidence-driven MoSCoW rules are skipped and
RICE Confidence defaults to 0.8. Label-driven rules and LLM fallback
continue to work.
- **Vision audit**: auto-discovery at `<codebase>/audits/<pillar>/vision-audit-*.md`
only fires in legacy pillar mode. Agnostic mode requires the explicit
`--audit <path>` flag (no flag → no audit enrichment).
- **Output path**: default is now `./priority-<YYYY-MM-DD>.md` in cwd, with
`~/` expansion when `--out <path>` is provided. Legacy pillar mode keeps
the original `<codebase>/audits/<pillar>/priority-<DATE>.md` default.
- **Snapshot comment artifact**: posted on the `--evidence` Linear issue
when evidence is an issue ID; skipped when evidence is a local file or
absent. Legacy pillar mode continues to post on `pillars.<slug>.spike`.
- **MoSCoW rule split**: scoring rules are now annotated as
*evidence-driven* (skip when no anchor) vs *label-driven* (always fire).
New label-driven rules added for explicit `moscow/{must,should,could,wont}`
labels so that workspaces using MoSCoW labels directly get deterministic
coverage without needing an evidence anchor.

Rationale: the original command was opinionated against a pillar taxonomy
that does not exist in typical Linear workspaces (per Andrés analysis,
2026-06-02). Dogfood configs continue to work unchanged.

## [1.23.0] - 2026-05-29

### Added
Expand Down
259 changes: 172 additions & 87 deletions commands/prioritize.md
Original file line number Diff line number Diff line change
@@ -1,142 +1,227 @@
---
description: Aplica MoSCoW + RICE-adaptado a los issues de un pillar, justificando cada veredicto contra el sub-spike PIBER+IDCF y el vision audit mas reciente. Accepts pillar-slug como $ARGUMENTS.
argument-hint: "<pillar-slug> [--framework <name>] [--no-audit] [--target <description|labels|both>] [--dry-run] [--out <path>] [--issue-ids <ids>]"
description: Applies MoSCoW + RICE-adapted to a scoped set of Linear issues. Workspace-agnostic — optional Linear project, label, or filter scope; optional product-vision evidence anchor; optional vision-audit enrichment. Accepts a scope and flags as $ARGUMENTS.
argument-hint: "[<project-slug>] [--label <name>] [--filter <query>] [--evidence <path-or-issue-id>] [--audit <path>] [--framework <name>] [--no-audit] [--target <description|labels|both>] [--dry-run] [--out <path>] [--issue-ids <ids>] [--codebase <path>]"
priority: 85
---

# /prioritize -- MoSCoW + RICE traceable to product vision
# /prioritize -- MoSCoW + RICE on any Linear backlog slice

Ejecuta priorizacion de issues de un pillar contra su sub-spike PIBER+IDCF, enriquecida por el vision audit mas reciente del pillar cuando existe.
Runs prioritization on a scoped set of Linear issues using **MoSCoW** (bucket
assignment) + **RICE-adapted** (intra-bucket ranking). The command is
workspace-agnostic: it does NOT require a pillar taxonomy, a PIBER+IDCF sub-spike,
or a vision-audit doc. When those signals exist, they enrich Confidence and
citations; when they don't, the run still produces a deterministic snapshot.

## Frameworks base

- **MoSCoW** (bucket assignment): Must / Should / Could / Won't + Unclassified + Decompose-required. Deterministico via reglas del sub-spike (ver `references/scoring-rules.md`).
- **RICE-adaptado** (intra-bucket ranking): `(Reach × Impact × Confidence) / Size`. `Size` usa T-shirt labels en vez de weeks (compatible con convencion `spike-recommend` y regla `no time estimates`).
- **MoSCoW** (bucket assignment): Must / Should / Could / Won't + Unclassified +
Decompose-required. Deterministic via label-driven rules (see
`references/scoring-rules.md`); evidence-driven rules layer on top when an
`--evidence` anchor is provided.
- **RICE-adaptado** (intra-bucket ranking): `(Reach × Impact × Confidence) / Size`.
`Size` uses T-shirt labels instead of weeks (compatible with the
`spike-recommend` convention and the `no time estimates` rule).

v1 implementa solo `moscow-rice`. Otros frameworks (`rice`, `moscow`, `ice`, `wsjf`, `kano`) tienen stubs en `references/frameworks/` y retornan "not yet implemented".
v1 implements only `moscow-rice`. Other frameworks (`rice`, `moscow`, `ice`,
`wsjf`, `kano`) have stubs under `references/frameworks/` and return
"not yet implemented".

## Modo de invocacion
## Modos de invocacion

```bash
# Default: dry-run false, genera report + aplica mutations a description
/make-no-mistakes:prioritize mobile
# 1. No arguments -- interactive: list Linear projects in the workspace and ask.
/make-no-mistakes:prioritize

# Primer sweep, sin audit aunque exista
/make-no-mistakes:prioritize agent --no-audit
# 2. Linear project slug (auto-resolved against linear-setup.json or MCP list).
/make-no-mistakes:prioritize pathways
/make-no-mistakes:prioritize agent --evidence APP-101

# Solo reportar sin mutaciones
/make-no-mistakes:prioritize backend --dry-run
# 3. Label-scoped query (project-less workspaces, or cross-project label work).
/make-no-mistakes:prioritize --label "team/frontend"

# Subset de issues
/make-no-mistakes:prioritize backend --issue-ids APP-123,APP-124
# 4. Arbitrary Linear filter query.
/make-no-mistakes:prioritize --filter "label:Frontend state:Backlog"

# Override output path
/make-no-mistakes:prioritize mobile --out /tmp/priority-mobile.md
```
# 5. Provide evidence anchor (Linear issue ID OR local markdown path).
/make-no-mistakes:prioritize pathways --evidence ./docs/vision/pathways.md
/make-no-mistakes:prioritize --filter "team:CORE" --evidence CORE-42

## Parsing de argumentos
# 6. Provide vision audit enrichment manually.
/make-no-mistakes:prioritize pathways --audit ./audits/pathways/vision-audit-latest.md

1. **Primer argumento** (`<pillar-slug>`) -- requerido:
- Debe matchear una clave en `linear-setup.json` -> `pillars.<slug>`.
- Si no existe, entrar a modo interactivo (ver "Modo sin config" mas abajo).
# 7. Dry-run + custom output path (default is ./priority-<DATE>.md in cwd).
/make-no-mistakes:prioritize --label "team/mobile" --dry-run --out /tmp/mobile-prio.md

2. **Flags**:
# 8. Subset of issues.
/make-no-mistakes:prioritize pathways --issue-ids APP-123,APP-124

| Flag | Default | Comportamiento |
|------|---------|----------------|
| `--framework <name>` | `moscow-rice` | v1 solo implementa `moscow-rice`. Otros retornan error claro referenciando el stub. |
| `--no-audit` | off | No cargar vision audit aunque exista. Confidence usa default 0.8. |
| `--codebase <path>` | desde config | Override del codebase resuelto por `pillars.<slug>.codebase`. |
| `--target <mode>` | `description` | `description`, `labels`, o `both`. v1 soporta `description`. `labels`/`both` validan primero que existan. |
| `--dry-run` | off | No tocar Linear. Report titulo = "Proposed mutations (dry-run, not applied)". |
| `--out <path>` | auto | Default: `<codebase>/audits/<pillar>/priority-<YYYY-MM-DD>.md`. Si path empieza con `~/`, expandir. |
| `--issue-ids <ids>` | off | Subset coma-separado. Resto del project queda intacto en el snapshot. |
# 9. Legacy pillar mode (backward-compatible; see "Legacy pillar mode" below).
/make-no-mistakes:prioritize mobile # works if linear-setup.json declares pillars.mobile
```

## Convencion de output (default)
## Parsing de argumentos

El report vive **dentro del repo del pillar**, junto al vision audit:
1. **Primer argumento posicional** (optional): a **scope key**.
- Resolved in this order:
1. If `linear-setup.json` has `pillars.<slug>`, treat as **legacy pillar mode**
and pull project/spike/codebase from there (backward-compat).
2. Else if `linear-setup.json` has `projects.<slug>`, use it as the Linear
project name/id (workspace-agnostic primary path).
3. Else try to match a Linear project by name via
`mcp__linear-server__list_projects`. If exactly one matches, use it.
4. Else error out with the resolved candidate list.
- If omitted **and** no `--label`/`--filter` is set, enter interactive mode
(see "Modo sin argumentos").

2. **Scope flags** (mutually exclusive with positional project arg):

| Flag | Behavior |
|------|----------|
| `--label <name>` | Scope to issues carrying this Linear label (no project required). |
| `--filter <query>` | Pass an arbitrary Linear filter string to `list_issues`. |

3. **Evidence + enrichment flags** (all optional):

| Flag | Default | Behavior |
|------|---------|----------|
| `--evidence <path-or-id>` | none | Linear issue ID (e.g. a PIBER+IDCF sub-spike) OR local markdown path. Used as the rule-citation anchor for MoSCoW + the Confidence anchor for RICE. Without it, MoSCoW falls back to label-only rules and RICE Confidence defaults to 0.8. |
| `--audit <path>` | none | Local vision-audit markdown path. Without it, Confidence stays at 0.8. |
| `--codebase <path>` | cwd or legacy config | Code root used only for resolving `--audit` defaults in legacy mode. |
| `--no-audit` | off | Force-skip audit loading even if discovered. |

4. **Run-control flags**:

| Flag | Default | Behavior |
|------|---------|----------|
| `--framework <name>` | `moscow-rice` | v1 only implements `moscow-rice`. Others error out referencing the stub. |
| `--target <mode>` | `description` | `description`, `labels`, or `both`. v1 supports `description`. `labels`/`both` validate the workspace can apply them. |
| `--dry-run` | off | Do not mutate Linear. Report title becomes "Proposed mutations (dry-run, not applied)". |
| `--out <path>` | `./priority-<YYYY-MM-DD>.md` | Output path. `~/` expanded. In legacy pillar mode the default becomes `<codebase>/audits/<pillar>/priority-<DATE>.md`. |
| `--issue-ids <ids>` | off | Comma-separated subset; the rest of the scope stays untouched in the snapshot. |

```
<codebase-root>/audits/<pillar-slug>/priority-<YYYY-MM-DD>.md
```
## Convencion de output (default)

Coexiste con los snapshots anteriores -- NO se sobreescribe. Git version-controla el historial; `ls -t audits/<pillar>/priority-*.md | head -1` da el mas reciente.
**Workspace-agnostic default**: `./priority-<YYYY-MM-DD>.md` in the current
working directory. Override with `--out <path>` (supports `~/`). If a file with
the same date already exists, the skill appends `-2`, `-3`, etc. — never
overwriting.

## Flujo del comando
**Legacy pillar default** (only when the first positional arg matched
`pillars.<slug>` in `linear-setup.json`): the report still goes to
`<codebase>/audits/<pillar>/priority-<YYYY-MM-DD>.md`, alongside the vision
audit, to preserve dogfood compatibility.

Delega a la skill `prioritize`. La skill se encarga de:
In both cases git version-controls history;
`ls -t priority-*.md | head -1` (or the `audits/<pillar>/` equivalent) gives the
most recent.

1. **Config resolution**: parsear `linear-setup.json` y extraer `pillars.<slug>.{project, spike, codebase}`.
2. **Fetch paralelo**: 3 subagents en background para issues del project, sub-spike IDCF, y vision audit mas reciente.
3. **MoSCoW bucket assignment**: aplicar tabla deterministica de `references/scoring-rules.md`. Fallback a LLM para UNCLASSIFIED (ver `references/prompts/llm-fallback-bucket.md`).
4. **RICE intra-bucket**: cuando un bucket tiene >3 issues, calcular `(R × I × C) / S` por issue y rankear desc.
5. **Composicion de artifacts**:
- Priority report markdown -> `<codebase>/audits/<pillar>/priority-<YYYY-MM-DD>.md`
- Description-footer por issue con delimiters HTML (idempotente) -- solo si `--dry-run=false`.
- Comment snapshot en el sub-spike del pillar -- solo si `--dry-run=false`.
## Flujo del comando

Ver `${CLAUDE_PLUGIN_ROOT}/skills/prioritize/SKILL.md` para detalle.
Delegates to the `prioritize` skill, which:

1. **Scope resolution**: parse args to determine whether to fetch by Linear
project, by label, or by raw filter. Resolve `linear-setup.json` if present
(pillars-first for legacy, projects-next for agnostic), else fall back to MCP.
2. **Fetch paralelo**: subagents in background for (a) issues in scope, plus
(b) the `--evidence` anchor when given (Linear issue OR local file), plus
(c) the `--audit` doc when given (or auto-discovered in legacy mode).
3. **MoSCoW bucket assignment**: apply the deterministic table from
`references/scoring-rules.md`. Evidence-driven rules only fire when evidence
was provided; label-only rules always apply. LLM fallback for UNCLASSIFIED
(see `references/prompts/llm-fallback-bucket.md`).
4. **RICE intra-bucket**: when a bucket has >3 issues, compute
`(R × I × C) / S` per issue and rank desc.
5. **Artifact composition**:
- Priority report markdown -> resolved `--out` path.
- Description footer per issue with idempotent HTML delimiters (only if not
`--dry-run`).
- Snapshot comment on the `--evidence` Linear issue when it IS a Linear issue
(only if not `--dry-run`). When evidence is a local file or absent, this
artifact is skipped — the report is still written.

See `${CLAUDE_PLUGIN_ROOT}/skills/prioritize/SKILL.md` for detail.

## Regla de idioma

Report en **espanol**. Nombres de frameworks (MoSCoW, RICE, PIBER, IDCF) y nombres propios quedan en original.
Report in **espanol**. Framework names (MoSCoW, RICE, PIBER, IDCF) and proper
nouns remain in original casing.

## Regla de evidencia

Cada veredicto en el report cita:
- La regla del sub-spike que matcheo (thesis #, feature tier, anti-pattern).
- El estado en el audit (OK/PARTIAL/MISSING/DRIFT/VIOLATION).
- El breakdown completo de RICE (R, I, C, S) cuando aplique.
Each verdict in the report cites:
- When evidence is provided: the rule from the anchor that matched (thesis #,
feature tier, anti-pattern, capability, etc., as parsed).
- When an audit is provided: the audit status (OK / PARTIAL / MISSING / DRIFT /
VIOLATION).
- The full RICE breakdown (R, I, C, S) when applicable.
- When neither is provided: label-only rationale + a note that this run lacked
product-vision grounding.

Nunca afirmar "Must" sin cita. Nunca afirmar "Won't" sin razon explicita.
Never claim "Must" without a citation — even when the citation is "two
high-priority labels matched". Never claim "Won't" without an explicit reason.

## Modo sin config
## Modo sin argumentos

Si el `pillar-slug` no existe en `linear-setup.json`, preguntar:
If the user invokes `/prioritize` without positional args AND without
`--label`/`--filter`:

1. "Cual es el project Linear del pillar?" (autocompletar con `mcp__linear-server__list_projects`)
2. "Cual es el sub-spike PIBER+IDCF del pillar? (Linear issue ID)"
3. "Cual es el path al codebase del pillar?"
4. "Guardar esta config en `linear-setup.json` para proximas corridas? (yes/no)"
1. List Linear projects in the workspace via `mcp__linear-server__list_projects`
(and pillars from `linear-setup.json` if present).
2. Ask: "Scope this run to a Linear project, a label, or a custom filter?"
3. Proceed once a scope is chosen.

Si yes -> escribir `pillars.<slug>` al archivo. Si no -> proceder una vez, pedir de nuevo el proximo run.
## Modo sin config

## Modo sin argumentos
If `linear-setup.json` does not exist:
- The agnostic path still works — the skill goes straight to
`mcp__linear-server__list_projects` / `list_issues`.
- Offer at the end: "Save the resolved scope to `linear-setup.json` for next
runs? (yes/no)".

Si el usuario invoca `/prioritize` sin args, preguntar:
## Legacy pillar mode

1. "Cual es el pillar a priorizar?" (listar pillars conocidos del `linear-setup.json`)
2. El resto del flow procede como si el arg hubiera sido pasado.
When the positional arg matches `pillars.<slug>` in `linear-setup.json`, the
skill activates legacy behavior:
- Pull `project`, `spike`, `codebase` from `pillars.<slug>`.
- Auto-discover the most recent
`<codebase>/audits/<pillar>/vision-audit-*.md` (unless `--no-audit`).
- Default `--out` becomes `<codebase>/audits/<pillar>/priority-<DATE>.md`.
- Post snapshot comment on the `pillars.<slug>.spike` Linear issue.

## Dog-fooding
This is the original behavior preserved for dogfood configs. New projects
should prefer the agnostic flags.

Este comando fue dogfooded por el autor contra 2 pillars productivos (audits del
2026-04-17), generando un report markdown por pillar en
`<codebase>/audits/<pillar>/priority-<YYYY-MM-DD>.md` y un comment en el
sub-spike correspondiente. Los identificadores concretos viven en notebook
privado del autor.
## Dog-fooding

Los reports complementan los vision audits generados por
`/business-model-toolkit:product-vision-audit` en la misma convencion de path.
Originally dogfooded against 2 production pillars in early 2026 (`mobile`,
`agent`). The agnostic mode was added on top to support workspaces without a
pillar taxonomy. See `CHANGELOG.md` "Workspace-agnostic mode" entry.

## Chain posicion

El comando encaja en la cadena del toolkit:
The command fits the toolkit chain:

```
product-vision-audit -> prioritize -> spike-recommend -> implement
(business-model) (this one) (make-no-mistakes) (make-no-mistakes)
(optional) product-vision-audit -> prioritize -> spike-recommend -> implement
(business-model) (this one) (make-no-mistakes) (make-no-mistakes)
```

Un usuario tipico:
1. Corre `product-vision-audit mobile` -> genera `audits/mobile/vision-audit-2026-04-17.md`.
2. Corre `prioritize mobile` -> genera `audits/mobile/priority-2026-04-21.md` + mutations.
3. Toma el top-3 Must del priority report y corre `spike-recommend APP-XXX` para cada uno -> genera issue-brief bilingual.
4. Corre `implement APP-XXX` -> ejecuta el issue con discipline (worktree, reviewers, CI).
A typical user:
1. Optionally runs `product-vision-audit <scope>` -> generates a vision-audit
markdown.
2. Runs `prioritize <scope> [--evidence ...] [--audit ...]` -> generates
`priority-<DATE>.md` + Linear mutations.
3. Takes the top-3 Must from the report and runs
`spike-recommend <issue-id>` for each.
4. Runs `implement <issue-id>` to execute with discipline (worktree,
reviewers, CI).

## Requisitos

- `mcp__linear-server` configurado y autenticado en el workspace del pillar.
- `linear-setup.json` en la raiz del cwd, con `pillars.<slug>` para el pillar target (o entrar a modo interactivo para crearlo).
- Codebase del pillar debe existir en el path declarado.
- Opcional: vision audit en `<codebase>/audits/<pillar>/vision-audit-*.md` para enriquecer Confidence.
- `mcp__linear-server` configured and authenticated in the target workspace.
- Optional: `linear-setup.json` at cwd root with either `pillars.<slug>`
(legacy) or `projects.<slug>` (agnostic), or neither (the skill resolves via
MCP).
- Optional: an evidence doc (Linear issue or local markdown) for stronger
rule citations.
- Optional: a vision-audit markdown to lift Confidence beyond the 0.8 default.
Loading