| 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:
- 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.
- 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.
- Strip the log honestly. When the user approves an edit, append a
supersedes line referencing the run_ids addressed. Do not rewrite or delete prior entries.
- 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
-
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.
-
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.
-
Cluster by (sub_skill, category). Report cluster sizes:
## 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
-
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:
<sub_skill> / <category> 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:
- Follow
templates/FAILSAFE.md for every write: backup <file>.bak-<ISO> → write temp → atomic rename → prune to 5.
- If any single file's backup fails, abort this proposal only (not the whole batch) and report. Other proposals continue.
- 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:
{
"ts": "<ISO>",
"run_id": "<new uuid4>",
"skill": "ak-threads-booster",
"sub_skill": "optimize",
"category": "other",
"summary": "addressed by /optimize",
"evidence_post_id": null,
"evidence_quote": null,
"user_signal": "<verbatim original user_signal that drove the edit>",
"suggested_fix": "<file:section that was edited>",
"status": "logged",
"supersedes": "<original run_id>"
}
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:
## 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.