| 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:
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)
- Model ignored a clear instruction? → SKIP (compliance, not coverage)
- Fix adds new rule/exception for a one-time event? → SKIP
- Fix makes plugin longer with marginal improvement? → SKIP
- Already covered by existing instructions? → SKIP
- 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.
