Feedback Review

---
name: feedback-review
description: Batch-review the draft feedback rules captured automatically at session end by the correction detector and by wrap_session corrections — approve, reject, or flag conflicts in one pass. Use when the user says "review feedback drafts", "approve feedback drafts", "feedback drafts", "pending feedback rules", or when the injected SESSION.md shows a "Pending Feedback Drafts" section with a nonzero count.
---
<!-- generated by tools/build-codex-plugin.js from plugin/; edit the source there, not this file -->

> Host: Codex CLI, through the `agenticos` plugin. Invoke as `$agenticos:feedback-review`. `<plugin root>` is the plugin's folder, two levels above the folder that holds this SKILL.md; the `aos` launcher is `<plugin root>/bin/aos`. The tools of the `agenticos` MCP server are named `mcp__agenticos__<tool>`. A question to the user is one message with its options numbered (where it says multiSelect, the user may pick several); wait for the reply before acting on it.

# Feedback review — draft approval

Corrections the user made in past sessions are auto-drafted as feedback rules under
`brain/memory/feedback/_drafts/` (by the session-end correction detector, or by the
`corrections` you pass to `wrap_session`). This skill is the human half of the loop:
ONE batched approval, applied through `feedback-apply` (memory-writer underneath) so an
approved rule is identical to a hand-written one.

Vault: the `vault` value in `${CLAUDE_CONFIG_DIR:-~/.claude}/agenticos.json`.

## Steps

1. List pending drafts: Bash `aos feedback-apply --list` (fallback: `sh "<plugin root>/bin/aos" feedback-apply --list`). Output is `slug | title | description` lines. If it prints `no drafts pending`, say so and stop.
2. Read every listed draft at `<vault>/brain/memory/feedback/_drafts/<slug>.md`. A draft whose frontmatter tags include `status/needs-review` came from the regex prefilter with no model to distill a rule: its `## Rule` is the user's raw wording. Such a draft is **rewrite-or-reject** — never approve it verbatim: either edit its `## Rule`, `## Why` and `## How to apply` into a real rule first (edit the draft file in place) and then approve, or reject it.
3. Conflict-check in-session (no script, no model call): call the `feedback_rules` tool of the `agenticos` MCP server (`mcp__agenticos__feedback_rules`) once with `full: true` to get every active rule's text (without it the tool returns only an index of titles and descriptions; drafts are never in it), then compare each draft against them. A conflict means an agent obeying BOTH rules at once is forced into contradiction: they command opposite actions in the same situation, one forbids what the other requires, or they state incompatible values for the same fact (two canonical paths for the same binary; "always ask first" vs "never ask, just act" for the same action). Overlapping topics, redundancy, or rules about different situations are NOT conflicts. A conflicting draft is a MERGE candidate: present it with the conflicting rule named and recommend "merge into <rule>" rather than plain approval.
4. Ask ONE question (multiSelect: true) — never one question per draft. One option per draft: label = the slug (shortened to fit), description = `<title> — <description>`, prefixed `CONFLICTS with <rule>: ` when step 3 flagged it. More than 4 drafts pending → additional questions of up to 4 each. Selected options = approved.
5. For each approved slug: `aos feedback-apply --approve <slug>`. For an approved MERGE candidate: approve it the same way, then edit the two conflicting rule files into one merged rule (keep the newest guidance and the strongest **Why** / **How to apply**), delete the superseded file, and remove its line from `<vault>/MEMORY.md`.
6. If any drafts were left unselected, ask one follow-up question: "Reject the unselected drafts or keep them pending?" (options: "Reject them" / "Keep pending"). On reject, for each: `aos feedback-apply --reject <slug>`. Rejection is remembered — the slug is trail-logged so the detector never re-drafts the same rule.
7. If the vault is a git repository, offer to commit `brain/memory/feedback`, `MEMORY.md` and `brain/_index/feedback-metrics.jsonl` with the message `feat: apply reviewed feedback drafts`. Do not commit without the user's yes.
8. Report one line: `applied N, rejected M, still pending K`.

## Boundaries

- Never write to `brain/memory/feedback/` directly — approval goes through `feedback-apply` so `MEMORY.md` stays in sync.
- Never auto-merge conflicting rules without the user selecting the merge option.
- The weekly captured-vs-recurred counter belongs to the persona's reflect duty (`feedback-metrics.js`), not to this skill.