[SkillOpt] SkillOpt-Sleep allows skills to evolve while the user is asleep.

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

【SkillOpt】寝る子は育つ？SkillOpt-Sleepで寝ている間にスキルが自己進化【Skill】 #AI - Qiita

はじめに Microsoftが公開している SkillOpt は、「エージェントのスキル（プロンプト/手順書）をニューラルネットの重みのように"訓練"する」というコンセプトのフレームワークです。 そこに2026年6月、SkillOpt-Sleep という新しいプレビュー機...

qiita.com

Introduction

Microsoft's SkillOpt (https://github.com/microsoft/SkillOpt) is a framework based on the concept of "training" agent skills (prompts/procedures) like the weights in a neural network.

In June 2026, a new preview feature called SkillOpt-Sleep was added. Roughly speaking, this feature "gives local coding agents (Claude Code / Codex / Copilot) a nightly 'sleep cycle,' allowing them to review their daytime usage logs, replay repetitive tasks, and propose what they've learned as verified long-term memory and skills."

We actually tested whether self-improvement could truly occur overnight based on actual daytime usage logs (in this case, manually executing tasks intended for nighttime during the day). We confirmed that intentionally incomplete skills, based on actual Claude Code usage logs and verified through a held-out gate, self-improved to the intended level. This article is a record of that verification.

At the time of writing, SkillOpt-Sleep is a preview feature, and its interface and behavior may change in the future.

What is SkillOpt?

SkillOpt is a framework that proposes a method of "training skill documents (Markdown like SKILL.md) like the weights of a neural network." It is a relatively new project, released on PyPI as v0.1.0 on June 2, 2026.

• Model weights are not changed at all (frozen agent)
• Skill documents (Markdown of several hundred to 2000 tokens) are treated as "parameters to be learned"
• Another "optimizer" model looks at the execution results (rollout) and adds bounded edits of add / delete / replace to the skill documents
• Edits are only adopted if the score improves in a held-out validation set (equivalent to approving updates in gradient descent)
• Training is stabilized by a text "learning rate" budget, a buffer for rejected edits, and epoch-level slow/meta updates
• No additional model calls occur during inference at deployment (zero inference-time overhead)

According to the official repository, 6 benchmarks x 7 models x 3 execution environments (direct chat/Codex CLI/Claude Code) SkillOpt achieved best or tie performance in all 52 cells of the CLI, reporting improvements of +23.5pt in direct chat, +24.8pt in the Codex agent loop, and +19.1pt in Claude Code in GPT-5.5 (paper).

SkillOpt itself is a tool for "training skills against benchmarks offline."

What is SkillOpt-Sleep?

SkillOpt-Sleep is a post-deployment (deployment-time) companion tool that applies the SkillOpt concept to "your own daily usage logs" (docs/sleep/README.md). Announced as a preview on June 15, 2026, it was officially released on PyPI as the skillopt-sleep CLI in SkillOpt v0.2.0 on July 2, 2026. This is an even newer feature, appearing approximately one month after the main SkillOpt application.

• No weight training required for the model
• Zero overhead during inference (nightly batch processing only)
• A combination of three ideas: SkillOpt (validation-gated bounded edits), Claude Dreams (offline integration/review-then-adopt), and agent-sleep (transferring short-term experience to long-term ability)

The official documentation (RESULTS.md) shows that in experiments using GPT-5.4-nano and SearchQA, accuracy collapsed from 0.554 to 0.026 (-52.8pt) without gates, while with gates it remained at 0.570 → 0.570 (safely rejected). Furthermore, in the public benchmark gbrain-evals, intentionally incomplete skills were evaluated using Claude Dreams. Demonstration results have been reported showing improvements from 0.00 to 1.00 in both Code and Codex.

The actual entry point for users is the CLI command skillopt-sleep (plugins for Claude Code/Codex/Copilot also internally use the same command), which has the following subcommands.

Although the word "Sleep" might suggest it runs at night, improvement tasks can be executed at night or other times via scheduling, such as with Cron. Since improvement tasks can be executed manually at any time, day or night, it's a good approach to run them at any time after accumulating logs from using the Skill for a while.

skillopt-sleep harvest # Performs only collection + task extraction (free, for debugging)
skillopt-sleep dry-run # Runs a full cycle and reports the results only (does not stage)
skillopt-sleep run # Runs a full cycle and stages proposals
skillopt-sleep status # Displays the latest staged proposals
skillopt-sleep adopt # Applies proposals (with backup)

Meaning of Each Process

The sequence of processes "harvest→mine→replay→consolidate→gate→stage→adopt," which appears repeatedly in the article, each has the following role:

Process	Meaning	Notes
harvest (collection)	Reads past session history (transcripts) accumulated in ~/.claude, etc.	Read-only. No changes made
mine (extraction)	Detects "recurring tasks" from collected sessions and extracts them as learning material (TaskRecord)	This is done either heuristically (detection of negative/positive feedback, etc.) or by synthesis using LLM
replay (re-execution)	The extracted tasks are executed again using the current skills/memory	This is reproduced offline in a night batch, separate from the actual daytime sessions
consolidate (integration and review)	Based on the results of replay (success/failure), the LLM's "optimizer" proposes specific editing suggestions for skills/memory	Suggestions are limited to bounded edits such as add/delete/replace
gate (validation gate)	The editing suggestions proposed in consolidate are scored on held-out (not used for learning) tasks, and are only adopted if they exceed the current score	This is SkillOpt-Sleep's safety mechanism. The role of filtering out bad proposals
Stage	Edits that have passed the gate are saved for review without being reflected in the final file.	The contents can be checked with the status command.
Adopt	Staged proposals are reviewed by a human and actually reflected in SKILL.md/CLAUDE.md.	A backup is automatically created before reflection.

Contents of the Staging Folder

The .skillopt-sleep/staging/<timestamp>/ folder created during the stage process actually generates the following files:

File	Content	Purpose
proposed_SKILL.md	Full text of the proposed SKILL.md	This content is copied directly to the production file during adopt
proposed_CLAUDE.md	Full text of the proposed CLAUDE.md	Same as above
report.md	Human-readable proposal summary	The exact content displayed by skillopt-sleep status
report.json	Machine-readable version of the same content as report.md	For reading from programs
manifest.json	Actual path of the production file (live_skill_path/live_memory_path) and whether or not SKILL/CLAUDE proposals exist	Configuration information for determining "where" and "what" the adopt command should copy
diagnostics.json	Details for each held-out task (baseline_score/candidate_score/holdout_detail, etc.)	Self-diagnostic information to review the reasoning behind that night's decisions later

I'll first share some points that are surprisingly easy to misunderstand, based on reading the source code (skillopt_sleep/cycle.py, harvest.py, mine.py, config.py).

How to interpret logs and output

Examples of run/dry-run/status/harvest output (JSON and text) appear many times in this article. I'll summarize the meaning of the frequently appearing fields beforehand.

Fields appearing in the results of a night cycle (run/dry-run):

Field	Meaning
night	Which night cycle it is (counter)
baseline	Score in the held-out task before applying the edit
candidate	Score in the held-out task if the proposed edit were applied
accepted	Whether the edit proposal for that night was accepted (true/false)
gate_action	The result of the gate's decision. accept_new_best (accepted), reject (rejected), etc.
n_sessions	Number of sessions collected by harvest
n_tasks	Number of tasks extracted and replayed by mine
n_accepted_edits / n_rejected_edits	Number of accepted/rejected edits
edits / rejected_edits	Specific details of accepted/rejected edits (target=target of edit, op=add/delete/replace, content=edit content, rationale=reason for acceptance)
staging_dir	Path to the staging folder where the proposal is saved
adopted	Whether automatic adoption was performed on the spot (default is false. A human must perform adopt separately)
tokens_used	Number of tokens consumed in that night's cycle

The gate will only accept the edit (gate_action: accept_new_best) if candidate exceeds baseline. If candidate is less than or equal to baseline, even the best edit proposal will be rejected (gate_action: reject), and the existing skill will remain unchanged.

Fields appearing in individual tasks (TaskRecords) extracted by harvest:

Field	Meaning
intent	What the user actually requested (prompt) for that task
context_excerpt	Additional interactions within the same session (e.g., negative feedback)
attempted_solution	The response the agent actually returned for that task
outcome	Success or failure of that task. fail (judged as failure based on negative feedback, etc.) / success (judged as success based on positive feedback, etc.) / unknown (no information available for judgment) / mixed (judgment is ambiguous due to more than 3 turns of interaction)
split	train (material for reflect) or val (target for scoring in gate)

I'll share some points that are surprisingly easy to misunderstand, based on reading the source code (skillopt_sleep/cycle.py, harvest.py, mine.py, config.py).

"Daytime use" and "nighttime processing" are separate events, but the 5 steps within nighttime processing are executed together.

• Daytime: Work as usual with Claude Code. SkillOpt-Sleep is not involved at all during this time. Claude Code itself is simply recording normal session logs under ~/.claude/projects/ as a secondary process (Claude Code does this by default even without SkillOpt-Sleep).
• The moment skillopt-sleep run is executed: This is the first time that harvest → mine → replay → consolidate → gate → stage run consecutively within a single process execution. Splitting the process into units like "harvest today, consolidate on another day" is not the default (there is a workaround for splitting by using the harvest command alone + --tasks-file to replay later).

If --target-skill-path is not specified, a new skill will be created in an unintended location.

By default in config.py, the target for evolution is:

~/.claude/skills/skillopt-sleep-learned/SKILL.md

This becomes a new managed skill. The project's existing CLAUDE.md file is not automatically rewritten.

Feedback Detection is Hardcoded to Use English Phrases (Verified)

The heuristics in harvest.py ("still wrong", "thanks", "lgtm", etc.) are defaulted to English only. This has been verified. When harvesting a session where negative feedback was sent in Japanese ("That's wrong. The Key Risks section and Confidence level are missing."), the results were:

• Without environment variables set: outcome: "unknown" (not detected as negative feedback)

• With SKILLOPT_SLEEP_NEG_FEEDBACK="That's wrong, it's not fixed yet" set: outcome: "fail" (correctly detected)

When communicating in Japanese, adding Japanese phrases to the environment variables SKILLOPT_SLEEP_NEG_FEEDBACK/_POS_FEEDBACK confirmed that the system can capture positive/negative user response signals in the same way as with English.

Verification Strategy

The verification was designed as follows: "Intentionally create a flawed skill, run actual Claude Code sessions, harvest the transcripts obtained, mine the results, and compare them before and after using held-out."

• Data Source: Actual Claude Code sessions run by the user (simulated "actual daytime use")

• Scope: Limited to a dedicated test project directory (--scope invoked) to avoid confusion with personal usage history

• Flawed Skill: Created a skill identical to the brief-writer seed of the public benchmark gbrain-evals (a brief creation skill lacking the "Key Risks section" and "Confidence:" notation), and explicitly specified it with --target-skill-path

Constraints of this Verification (Not Exactly Like Production Operation)

This article's verification includes "verification-specific steps" intentionally added to make the effect measurable, and it should be noted upfront that these steps will not occur in actual production operation.

What to do during verification	How to handle in production
Prepare a deliberately flawed SKILL.md	In production, don't deliberately break your skills. Just use your existing skills (including their imperfections) as they are.
Run claude -p multiple times in a row to artificially generate logs together	In production, just wait for logs to accumulate naturally as a byproduct of your normal work.
Intentionally mix negative/positive feedback	In production, this is a natural reaction that comes when you are truly satisfied/dissatisfied with the answer.
Run harvest alone first to check its contents	A debugging verification step that is often omitted in production.
Consciously perform "daytime log generation" and "nighttime processing" on different days	Do not consciously separate them in production. During the day, work proceeds normally, and processes only run when the system feels like it (or via an automatically scheduled execution).

On the other hand, the CLI commands used (harvest/dry-run/run/status/adopt) and their internal pipeline (harvest→mine→replay→consolidate→gate→stage→adopt) are completely identical to those used in production, and we are verifying their actual behavior, not just a simulation.

Regarding full automation in production (cron registration using skillopt-sleep schedule), we actually executed the schedule command in this environment and obtained the following results:

$ skillopt-sleep schedule --project ...
[sleep] crontab not found on this system. Add this line to your scheduler manually:
17 3 * * * mkdir -p "..." ; cd "..." && ...python.exe -m skillopt_sleep run ...

In environments where crontab does not exist, the system prompts for a command line to manually register the task and then terminates, which is a reasonable fallback behavior (as commented in skillopt_sleep/scheduler.py). In environments where automatic cron registration is not performed, you can register the displayed command yourself in a task scheduler or similar to run it at night on the same schedule.

Verification Environment

Item	Value
OS	Windows 11 Home
Python	3.12.7
SkillOpt	Equivalent to v0.2.0, commit e4ea6a6 (editable install with pip install -e ".[claude]")
Claude Code CLI	2.1.150
Model	Haiku

Procedure Overview

Step	Content	Category
1	Create a dedicated test project folder and place the defective SKILL.md file inside	Verification only
2	Run claude -p multiple times in that folder to generate a session history equivalent to a "daily usage log" (intentionally include negative/positive feedback)	Verification only
3	skillopt-sleep harvest: Verify that logs are collected and tasks are extracted correctly	Verification only (debug verification)
4	dry-run (verify wiring with mock → claude backend for production): Run through to replay → consolidate → gate	Same as production operation
5	status: Verify the staged proposal content	Same as production operation
6	adopt: Verify that SKILL.md is actually updated, and check the Before/After diff	Same as production operation

For an explanation of why the "verification only" step is necessary and how it differs from production operation, please refer to the previous section, "Constraints of this Verification."

Correspondence between the 3 stages of normal operation and this verification step

SkillOpt-Sleep's production operation consists of the following three main stages:

Stage	Content	Who/What Does It Do
① Daytime: Run Skill and obtain logs	Use Claude Code as usual. Logs are automatically recorded to ~/.claude as a byproduct.	Human (normal work)
② Nighttime: Review logs and create improvement proposals	harvest→mine→replay→consolidate→gate are executed in one command, and improvement proposals are staged	The system is fully automated (skillopt-sleep run)
③ Human decision on approval	Review the staged proposals and decide whether to adopt them	Human (status→adopt)

While expressing ② as "review logs and create improvement proposals" might sound like a human is making a visual judgment, in reality, no human intervention is involved. Reflect (editing proposals by LLM) → gate (verification with held-out scores) are processed mechanically in a single batch. Human judgment is only involved in ③. Furthermore, the expression "the next day" is not a strict constraint; it means that ③ can be performed at any time after ② is completed (in this verification, ① corresponds to Steps 1-2, ② to Steps 3-4, and ③ to Steps 5-6).

Verification Results

Step 1-2: Test Project Creation and Log Generation

A SKILL.md file lacking the "Key Risks section" and "Confidence:" notation was placed in a test project folder dedicated to verification.

name: brief-writer-planb
version: 0.1.0
description: Brief Writer (Plan B verification copy)

## Brief Writer

When asked, write a short, clear research brief that answers the question.
Keep it focused and readable. Lead with the answer.

Within this, multiple brief creation tasks were executed using claude -p. For example, the initial response to the task "Should we deprecate the legacy API?" lacked both "Key Risks" and "Confidence," as follows:

## Brief: Deprecating a Legacy API with Active Users
### Recommendation: Deprecate with a structured transition plan

You should deprecate the legacy API, but only with a well-defined migration path...

### Rationale
...
### How to make it work
...
### The risk of *not* deprecating
...
Bottom line: Deprecation is a feature, not a bug. Do it early, do it clearly, support the transition, then move on.

Following this, negative feedback was sent ("That's wrong, it's missing a Key Risks section and a Confidence indicator. Please redo it with both."), and the model immediately self-corrected within a single conversation.

### Key Risks
1. User exodus before migration. If the replacement API isn't ready or isn't clearly better, users may fork or switch to competitors.
2. Stranded critical integrations. Some users may have no bandwidth to migrate...
3. Hidden dependencies. ...
4. Timeline slip. ...

### Confidence: High

This approach aligns with how mature platforms (AWS, Google Cloud, Stripe) handle similar transitions...

This interaction was recorded as expected as a session under ~/.claude/projects/, and we confirmed that it could be correctly retrieved in the subsequent harvest.

Step 3: Harvest Results

Executing the skillopt-sleep harvest command correctly extracted tasks from the session (excerpt).

{ 
"tasks": [ 
{ 
"id": "task_6c20a6745066", 
"intent": "Using the SKILL.md in this directory as your guide, write a brief on whether to deprecate a legacy API with active users.", 
"context_excerpt": "Follow-up constraints from the same session:\n- That's wrong, it's missing a Key Risks section and a Confidence indicator. Please redo it with both.", 
"attempted_solution": "# Brief: Deprecating a Legacy API with Active Users\n\n## Recommendation: Deprecate with a structured transition plan\n\n...", 
"outcome": "fail", 
"reference_kind": "none", 
"split": "train", 
"origin": "real" 
} ]
}

The negative feedback sent earlier has been correctly reflected in context_excerpt as "Follow-up constraints from the same session," and outcome has been determined to be "fail". This confirms that the heuristic retry chain detection is functioning as intended for the actual session log.

Step 4: Dry-run / Run Results

The dry-run with the mock backend resulted in no change (this is expected behavior, as mock does not simulate actual training).

{
"night": 1,
"accepted": false,
"gate_action": "reject",
"baseline": 0.0,
"candidate": 0.0,
"n_tasks": 3,
"n_sessions": 3,
"n_accepted_edits": 0,
"edits": [],
"adopted": false
}

Next, when I ran the production run using the claude backend, I got the following result:

{ 
"baseline": 0.0, 
"candidate": 0.16666666666666666, 
"gate_action": "accept_new_best", 
"accepted": true, 
"edits": [ 
{"target": "memory", "content": "...always include a section titled 'Key Risks'"}, 
{"target": "memory", "content": "...always include a section titled 'Confidence'"}, 
{"target": "memory", "content": "...always include the text 'Recommendation' in the response"}, 
{"target": "memory", "content": "...do not ask the user for a format file or clarification—proceed immediately..."} 
]
}

The "Key" I was aiming for The "Risks" and "Confidence" parameters were correctly identified as learning targets, along with an improvement in the held-out score (0.0 → 0.167). In addition, two extra rules were picked up from the actual logs: "Include the word 'Recommendation'" and "Create the document immediately without seeking confirmation." Unlike predefined rule-based judgments like gbrain-evals, the actual harvest→mine flow uses a general rubric scoring system based on LLM, demonstrating that it can learn not only the intended content but also a wide range of improvement points picked up from the actual logs.

Step 5: Confirmation of Proposal Content (status)

Running skillopt-sleep status displayed the following proposal content:

[sleep] nights so far: 1
[sleep] project: C:\...\test-project
[sleep] latest staged proposal: C:\...\staging\20260711-153831

## SkillOpt-Sleep — night 1 report

- project: `C:\...\test-project`
- backend: `claude` replay: `mock`
-sessions harvested: 3
- tasks mined: 1 (replayed: 1)
- held-out score: 0.000 -> 0.167
- gate: accept_new_best (accepted=True)
-tokens used: 2593

### Accepted edits
- [memory/add] When writing a brief or structured document, always include a section titled 'Key Risks' 
_why: Failed outputs did not include the required 'Key Risks' section_
- [memory/add] When writing a brief or structured document, always include a section titled 'Confidence' 
_why: Failed outputs did not include the required 'Confidence' section_
- [memory/add] When writing a brief or structured document, always include the text 'Recommendation' in the response 
_why: Failed outputs did not contain the required word 'Recommendation'_
- [memory/add] When writing a structured document and no explicit format reference is provided, do not ask the user for a format file or clarification—proceed immediately with the document... 
_why: Agent was requesting a reference file instead of writing the document with required sections._

_Review, then run `/sleep adopt` to apply, or Discard this folder.

You can see all the information you need for the review at a glance, including the held-out score, the adopted edits, and the reasons for their adoption.

Step 6: Adopt Results - Before/After Comparison

When you run skillopt-sleep adopt, the staged suggestions are actually reflected in the file.

Before (SKILL.md):

---
name: brief-writer-planb
version: 0.1.0
description: Brief Writer (Plan B verification copy)
---

## Brief Writer

When asked, write a short, clear research brief that answers the question.
Keep it focused and readable. Lead with the answer.

After (CLAUDE.md, newly created after adopt):

<!-- SKILLOPT-SLEEP:LEARNED START -->
### Learned preferences & procedures

_This block is maintained by SkillOpt-Sleep. Edits here are proposed offline, validated against your past tasks, and adopted only after you approve them. Hand-edits outside this block are never touched._

- When writing a brief or structured document, always include a section titled 'Key Risks'
- When writing a brief or structured document, always include a section titled 'Confidence'
- When writing a brief or structured document, always include the text 'Recommendation' in the response.
- When writing a structured document and no explicit format reference is provided, do not ask the user for a format file or clarification—proceed immediately with the document, ensuring it includes the mandatory sections 'Key Risks' and 'Confidence' and the text 'Recommendation'.
<!-- SKILLOPT-SLEEP:LEARNED END -->

We were able to confirm that the initial target of missing "Key Risks" and "Confidence" was correctly learned and reflected based on the actual Claude Code usage logs. The original SKILL.md remained completely unchanged as designed by SkillOpt-Sleep, and the learned content was added to CLAUDE.md as a <!-- SKILLOPT-SLEEP:LEARNED --> block, reflecting the changes without altering existing descriptions. A backup was also automatically created during the adopt execution.

::: note
SkillOpt-Sleep evolves two separate files: SKILL.md (the skill itself) and CLAUDE.md (memory, where learned behaviors are stored). The optimizer decides which file to write to each time.
Looking closely at the status output in Step 5, all four edits that were adopted were [memory/add] (= target: "memory"), and there were no edits with target: "skill". This means that in this case, the optimizer determined that "these rules should be written to CLAUDE.md (memory) rather than the SKILL.md file itself."
Therefore, SKILL.md itself was not changed, and a new CLAUDE.md was created.

:::

Verification with Multiple Tasks

We also performed verification on different scales by increasing the number of tasks and running run multiple times. The measured values are compiled from started_at/ended_at/tokens_used recorded in report.json (all backends are Claude Haiku).

Number of Tasks	Duration	Tokens Consumed
1	1 minute 41 seconds	2,593
5	6 minutes 41 seconds	17,182
6	10 minutes 6 seconds	25,252

While there was a tendency for the duration and token consumption to increase with the number of tasks, it wasn't a simple proportional increase. This is likely because gate replays the entire val split each time it verifies candidate edits, so the number of calls changes not only depending on the number of tasks but also on the number of edits made to the candidates. Since this was a small-scale test with a limited number of tasks, the duration at a production scale, such as with the default value max_tasks_per_night: 40 in config.py, needs to be checked separately.

Detection of Japanese Feedback

We also separately verified whether negative feedback in Japanese could be correctly detected. After executing a new task, we submitted negative feedback in Japanese stating, "That's incorrect. The Key Risks section and Confidence level are missing. Please rewrite it including both." Simply setting the environment variable SKILLOPT_SLEEP_NEG_FEEDBACK="That's incorrect, it's not fixed yet" correctly detected the task's outcome as "fail". This confirmed that heuristics with default English phrases can handle Japanese feedback simply by adding an environment variable.

Discussion

We confirmed that the intended workflow—harvesting daytime usage logs and performing verified improvements via mine→replay→consolidate→gate at night—actually functions as intended. We were able to observe the entire process, from the intentionally incomplete SKILL.md file being correctly learned from actual Claude Code usage logs, to the held-out score improving, and the intended content (Key Risks / Confidence) being reflected in the actual file.

The following points were particularly impressive:

• The safety design using held-out gates is clearly visualized in the report (baseline → candidate scores, accepted/rejected edits and reasons), making it easy for humans to review what was learned and how.
• Learning content is added as a <!-- SKILLOPT-SLEEP:LEARNED --> block, and the design ensures that the original skill description is not altered at all.
• Without relying on fixed benchmark criteria, the LLM-based general rubric scoring allows for learning of not only targeted improvements (Key Risks/Confidence) but also additional improvements picked up from actual logs.
• Even parts not supported by default, such as Japanese feedback, can be extended with settings such as adding environment variables, offering flexibility.

It was a significant gain to confirm the core claims of SkillOpt-Sleep not only through evaluation with fixed benchmarks but also through verification using my own Claude Code usage logs.

Summary

• We verified SkillOpt-Sleep's original "harvest→mine→replay→consolidate→gate→stage→adopt" flow using actual Claude Code usage logs, confirming that it self-improved as intended (improvement in held-out score, adoption of specific edits, and successful adoption).

• We confirmed, with actual command output, that the intentionally incomplete "Key Risks"/"Confidence" omission in SKILL.md was correctly learned from the actual logs and reflected in CLAUDE.md.

• We confirmed that Japanese feedback can be detected in the same way as English feedback by adding environment variables.

• We confirmed that SkillOpt-Sleep's design philosophy, including the safety design using held-out gates, the possibility of reviewing edited content, and the append-type design that does not change the original skill description, functions properly in actual behavior.

In Conclusion

While evaluating and improving skills manually can be difficult, SkillOpt-Sleep allows you to collect logs of how people use skills and provide feedback during the day. When skills are not in use, the AI uses these logs to make improvements, creating a continuous improvement loop.
This tool is particularly useful if you want to know if the quality of your current skills can be improved, or if you want to improve skills but lack the necessary evaluation criteria.