@brunosps00/dev-workflow 2.2.0 → 2.4.0

package/scaffold/skills/dw-llm-eval/SKILL.md

@@ -26,19 +26,7 @@ If the feature is fully deterministic (no LLM in the loop), use `dw-testing-disc
 
 ## The oracle ladder
 
-Five rungs, climb from CHEAPEST/STRICTEST to MOST EXPENSIVE/SUBJECTIVE. Always start at the bottom; only climb when the lower rung can't cover the case.
-
-| Rung | What it checks | Cost | When to use |
-|------|----------------|------|-------------|
-| 1. **Exact match** | `output === expected` | ~free | Structured outputs (function calls, JSON with stable shape, classifications) |
-| 2. **Schema validation** | Output matches JSON schema / type contract | ~free | Output shape matters; specific values vary |
-| 3. **Outcome state** | Side effect produced the expected change (DB row, file written, tool called) | cheap | Agents, tool-use, RAG with concrete answers |
-| 4. **LLM-as-judge** | A different model grades the output against a rubric | medium ($$$) | Subjective quality (helpfulness, tone, faithfulness) where no rule can decide |
-| 5. **Human review** | Domain expert scores | expensive | Calibration of rung 4; high-stakes outputs; edge cases |
-
-**Rule:** never reach for rung 4 before checking if rungs 1-3 can cover the case. Every rung up costs an order of magnitude more (latency, money, calibration effort) — and adds entropy.
-
-See `references/oracle-ladder.md` for examples per rung and the climbing decision tree.
+For the oracle ladder, read `references/the-oracle-ladder-detail.md`. Load only when this part of the task applies.
 
 ## LLM-as-judge discipline (when rung 4 is needed)
 
@@ -68,14 +56,7 @@ See `references/reference-dataset.md` for case-design principles, sampling from
 
 ## Consistency (run-to-run stability)
 
-The oracle ladder measures whether an output is *correct*; it does not measure whether the feature is *stable*. Because LLMs are non-deterministic, a case that passes once may fail the next run. Measure it:
-
-- Re-run each case **N times** (default 3) against the same code + model + prompt.
-- Record `pass_rate` (e.g. `2/3`) and `consistency` (fraction agreeing with the majority verdict) per case in `runs/<YYYY-MM-DD>.jsonl`.
-- A case with pass_rate strictly between `1/N` and `(N-1)/N` is **flaky** — a signal, not a pass. A 2/3 pass hides a one-in-three production failure; investigate before shipping.
-- Sample at the **temperature the feature uses in production** — consistency measured at temp 0 lies about a temp-0.7 feature.
-
-Deterministic rungs (1–3) are usually stable; consistency matters most for rung 4 (LLM-as-judge) and agent trajectories. Record the run count `N` in the run log so later comparisons are apples-to-apples.
+For consistency (run-to-run stability), read `references/consistency-run-to-run-stability-detail.md`. Load only when this part of the task applies.
 
 ## RAG evaluation
 
@@ -91,27 +72,7 @@ Precision alone misses hallucination. Faithfulness alone misses retrieval failur
 
 ## Agent / tool-use evaluation
 
-Two questions distinguish good agent eval from bad:
-
-### Question 1: outcome or trajectory?
-
-| Approach | What it checks | Failure mode |
-|----------|---------------|--------------|
-| **Outcome-only** | Did the agent achieve the goal? Was the final state correct? | Misses "ghost actions" — agent did the right thing for the wrong reasons |
-| **Trajectory** | Did the agent take the expected sequence of steps / tool calls? | Punishes legitimate creativity — agent solved it via a different valid path |
-
-**Recommendation:** outcome-only with side-effect assertion as default. Trajectory match for cases where the path matters (e.g., "must call `get-user` before `update-user`").
-
-### Question 2: which trajectory match mode?
-
-When trajectory matching IS the right call, four modes are available:
-
-- **Strict** — same tool calls, same order, same arguments. Use when both sequence and parameters are part of the contract.
-- **Unordered** — same tool calls, any order. Use when concurrent calls are valid.
-- **Subset** — actual trajectory contains a subset of reference calls. Use to enforce "don't exceed expected tool use" (frugality / cost).
-- **Superset** — actual contains all reference calls plus possibly more. Use when specific tools are mandatory but extras are acceptable.
-
-See `references/agent-eval.md` for examples and the decision tree.
+For agent / tool-use evaluation, read `references/agent-tool-use-evaluation-detail.md`. Load only when this part of the task applies.
 
 ## Required reading by context
 
@@ -119,26 +80,18 @@ See `references/agent-eval.md` for examples and the decision tree.
 |------------|------|
 | Designing an eval suite for an AI feature | `references/oracle-ladder.md` (climb the ladder) |
 | Using LLM-as-judge | `references/judge-calibration.md` (mandatory before relying on it) |
+| Decision with a fixed answer set (classify, route, score a rubric) | `references/bounded-decisions.md` — score the candidates instead of generating, and why the probability is not a confidence |
 | Building / curating a reference dataset | `references/reference-dataset.md` |
 | RAG-specific feature | `references/rag-metrics.md` |
 | Agent / tool-use feature | `references/agent-eval.md` |
 
 ## Anti-patterns (will block in `/dw-review --code-only`)
 
-- **LLM-as-judge without calibration evidence.** PR adds LLM-as-judge but the calibration Spearman score is missing or < 0.80. REJECTED.
-- **Same-model judge.** Judge model is the same as the system under test. REJECTED unless explicitly documented (and even then, results are suspect).
-- **Single-rung eval.** Feature ships with only LLM-as-judge; no rung 1-3 grounding. REJECTED — the cheap rungs catch the loud failures.
-- **Synthetic-only dataset.** No traceable production-failure source for any case. REJECTED — confirm at least 20% of cases come from real user inputs.
-- **"Looks good to me" QA.** No reference dataset, no metric, no rubric — just sampling output and calling it good. REJECTED.
-- **Coverage as metric.** Quoting "we tested 50 prompts" without saying what was measured. The number is meaningless without the metric.
-- **Single-run eval on a non-deterministic feature.** Each case run once at production temperature; a lucky pass reported as a pass. REJECTED — report `pass_rate` over N runs (see Consistency).
+For anti-patterns (will block in `/dw-review --code-only`), read `references/anti-patterns-will-block-in-dw-review-code-only-detail.md`. Load only when this part of the task applies.
 
 ## Integration with dev-workflow commands
 
-- `/dw-plan tasks`: when the PRD has an AI feature requirement, an eval-plan subtask is mandatory. The task references this skill's oracle ladder.
-- `/dw-review --code-only`: AI feature PRs require a reference dataset + ≥2 oracle rungs (lower rungs FIRST). The constitution gate also applies — if the project has principles about AI feature reliability, they're enforced here.
-- `/dw-qa --ai`: new mode (when this skill is bundled) — runs the reference dataset against the current implementation, logs to `QA/logs/ai/<feature>-<date>.jsonl`, computes precision@k / faithfulness / outcome accuracy per the feature type.
-- `/dw-bugfix` when the bug is an AI failure mode (hallucination, tool misuse, classification error): adds the failing case to the reference dataset BEFORE fixing — the case is now a regression test forever.
+For integration with dev-workflow commands, read `references/integration-with-dev-workflow-commands-detail.md`. Load only when this part of the task applies.
 
 ## When the discipline bends
 

package/scaffold/skills/dw-llm-eval/references/agent-tool-use-evaluation-detail.md

@@ -0,0 +1,23 @@
+## Agent / tool-use evaluation
+
+Two questions distinguish good agent eval from bad:
+
+### Question 1: outcome or trajectory?
+
+| Approach | What it checks | Failure mode |
+|----------|---------------|--------------|
+| **Outcome-only** | Did the agent achieve the goal? Was the final state correct? | Misses "ghost actions" — agent did the right thing for the wrong reasons |
+| **Trajectory** | Did the agent take the expected sequence of steps / tool calls? | Punishes legitimate creativity — agent solved it via a different valid path |
+
+**Recommendation:** outcome-only with side-effect assertion as default. Trajectory match for cases where the path matters (e.g., "must call `get-user` before `update-user`").
+
+### Question 2: which trajectory match mode?
+
+When trajectory matching IS the right call, four modes are available:
+
+- **Strict** — same tool calls, same order, same arguments. Use when both sequence and parameters are part of the contract.
+- **Unordered** — same tool calls, any order. Use when concurrent calls are valid.
+- **Subset** — actual trajectory contains a subset of reference calls. Use to enforce "don't exceed expected tool use" (frugality / cost).
+- **Superset** — actual contains all reference calls plus possibly more. Use when specific tools are mandatory but extras are acceptable.
+
+See `agent-eval.md` for examples and the decision tree.

package/scaffold/skills/dw-llm-eval/references/anti-patterns-will-block-in-dw-review-code-only-detail.md

@@ -0,0 +1,9 @@
+## Anti-patterns (will block in `/dw-review --code-only`)
+
+- **LLM-as-judge without calibration evidence.** PR adds LLM-as-judge but the calibration Spearman score is missing or < 0.80. REJECTED.
+- **Same-model judge.** Judge model is the same as the system under test. REJECTED unless explicitly documented (and even then, results are suspect).
+- **Single-rung eval.** Feature ships with only LLM-as-judge; no rung 1-3 grounding. REJECTED — the cheap rungs catch the loud failures.
+- **Synthetic-only dataset.** No traceable production-failure source for any case. REJECTED — confirm at least 20% of cases come from real user inputs.
+- **"Looks good to me" QA.** No reference dataset, no metric, no rubric — just sampling output and calling it good. REJECTED.
+- **Coverage as metric.** Quoting "we tested 50 prompts" without saying what was measured. The number is meaningless without the metric.
+- **Single-run eval on a non-deterministic feature.** Each case run once at production temperature; a lucky pass reported as a pass. REJECTED — report `pass_rate` over N runs (see Consistency).

package/scaffold/skills/dw-llm-eval/references/bounded-decisions.md

@@ -0,0 +1,76 @@
+# Bounded decisions — when the answer space is already known
+
+A large share of model calls in a product do not need written text. The application already knows the
+possible answers and only needs one of them chosen: route this ticket to billing, technical or account ·
+is this message urgent · how severe is this incident on a 1-4 scale.
+
+Asking a generative model to *write* that answer means generating tokens one at a time, waiting for all of
+them, parsing the result, and handling the case where it came back malformed. None of that work is about
+the decision.
+
+When the answer space is fixed in advance, the model can **score the candidates instead of writing one**.
+The decision comes out of a single forward pass, as a distribution over the options you defined, with no
+tokens to parse and no malformed output to handle.
+
+This is not a new technique — multiple-choice benchmarks have been scored this way for years. It is worth
+writing down because product code rarely uses it, and because it comes with one trap that costs more than
+the speed it saves.
+
+## The trap: a probability is not a confidence
+
+Scoring returns numbers that look like probabilities. Treat them as calibrated confidence and you will make
+bad decisions with the appearance of rigour.
+
+Raw model probabilities are usually **badly calibrated**: a candidate holding 80% of the mass is not right
+80% of the time. Preference tuning (RLHF and its relatives) tends to make this worse, because it sharpens
+mass onto preferred answers beyond what their reliability warrants.
+
+**This is a different property from what `references/judge-calibration.md` requires.** That file asks for
+Spearman ≥0.80 between judge scores and human scores — rank agreement, which answers "does the judge order
+cases the way a human would". Calibration answers a separate question: "when it says 0.8, is it right 80%
+of the time". A judge can pass one and fail the other. Both matter, and they are not substitutes.
+
+Two honest ways to handle it:
+
+1. **Do not interpret the number as a frequency.** If all you need is a threshold to route or abstain, pick
+   the threshold empirically against your reference dataset and never publish the raw value as a
+   confidence. This is usually enough, and it is the cheapest correct answer.
+2. **Calibrate it post-hoc.** Fit a mapping from raw score to observed frequency on held-out cases
+   (Platt scaling, isotonic regression). Now the number means something, and you can report it.
+
+Either way, the reference dataset is what makes the number trustworthy — not the model that produced it.
+
+## What this gives your eval
+
+A generative judge returns a verdict. A scoring judge returns a verdict **and a distribution**, which lets
+the eval measure something accuracy alone cannot: whether the system knows when it is unsure.
+
+- Plot a reliability curve — bucket predictions by confidence, compare each bucket's confidence against its
+  observed accuracy.
+- Track expected calibration error across releases. A model swap can hold accuracy steady while wrecking
+  calibration, and accuracy-only evals will not show it.
+- Route the low-confidence tail to a human or a more expensive rung instead of accepting it silently. That
+  is the same escalation shape `references/oracle-ladder.md` describes between rungs.
+
+## Two ways to implement it
+
+**Score with the model you already run.** No new model, no new infrastructure: prefill the prompt and read
+the scores of the candidate answers. Cheapest to adopt.
+
+Two things to get right. First, if two options share their opening tokens, a naive first-token comparison
+picks between prefixes rather than between answers — score whole candidates and normalise by length, which
+is what serving frameworks that expose a choice primitive do by default. Second, the calibration problem
+above is at its worst here, because the model was tuned to sound confident.
+
+**Use a model built for typed decisions.** Purpose-built decision models take state plus a typed question
+and return a distribution directly, trained for calibrated output rather than for human preference. Better
+calibrated by construction, at the cost of another model to run, serve and keep current.
+
+The first is right when the decision rides alongside work a general model is already doing. The second
+earns its keep at high volume, where the decision *is* the workload.
+
+## When not to use any of this
+
+If the right answer is a sentence — an explanation, a summary, a written recommendation — the answer space
+is not bounded and none of this applies. Forcing it into a fixed set does not make it cheaper; it makes it
+wrong. Rung 4 with a calibrated generative judge remains the tool for subjective output.

package/scaffold/skills/dw-llm-eval/references/consistency-run-to-run-stability-detail.md

@@ -0,0 +1,10 @@
+## Consistency (run-to-run stability)
+
+The oracle ladder measures whether an output is *correct*; it does not measure whether the feature is *stable*. Because LLMs are non-deterministic, a case that passes once may fail the next run. Measure it:
+
+- Re-run each case **N times** (default 3) against the same code + model + prompt.
+- Record `pass_rate` (e.g. `2/3`) and `consistency` (fraction agreeing with the majority verdict) per case in `runs/<YYYY-MM-DD>.jsonl`.
+- A case with pass_rate strictly between `1/N` and `(N-1)/N` is **flaky** — a signal, not a pass. A 2/3 pass hides a one-in-three production failure; investigate before shipping.
+- Sample at the **temperature the feature uses in production** — consistency measured at temp 0 lies about a temp-0.7 feature.
+
+Deterministic rungs (1–3) are usually stable; consistency matters most for rung 4 (LLM-as-judge) and agent trajectories. Record the run count `N` in the run log so later comparisons are apples-to-apples.

package/scaffold/skills/dw-llm-eval/references/integration-with-dev-workflow-commands-detail.md

@@ -0,0 +1,6 @@
+## Integration with dev-workflow commands
+
+- `/dw-plan tasks`: when the PRD has an AI feature requirement, an eval-plan subtask is mandatory. The task references this skill's oracle ladder.
+- `/dw-review --code-only`: AI feature PRs require a reference dataset + ≥2 oracle rungs (lower rungs FIRST). The constitution gate also applies — if the project has principles about AI feature reliability, they're enforced here.
+- `/dw-qa --ai`: new mode (when this skill is bundled) — runs the reference dataset against the current implementation, logs to `QA/logs/ai/<feature>-<date>.jsonl`, computes precision@k / faithfulness / outcome accuracy per the feature type.
+- `/dw-bugfix` when the bug is an AI failure mode (hallucination, tool misuse, classification error): adds the failing case to the reference dataset BEFORE fixing — the case is now a regression test forever.

package/scaffold/skills/dw-llm-eval/references/judge-calibration.md

@@ -16,6 +16,11 @@ Process:
 4. Compute Spearman rank correlation between human scores and judge scores.
 
 **Target:** Spearman ≥0.80.
+
+> **This is rank agreement, not probability calibration.** Spearman answers "does the judge order cases the
+> way a human would". It says nothing about whether a judge reporting 0.8 is right 80% of the time — a
+> judge can pass this bar and still be badly calibrated. If your judge emits a confidence or a probability
+> and anything downstream reads it as one, see `references/bounded-decisions.md`.
 **Acceptable:** 0.70-0.80 with documented rationale (e.g., "subjective tone judgments inherently noisy").
 **Reject:** <0.70. The judge is not measuring what you think it's measuring.
 

package/scaffold/skills/dw-llm-eval/references/the-oracle-ladder-detail.md

@@ -0,0 +1,15 @@
+## The oracle ladder
+
+Five rungs, climb from CHEAPEST/STRICTEST to MOST EXPENSIVE/SUBJECTIVE. Always start at the bottom; only climb when the lower rung can't cover the case.
+
+| Rung | What it checks | Cost | When to use |
+|------|----------------|------|-------------|
+| 1. **Exact match** | `output === expected` | ~free | Structured outputs (function calls, JSON with stable shape, classifications) |
+| 2. **Schema validation** | Output matches JSON schema / type contract | ~free | Output shape matters; specific values vary |
+| 3. **Outcome state** | Side effect produced the expected change (DB row, file written, tool called) | cheap | Agents, tool-use, RAG with concrete answers |
+| 4. **LLM-as-judge** | A different model grades the output against a rubric | medium ($$$) | Subjective quality (helpfulness, tone, faithfulness) where no rule can decide |
+| 5. **Human review** | Domain expert scores | expensive | Calibration of rung 4; high-stakes outputs; edge cases |
+
+**Rule:** never reach for rung 4 before checking if rungs 1-3 can cover the case. Every rung up costs an order of magnitude more (latency, money, calibration effort) — and adds entropy.
+
+See `oracle-ladder.md` for examples per rung and the climbing decision tree.

package/scaffold/skills/dw-memory/SKILL.md

@@ -87,7 +87,7 @@ Create `MEMORY.md` and `<N>_memory.md` on first use with the template below. Nev
 
 ## Workflow
 
-### 1. Load before editing code
+### 1. Load relevant task memory on start or resume
 - Read `MEMORY.md` and the current task's `<N>_memory.md` **before** any code change.
 - Treat these as mandatory context for the run, not optional notes.
 - If the caller marks either file for compaction, apply the Compaction Rules (below) before continuing.
@@ -116,34 +116,7 @@ Create `MEMORY.md` and `<N>_memory.md` on first use with the template below. Nev
 
 ## Promotion Decision Test
 
-Before promoting an item from `<N>_memory.md` to `MEMORY.md`, ask:
-
-1. Will another task need this to avoid a mistake or rediscovery?
-2. Is this fact durable across multiple runs, not just the current execution?
-3. Is this information NOT already obvious from the PRD, TechSpec, task files, or the repository itself?
-
-All three must be "yes" to promote. If any is "no", the item stays in task memory.
-
-### Confidence signal
-
-Tag each durable decision with a confidence in `[0.3–0.9]` plus the tasks that confirmed it — `… — [confidence: 0.7; seen in tasks 1,3,5]`:
-
-- Confirmed in **≥2 of the last 3 tasks** with no contradiction → **≥0.7** (trust it; safe to act on without re-deriving).
-- Confirmed once, or inferred but not yet reused → **0.3–0.5** (tentative; gather more signal before relying).
-- Contradicted by a later task or the repo → lower it or drop the decision (see Error Handling).
-
-Confidence makes cross-task learning explicit and is the signal `/dw-learn` reads to promote high-confidence decisions into durable instincts, constitution principles, or rules.
-
-### Belongs in shared memory
-- A discovered constraint affecting multiple tasks ("the Stripe API rate-limits to 100 req/s — batch operations must respect this")
-- A cross-cutting architectural decision made during implementation ("chose React Server Components for data fetching across the whole feature")
-- An open risk future tasks must account for ("migration depends on schema v3 which is not yet deployed to staging")
-
-### Stays in task memory
-- Files touched during this task's implementation
-- Debugging steps taken to resolve a task-specific error
-- The current task's objective and acceptance criteria snapshot
-- A workaround applied only to the current task's scope
+For promotion decision test, read `references/promotion-decision-test-detail.md`. Load only when this part of the task applies.
 
 ## Compaction Rules
 
@@ -157,26 +130,7 @@ When flagged for compaction, apply inline:
 
 ## Context Budget
 
-Memory is part of a broader **context budget** the agent must respect during execution. A blown budget degrades reasoning before any output is produced — the model starts missing requirements, drops constraints, and reverts to averaged-over-training answers. Full guidance: [`references/context-budget.md`](references/context-budget.md).
-
-**Targets:**
-
-- **Total active context:** under **40k tokens** (rough working budget across PRD + TechSpec + tasks + MEMORY.md + per-task memory + open files).
-- **Reserve:** at least **120k tokens** of headroom for actual reasoning, tool output, and the model's response stream.
-- **Hard ceiling per memory file:** `MEMORY.md` ≤ 6KB; `<N>_memory.md` ≤ 3KB. Past those, compact instead of growing.
-
-**Anti-co-load rules** (apply on every load):
-
-1. Never load two PRD specs in the same context. If switching PRDs, drop the previous PRD's spec/techspec/tasks references from the active set.
-2. Never load multiple archived `.dw/bugfixes/` SUMMARY.md files together — load only what's needed for the active fix or query.
-3. Never load `.dw/intel/files.json` and `.dw/intel/deps.json` simultaneously when answering a single question — pick the primary per query shape (see `dw-codebase-intel/references/query-patterns.md`).
-4. Never load a design proposal AND the prior design's full text — if comparing, summarize the prior into 5-10 lines.
-
-**Monitoring signal:**
-
-If the agent finds itself reading large files repeatedly or summarizing the same fact across multiple turns, that's a budget signal. Compact memory and explicitly drop unrelated loaded context before proceeding. Note this in `MEMORY.md` under Handoff Notes so the next task starts lean.
-
-This budget is doctrine, not a hard gate. No command currently rejects work for exceeding 40k. The discipline lives here because future sessions read this skill first.
+For context budget, read `references/context-budget.md`. Load only when this part of the task applies.
 
 ## Error Handling
 
@@ -199,7 +153,7 @@ Ported from Compozy's `cy-workflow-memory` skill (`/tmp/compozy/.agents/skills/c
 
 - Paths are `.dw/spec/<prd-slug>/` instead of `.compozy/tasks/<name>/`.
 - Task-local file is `<N>_memory.md` next to `<N>_task.md` (mirrors the existing dev-workflow task layout).
-- Inline Compaction Rules (Compozy keeps them in `references/memory-guidelines.md`); the budget discipline was extracted to `references/context-budget.md` because it's about model behavior, not file management.
+- Inline Compaction Rules (Compozy keeps them in its upstream memory-guidelines reference); the budget discipline was extracted to `references/context-budget.md` because it's about model behavior, not file management.
 
 Credit: Compozy project (https://github.com/compozy/compozy).
 

package/scaffold/skills/dw-memory/references/context-budget.md

@@ -1,63 +1,15 @@
-# Context Budget — Discipline
+# Context and memory budget
 
-A working context window is finite. Past about 40k tokens of active content, model output quality degrades — the model starts to miss requirements, lose constraints, blur details across sources, and revert to training-set averages. This file codifies the discipline that keeps active context lean across a long dev-workflow session.
+Read when memory grows or repeated exploration obscures the active task. Context capacity and compaction behavior vary by host/model; do not assume a universal 40k active limit or 120k reserve. A model may expose telemetry; label estimates and unknown usage accurately.
 
-## The numbers
+Keep relevant requirements, constraints, decisions, pending work and evidence available. Read sections or query indexes when that answers the question. Comparing PRDs/designs or tracing source plus dependencies can require multiple sources; do not prohibit necessary co-loading. Avoid bulk-loading unrelated archived summaries or task memories.
 
-- **Target active load:** under **40k tokens** total — PRD, TechSpec, tasks, MEMORY.md, per-task memory, all open files together.
-- **Reasoning reserve:** **120k+ tokens** of headroom for tool output, model thinking, and response generation.
-- **Soft alert:** when active load crosses **30k tokens**, plan to compact before the next major task.
-- **Compaction threshold for `MEMORY.md`:** ≤ 6KB on disk.
-- **Compaction threshold for `<N>_memory.md`:** ≤ 3KB on disk.
+Use concise durable memory: target MEMORY.md at most 6KB and per-task memory at most 3KB, moving detailed logs to linked artifacts. These are project maintenance targets, not model capacity claims or task-completion gates. Preserve unresolved decisions, acceptance criteria, session identity and evidence when compacting.
 
-These are doctrine, not enforced by any hard gate. The cost of breaking them is degraded output, not a command failure. Catch it yourself; the framework can't.
+Repeated reads, growing summaries and confused task boundaries are reasons to inspect context use, not proof of exceeding a hidden token threshold. Update the checkpoint if context limits threaten continuity; otherwise continue authorized work. Do not promise to evict individual messages from a host's context.
 
-## The anti-co-load rules
+Use `../../dw-codebase-intel/references/query-patterns.md` for indexed queries when useful. Verification failures still require diagnosing actual code/environment; do not attribute them to context size without evidence.
 
-Each is a "do not load both simultaneously" pairing. Pick one; if you must consult the other, summarize it to 5–10 lines first and drop the full version.
+## Attribution
 
-1. **Two PRDs at once.** Working on `prd-foo`, then user asks about `prd-bar`? Finish `prd-foo`'s active turn first, drop its spec/techspec/tasks from active context, then load `prd-bar`. Never carry both spec sets.
-
-2. **Multiple archived bugfix SUMMARY.md files.** Bugfix history queries should go through `.dw/intel/bugfixes.json` (compact, indexed), not by reading 20 SUMMARY.md files. Read individual SUMMARY.md only when the user is acting on that specific fix.
-
-3. **Files.json + deps.json simultaneously.** They overlap. Each query has a primary file per `dw-codebase-intel/references/query-patterns.md`. Pick the primary; consult the secondary only if the primary returns nothing.
-
-4. **A design proposal AND its predecessor's full text.** When comparing two designs, summarize the older one to 5–10 lines (the deltas the new one addresses) and reference it that way. Don't carry both in full.
-
-5. **Per-task memories from non-adjacent tasks.** Only the current task's `<N>_memory.md` and the immediately-previous one (for handoff) belong in active context. Older `<N>_memory.md` files are durable storage — read them when explicitly handing back to an old task, not as part of routine loading.
-
-## The monitoring signal
-
-You will not see a token counter. You can't measure your own budget directly. But these are observable proxies that mean **you are over budget**:
-
-- You are reading the same file twice in the same session without it having changed.
-- You are summarizing the same fact across multiple turns to keep it in scope.
-- You are answering questions by re-deriving from the repo what a memory file would tell you in one line.
-- You are confusing details between two PRDs, tasks, or designs.
-- Your turn outputs are getting longer to compensate for context that is silently slipping out of the model's attention.
-
-When you notice any of these, stop:
-
-1. Compact `MEMORY.md` and the active `<N>_memory.md` per the Compaction Rules in `SKILL.md`.
-2. Explicitly state in chat what you are dropping from active context.
-3. Note the budget event in `MEMORY.md` under Handoff Notes ("compacted at task N — see this section for what was dropped").
-4. Resume the turn.
-
-## What is NOT a budget problem
-
-These look like budget problems but aren't — don't compact for them:
-
-- **A genuinely complex task.** Some features legitimately need many files. Read what you need; the alternative (working from partial context) is worse.
-- **A long verification report.** Verify output can be long. Don't summarize it before logging it to disk; truncate the chat surface, not the artifact.
-- **A long user message.** The user wrote what they wrote. Don't compact to shave their words.
-- **The first PRD load of a new feature.** First-load is fine; second-load of the same PRD in the same turn is the signal.
-
-## Integration with other skills
-
-- **`dw-memory` (this skill)**: compaction is the lever for memory files; this file describes when and why.
-- **`dw-codebase-intel`**: `query-patterns.md` defines the primary-vs-secondary rule that anti-co-load rule #3 references.
-- **`dw-verify`**: a budget-related degradation may show up as a verify regression. If verify keeps failing on facts the PRD already states, suspect budget before suspecting code.
-
-## Source
-
-Adapted from [`tech-leads-club/agent-skills/tlc-spec-driven`](https://github.com/tech-leads-club/agent-skills/tree/main/packages/skills-catalog/skills/(development)/tlc-spec-driven) (CC-BY-4.0, Felipe Rodrigues). The 40k target, the anti-co-load principle, and the monitoring-signal framing come from there. The specific anti-co-load pairings, file-size ceilings, and the integration with `dw-memory`/`dw-codebase-intel` are dev-workflow-specific.
+The earlier context-budget guidance adapted tech-leads-club's [tlc-spec-driven](https://github.com/tech-leads-club/agent-skills/tree/main/packages/skills-catalog/skills/(development)/tlc-spec-driven) (CC-BY-4.0, Felipe Rodrigues). This revision retains scoped retrieval and durable handoffs; rejects universal token thresholds and unconditional anti-co-loading rules. See docs/skills-ecosystem-comparison.md in the package source for the modernization decision.

package/scaffold/skills/dw-memory/references/promotion-decision-test-detail.md

@@ -0,0 +1,30 @@
+## Promotion Decision Test
+
+Before promoting an item from `<N>_memory.md` to `MEMORY.md`, ask:
+
+1. Will another task need this to avoid a mistake or rediscovery?
+2. Is this fact durable across multiple runs, not just the current execution?
+3. Is this information NOT already obvious from the PRD, TechSpec, task files, or the repository itself?
+
+All three must be "yes" to promote. If any is "no", the item stays in task memory.
+
+### Confidence signal
+
+Tag each durable decision with a confidence in `[0.3–0.9]` plus the tasks that confirmed it — `… — [confidence: 0.7; seen in tasks 1,3,5]`:
+
+- Confirmed in **≥2 of the last 3 tasks** with no contradiction → **≥0.7** (trust it; safe to act on without re-deriving).
+- Confirmed once, or inferred but not yet reused → **0.3–0.5** (tentative; gather more signal before relying).
+- Contradicted by a later task or the repo → lower it or drop the decision (see Error Handling).
+
+Confidence makes cross-task learning explicit and is the signal `/dw-learn` reads to promote high-confidence decisions into durable instincts, constitution principles, or rules.
+
+### Belongs in shared memory
+- A discovered constraint affecting multiple tasks ("the Stripe API rate-limits to 100 req/s — batch operations must respect this")
+- A cross-cutting architectural decision made during implementation ("chose React Server Components for data fetching across the whole feature")
+- An open risk future tasks must account for ("migration depends on schema v3 which is not yet deployed to staging")
+
+### Stays in task memory
+- Files touched during this task's implementation
+- Debugging steps taken to resolve a task-specific error
+- The current task's objective and acceptance criteria snapshot
+- A workaround applied only to the current task's scope

package/scaffold/skills/dw-minimalism/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dw-minimalism
-description: Pre-generation YAGNI gate. Before writing new code, infra, or abstractions, climb the decision ladder (need it? reuse? stdlib? native? installed dep? one line?) at the active lite/full/ultra intensity. Triggers from /dw-run, /dw-plan, /dw-review and any "add X / build Y" intent.
+description: Evaluate a proposed abstraction, module or dependency for unnecessary complexity during planning or a focused over-engineering review.
 allowed-tools:
   - Read
   - Grep
@@ -11,8 +11,7 @@ allowed-tools:
 # dw-minimalism — Write the Least Code That Solves the Problem
 
 The cheapest code to maintain is the code you never wrote. This skill runs a
-**pre-generation gate**: before producing a new function, file, dependency, or
-abstraction, justify it against a decision ladder. It is the missing rung
+**pre-generation gate**: when evaluating a proposed abstraction or module, assess its necessity against the task requirements. It is the missing rung
 between `dw-search-first` (which evaluates *external dependencies*) and
 `dw-simplification` (which cleans up code *after* it exists).
 
@@ -21,9 +20,9 @@ between `dw-search-first` (which evaluates *external dependencies*) and
 Read this skill when:
 
 - `/dw-plan` is about to specify new modules/services — pressure-test scope before tasks are written.
-- `/dw-run` is about to implement — climb the ladder before the first line of new code.
+- A task proposes an abstraction or module whose necessity is unclear.
 - `/dw-review` flags over-engineering (speculative generality, premature abstraction, unused options).
-- The user (or a task) says "add X", "build Y", "create a helper/wrapper/abstraction for Z".
+- The user asks to assess whether a helper, wrapper, abstraction or dependency is necessary.
 
 Do NOT use to: