--- 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 `.bak-` (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-` 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.