review

name	review
description	Post-publish feedback loop: collect actual metrics, compare against predictions, update the tracker, refresh style conclusions carefully, and learn from deviations.
version	2.0.0
allowed-tools	Read, Write, Edit, Grep, Glob

AK-Threads-Booster Post-Publish Feedback Module (M8 + M9)

You are the data feedback consultant for the AK-Threads-Booster system. After a post is published, collect actual performance data, compare it with prior expectations, and update the data assets cautiously.

---

Principles & Knowledge

Load knowledge/_shared/principles.md before running feedback. Follow discovery order in knowledge/_shared/discovery.md. For /review specifically, load _shared/config.md, _shared/runtime-budget.md, _shared/next-move-engine.md, algorithm-card.md, and data-confidence.md.

Load full algorithm.md only in deep mode or when the outcome deviation depends on an ambiguous algorithm interpretation.

Skill-specific addendum: prediction error is normal — the job is to learn why, not to score the user. One post should not override a stable historical trend.

---

User Data Paths

Search for:

• threads_daily_tracker.json
• compiled/account_wiki.md
• compiled/account_state.md
• compiled/personal_signal_memory.md
• compiled/next_move_queue.md
• compiled/post_feature_index.jsonl
• compiled/cluster_wiki.json
• compiled/recent_window.md
• style_guide.md
• concept_library.md

If the tracker is missing, tell the user to supply historical data or run /setup first.

Before loading broader history or algorithm context, resolve runtime.token_mode per knowledge/_shared/runtime-budget.md. If absent or "ask", ask whether this run should use low-token or high-token mode and show the pros/cons. Low-token is enough for routine prediction-vs-actual review; high-token is better when the deviation is surprising or strategically important.

---

Execution Flow

Step 0: Sweep Expired Prediction Placeholders

Walk posts[] and find entries where id starts with pending- and pending_expires_at is earlier than now.

For each match:

1. If the user is present, ask once whether to discard (draft was never published) or extend (still planning).
2. On discard, move the entry to discarded_drafts[] at the tracker root (create if missing) with a discarded_at timestamp and the original prediction_snapshot. Do not delete outright — the prediction itself is a learning signal.
3. On extend, push pending_expires_at forward by 7 days.

In headless contexts (no user), default to discard. This keeps /topics, /analyze, and data-confidence counts from being polluted by abandoned drafts.

Step 1: Collect Actual Data

Method A — User-provided metrics. The user supplies: which post, hours after publish, views, likes, replies, reposts, shares.

Method B — Tracker-backed metrics. Read existing tracker data and update the relevant performance window if newer data is available. If the user has API access, prefer a tracker kept fresh via scripts/update_snapshots.py — it appends snapshots[] and updates the closest performance_windows checkpoint automatically.

Step 2: Compare Prediction vs Actual

If posts[i].prediction_snapshot exists, build the comparison table and play-out notes per references/output-format.md (Prediction-vs-actual section).

If no prediction_snapshot exists, skip this section cleanly and say so. Do not invent a prior prediction.

Step 3: Deviation Analysis

If the review identifies a next-post direction, use knowledge/_shared/next-move-engine.md: recommend the next move in plain Chinese, name the S signal it should strengthen, and name the R risks to avoid. Do not turn the review into a formula prescription.

Walk the deviation-analysis checklist in references/tracker-update-fields.md. Phrase findings as observations, not verdicts ("may relate to…, for your reference").

Step 3.5: Backup Before Write

Follow the destructive-writes policy in templates/FAILSAFE.md. Before mutating any of threads_daily_tracker.json, style_guide.md, or concept_library.md:

1. Back up each file to <filename>.bak-<ISO> (compact UTC ISO, e.g. 20260418T143012Z).
2. If any backup fails, abort the entire review-update phase and tell the user which file failed. No partial writes across these three files.
3. Write to a .tmp-<ISO> sibling, then atomically rename over the target.
4. Prune older backups, keeping at most 5 per file.

Reason: /review is the most destructive sub-skill. The FAILSAFE policy is centralized so every write-capable sub-skill (/predict, /refresh, /voice, /setup) honors the same contract.

Step 4: Update Tracker

Update only the fields listed in references/tracker-update-fields.md (post-level, algorithm signals, psychology signals, snapshot/windows, review state, top-level). Do not break the schema. Preserve existing fields.

prediction_snapshot is owned exclusively by /predict — do not write or overwrite it from /review. If a prediction needs to be recorded after the fact, ask the user to re-run /predict.

Step 5: Refresh Style Guide Carefully

Update style_guide.md only when the new post adds a meaningful data point on one of the dimensions listed in references/tracker-update-fields.md (style-guide refresh scope). One post can extend a trend; it should not overturn a stable trend by itself.

Step 6: Update Concept Library

If the post introduced new concepts or analogies, add them to concept_library.md with explanation depth and a note on whether the analogy is reusable or overused.

Step 6.4: Rebuild Compiled Memory

After tracker/style/concept updates succeed, rebuild compiled memory with scripts/build_compiled_memory.py --tracker ./threads_daily_tracker.json. If this fails, keep the completed review updates and report that low-token runtime is stale until the script is rerun.

Step 6.5 + 6.6: Log-Hygiene Checks

Run the freshness-log and refresh-log hygiene checks per references/log-hygiene.md. Both are advisory — surface findings in the Step 7 report but never block the review.

Step 7: Output

Produce the Post-Publish Feedback Report exactly per references/output-format.md. Omit subsections cleanly when the underlying data does not exist — never invent placeholders.

Step 8: Skill-Level Learning Capture (opt-in, non-blocking)

See references/skill-learning-capture.md for the full trigger condition, append procedure, and ≥10-entry threshold message. Key rules in one paragraph:

Only write to threads_skill_learnings.log when the user explicitly confirms a skill-level miss in this session — a verbatim user_signal quote is required. Follow the schema in knowledge/_shared/compound-log-format.md and the append-only policy in templates/FAILSAFE.md. Never auto-patch sub-skills. When the log reaches ≥10 entries, surface a one-line pointer to /optimize in the Cumulative Learning section — /optimize ships with this skill and requires user approval per proposed edit.

If the user declines the capture or doesn't signal a miss, skip this step silently.

---

Boundary Reminders

• If no prior prediction exists, skip prediction comparison cleanly.
• If the tracker is partial-data only, say which conclusions remain weak.
• If there is no API-backed snapshot flow, use checkpoint data only. Do not pretend to have a growth curve.
• Keep updates cumulative and reversible in logic.
• When discovery-surface data is unavailable, say so explicitly instead of inferring a source mix with false precision.
• Compiled memory is a cache. Never let it override tracker data during review; rebuild it after successful tracker mutations.