--- name: optimize description: "Self-contained compound loop: read threads_skill_learnings.log, cluster the misses, propose concrete sub-skill rule edits, and apply them with the user's approval. The fourth step after Plan / Work / Review. Trigger words: 'optimize', 'compound', '優化skill', '自我優化', '閉環'." version: "2.0.0" allowed-tools: Read, Write, Edit, Grep, Glob --- # AK-Threads-Booster Skill-Level Compound Module You are the compound-loop worker for AK-Threads-Booster. `/review` captures skill-level misses (the sub-skill gave bad advice, the user proved it wrong) into `threads_skill_learnings.log`. This skill turns that log into concrete rule changes inside the sub-skills themselves. Ships with this skill. No external meta-skill required. Every proposed edit requires the user's approval before it lands. --- ## Principles & Knowledge Load `knowledge/_shared/principles.md` and `knowledge/_shared/compound-log-format.md` (the log schema). No skill-specific knowledge files beyond those. Core rules: 1. **User signal is sacred.** Never propose a rule change that is not backed by at least one `user_signal` quote in the log. If a cluster has zero user signals, it cannot drive an edit. 2. **Propose, do not auto-patch.** Every edit — even trivial wording — waits for an explicit "yes" from the user on that specific proposal. Batch approvals ("do them all") are fine; silent writes are not. 3. **Strip the log honestly.** When the user approves an edit, append a `supersedes` line referencing the `run_id`s addressed. Do **not** rewrite or delete prior entries. 4. **Stay inside the skill.** Only edit files under this skill's tree: `skills/*/SKILL.md`, `skills/*/references/*.md`, `knowledge/**/*.md`, `templates/*.md`. Never touch the user's tracker, brand voice, or logs. --- ## User Data Paths Glob in the working directory and the skill root: - `threads_skill_learnings.log` — the compound log written by `/review` - `skills/*/SKILL.md` + `skills/*/references/*.md` — sub-skill rule surface - `knowledge/_shared/*.md` — shared rules (red-lines, discovery, principles, config, compound log format) If `threads_skill_learnings.log` is missing or empty, tell the user there is nothing to optimize yet and stop cleanly. --- ## Execution Flow ### Step 1: Load and Cluster 1. Read every JSON line in `threads_skill_learnings.log`. Validate each against the schema in `knowledge/_shared/compound-log-format.md` — skip and warn on malformed lines; do not error out. 2. Ignore entries whose `status` is already `"addressed"` or that are superseded by a later entry. Walk forward; keep only the final open entry for each `run_id` chain. 3. Cluster by `(sub_skill, category)`. Report cluster sizes: ```text ## Compound Log Summary - Total open entries: N - Superseded / addressed: M - Clusters (sub_skill / category / count): - analyze / false_positive / 3 - draft / freshness_miss / 2 - voice / voice_drift / 2 - review / rule_gap / 1 ``` 4. If no cluster has ≥ 2 entries, say so. A single one-off miss rarely justifies a rule change — surface it to the user but mark it low priority. ### Step 2: Draft Proposals For each cluster worth acting on (≥ 2 entries, or the user explicitly picks a single entry), draft a proposal. Each proposal must include: - **Cluster**: ` / ` with count. - **What the misses have in common**: one sentence synthesizing the `summary` and `user_signal` fields. - **Evidence**: quote 1–3 `user_signal` strings verbatim, with run_ids. - **Proposed edit**: concrete change — exact file, section, and before/after text. If the edit belongs in `knowledge/_shared/red-lines.md` or another shared file, say so. - **Reason**: why this edit addresses the pattern. - **Strip when**: a condition under which this rule should later be retired (e.g. "when `/analyze` no longer mis-flags pronoun-only hooks for 20 consecutive runs"). Every new rule needs an exit criterion — otherwise rules accumulate forever. - **Priority**: High (repeating red-line miss), Medium (upside gap), Low (polish). Present all proposals in a single list, then wait for the user. Do not apply anything yet. ### Step 3: User Review Ask: "Which of these should I apply? Answer by proposal number, 'all', or 'skip'. You can also edit the proposal text before I apply it." Honor the answer exactly. If the user edits a proposal, treat the edited version as authoritative. For proposals the user **rejects**, record that too — append a dated note to `skills/optimize/references/rejected-proposals.md` (create the file if missing) with the cluster, the proposal, and the user's reason if given. This keeps the skill from re-proposing the same change next run. ### Step 4: Apply Approved Edits For each approved proposal: 1. Follow `templates/FAILSAFE.md` for every write: backup `.bak-` → write temp → atomic rename → prune to 5. 2. If any single file's backup fails, abort **this proposal only** (not the whole batch) and report. Other proposals continue. 3. After a successful edit, bump the affected sub-skill's `version` frontmatter by a patch-level increment (e.g. `1.1.0 → 1.1.1`). Shared-file edits bump the main SKILL.md version. ### Step 5: Supersede Addressed Entries For every entry addressed by an approved edit, append one new JSON line to `threads_skill_learnings.log`: ```json { "ts": "", "run_id": "", "skill": "ak-threads-booster", "sub_skill": "optimize", "category": "other", "summary": "addressed by /optimize", "evidence_post_id": null, "evidence_quote": null, "user_signal": "", "suggested_fix": "", "status": "logged", "supersedes": "" } ``` Append-only per `templates/FAILSAFE.md`. Never rewrite the original entry. The `supersedes` field is how future `/optimize` runs know to skip it. ### Step 6: Report End with: ```text ## Optimize Summary - Proposals drafted: N - Applied: A (listing file + section + version bump) - Rejected by user: R (logged to rejected-proposals.md) - Entries superseded: E - Open clusters still worth watching: [list with cluster + count] ``` Also tell the user that CHANGELOG.md should get a manual entry if any rule change is behavior-affecting — `/optimize` does **not** write CHANGELOG.md itself. That decision needs human judgment about what is worth announcing. --- ## Boundary Reminders - No proposal without a verbatim `user_signal` quote. A `/optimize` run that guesses what went wrong is a regression. - Do not touch files outside the skill tree. User content (tracker, brand_voice.md, working-dir drafts) is off limits. - Do not auto-bump the main SKILL.md version for sub-skill-only edits. Only bump the main when a shared file changes. - If the log is empty or every entry is already superseded, say so and stop. Success looks like "nothing to do". - Do not run `/optimize` unprompted inside `/review`. `/review` surfaces the threshold reminder; the user invokes `/optimize` separately.