ワンクリックでManusで任意のスキルを実行

remediation-loop

スター0

フォーク0

更新日2026年6月20日 14:10

Use when independent verification returns any fail — route each fail to one of three exits (fix root cause / fix the table / accept with known defect), leave a trace, then re-verify. Bounded to one cycle before escalating. Part of meta-workflow (Step ⑤); uses superpowers receiving-code-review for posture.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

ZadAnthony

ZadAnthony/meta-workflow

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Step ⑤ — Remediate

Why this exists: a failed check has exactly three exits, and shipping it quietly is not one of them. The dangerous move is the silent fourth path: tweak the symptom until the verdict looks better, or quietly call it done. "I can't fix it, so I'll lower the bar" is hiding, not aligning.

The three exits (every fail goes to exactly one, with a trace)

Fix the output (default). Go to root cause, don't suppress the symptom to make the verdict look better. Then re-verify. (For metric claims, the fix is re-validated the same strict way it was caught — see references/hard-gates.md.)
Fix the table. Only if verification reveals the table itself was wrong → align toward truth, with explicit declaration + human sign-off + the time-anchor test from freeze-acceptance. Lowering the bar because it was hard is not this — that's the forbidden fourth path wearing a disguise.
Accept with a known defect. The human explicitly signs off on shipping with the fail → record it: which item failed, why, the recovery trigger, the owner. This is ship-with-defect, not done — never relabel it "complete" afterward.

Bounded loop

Default to one fix → re-check cycle. If it still fails on the second pass, do not auto-loop — escalate to the human (keep investing / fix the table / accept the defect). This keeps re-review cost from spiraling.

Feed the lesson back

If the root cause is a process / recurring problem, don't just fix this instance — pick a prevention layer (L1 code enforcement … L4 a written rule) and push it upstream. The closer to code, the more reliable. See references/prevention-layers.md.

Relationship to superpowers

superpowers receiving-code-review gives the posture: take feedback with technical rigor, not performative agreement and not blind implementation. This skill adds the three-exits discipline and the prevention-layer feedback.

このリポジトリの他の Skills

同じリポジトリ

freeze-acceptance

ZadAnthony/meta-workflow

Use after intent is clear and before building anything heavy — break the work into stages, write an acceptance table (expected value × how to verify × measurable/judgment), and freeze it with the human. Part of meta-workflow (Step ②); uses superpowers writing-plans for the breakdown. This is the core asset superpowers does not have.

2026-06-210

meta-workflow

ZadAnthony/meta-workflow

Use at the start of any non-trivial task to run it as a closed loop instead of a straight line — classify the task's weight, clarify the real goal, freeze acceptance criteria before building, execute, then independently verify "done AND good enough" before delivering. Orchestrates the step sub-skills and hands execution to superpowers. Skip for chat, lookups, and trivial one-line edits.

2026-06-210

clarify-intent

ZadAnthony/meta-workflow

Use when a task is classified design or build, before exploring solutions — pin the real goal (not the means), the constraints and key assumptions, and the success criteria, then show them to the human. Part of meta-workflow (Step ①); runs upstream of superpowers brainstorming.

2026-06-200

execute-with-spec

ZadAnthony/meta-workflow

Use when executing a frozen plan — hand the work to superpowers execution skills, and carry each stage's expected-value × how-to-verify into every sub-agent you dispatch (fractal hand-off). Part of meta-workflow (Step ③). Intentionally thin — execution itself is superpowers' job.

2026-06-200

independent-verify

ZadAnthony/meta-workflow

Use when work is built and before delivering — an independent reviewer (not the builder) checks each stage against the frozen acceptance table and issues a per-stage verdict. Metric claims get a stricter hand-recompute gate. Part of meta-workflow (Step ④); uses superpowers requesting-code-review. This is where most of the discipline lives.

2026-06-200

task-classification

ZadAnthony/meta-workflow

Use at the very start of a task, before anything else, to decide how much process it deserves — chat / trivial edits / simple docs get done immediately; design / build / exploration enter the loop. Judge by blast radius, not by how long the request was. Part of meta-workflow (Step 0).

2026-06-200

name	remediation-loop
description	Use when independent verification returns any fail — route each fail to one of three exits (fix root cause / fix the table / accept with known defect), leave a trace, then re-verify. Bounded to one cycle before escalating. Part of meta-workflow (Step ⑤); uses superpowers receiving-code-review for posture.

Step ⑤ — Remediate

The three exits (every fail goes to exactly one, with a trace)

Fix the output (default). Go to root cause, don't suppress the symptom to make the verdict look better. Then re-verify. (For metric claims, the fix is re-validated the same strict way it was caught — see references/hard-gates.md.)
Fix the table. Only if verification reveals the table itself was wrong → align toward truth, with explicit declaration + human sign-off + the time-anchor test from freeze-acceptance. Lowering the bar because it was hard is not this — that's the forbidden fourth path wearing a disguise.
Accept with a known defect. The human explicitly signs off on shipping with the fail → record it: which item failed, why, the recovery trigger, the owner. This is ship-with-defect, not done — never relabel it "complete" afterward.