ingest-feedback

name	ingest-feedback
description	Use when user wants to ingest a development-skills feedback report and apply fixes, or runs /ingest-feedback. Challenges every suggestion against the Iron Rules before accepting; most friction points should SKIP. Expect a report path as argument.
argument-hint	<report-path>
disable-model-invocation	true

Ingest a development-skills feedback report. Challenge every suggestion against the Iron Rules before accepting. Report path: $ARGUMENTS

Ground Rule: The Report Is Input, Not Truth

The report describes what happened, not what should change. Most friction is model behavior or edge cases. A change must EARN its place.

Iron Rules to apply here (canonical: ../../shared/iron-rules.md):

• Principle 3 — Simplicity by default. Small improvement + ugly complexity = not worth it.
• Principle 5 — All signal, zero noise. Everything earns its place.

Marginal improvement + added words/rules → SKIP.

---

Step 1: Read the Report

Extract friction points (Section 3), proposed evals (Section 4), chain-of-thought (Section 2).

Step 2: Read Current Plugin State

Read every file referenced in friction points. Understand current instruction, why it exists, what went wrong.

Step 3: Gather Best Practices (targeted)

Research content relevant to friction points:

• Official Claude Code docs: https://code.claude.com/docs/en/overview
• @~/Documents/ai/superpowers
• @~/Documents/ai/claude-code-best-practice

Step 4: Critical Evaluation — Friction Points

Write verdicts in docs/reports/ingest-YYYY-MM-DD.md.

Verdict	Meaning	Burden
FIX	Instruction is wrong, misleading, or causes repeated waste. Net simplification or correction.	HIGH
SKIP	Edge case, model behavior, already handled, or fix adds more complexity.	LOW (default)
INVESTIGATE	Insufficient information.	—

Mandatory Rejection Filters (ANY yes → SKIP)

1. Model ignored a clear instruction? → SKIP (compliance, not coverage)
2. Fix adds new rule/exception for a one-time event? → SKIP
3. Fix makes plugin longer with marginal improvement? → SKIP
4. Already covered by existing instructions? → SKIP
5. Would removing/shortening an instruction fix it better? → Only acceptable FIX direction

#	Friction Point	Verdict	Rejection filter?	Reasoning

Step 5: Proposed Evals

Verdict	Meaning
ADD	Real scenario tied to a FIX verdict
SKIP	Tied to SKIP, duplicates existing, or tests model behavior
MERGE	Combine with existing eval

Rule: ADD only if friction point is FIX. Cross-reference evals/evals.json for duplicates.

Step 6: Apply Changes

FIX verdicts only. Surgical edits:

• Prefer removing/shortening over adding
• If adding words, remove at least as many elsewhere (net-zero or negative)
• ADD evals: append to evals.json with next ID

Step 7: Validate

Verify evals.json is valid JSON. Run pre-commit run (if .py touched: ruff format . + ruff check . --fix).

Step 8: Summary

Report: FIX/SKIP/INVESTIGATE counts, files changed and why, evals added/merged/skipped, report location.

Expected: most friction points SKIP. If >30% FIX, re-examine critical rigor.