accenture/mercury/apply-critique

apply-critique

⚠️ Tool-managed skill provided by agent-memory (provenance: agent-memory-builtin). Don't edit it

in place — it is overwritten on upgrade. To change behavior: fork it under a new skill name, or

upstream a genuine fix to the agent-memory project (file an issue in its repo, or bring it to the

tool maintainer) for back-port + validation. See SKILLS.md → "Tool-provided (system) skills".

Consumes the critique a clean-memory reviewer hands back from a `second-opinion` review and turns it into a bounded, validated set of changes — never an open autonomous loop. The critique is advisory: it is one input, gated by deterministic checks and a human decision.

When to use

After a fresh-context reviewer (a clean session or a different vendor) returns a critique of a snapshot you generated with second-opinion. The human points you at the critique (a pasted block or a review-scratch/critique-<UTC>.md file).

What to do

1. Parse the critique into: critical issues, gaps, design feedback, execution guidance,

risks, confidence. (The expected shape is below; tolerate a free-form critique by mapping it onto these buckets.)

1. Plan a small, focused set of actions — only a handful of scoped changes that address

the critical issues and execution guidance. A bounded repair, not a rewrite. State the plan before editing.

1. Apply the scoped changes.
2. Validate deterministically:

• the target's build / tests for code changes;
• `memory-lint` (python3 agent-skills/memory-lint/scripts/memory-lint.py) if any

memory/ file changed.

• If neither gate applies (e.g. a docs-only change in a repo with no test suite and no

memory/ edit), say so explicitly in the summary — the change then rests on judgment alone, which the human must know. This is exactly the failure mode the deterministic gate exists to prevent, so don't let "no gate fired" pass silently. A failing check blocks the change — fix or revert; do not paper over it.

1. Summarize applied vs. rejected recommendations and why. A recommendation you

disagree with is fine to reject — say so explicitly. A genuine conflict you can't resolve becomes a - [ ] Contradiction: Open Thread (never-pick-a-winner), not a silent overwrite. The human gates the result.

1. Record it. A critique→repair cycle is a memory-relevant event → write a normal

session log with a ## Memory References section (it stays inside the existing ritual, not beside it).

Critique template (what the reviewer should return)

# Fresh-Context Critique
 
## Summary
## Critical Issues
## Gaps
## Design Feedback
## Execution Guidance
1.
2.
## Validation Strategy
## Risks
## Confidence

Notes

• Bounded, not autonomous — a small number of scoped actions per cycle; re-snapshot and

re-review if more is needed, rather than looping unattended.

• Deterministic gate over LLM judgment — the reviewer (and you) can miscount or

misjudge; build/tests and memory-lint are the objective backstop. This is the lesson the memory layer already learned the hard way.

• No-code, agent-run — you apply changes and run checks at the human's direction; the

tool itself runs nothing (no-build-step-agent-run).