mirror of
https://github.com/alirezarezvani/claude-skills.git
synced 2026-10-08 03:07:51 +00:00
generate-docs.py learns the agent-launcher domain (5 hardcoded maps extended); regenerated docs tree: 343 skill pages / 96 agent pages / 122 command pages (561 total). mkdocs.yml nav gains the Agent Launcher skill section (7 pages), 4 cs-agent-* agent entries, and 8 /cs:* command entries; all nav targets verified to exist. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012FwXG6TqCXKZQvF4iD69cv
87 lines
4.6 KiB
Markdown
87 lines
4.6 KiB
Markdown
---
|
|
title: "/skillopt-sleep — Slash Command for AI Coding Agents"
|
|
description: "Run or manage the SkillOpt-Sleep self-evolution cycle (review past sessions, replay tasks offline, consolidate validated memory + skills; can also. Slash command for Claude Code, Codex CLI, Gemini CLI."
|
|
---
|
|
|
|
# /skillopt-sleep
|
|
|
|
<div class="page-meta" markdown>
|
|
<span class="meta-badge">:material-console: Slash Command</span>
|
|
<span class="meta-badge">:material-github: <a href="https://github.com/alirezarezvani/2-claude-skills/tree/main/engineering/skillopt-sleep/commands/skillopt-sleep.md">Source</a></span>
|
|
</div>
|
|
|
|
|
|
You are driving **SkillOpt-Sleep**: a tool that lets this user's Claude agent
|
|
improve offline by reviewing past sessions, replaying recurring tasks, and
|
|
consolidating what it learns into **validated** memory (`CLAUDE.md`) and skills
|
|
(`SKILL.md`). It is gated like SkillOpt: a change is kept only if it improves a
|
|
held-out replay score, and nothing live is modified until the user adopts it.
|
|
|
|
## Requested action: $ARGUMENTS
|
|
|
|
(If `$ARGUMENTS` is empty, treat it as `status`.)
|
|
|
|
## How to run it
|
|
|
|
The engine is the `skillopt_sleep` Python package in this repo. Use the
|
|
**plugin's bundled runner** so the right interpreter and repo are on the path:
|
|
|
|
```bash
|
|
"${CLAUDE_PLUGIN_ROOT}/scripts/sleep.sh" <action> --project "$(pwd)" --scope invoked
|
|
```
|
|
|
|
`<action>` is one of:
|
|
|
|
| action | what it does |
|
|
|--------------|--------------|
|
|
| `status` | show how many nights have run + the latest staged proposal (READ-ONLY) |
|
|
| `dry-run` | harvest → mine → replay → report, but **stage nothing** (safe preview) |
|
|
| `run` | full cycle: also **stage** a reviewed proposal (still does NOT touch live files) |
|
|
| `adopt` | apply the latest staged proposal to live `CLAUDE.md` / `SKILL.md` (backs up first) |
|
|
| `harvest` | debug: print the recurring tasks mined from recent sessions |
|
|
| `schedule` | install a nightly cron entry for this project (`--hour --minute`, off-:00 by default) |
|
|
| `unschedule` | remove the nightly cron entry (`--all` to remove every managed entry) |
|
|
|
|
Default backend is `mock` (deterministic, no API spend). To use real budget for
|
|
genuine improvement, add `--backend claude` or `--backend codex`. To steer what
|
|
the optimizer writes, add `--preferences "<your house rules>"`.
|
|
|
|
## Steps to follow
|
|
|
|
1. **For `schedule`:** confirm with the user *before* running it. Unlike
|
|
every other action, `schedule` writes directly to the user's real
|
|
crontab the moment it runs (via `scheduler.schedule()` → `crontab -`) —
|
|
it is not a preview. Tell them what will be scheduled (project, hour,
|
|
minute, backend) and get an explicit go-ahead first. If they'd rather
|
|
review the exact line before anything is installed, offer
|
|
`${CLAUDE_PLUGIN_ROOT}/scripts/install-cron.sh` instead (prints the line;
|
|
installs nothing). Once they've confirmed, add `--yes` to the `schedule`
|
|
invocation in step 2 — the CLI itself refuses to install non-interactively
|
|
without it (defense-in-depth for anyone running the CLI directly, outside
|
|
this chat-confirmed flow); `--yes` is how you record that the confirmation
|
|
above already happened.
|
|
2. **Run the requested action** via the bundled runner above. Capture stdout.
|
|
3. **For `run` / `dry-run`:** after it completes, `Read` the generated
|
|
`report.md` in the staging dir it prints, and show the user:
|
|
- held-out score: baseline → candidate (the proof it helped)
|
|
- the gate decision (accept/reject) and the exact edits it proposes
|
|
- where the proposal is staged
|
|
4. **For `run` that produced an accepted proposal:** tell the user the diff is
|
|
staged and that **nothing live changed yet**. Offer to run `/skillopt-sleep adopt`.
|
|
5. **For `adopt`:** confirm which live files were updated and that backups were
|
|
written under the staging dir's `backup/`.
|
|
6. **Never** edit `CLAUDE.md` or `SKILL.md` yourself — only the `adopt` action
|
|
does that, with a backup. Respect the review gate.
|
|
|
|
## Safety reminders
|
|
|
|
- Harvest is **read-only** over `~/.claude`. Replay in `mock` mode runs no
|
|
shell side effects.
|
|
- The cycle stages proposals; the user is in control of adoption.
|
|
- `schedule` installs a real crontab entry immediately — it is not a preview,
|
|
unlike `run`/`dry-run`. Always confirm with the user first (see Steps to
|
|
follow, step 1), then pass `--yes`. Without `--yes`, the CLI itself refuses
|
|
to install non-interactively — that's a backstop for direct CLI use, not a
|
|
substitute for the chat confirmation above. `${CLAUDE_PLUGIN_ROOT}/scripts/install-cron.sh`
|
|
remains available as a print-only alternative for a user who wants to inspect
|
|
or hand-edit the line before installing anything.
|