菜单
Use when you have spare capacity and want to set your system improving without active attention. Operator-invoked only, never scheduled. Safe, additive, reversible hygiene work runs under a threshold model with a permanent floor of actions the agent never takes on its own.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | autonomous-improvement-session |
| description | Use when you have spare capacity and want to set your system improving without active attention. Operator-invoked only, never scheduled. Safe, additive, reversible hygiene work runs under a threshold model with a permanent floor of actions the agent never takes on its own. |
| status | active |
| version | 1.1 |
This skill also ships inside the Sovereign Ecosystem template.
Purpose: Run a set-and-forget session that improves your system without your active attention. Burns extra capacity on low-stakes, additive, internal hygiene and improvement work. Tier 1 items land edits directly. Tier 2 items produce findings for your review. The skill is a recursive flywheel: a research rotation grows its own menu of improvement types every cycle, a threshold model lets execution authority climb one earned step at a time, and a decision board lets you ratify that climb on your own schedule. Menu growth is fast and wide. Execution authority is slow and earned.
Trigger: Operator-invoked when extra capacity exists. Examples: heading out, end of week with capacity to burn, end of session with remaining budget. Never scheduled, never auto-fired.
Inputs: A run-log file (path of your choosing, defaults to Logs/Autonomous Improvement Log.md) where state lives in frontmatter. Optional invocation hint: number of items to run, a tier preference, or a "full sweep" override.
Outputs: One appended entry at the top of the log body and a regenerated decision board (a file adjacent to the log, such as autonomous-improvement-decision-board.md). Tier 1 items leave evidence as edits in their target files. Tier 2 items fold their findings into the decision board.
Output doctrine. The decision board is the single decision surface. No skill-generated report files land in your inbox. Your inbox is a routing queue for genuine inbound notes, not a place for this skill's output. The run-log entry plus your version control commit is the durable breadcrumb, lightweight by design.
This is an autonomous improvement and hygiene engine. The default verb is DO, not propose.
If an action is additive, reversible, system-internal and touches no deletion, no canonical-governance ratification, no voice and no outward surface, execute it and record it in the run log. Do not ask. Routing an inbox item to its container, archiving an implemented plan, fixing a reference to a retired artifact, adding a missing index entry, normalizing a slug: these are the work, not proposals. If something is broken or missing and the clean fix is obvious and safe, make the fix.
Surface to the operator only two things. First, a genuine judgment fork: the routing heuristics conflict or none clearly applies, the situation is materially novel, intent is ambiguous and the choice would set a pattern, or the action is reversible but high-impact (touches many files at once or a high-inbound-reference artifact). Second, anything that touches the Permanent Floor. These two reflexes are opposite and must not blur: safe work is act-then-show, floor-class work is surface-then-wait. "Do not ask" governs the safe domain. It's never license to act on a floor item, and the floor's existence is never license to ask about safe work near it. A clean run leaves the Approvals bucket near empty, because the safe work is already done and sits in the Completed bucket for review.
The flywheel runs at two speeds on purpose. Menu growth is fast and wide: the research rotation casts a wide net for categories and mechanisms of improvement, and the menu of things the skill knows how to do grows every cycle. Execution authority is slow and earned: v1 keeps today's line, and the line climbs item by item only through ratified decisions. Wide net for ideas. Narrow gate for action. The gate widens only with proof.
Every menu item and every discovered action carries an autonomy level. The level governs execution authority. It's distinct from the tier, which governs output shape: Tier 1 lands edits, Tier 2 writes findings.
A skill-level auto_execute_threshold lives in the log frontmatter and defines the line. It starts at 1. At or below the line the agent executes. Above the line it parks to the decision board. The threshold and per-item levels move only through ratified decisions logged in the run history. Nothing raises its own autonomy.
v1 posture: threshold 1, every starter item Level 1. The autonomy field becomes important as the menu grows and new items arrive carrying judgment forks or structural reach.
One review surface. The closing output is the board, and a durable backing file holds the same content for continuity across sessions. The board is regenerated each run with the current run's open decisions. Resolved decisions log to the run log, not the board.
Four buckets:
The menu grows every cycle through the research rotation. These starter items ship with the skill. They cover the most portable, universal hygiene that applies regardless of what your system contains.
Tier 1 (autonomous, edits land directly): All Tier 1 items are additive, reversible, system-internal and Level 1 at v1.
T1-1: Reference integrity re-sweep. Walk your active system containers and check internal references (wikilinks, file paths, imports). For each broken reference, if the target exists at a slightly different path (renamed, moved, suffix added), fix the reference in place. Skip references where the target genuinely does not exist anywhere. Surface those counts to you in the run entry. Eligibility: not run in 7+ days.
T1-2: Index regeneration. Run any index-generation scripts present in your scripts directory. Confirm the regenerated index shows the correct total count. Sweep index frontmatter fields for references pointing at paths that no longer exist and update each to the current path. Scope to frontmatter fields only, never prose mentions (prose is intentional history). Eligibility: condition-based. Eligible whenever an artifact was added, archived or had its status change since the last index build.
T1-3: Anti-AI sweep on draft articles. Glob all draft markdown files in your drafts directory with a draft or ideas status marker. For each, run your writing style codex sweep against the file body. Apply approved find-and-replace transforms in place. Leave judgment-required findings as inline comments for your review. Skip files already swept since they were last edited. Eligibility: not run in 7+ days. Skip entirely if your system does not ship an Anti-AI Writing Patterns document.
T1-4: Memory file slug normalization. Walk all files in your AI interface's project memory directory. Grep for link variants using hyphens where the slug exists on disk with underscores (or vice versa). Verify the canonical variant exists. If yes, replace the non-canonical form. Surface any links where neither variant exists. Eligibility: not run in 14+ days.
T1-5: Index completeness sweep. Glob your codices or reference files. For each with an active status marker, check whether it appears in the master index. For each active file absent from the index, add an entry in the correct category section. Skip files intentionally held out of the index. Surface any ambiguous category placements as judgment forks; add the unambiguous ones. Eligibility: condition-based. Eligible whenever an active reference file is absent from the index.
T1-6: Superseded-artifact sweep.
Grep active containers for files with a status: superseded or status: retired marker that still sit outside your archive location. For each with an explicit superseded-by pointer or clear archival destination, archive it, run the reference-repoint sweep (grep for the old path and repoint active references to the canonical superseder, not the archive), regenerate any affected index. Surface only: a superseded file with no destination pointer. Act on the clear cases.
Eligibility: condition-based. Eligible whenever a superseded or retired file sits in an active container.
T1-7: Runtime log rotation. For each operational log that exceeds its line cap (default: 2000 lines), truncate to the last N lines. This is operational maintenance of a transient append log, not content deletion. List stale operational files (30+ days old, not active state files) as operator-approved removal candidates. Do not delete them. File deletion is the Permanent Floor. Eligibility: condition-based. Eligible whenever a named operational log exceeds its line cap.
T1-8: Skill mandatory-sections completeness sweep. Glob all skill files. For each, check for the sections the system calls mandatory: Purpose or Trigger, When to Use, Steps or Behavior, Constraints, Refinements. For each skill missing only a Refinements section, append an empty stub (additive and reversible). Surface as read-only findings (do not auto-edit): any skill missing Constraints, When to Use or Steps. Composing those sections is authoring, not a stub. Eligibility: condition-based. Eligible whenever a skill file lacks a Refinements section.
Tier 2 (autonomous, read-only scans, findings to the decision board): All Tier 2 items are Level 1 at v1. Producing a read-only finding is fully autonomous.
T2-1: Inbox triage sweep. Walk your inbox. For each unrouted item, classify it against your routing heuristics and act: safely routable items route via file move. After any move, run the reference-repoint sweep for the old path. Hold-for-operator items (conflicting heuristics, real judgment, durable-role decisions) surface on the decision board. The hold-for-operator set stays narrow by design. Eligibility: condition-based. Eligible whenever the inbox holds unrouted items.
T2-2: Stale draft surface. Walk your drafts directory. For each draft older than 30 days, classify: ready-to-publish, event-gated or abandoned. Produce a report per content type. Eligibility: not run in 30+ days.
T2-3: External link rot scan. Sweep outbound URLs in published articles or published notes. Fetch each (HEAD or short GET), flag any 4xx or 5xx response. Skip URLs requiring auth, payment walls or known anti-bot surfaces. Eligibility: not run in 30+ days.
T2-4: Memory file cross-reference health. Walk all files in your AI interface's project memory directory. Extract every internal link. Check each target against the directory. Build a structured list of broken cross-refs plus a candidate-target inventory. Suggest the likely correct target from the inventory. Verify suggestions against live state before reporting. Eligibility: not run in 30+ days.
T2-5: Reference orphan and inbound-density report. For each codex or reference file in your active governance layer, count inbound references across the system. Flag every file with fewer than 5 inbound references as a low-pollination candidate. Sort ascending and write the report. Eligibility: not run in 60+ days.
T2-6: Skill cross-reference health. Walk all skill files. Extract every internal link. Check each target against the system. Build a structured list of broken cross-refs plus a candidate-target inventory. Suggest the likely correct target from the inventory. Eligibility: not run in 30+ days.
T2-7: Memory compression candidate report. Read your AI interface's memory index and walk each linked memory file body. Identify candidates for compression: entries that are stale, redundant or superseded by later refinements. Surface a prioritized list. Eligibility: not run in 60+ days, or when memory index exceeds your defined line cap.
T2-8: Breadcrumb propagation and stale-reference sweep. Gather changed governance artifacts from recent version control history (last 14 days). For each, grep the system for inbound references and documents that enumerate the same subject. For each with candidate parallel docs, check whether those docs reflect the change or carry a now-stale claim. Read-only. Propose the reconciliation; do not apply it. Check version history before calling any mismatch drift: mismatches often have intentional history. Eligibility: not run in 14+ days.
T2-9: Style-guide conformance sweep. Scope to durable canonical content only: reference docs, protocols, product pages and other content meant to stand indefinitely. Skip in-progress drafts and already-shipped ephemera; expression quality on live drafts belongs at drafting time, not a background sweep. If your system ships a style guide or an anti-AI writing-patterns document, check conformance against its stated rules (banned phrases, capitalization conventions, punctuation rules). Skip entirely if no such document exists. Read-only; every finding surfaces for review. Eligibility: not run in 30+ days.
T2-10: YAML frontmatter validity scan. Walk all files that carry YAML frontmatter. Parse each block. An unquoted colon inside a value (commonly a title or description field) can silently break the whole properties block, defeating every frontmatter-based check for that file with no visible error. Flag every file that fails to parse cleanly, with the specific line at fault. Eligibility: not run in 30+ days.
T2-11: MCP tool-description integrity sweep. Hash the descriptions of your active MCP tool schemas each run and diff against the prior hash. A tool description that changes without a corresponding version bump is the signature of a supply-chain rug-pull on a trust boundary you rely on. Flag any drift for review. Eligibility: not run in 14+ days.
Read the run-log file. Parse the frontmatter: menu_state map (item ID to last-run date), run_counter integer, auto_execute_threshold integer, research_state map (category ID to last-researched date) and priority_flags list. If the log does not exist, halt and surface: "Log file missing. Create the seed log per the SKILL.md and retry."
For each menu item (T1-* and T2-*), apply its eligibility rule against the state. Build an eligible-items list. If the operator passed an item name, narrow to that item only.
Three-tier eligibility (resolves the cooldown problem):
Any item listed in the log frontmatter priority_flags is eligible this run regardless of its day-window or last-run date. Consume the flag when the item runs and delivers.
No single run executes everything. Rank eligible items by priority, then select up to a budget of 8 per run. Priority, highest first: operator-flagged items lift to the top, research-surfaced high-value items lift next, staleness lifts an item the further it has sat past its window.
If the operator passed an item count, honor it against the ranked list. If they passed "full sweep," run every eligible item with no cap. Selection respects the threshold: only items at or below auto_execute_threshold execute. Eligible items above the line surface on the decision board instead.
Output a one-paragraph plan: "Running N items this session. Tier 1: [list]. Tier 2: [list]. Estimated wall time: [rough estimate]." This is the only announcement until close.
For each Tier 1 item, first check its autonomy level against auto_execute_threshold:
After each item completes, do a layer-1 opportunistic capture (Step 6), then move to the next item.
Immediately after each Tier 1 item completes, ask: "Did running this item surface any other opportunity types worth adding to the menu?" Capture findings as draft candidate entries. Findings flow into Step 9 synthesis.
Dispatch all Tier 2 items in parallel as Sonnet subagents (read-only scans are safely parallel). Each returns a structured finding. When a finding needs a ruling the return session should act on, mirror it as a board bucket-2 entry.
Single-context workers. Every worker prompt states: run single-context, do not spawn subagents. A worker that fans out returns narration about its own children instead of findings, and per-item results get lost in the hop. This rule applies to every dispatched worker, Tier 1 editors included, not just Tier 2 scans.
The research rotation is the engine of menu growth. It rotates through the research categories below. Keys how many it runs to how many categories exist: six or fewer categories means one per session, more than six means two per session. Read research_state, pick the least-recently-researched categories, dispatch one Sonnet worker per selected category. Each returns a self-ranked top-5 candidate list with a one-line "why this beat the rest." Candidates flow into Step 9 and surface on the decision board's bucket 3.
Research categories:
Ground-truth gate on state-claims. Any candidate that asserts a claim about the current state of an existing artifact gets verified against live state before it reaches the board. Run the cheapest live check (an ls, a grep, a scoped read) at the moment of surfacing. A candidate whose premise fails verification never reaches the operator. A forward proposal to build something absent needs no artifact check.
After execution completes, ask: "Did running this skill surface any defects, friction or improvements in the skill itself?" Capture as Layer 4 candidates. These propose modifications to this SKILL.md, distinct from menu-item candidates. Findings flow into Step 9 under their own category.
Aggregate the opportunistic capture, the research rotation, the self-refinement findings and every fork parked during execution into the four-bucket board. Apply the recommendation bar: if you wouldn't recommend a candidate, route it to Patterns Noticed as a one-liner rather than a decision. Every recommended candidate carries a proposed tier and a proposed autonomy level.
When a decision is nuanced, present Three Solutions: the situation, three real options, the one you recommend and its tradeoff. When it's simple, one recommendation. Never a bare open question.
Ground-truth gate on proposed plans. The operator approves plan creation from the premise stated in the cliff-note. If the cliff-note's operative claim is a state-claim about an existing artifact, verify it against live state before writing it to the board. A false premise spends a real approval and an entire later session on work that didn't need doing.
Append a run entry at the top of the log body. Update the frontmatter: set new last-run dates in menu_state for items that ran, set new last-run dates in research_state for each category researched, increment run_counter, set last_run. Leave auto_execute_threshold unchanged unless a return-session ratified climb moved it.
Write the four-bucket board to the decision board file, replacing the prior run's open decisions. Present the same board as the closing output.
Closing line: "Autonomous Improvement Session complete. [N] items ran. Decision board: [A] approvals and questions, [B] menu candidates, [C] proposed plans. Log and board updated."
The operator's board answers encode forward. This is the learning loop. The skill never modifies its own SKILL.md, menu or autonomy posture autonomously. Every move below is an explicit, operator-triggered edit cycle.
Bucket 2: Approvals and questions. Apply the decision to the parked work. If the answer carries a forward rule, encode it. A rule that turns a recurring judgment fork into a deterministic step is the recursion working: it can move an item from Level 3 to Level 2, or Level 2 to Level 1.
Bucket 3: Accepted menu candidate. Add the new menu item with execution spec, eligibility rule, output artifact and its assigned autonomy level, under the correct tier. Seed menu_state with today's date. Document the promotion in the run entry.
Accepted skill self-refinement. Edit this SKILL.md to apply it. Document it in the Refinements section with date and source-run reference.
Bucket 4: Approved plan. On an "approve plan creation?", draft the full plan using the board cliff-note as the seed. The plan starts at status: proposed. Plan creation is authorized; execution of the drafted plan is not, and runs in its own dedicated session later.
An item's autonomy level lowers, or the skill-level auto_execute_threshold rises, only through a ratified decision. The threshold widens from proven workflows, never from projection.
The safety guard sits in the Permanent Floor, not in the climb mechanics. A move that would touch an outward surface, delete, move a canonical file or self-edit breaches the floor and fails regardless of how high the threshold has climbed.
v1 is operator-invoked only. Scheduling is a future direction, gated on a track record of clean review-and-climb cycles, never a date. The likely shape, when it arrives, is several runs per week with different priority weightings and different subsets of research categories. The threshold model and the priority score already carry the machinery; scheduling just sets the cadence.
Single file at a path you choose (for example Logs/Autonomous Improvement Log.md).
Retention rule. At session open, when the log body exceeds roughly 1200 lines, compress the oldest full run entries into one-line summaries (run number, date, items executed, board outcome) until the body sits under 1000 lines, keeping the newest 8 runs in full. Frontmatter state is never compressed. The compression runs as part of the session; it needs no separate approval. The log that watches other logs' rotation carries its own window.
Frontmatter:
---
status: active
run_counter: 0
last_run:
auto_execute_threshold: 1
research_state:
R1:
R2:
R3:
R4:
R5:
R6:
R7:
R8:
R9:
priority_flags: []
menu_state: {}
---
Body: Reverse-chronological run entries. Newest at the top.
This section is the Hard Ceiling. It holds regardless of how high auto_execute_threshold climbs. No ratified climb, accepted candidate or forward rule may breach the permanent floor.
The ceiling is drawn by action type, not location. Destructive, voice-bound and outward-broadcast actions stay forbidden forever. Additive, reversible, build-verified correction opens as a gated lane that earns its way toward gateless operation one proven class at a time.
No threshold, climb, candidate or forward rule breaches these. Ever.
status: implemented plan from the active directory to the archive is operational lifecycle closure, not a governance move: it stays inside the system, it's reversible, it deletes nothing and it changes no governance.Two classes of action, both additive or corrective, never voice-bound, always reversible.
A fix enters at Level 3, propose-only. When you authorize a class, the form is a branch plus a pull request with a green build. You merge. A narrow class with a clean track record climbs to auto-open PR, then to auto-merge on green build, one ratified step at a time. The part that climbs away is the merge click, never the build gate.
Dispatch the cheapest model that does the job well. Before each delegated step, ask whether a smaller model would produce equivalent output.
| Work type | Model |
|---|---|
| Mechanical lookups, deterministic commands, structured extraction against a spec | Haiku |
| Multi-step synthesis, drafting, diagnosis, most worker dispatch | Sonnet |
| Architectural judgment, plan design, judgment-dense synthesis | Opus |
Set the model explicitly on every subagent dispatch. Never silently inherit the top tier.
Specific step routing:
| Step | Default model | Rationale |
|---|---|---|
| Step 1: Load state | Haiku | Mechanical YAML read with known schema. |
| Step 2: Compute eligibility | Haiku | Deterministic date math, no judgment. |
| Step 3: Select items by priority | Sonnet | Light prioritization across heterogeneous items. |
| Step 4: Announce plan | Sonnet | Operator-facing prose with capacity framing. |
| Tier 1 mechanical items (T1-1, T1-2, T1-4) | Haiku | Mechanical path and slug corrections. |
| Tier 1 judgment items (T1-3 anti-AI sweep) | Sonnet | Pattern-match with light inline-versus-fix judgment. |
| Step 7: Tier 2 worker dispatch | Sonnet | Read-only scans with structured synthesis. |
| Steps 6 and 8b: opportunistic capture and self-refinement | Opus | Reflection on what was just observed; judgment-dense. |
| Step 8: Research rotation workers | Sonnet | Parallel research workers per category. |
| Step 9: Synthesize the decision board | Opus | Classification, tier and autonomy judgment. |
| Step 10: Write log entry and board | Sonnet | Structured prose with state update. |
Session Closeout is the natural companion: run Autonomous Improvement at the end of a session when you have capacity to spare, then run Session Closeout to seal the session. Together they make the close a net-positive rather than just a wrap.
Pattern Harvest and Autonomous Improvement work the same flywheel from different angles. Pattern Harvest extracts durable patterns from external sources; Autonomous Improvement extracts improvement candidates from your own system's drift. Both feed the decision board.
If Session Closeout isn't installed yet: Install Session Closeout via Infinite Game OS. If Pattern Harvest isn't installed yet: Install Pattern Harvest via Infinite Game OS.
(Empty. Populated when execution mistakes occur during sessions.)
Use when a long-form manuscript (book chapter, ebook, multi-chapter playbook, long-form digital product) needs an editing pass to identify and remove AI writing tells. Sweeps across 8 pattern categories, assembles a structured edit packet for operator review, and applies approved edits.
Use when archiving several workspace artifacts at once with per-artifact approval gates before any archive move executes.
Use when deciding whether a piece of deterministic, no-judgment work should route to a secondary AI provider instead of your primary interface. Covers the provider catalog, the five-condition eligibility test and the dispatch script.
Retire a stalled or indefinitely-deferred plan without losing its value. Candidate scan, harvest, distribute, sweep, archive and codify.
Automated pull request review for your repos. Five parallel agents, confidence scoring, convention-file compliance, and GitHub comment posting.
Use when the operator wants parallel sub-agent research aggregated into a structured report. Spawns up to 4 independent workers each investigating a different angle, then synthesizes findings for operator review. Research feeds decisions, does not trigger execution.