From 57f9907f6b12c788c5b1a1a4e3abe9aac38b0a64 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9s=20Pe=C3=B1a?= Date: Tue, 2 Jun 2026 08:23:16 -0600 Subject: [PATCH] feat(prioritize): make command workspace-agnostic (drop pillar-slug + sub-spike requirements) Drops the four hard couplings of the original dogfood design while preserving full backward compatibility with existing pillars. configs: 1. Scope: first positional arg is now optional. Resolution order is pillars. (legacy) -> projects. (agnostic) -> Linear MCP exact-name match -> interactive. New --label / --filter scope flags. 2. Evidence anchor: optional --evidence flag 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. 3. Vision audit: auto-discovery only fires in legacy pillar mode. Agnostic mode requires explicit --audit . 4. Output path: default is ./priority-.md in cwd. Override with --out. Legacy pillar mode keeps the audits// default. Also splits MoSCoW scoring rules into evidence-driven (skip when no anchor) vs label-driven (always fire) families, and adds explicit moscow/{must,should,could,wont} label rules so workspaces using MoSCoW labels get deterministic coverage without an evidence anchor. Rationale: the original command was opinionated against a pillar taxonomy that does not exist in typical Linear workspaces (per Andres analysis, 2026-06-02). Dogfood configs continue to work unchanged. Co-Authored-By: Claude Opus 4.7 --- CHANGELOG.md | 32 ++ commands/prioritize.md | 259 +++++++---- skills/prioritize/SKILL.md | 401 ++++++++++++------ .../references/frameworks/moscow-rice.md | 31 +- .../prioritize/references/linear-mutations.md | 34 +- skills/prioritize/references/scoring-rules.md | 159 +++++-- 6 files changed, 644 insertions(+), 272 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 459eeef..38fe2fe 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -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.` configs: + - **Scope**: the first positional arg is now optional. Resolution order is + `pillars.` (legacy) → `projects.` (agnostic) → Linear MCP + `list_projects` exact-name match → interactive. Two new alternative + scope flags: `--label ` and `--filter `. + - **Evidence anchor**: the required PIBER+IDCF sub-spike is now optional via + `--evidence `. 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 `/audits//vision-audit-*.md` + only fires in legacy pillar mode. Agnostic mode requires the explicit + `--audit ` flag (no flag → no audit enrichment). + - **Output path**: default is now `./priority-.md` in cwd, with + `~/` expansion when `--out ` is provided. Legacy pillar mode keeps + the original `/audits//priority-.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..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 diff --git a/commands/prioritize.md b/commands/prioritize.md index 2c949c2..dbed37b 100644 --- a/commands/prioritize.md +++ b/commands/prioritize.md @@ -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: " [--framework ] [--no-audit] [--target ] [--dry-run] [--out ] [--issue-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: "[] [--label ] [--filter ] [--evidence ] [--audit ] [--framework ] [--no-audit] [--target ] [--dry-run] [--out ] [--issue-ids ] [--codebase ]" 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** (``) -- requerido: - - Debe matchear una clave en `linear-setup.json` -> `pillars.`. - - Si no existe, entrar a modo interactivo (ver "Modo sin config" mas abajo). +# 7. Dry-run + custom output path (default is ./priority-.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 ` | `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 ` | desde config | Override del codebase resuelto por `pillars..codebase`. | -| `--target ` | `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 ` | auto | Default: `/audits//priority-.md`. Si path empieza con `~/`, expandir. | -| `--issue-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.`, treat as **legacy pillar mode** + and pull project/spike/codebase from there (backward-compat). + 2. Else if `linear-setup.json` has `projects.`, 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 ` | Scope to issues carrying this Linear label (no project required). | +| `--filter ` | Pass an arbitrary Linear filter string to `list_issues`. | + +3. **Evidence + enrichment flags** (all optional): + +| Flag | Default | Behavior | +|------|---------|----------| +| `--evidence ` | 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 ` | none | Local vision-audit markdown path. Without it, Confidence stays at 0.8. | +| `--codebase ` | 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 ` | `moscow-rice` | v1 only implements `moscow-rice`. Others error out referencing the stub. | +| `--target ` | `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 ` | `./priority-.md` | Output path. `~/` expanded. In legacy pillar mode the default becomes `/audits//priority-.md`. | +| `--issue-ids ` | off | Comma-separated subset; the rest of the scope stays untouched in the snapshot. | -``` -/audits//priority-.md -``` +## Convencion de output (default) -Coexiste con los snapshots anteriores -- NO se sobreescribe. Git version-controla el historial; `ls -t audits//priority-*.md | head -1` da el mas reciente. +**Workspace-agnostic default**: `./priority-.md` in the current +working directory. Override with `--out ` (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.` in `linear-setup.json`): the report still goes to +`/audits//priority-.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//` equivalent) gives the +most recent. -1. **Config resolution**: parsear `linear-setup.json` y extraer `pillars..{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 -> `/audits//priority-.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.` 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.` in `linear-setup.json`, the +skill activates legacy behavior: +- Pull `project`, `spike`, `codebase` from `pillars.`. +- Auto-discover the most recent + `/audits//vision-audit-*.md` (unless `--no-audit`). +- Default `--out` becomes `/audits//priority-.md`. +- Post snapshot comment on the `pillars..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 -`/audits//priority-.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 ` -> generates a vision-audit + markdown. +2. Runs `prioritize [--evidence ...] [--audit ...]` -> generates + `priority-.md` + Linear mutations. +3. Takes the top-3 Must from the report and runs + `spike-recommend ` for each. +4. Runs `implement ` 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.` para el pillar target (o entrar a modo interactivo para crearlo). -- Codebase del pillar debe existir en el path declarado. -- Opcional: vision audit en `/audits//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.` + (legacy) or `projects.` (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. diff --git a/skills/prioritize/SKILL.md b/skills/prioritize/SKILL.md index 7d4ea51..1124335 100644 --- a/skills/prioritize/SKILL.md +++ b/skills/prioritize/SKILL.md @@ -1,41 +1,85 @@ --- name: prioritize description: > - Applies MoSCoW (bucket) + RICE-adapted (intra-bucket ranking) to Linear issues - of a product pillar, traceable to its PIBER+IDCF sub-spike and the latest vision - audit. Use when the user asks to "prioritize issues", "priorizar el pillar", + Applies MoSCoW (bucket) + RICE-adapted (intra-bucket ranking) to a scoped set + of Linear issues. Workspace-agnostic: works with any Linear project, label, or + filter; an optional product-vision evidence anchor (Linear issue OR local + markdown) drives stronger citations; an optional vision-audit doc lifts + Confidence beyond the default. Backward-compatible with the legacy pillar + taxonomy. + Use when the user asks to "prioritize issues", "priorizar el pillar", "aplicar MoSCoW", "rank the backlog", "RICE scoring", "/prioritize", or wants a - data-backed decision on what to work on next within a pillar. - Do NOT trigger for: generic backlog ranking without pillar context (use - spike-recommend or implement-advisor instead), issue creation, or PR review. + data-backed decision on what to work on next. + Do NOT trigger for: issue creation, PR review, or runs with no scope and no + workspace to inspect. --- -# /prioritize -- MoSCoW + RICE traceable to product vision +# /prioritize -- MoSCoW + RICE on any Linear backlog slice -Skill que aplica **MoSCoW** (bucket) + **RICE-adaptado** (ranking) a los issues de un pillar, justificando cada veredicto contra el sub-spike PIBER+IDCF declarado en Linear y el vision audit mas reciente (si existe). +Skill that applies **MoSCoW** (bucket) + **RICE-adapted** (ranking) to a scoped +set of Linear issues. The scope can be a Linear project, a label, or a raw +filter. When the caller provides an `--evidence` anchor (Linear issue or local +markdown — e.g. a PIBER+IDCF sub-spike, a PRD, or a vision doc) and/or an +`--audit` markdown, the skill enriches MoSCoW citations and lifts RICE +Confidence beyond the default 0.8. -El output es: +The output is: -1. Un report markdown en `/audits//priority-.md`. -2. Descripcion de cada issue en Linear con un footer autogenerado (delimiter HTML, idempotente). -3. Un comment snapshot en el sub-spike del pillar (APP-101 para mobile, BACK-101 para backend, etc.). +1. A report markdown — default `./priority-.md` in cwd + (or `/audits//priority-.md` in legacy pillar mode). +2. A description footer on every scored issue with idempotent HTML delimiters. +3. A snapshot comment on the `--evidence` Linear issue **only when evidence is + a Linear issue ID** (skipped for local-file evidence or no evidence). Legacy + pillar mode posts on `pillars..spike` as before. + +## Workspace-agnostic mode (v1.23+) + +Starting with v1.23, the four hard couplings of the original dogfood design are +optional: + +| Coupling (v1.0–v1.22) | Status in v1.23+ | +|-----------------------|------------------| +| First arg = required `` validated against `pillars.` | Optional. First positional arg falls through to `pillars.` → `projects.` → Linear MCP resolution → interactive list. Also accepts `--label` / `--filter` as alternative scopes. | +| Sub-spike PIBER+IDCF as required Confidence anchor | Optional `--evidence ` flag. Without it, MoSCoW uses label-only rules and Confidence defaults to 0.8. | +| Vision audit auto-discovered at `/audits//vision-audit-*.md` | Optional `--audit ` flag. Auto-discovery only kicks in for legacy pillar mode. | +| Output path hardcoded to `/audits//priority-.md` | Optional `--out ` (supports `~/`). Default: `./priority-.md` in cwd. Legacy pillar mode keeps the original default. | + +The legacy behavior is preserved when `linear-setup.json` declares +`pillars.` — new projects should prefer the agnostic flags but no existing +dogfood config breaks. ## Anti-trigger -Esta skill NO se activa cuando: +This skill does NOT activate when: -- El usuario quiere priorizar sin contexto de pillar (usar `spike-recommend` o triaging manual). -- El usuario quiere crear o editar issues individuales (usar MCP directo). -- El input es un PR, branch, o commit (el input es un pillar-slug). +- The user wants to create or edit individual issues (use MCP directly). +- The input is a PR, branch, or commit (this skill expects a Linear scope, not + a code change). +- The user has no Linear workspace authenticated and no `linear-setup.json` — + exit 1 with a setup hint. ## Config resolution -Lee `linear-setup.json` en la raiz del cwd. Schema esperado: +Reads `linear-setup.json` at the cwd root if present. Both schemas are +supported: + +### Agnostic schema (preferred for new projects) + +```json +{ + "team": { "key": "DOJ" }, + "projects": { + "": "" + } +} +``` + +### Legacy pillar schema (kept for backward-compat) ```json { "team": { "key": "APP" }, - "projects": { ... legacy mapping ... }, + "projects": { "...": "..." }, "pillars": { "": { "project": "", @@ -46,119 +90,200 @@ Lee `linear-setup.json` en la raiz del cwd. Schema esperado: } ``` -- Si el archivo no existe: error claro, sugerir `/make-no-mistakes:linear-projects-setup`. -- Si `pillars.` no existe: modo interactivo (ver `commands/prioritize.md`). -- Si la config tiene pillars pero falta campo (`project`, `spike`, o `codebase`): pedir el faltante, ofrecer guardar. +Resolution order (when a positional arg is provided): + +1. `pillars.` → **legacy mode** (project + spike + codebase). +2. `projects.` → **agnostic mode** (project only). +3. `mcp__linear-server__list_projects` exact-name match → **agnostic mode**. +4. No match → error with candidate list, or enter interactive selection. + +When no positional arg AND no `--label` / `--filter` is provided, enter +interactive selection (see "Modo sin argumentos" in the command doc). + +When `linear-setup.json` does not exist at all, the agnostic path still works +via MCP. The skill offers to save the resolved scope at the end of the run. ## Flujo principal ### Paso A: Fetching paralelo -Dispatch 3 subagents via Agent tool con `run_in_background: true`: +Dispatch up to 3 subagents via Agent tool with `run_in_background: true`. The +number depends on which optional anchors were provided. -**Subagent 1 -- fetch-issues**: +**Subagent 1 -- fetch-issues** (always): ``` -description: "Fetch issues del project " +description: "Fetch Linear issues for scope=" subagent_type: "general-purpose" -prompt: "Usar mcp__linear-server__list_issues para retornar todos los issues del project '' - que esten en estado Backlog, Todo, o In Progress. Si --issue-ids fue pasado, filtrar solo a esos. - Output: JSON array con {id, identifier, title, description, labels, state, priority, size_label, - estimate} por issue. Responder en bajo 200 palabras de explicacion + JSON." +prompt: | + Use mcp__linear-server__list_issues to return all issues in scope, in states + Backlog / Todo / In Progress. + + Scope is one of: + - project= (legacy or agnostic mode with positional arg) + - label= (--label flag) + - filter= (--filter flag) + + If --issue-ids was passed, intersect with that comma-separated list. + + Output JSON array of {id, identifier, title, description, labels, state, + priority, size_label, estimate} per issue. Reply in under 200 words of + explanation + JSON. ``` -**Subagent 2 -- fetch-spike**: +**Subagent 2 -- fetch-evidence** (only when `--evidence` was provided OR legacy +pillar mode supplies a spike): ``` -description: "Fetch y parse sub-spike PIBER+IDCF " +description: "Fetch and parse evidence anchor " subagent_type: "general-purpose" -prompt: "Usar mcp__linear-server__get_issue con id=. Parsear el markdown buscando secciones: - ## P, ## I, ## B, ## E, ## R, ## D -- Design Theses (marcar theses con ⚠️ como killshot), - ## C -- Capabilities (tabla con build/buy/partner + priority), ## F -- Features (P0, P1, P2, P3), - y Anti-patterns si existe. Output: JSON estructurado con estos campos + texto raw del spike por - si la parsing falla. Responder en bajo 300 palabras + JSON." +prompt: | + The evidence arg is either: + (a) A Linear issue ID (e.g. APP-101, CORE-42). Use + mcp__linear-server__get_issue to fetch it. + (b) A local markdown file path (absolute, ~/-prefixed, or relative to cwd). + Read it from disk. + + Parse the markdown looking for the standard PIBER+IDCF sections when they + exist: + ## P, ## I, ## B, ## E, ## R, ## D -- Design Theses (mark theses with ⚠️ as + killshot), ## C -- Capabilities (table with build/buy/partner + priority), + ## F -- Features (P0, P1, P2, P3), and Anti-patterns if present. + + If the doc is NOT PIBER+IDCF-shaped (e.g. a freeform PRD), still extract: + - any headings that look like priority tiers, + - any explicit "must-have" / "out-of-scope" / "P0/P1/P2" callouts, + - any anti-pattern list. + + Output JSON with whichever fields exist + the raw text under `raw` for + downstream keyword matching. If nothing parseable is found, return + {parsed: false, raw: ""} and the skill will fall back to label-only + rules with a warning. Reply in under 300 words + JSON. ``` -**Subagent 3 -- load-audit**: +**Subagent 3 -- load-audit** (only when `--audit` was provided OR legacy pillar +mode auto-discovers one): ``` -description: "Load most recent vision audit para en " +description: "Load vision audit from " subagent_type: "general-purpose" -prompt: "Glob pattern '/audits//vision-audit-*.md'. Si no hay matches, - responder {audit: null, reason: 'no audit found'}. Si hay matches, elegir el de fecha mas - reciente (YYYY-MM-DD en el filename). Read ese archivo. Parsear el scorecard table, Design - Theses table (status OK/PARTIAL/MISSING/DRIFT), Capabilities table, Features por tier, - Anti-patterns violations, y top 5 recommendations. Output: JSON estructurado + path del - archivo cargado. Responder en bajo 250 palabras + JSON." +prompt: | + Path resolution: + - If --audit was provided: read exactly that file. + - Else if legacy pillar mode: glob + '/audits//vision-audit-*.md', pick the most recent + by filename date (YYYY-MM-DD). + - Else: return {audit: null, reason: 'no audit configured'}. + + Read the matched file. Parse the scorecard table, Design Theses table + (status OK / PARTIAL / MISSING / DRIFT), Capabilities table, Features by + tier, Anti-patterns violations, and top 5 recommendations. Output JSON + + the loaded path. Reply in under 250 words + JSON. ``` -Esperar a los 3 antes de proceder al Paso B. Si subagent-1 o 2 fallan -> exit 2 con mensaje claro. Si subagent-3 falla (o retorna null) -> continuar con `audit = null` y Confidence default 0.8. +Wait for all dispatched subagents before Paso B. Subagent-1 failure → exit 2 +with a clear message. Subagent-2 failure → continue with `evidence = null` and +a warning (MoSCoW falls back to label-only rules). Subagent-3 failure (or null) +→ continue with `audit = null` and RICE Confidence default 0.8. ### Paso B: MoSCoW bucket assignment -Para cada issue retornado por subagent-1, aplicar las reglas de `references/scoring-rules.md` en orden. Primera regla que matchea gana. +For each issue from subagent-1, apply the rules from +`references/scoring-rules.md` in order. First match wins. -Output intermedio: cada issue etiquetado con: +Output per issue: - `bucket`: MUST | SHOULD | COULD | WONT | UNCLASSIFIED | DECOMPOSE -- `matched_rules`: array de nombres de reglas que aplicaron -- `cited_thesis` / `cited_feature` / `cited_capability` / `cited_antipattern`: referencias al spike -- `audit_status`: si el audit existe y matchea (OK/PARTIAL/MISSING/DRIFT/VIOLATION/null) - -**UNCLASSIFIED fallback**: si ninguna regla matchea, dispatch un subagent sync (no background) con el prompt de `references/prompts/llm-fallback-bucket.md`, pasando el issue + sections relevantes del spike. Si el subagent retorna confidence < 0.6 -> mantener UNCLASSIFIED. Si >= 0.6 -> asignar el bucket retornado + anotar `matched_rules: ["llm-fallback"]` + `llm_rationale: `. - -**DECOMPOSE**: issues con `size_label == "XL"` van a DECOMPOSE directamente, sin pasar por otras reglas. No reciben RICE score. Aparecen en seccion separada del report. +- `matched_rules`: array of matched rule slugs +- `cited_thesis` / `cited_feature` / `cited_capability` / `cited_antipattern`: + references into the evidence anchor when present +- `audit_status`: when audit exists and matches (OK / PARTIAL / MISSING / + DRIFT / VIOLATION / null) + +**Without evidence**: only label-driven and explicit rules fire (e.g. +DECOMPOSE on XL, WONT on phase-conflict, COULD on `ux`/`perf` labels without +contrary signal). The remainder route to UNCLASSIFIED → LLM fallback (see +below). + +**UNCLASSIFIED fallback**: if no rule matches, dispatch a synchronous subagent +(no background) using `references/prompts/llm-fallback-bucket.md`, passing the +issue + relevant sections of the evidence anchor when present. If confidence < +0.6 → keep UNCLASSIFIED. If ≥ 0.6 → assign returned bucket + annotate +`matched_rules: ["llm-fallback"]` + `llm_rationale: `. + +**DECOMPOSE**: issues with `size_label == "XL"` go directly to DECOMPOSE, +short-circuiting all other rules. They receive no RICE score and appear in a +separate report section. ### Paso C: RICE intra-bucket ranking -Para cada bucket (MUST, SHOULD, COULD, WONT), si tiene >3 issues: +For each bucket (MUST, SHOULD, COULD, WONT), if it has > 3 issues: -1. Calcular RICE por issue: `(Reach × Impact × Confidence) / Size`. +1. Compute RICE per issue: `(Reach × Impact × Confidence) / Size`. 2. Variables: - - **Reach**: inferir del spike (`every user` = 9, `pillar users` = 3, `admin-only` = 1). Default 3. - - **Impact**: `0` (no thesis avanzada), `1` (1 match), `2` (2+ matches), `3` (killshot ⚠️ match). - - **Confidence**: audit lookup. `PARTIAL` -> 1.0, `DRIFT` -> 0.8, `MISSING` -> 0.5. Sin audit o ambiguo -> 0.8. - - **Size**: XS=1, S=2, M=4, L=8. (XL ya esta en DECOMPOSE.) Sin label -> M=4 + flag `low-confidence-estimate`. -3. Ranking desc. Empates por `issue.identifier` lexicografico asc. - -Si un bucket tiene ≤3 issues, mantener orden natural (spike-derived) sin rankear. Ver `references/frameworks/moscow-rice.md` para detalle de edge cases. + - **Reach**: infer from evidence (`every user` = 9, ` users` = 3, + `admin-only` = 1). Default 3. + - **Impact**: `0` (no thesis advanced), `1` (1 match), `2` (2+ matches), + `3` (killshot ⚠️ match). When no evidence: collapses to 0 or 1 based on + label heuristics; flagged as `low-confidence-estimate`. + - **Confidence**: audit lookup. `PARTIAL` → 1.0, `DRIFT` → 0.8, `MISSING` → + 0.5. No audit, ambiguous, or `--no-audit` → 0.8. + - **Size**: XS=1, S=2, M=4, L=8. (XL → DECOMPOSE.) No label → M=4 + flag + `low-confidence-estimate`. +3. Rank desc. Ties broken by `issue.identifier` lexicographic asc. + +If a bucket has ≤ 3 issues, keep natural order without ranking. See +`references/frameworks/moscow-rice.md` for edge cases. ### Paso D: Confidence flags -Marcar cada issue con flag `low-confidence-estimate` si: -- `size_label` missing -> Size default=M. -- `description.length < 100` -> Reach/Impact inferidos solo del titulo. -- `--no-audit` fue pasado pero el audit existe -> Confidence default=0.8. -- Subagent-2 parse warnings presentes (ambiguity en spike sections). +Mark each issue with `low-confidence-estimate` if: +- `size_label` missing → Size defaulted to M. +- `description.length < 100` → Reach/Impact inferred only from title. +- `--no-audit` was passed but an audit is on disk → Confidence defaulted. +- No `--evidence` was provided → Impact derived from labels only. +- Subagent-2 parse warnings present (ambiguity in evidence sections). -El flag se muestra como "⚠" en el report al lado del RICE score. NO bloquea el ranking. +The flag is shown as "⚠" next to the RICE score in the report. It does NOT +block ranking. ### Paso E: Composicion de artifacts -Generar 3 artifacts en paralelo (via Agent tool subagents para I/O pesado) o secuencial si mas simple: +Generate up to 3 artifacts in parallel (via Agent tool subagents for heavy I/O) +or sequential if simpler: **Artifact 1 -- Priority report markdown**: -- Write a `/audits//priority-.md`. -- Si el directorio no existe, crear con `mkdir -p`. -- Si ya existe un archivo con la misma fecha -> append sufijo `-2`, `-3`, etc. -- Template: ver `references/linear-mutations.md` seccion "Priority report template". +- Resolve the output path: + - `--out ` if provided (expand `~/`). + - Else if legacy pillar mode: + `/audits//priority-.md` (mkdir -p). + - Else: `./priority-.md` in cwd. +- If the same path already exists (same date), append suffix `-2`, `-3`, etc. +- Template: see `references/linear-mutations.md` "Priority report template". **Artifact 2 -- Description footer per issue**: -- Solo si `--dry-run=false`. -- Para cada issue scoreado, leer la description actual via `mcp__linear-server__get_issue`. -- Aplicar la regla de reemplazo idempotente de `references/linear-mutations.md` seccion "Delimiter convention". -- Escribir la description actualizada via `mcp__linear-server__save_issue`. -- Log success/fail por issue. Fallas NO abortan el batch -- se reportan al final. - -**Artifact 3 -- Snapshot comment en sub-spike**: -- Solo si `--dry-run=false`. -- Target: `pillars..spike` (ej: APP-101 para mobile). -- NO editar comment anterior. Siempre agregar uno nuevo con fecha. -- Si existe comment previo con patron matching, agregar link al bottom del nuevo comment. -- Usar `mcp__linear-server__save_comment` con el body del template (ver `references/linear-mutations.md` seccion "Sub-spike comment template"). +- Only if `--dry-run = false`. +- For each scored issue, read the current description via + `mcp__linear-server__get_issue`. +- Apply the idempotent replacement rule from + `references/linear-mutations.md` "Delimiter convention". +- Write the updated description via `mcp__linear-server__save_issue`. +- Log success/fail per issue. Failures do NOT abort the batch — reported at + the end. + +**Artifact 3 -- Snapshot comment on evidence Linear issue**: +- Only if `--dry-run = false` AND `--evidence` is a Linear issue ID + (NOT a local file) — OR legacy pillar mode (post on + `pillars..spike`). +- Never edit a previous comment; always add a new one with date. +- If a previous matching comment exists, link to it from the new one. +- Use `mcp__linear-server__save_comment` with the body from + `references/linear-mutations.md` "Sub-spike comment template". +- When evidence is a local file or absent, skip this artifact — the report is + still written. ### Paso F: Resumen al usuario -Al final de la ejecucion (independiente de dry-run): +At the end of execution (regardless of dry-run): ``` -Priority snapshot generado para : +Priority snapshot generated for : Must: N issues (top: ALT-XXX, RICE=X.X) Should: N issues Could: N issues @@ -166,70 +291,88 @@ Priority snapshot generado para : Unclassified: N issues (needs human review) Decompose: N issues (XL-sized, suggest /spike-recommend) -Report: - +Report: + Descriptions updated: N/M issues ( failures) - Sub-spike comment: + Evidence comment: Mutations proposed but NOT applied. Run without --dry-run to apply. Next steps: - - Review top Musts en el report. - - Corre `/make-no-mistakes:spike-recommend ` para el top-3 Must. - - Corre `/make-no-mistakes:implement ` una vez el brief este listo. + - Review top Musts in the report. + - Run `/make-no-mistakes:spike-recommend ` for the top-3 Must. + - Run `/make-no-mistakes:implement ` once each brief is ready. ``` ## Error handling -Ver `references/scoring-rules.md` y `references/linear-mutations.md` para detalle por caso. Tabla resumen: - -| Escenario | Accion | -|-----------|--------| -| linear-setup.json no existe | Exit 1 con sugerencia `/linear-projects-setup`. | -| pillars. no existe | Modo interactivo. | -| MCP linear-server no disponible | Exit 1 con mensaje setup. | -| Subagent fetch-issues falla | Exit 2, no tocar Linear. | -| Subagent fetch-spike falla | Exit 2, no tocar Linear. | -| Subagent load-audit falla | Warn + continuar con audit=null. | -| Spike sin IDCF parseable | Warn + MoSCoW puro sin theses matching. | -| Issue sin Size label | Default=M + flag low-confidence-estimate. | -| --target=labels + labels missing | Exit 1, sugerir pedir a admin + usar --target=description. | -| Description update falla para 1+ issue | Continuar batch, reportar fallas al final. Exit 3 si >0% fallas. | -| Dry-run + mutations en output | "Proposed" en titulo del report + skip Artifacts 2-3. | +See `references/scoring-rules.md` and `references/linear-mutations.md` for +detail per case. Summary table: + +| Scenario | Action | +|----------|--------| +| linear-setup.json does not exist | Fine — agnostic path resolves via MCP. Offer to save scope at end. | +| `pillars.` not in config AND no other resolution match | Interactive selection. | +| MCP linear-server not available | Exit 1 with setup message. | +| Subagent fetch-issues fails | Exit 2, do not touch Linear. | +| Subagent fetch-evidence fails | Warn, continue with evidence=null + label-only MoSCoW. | +| Subagent load-audit fails | Warn, continue with audit=null and Confidence=0.8. | +| Evidence has no parseable IDCF sections | Warn, MoSCoW falls back to label-only rules; the raw text is still keyword-searched. | +| Issue without Size label | Default=M + flag low-confidence-estimate. | +| `--target=labels` and labels missing | Exit 1, suggest asking admin + using --target=description. | +| Description update fails for 1+ issues | Continue batch, report failures at end. Exit 3 if > 0% failures. | +| --dry-run + mutations in output | "Proposed" in report title + skip Artifacts 2-3. | +| `--evidence` and `--audit` both omitted | Allowed — run with Confidence=0.8 and label-only rules. Report notes the lack of vision grounding. | ## Reglas de oro -1. **Deterministico first, LLM second**: las reglas de MoSCoW se aplican primero. LLM solo para UNCLASSIFIED residual. -2. **Citar siempre**: cada bucket assignment cita el match (thesis #, feature tier, anti-pattern, audit status). -3. **Idempotencia en Linear**: correr 2 veces debe dar el mismo resultado. Description footer se reemplaza, no se stackea. Sub-spike comment es nuevo cada run (no edit del anterior). -4. **Coexistencia de snapshots**: el report NO sobreescribe el anterior. Git version-controla. -5. **No time estimates**: nunca decir "2 sprints", "1 mes". Sequential ordering con milestones conceptuales. -6. **Respetar config**: si `linear-setup.json` no declara un pillar, pedir al usuario, ofrecer guardar. Nunca inventar. -7. **Low-confidence transparente**: si faltan datos, marcar flag, no adivinar sin avisar. +1. **Deterministic first, LLM second**: MoSCoW rules apply first. LLM only for + residual UNCLASSIFIED. +2. **Always cite**: each bucket assignment cites the match (rule slug + thesis + # / feature tier / anti-pattern / label / audit status as applicable). +3. **Linear idempotency**: running twice should yield the same result. + Description footer is replaced, never stacked. Evidence snapshot comment is + new each run (no edit of the previous one). +4. **Snapshot coexistence**: the report does NOT overwrite previous ones. Git + version-controls the history. +5. **No time estimates**: never say "2 sprints", "1 month". Sequential + ordering with conceptual milestones. +6. **Respect the config**: never invent project/spike/codebase. Resolve via + `pillars` → `projects` → MCP → ask the user. Offer to save the resolved + scope. +7. **Transparent low-confidence**: when data is missing, set the flag — do not + guess silently. Absence of `--evidence` is itself a low-confidence signal. ## Interaccion con el usuario -- Confirmar args al inicio si algo es ambiguo (pillar sin config, codebase no existe, MCP no disponible). -- Mostrar progreso: "Fetching issues + spike + audit en paralelo...", "Aplicando reglas MoSCoW a N issues...", "Calculando RICE en bucket Must...". -- Al final, mostrar el resumen del Paso F. -- Preguntar si hay mutations fallidas: "Queres reintentar los N issues que fallaron?". +- Confirm args at start when something is ambiguous (no scope, codebase + missing, MCP unavailable). +- Show progress: "Fetching issues + evidence + audit in parallel...", + "Applying MoSCoW rules to N issues...", "Computing RICE in bucket Must...". +- At the end, show the Paso F summary. +- Ask about failed mutations: "Retry the N issues that failed?". ## Fallbacks -Si el codebase del pillar no tiene `audits//`: -- Crear el directorio antes de escribir el report. -- Mencionar en el executive summary del report: "primer priority snapshot, no hay historial previo". +If the resolved output directory does not exist: +- Create it with `mkdir -p` before writing the report. +- For legacy pillar mode without prior `audits//`, mention in the + executive summary: "first priority snapshot, no prior history". -Si el pillar tiene mas de 200 issues: -- Advertir al usuario: "200+ issues detectados, esto puede tomar un rato. Considera filtrar con --issue-ids o cerrar issues obsoletos primero." -- Proceder igual. +If the scope returns > 200 issues: +- Warn the user: "200+ issues detected, this may take a while. Consider + filtering with --issue-ids, --filter, or closing stale issues first." +- Proceed anyway. ## Referencias -- `references/scoring-rules.md` -- tabla deterministica MUST/SHOULD/COULD/WONT. -- `references/frameworks/moscow-rice.md` -- v1 impl (formula RICE, edge cases). +- `references/scoring-rules.md` -- deterministic MUST/SHOULD/COULD/WONT table. +- `references/frameworks/moscow-rice.md` -- v1 impl (RICE formula, edge cases). - `references/frameworks/{rice,moscow,ice,wsjf,kano}.md` -- v2 stubs. - `references/linear-mutations.md` -- delimiter convention + templates. -- `references/prompts/llm-fallback-bucket.md` -- LLM prompt para UNCLASSIFIED fallback. +- `references/prompts/llm-fallback-bucket.md` -- LLM prompt for UNCLASSIFIED + fallback. -Ver tambien el spec completo: `docs/superpowers/specs/2026-04-21-prioritize-command-design.md`. +Original spec: `docs/superpowers/specs/2026-04-21-prioritize-command-design.md`. +Agnostic-mode rationale: see CHANGELOG entry "Workspace-agnostic prioritize +mode" plus the Andres analysis 2026-06-02. diff --git a/skills/prioritize/references/frameworks/moscow-rice.md b/skills/prioritize/references/frameworks/moscow-rice.md index b00777b..2093c5d 100644 --- a/skills/prioritize/references/frameworks/moscow-rice.md +++ b/skills/prioritize/references/frameworks/moscow-rice.md @@ -157,17 +157,36 @@ Probable causa: spike sin IDCF parseable, o keyword detection demasiado estricta Poco probable pero posible si todos son same-size + same-thesis-count + same-confidence. En ese caso el tiebreak por issue.identifier da orden estable. Log en Appendix del report. -### Edge 4: pillar sin project Linear asociado +### Edge 4: positional scope arg cannot be resolved -Probable config error. Exit 1 con mensaje: "Pillar '' has no `project` field in linear-setup.json. Either add it or switch to interactive mode." +Posicional arg no matchea `pillars.`, `projects.`, ni un Linear +project name via MCP. Exit 1 with: "Scope '' could not be resolved. Pass +--label, --filter, or pick from the available Linear projects: ." -### Edge 5: codebase existe pero `audits//` no +### Edge 5: legacy pillar mode + codebase existe pero `audits//` no -Comportamiento: proceder sin audit (Confidence=0.8 default). Warn + sugerir `/business-model-toolkit:product-vision-audit`. +Comportamiento: proceder sin audit (Confidence=0.8 default). Warn + sugerir +`/business-model-toolkit:product-vision-audit`. -### Edge 6: codebase path no existe +### Edge 6: legacy pillar mode + codebase path no existe -Exit 1: "Codebase path '' does not exist. Check linear-setup.json `pillars..codebase` o pasa --codebase override." +Exit 1: "Codebase path '' does not exist. Check linear-setup.json +`pillars..codebase` o pasa --codebase override." + +### Edge 7: agnostic mode con --evidence y --audit ausentes + +Permitido. RICE Confidence default 0.8, MoSCoW corre con label-driven rules +solamente. El executive summary del report anota "Run without product-vision +grounding — verdicts derived from labels + LLM fallback only." Esto no es un +error, pero el reader debe interpretar los Musts con mas escepticismo. + +### Edge 8: agnostic mode con --evidence apuntando a archivo no-IDCF + +Si `subagent-2` retorna `{parsed: false, raw: ""}`, el rule engine usa +keyword matching sobre `raw` (la regex de Section "Keyword detection heuristics" +de scoring-rules.md sigue funcionando) pero NO puede citar +thesis_id/feature_tier explicitos. Los matches se etiquetan +`cited_evidence: "freeform"` + flag `low-confidence-estimate`. ## Testing diff --git a/skills/prioritize/references/linear-mutations.md b/skills/prioritize/references/linear-mutations.md index ef72c6f..877f2a2 100644 --- a/skills/prioritize/references/linear-mutations.md +++ b/skills/prioritize/references/linear-mutations.md @@ -106,22 +106,30 @@ Context + Acceptance criteria intactos. Solo el bloque de priority cambio. ## Priority report template Filename: `priority-.md` -Path: `/audits//priority-.md` +Path (default agnostic mode): `./priority-.md` in cwd. +Path (legacy pillar mode): `/audits//priority-.md`. +Override either with `--out ` (supports `~/`). ### Template completo +Fields shown as `<…>` are required; fields shown as `<… or "n/a">` collapse to +`"n/a"` (or `"none"` / `"absent"`) when the corresponding flag/config is +absent. In agnostic mode without `--evidence`, the `Evidence anchor` line +collapses to `none`. In agnostic mode without a pillar, the `Scope` line +shows the project / label / filter that was used. + ```markdown -# Priority Snapshot -- +# Priority Snapshot -- **Framework**: MoSCoW + RICE (Reach × Impact × Confidence / Size) -**Pillar**: -**Sub-spike**: []() -- -**Project Linear**: []() +**Scope**: | filter:> +**Evidence anchor**: []() -- | <local-path> | none +**Project Linear**: [<project-name>](<project url>) | n/a **Vision audit**: <path or "none"> (alineacion: <FUERTE|PARCIAL|DEBIL|CRITICO|N/A>) **Issues evaluated**: <N> **Fecha**: YYYY-MM-DD **Previous snapshot**: <path to prev or "first snapshot"> -**Command**: `/make-no-mistakes:prioritize <pillar> <flags>` +**Command**: `/make-no-mistakes:prioritize <args>` --- @@ -201,13 +209,21 @@ First priority snapshot. No comparison available. --- -## Sub-spike comment template +## Evidence-anchor comment template + +(Originally "Sub-spike comment template" — generalized for workspace-agnostic +mode.) ### Target -El spike del pillar: `pillars.<slug>.spike` (ej: APP-101 para mobile). +- **Agnostic mode**: the Linear issue passed as `--evidence` IF it is a Linear + issue ID (not a local file). Example: `--evidence APP-101`. +- **Legacy pillar mode**: `pillars.<slug>.spike` (e.g. APP-101 for mobile). +- **Skipped**: when evidence is a local file or absent entirely. The report is + still written and serves as the sole snapshot artifact for that run. -**NO** postear en el spike maestro APP-001 (constitucion umbrella, si aplica). +**Do NOT** post on a master umbrella spike (e.g. APP-001) when a more +specific anchor exists. ### Formato diff --git a/skills/prioritize/references/scoring-rules.md b/skills/prioritize/references/scoring-rules.md index 5f557bd..34309c2 100644 --- a/skills/prioritize/references/scoring-rules.md +++ b/skills/prioritize/references/scoring-rules.md @@ -1,10 +1,31 @@ # MoSCoW Scoring Rules -- deterministic bucket assignment -Tabla deterministica que mapea un issue a su MoSCoW bucket aplicando reglas contra el sub-spike PIBER+IDCF del pillar. Las reglas se evaluan en orden. **La primera regla que matchea gana**. +Tabla deterministica que mapea un issue a su MoSCoW bucket aplicando reglas en +orden. **La primera regla que matchea gana**. -Un issue matchea una regla cuando: -- Su `title` o `description` contiene keywords del target del spike (thesis/feature/capability/antipattern), O -- Un label del issue cita explicitamente el target (ej: label `thesis/D1`, `feature/P0`). +Las reglas se dividen en dos familias: + +- **Evidence-driven rules** (fire only when `--evidence` was provided — a + Linear issue ID, e.g. a PIBER+IDCF sub-spike, OR a local markdown doc). Cite + thesis / feature / capability / anti-pattern from the anchor. +- **Label-driven rules** (always fire — anchor-independent). Cite labels, + Size, priority, and phase locks. + +An issue matches an evidence-driven rule when: +- Its `title` or `description` contains keywords from the anchor target + (thesis/feature/capability/antipattern), OR +- A label on the issue explicitly cites the target (e.g. `thesis/D1`, + `feature/P0`). + +An issue matches a label-driven rule when the declared condition holds (Size +label, literal label, lock file in the codebase, etc.). These rules do not +require an anchor. + +**Workspace-agnostic mode**: when `--evidence` is NOT provided, all +evidence-driven rules are skipped automatically. The issue falls through to +label-driven rules; if those also don't match, it lands in UNCLASSIFIED → LLM +fallback. The final report notes the absence of an anchor in the executive +summary. ## Orden de evaluacion @@ -31,93 +52,144 @@ Un issue matchea una regla cuando: ## MUST (killshot + P0 + audit violations) -Cada regla en orden: +Each rule in order. MUST-1 through MUST-4 are **evidence-driven** (skipped when +no `--evidence` was provided). MUST-5 is **label-driven** (always fires). -### MUST-1: killshot-thesis-match +### MUST-1: killshot-thesis-match (evidence-driven) -- Condition: issue menciona thesis #N, Y spike declara thesis #N con ⚠️ (killshot). -- Additional: audit status de la thesis != "OK" (i.e., hay trabajo pendiente). -- Match: cita `thesis_id`, `killshot: true`, `audit_status`. +- Condition: issue mentions thesis #N, AND the anchor declares thesis #N with + ⚠️ (killshot). +- Additional: audit status of the thesis != "OK" (i.e., pending work). +- Match: cite `thesis_id`, `killshot: true`, `audit_status`. - `matched_rules: ["must/killshot-thesis-match"]` -### MUST-2: anti-pattern-violation +### MUST-2: anti-pattern-violation (evidence-driven) -- Condition: issue describe resolver un anti-pattern del spike, Y audit detecto VIOLATION. -- Match: cita `antipattern_name`, `audit_status: "VIOLATION"`. +- Condition: issue describes resolving an anti-pattern from the anchor, AND + audit detected VIOLATION. +- Match: cite `antipattern_name`, `audit_status: "VIOLATION"`. - `matched_rules: ["must/anti-pattern-violation"]` -### MUST-3: north-star-instrumentation +### MUST-3: north-star-instrumentation (evidence-driven) -- Condition: issue implementa instrumentacion de la metric North Star del spike, Y audit status es MISSING. -- Match: cita `north_star_metric`. +- Condition: issue implements instrumentation of the North Star metric from the + anchor, AND audit status is MISSING. +- Match: cite `north_star_metric`. - `matched_rules: ["must/north-star-instrumentation"]` -### MUST-4: feature-p0-missing-or-partial +### MUST-4: feature-p0-missing-or-partial (evidence-driven) -- Condition: issue implementa Feature P0 del spike, Y audit status != "SHIPPED" (o no hay audit). -- Match: cita `feature_name`, `feature_tier: "P0"`, `audit_status`. +- Condition: issue implements a Feature P0 from the anchor, AND audit status + != "SHIPPED" (or there is no audit). +- Match: cite `feature_name`, `feature_tier: "P0"`, `audit_status`. - `matched_rules: ["must/feature-p0-missing-or-partial"]` +### MUST-5: explicit-must-label (label-driven) + +- Condition: issue carries an explicit MoSCoW Must label + (`moscow/must`, `priority/must`, `MoSCoW: Must`, or the emoji-prefixed + equivalent if the workspace uses one). +- Match: cite the literal label string. +- `matched_rules: ["must/explicit-must-label"]` + --- ## SHOULD (soft theses + P1 + build-capability) -### SHOULD-1: soft-thesis-match +SHOULD-1 through SHOULD-3 are **evidence-driven**. SHOULD-4 is +**label-driven**. -- Condition: issue avanza una Design Thesis NO marcada con ⚠️, Y audit status != "OK". -- Match: cita `thesis_id`, `killshot: false`. +### SHOULD-1: soft-thesis-match (evidence-driven) + +- Condition: issue advances a Design Thesis NOT marked with ⚠️, AND audit + status != "OK". +- Match: cite `thesis_id`, `killshot: false`. - `matched_rules: ["should/soft-thesis-match"]` -### SHOULD-2: feature-p1-missing-or-partial +### SHOULD-2: feature-p1-missing-or-partial (evidence-driven) -- Condition: issue implementa Feature P1 del spike, Y audit status != "SHIPPED". +- Condition: issue implements a Feature P1 from the anchor, AND audit status + != "SHIPPED". - `matched_rules: ["should/feature-p1-missing-or-partial"]` -### SHOULD-3: build-capability-missing +### SHOULD-3: build-capability-missing (evidence-driven) -- Condition: issue cubre una Capability marcada `Build` en el spike con audit status MISSING o PARTIAL. -- Match: cita `capability_name`. +- Condition: issue covers a Capability marked `Build` in the anchor with audit + status MISSING or PARTIAL. +- Match: cite `capability_name`. - `matched_rules: ["should/build-capability-missing"]` +### SHOULD-4: explicit-should-label (label-driven) + +- Condition: issue carries an explicit MoSCoW Should label + (`moscow/should`, `priority/should`, etc.). +- Match: cite the literal label string. +- `matched_rules: ["should/explicit-should-label"]` + --- ## COULD (P2 + buy-partner + UX) -### COULD-1: feature-p2 +COULD-1 and COULD-2 are **evidence-driven**. COULD-3 and COULD-4 are +**label-driven**. + +### COULD-1: feature-p2 (evidence-driven) -- Condition: issue implementa Feature P2 del spike. +- Condition: issue implements a Feature P2 from the anchor. - `matched_rules: ["could/feature-p2"]` -### COULD-2: buy-partner-capability +### COULD-2: buy-partner-capability (evidence-driven) -- Condition: issue cubre una Capability marcada `Buy` o `Partner` (no `Build`). +- Condition: issue covers a Capability marked `Buy` or `Partner` (not + `Build`). - `matched_rules: ["could/buy-partner-capability"]` -### COULD-3: ux-improvement-no-thesis +### COULD-3: ux-improvement-no-anchor-match (label-driven) + +- Condition: `issue.labels` contains `ux`, `perf`, or `improvement`, AND no + evidence-driven rule matched (or no evidence provided). +- `matched_rules: ["could/ux-improvement-no-anchor-match"]` + +### COULD-4: explicit-could-label (label-driven) -- Condition: issue.labels contiene `ux`, `perf`, o `improvement`, Y NO matchea ninguna thesis ni feature tier. -- `matched_rules: ["could/ux-improvement-no-thesis"]` +- Condition: issue carries an explicit MoSCoW Could label + (`moscow/could`, `priority/could`, etc.). +- Match: cite the literal label string. +- `matched_rules: ["could/explicit-could-label"]` --- ## WONT (P3 + out-of-scope + phase-conflict) -### WONT-1: feature-p3 +WONT-1 and WONT-2 are **evidence-driven**. WONT-3 and WONT-4 are +**label-driven**. -- Condition: issue implementa Feature P3 del spike. +### WONT-1: feature-p3 (evidence-driven) + +- Condition: issue implements a Feature P3 from the anchor. - `matched_rules: ["wont/feature-p3"]` -### WONT-2: out-of-scope-explicit +### WONT-2: out-of-scope-explicit (evidence-driven) -- Condition: spike tiene seccion `Out of scope` y el issue cae ahi por title/description. +- Condition: anchor has an `Out of scope` section and the issue lands there by + title/description. - `matched_rules: ["wont/out-of-scope-explicit"]` -### WONT-3: phase-conflict +### WONT-3: phase-conflict (label-driven) -- Condition: el codebase tiene phase-lock (ej: `.claude/ship-gate.lock`, `.claude/design-freeze.lock`), Y el issue es una Feature nueva (no Bug, no Chore). -- Match: cita el lock file y la razon del spike. +- Condition: the codebase has a phase-lock (e.g. `.claude/ship-gate.lock`, + `.claude/design-freeze.lock`), AND the issue is a new Feature (not Bug, not + Chore). +- Match: cite the lock file and (when available) the anchor reason. - `matched_rules: ["wont/phase-conflict"]` +### WONT-4: explicit-wont-label (label-driven) + +- Condition: issue carries an explicit MoSCoW Won't label + (`moscow/wont`, `priority/wont`, etc.). +- Match: cite the literal label string. +- `matched_rules: ["wont/explicit-wont-label"]` + --- ## UNCLASSIFIED (fallback) @@ -131,7 +203,12 @@ Si >= 0.6 -> asignar el bucket sugerido + anotar `matched_rules: ["llm-fallback" ## Keyword detection heuristics -Cuando el issue NO tiene labels explicitos (ej: `thesis/D1`), buscar keywords del spike: +These heuristics only apply when an `--evidence` anchor was provided. In +workspace-agnostic runs without an anchor, keyword detection is skipped and the +rule engine relies on label-driven rules + the LLM fallback. + +When the issue does NOT carry explicit labels (e.g. `thesis/D1`), search for +anchor keywords: - **Thesis match**: buscar en title/description substrings del statement de la thesis. Ejemplo: thesis "Must require certification exam with human judge attestation" -> keywords `certification exam`, `human judge`, `Black Belt`, `attestor`, `attestation`. - **Feature match**: buscar el feature name literal. Ejemplo: feature "Core Pathway engine" -> keywords `Pathway engine`, `pathway core`, `Pathway schema`.