selftune 0.2.31 → 0.2.32

package/skill/workflows/EvolveBody.md

@@ -10,21 +10,25 @@ LLM validates them through a 3-gate pipeline.
 selftune evolve body --skill <name> --skill-path <path> --target <target> [options]
 ```
 
-## Recommended Creator Loop
+## Recommended Package Evaluation Pipeline
 
-Before mutating routing or the full body, make sure the creator trust loop is in
-place:
+Before mutating routing or the full body, make sure the package evaluation
+pipeline is in place:
 
 ```bash
+selftune verify --skill-path <path>
 selftune eval generate --skill <name> --skill-path <path>
+selftune verify --skill-path <path>
 selftune eval unit-test --skill <name> --generate --skill-path <path>
+selftune create replay --skill-path <path> --mode package
+selftune create baseline --skill-path <path> --mode package
+selftune verify --skill-path <path>
 selftune evolve body --skill <name> --skill-path <path> --target <target> --dry-run --validation-mode replay
-selftune grade baseline --skill <name> --skill-path <path>
 ```
 
 If replay validation or the baseline is still missing, prefer filling that gap
 before live deployment. Body and routing evolution are much harder to trust than
-description-only changes when the creator loop is incomplete.
+description-only changes when the package evaluation pipeline is incomplete.
 
 ## Options
 
@@ -40,6 +44,7 @@ description-only changes when the creator loop is incomplete.
 | `--eval-set <path>`          | Pre-built eval set JSON                                                               | Auto-generated from logs |
 | `--dry-run`                  | Propose and validate without deploying                                                | Off                      |
 | `--max-iterations <n>`       | Maximum refinement iterations                                                         | 3                        |
+| `--confidence <n>`           | Low-confidence review threshold (warning/escalation only)                             | 0.6                      |
 | `--task-description <text>`  | Context for the evolution goal                                                        | None                     |
 | `--validation-model <model>` | Model for trigger-check validation calls (overrides `--student-model` for validation) | None                     |
 | `--validation-mode <mode>`   | Validation strategy: `auto`, `replay`, or `judge`                                     | `auto`                   |
@@ -65,15 +70,17 @@ teacher generates a complete replacement, validated through 3 gates.
 
 Every proposal passes through three sequential gates:
 
-| Gate                          | Type        | What it checks                                                                                  | Cost     |
-| ----------------------------- | ----------- | ----------------------------------------------------------------------------------------------- | -------- |
-| **Gate 1: Structural**        | Pure code   | YAML frontmatter present, `# Title` exists, `## Workflow Routing` preserved if original had one | Free     |
-| **Gate 2: Trigger Accuracy**  | Replay or student LLM | Runtime replay when available; otherwise YES/NO trigger check per eval entry                     | Cheap    |
-| **Gate 3: Quality**           | Student LLM | Body clarity and completeness score (0.0-1.0)                                                   | Cheap    |
-| **Gate 4: Reviewer** (opt-in) | Subagent    | `evolution-reviewer` multi-turn review — reads files, checks evidence, APPROVE/REJECT verdict   | Moderate |
+| Gate                          | Type                  | What it checks                                                                                  | Cost     |
+| ----------------------------- | --------------------- | ----------------------------------------------------------------------------------------------- | -------- |
+| **Gate 1: Structural**        | Pure code             | YAML frontmatter present, `# Title` exists, `## Workflow Routing` preserved if original had one | Free     |
+| **Gate 2: Trigger Accuracy**  | Replay or student LLM | Runtime replay when available; otherwise YES/NO trigger check per eval entry                    | Cheap    |
+| **Gate 3: Quality**           | Student LLM           | Body clarity and completeness score (0.0-1.0)                                                   | Cheap    |
+| **Gate 4: Reviewer** (opt-in) | Subagent              | `evolution-reviewer` multi-turn review — reads files, checks evidence, APPROVE/REJECT verdict   | Moderate |
 
 If any gate fails, the teacher receives structured feedback and generates
 a refined proposal. This repeats up to `--max-iterations` times.
+Low confidence does not reject a proposal by itself; it is treated as review
+metadata and may justify extra scrutiny.
 
 ## Steps
 
@@ -162,11 +169,11 @@ failure details and generates a refined proposal.
 
 `evolve body` uses the same validation contract as `evolve`:
 
-| Mode     | Behavior                                                                 |
-| -------- | ------------------------------------------------------------------------ |
+| Mode     | Behavior                                                                  |
+| -------- | ------------------------------------------------------------------------- |
 | `auto`   | Try replay-backed validation first; fall back to LLM judge if unavailable |
-| `replay` | Replay engine only; error if no replay fixture or runner is available    |
-| `judge`  | LLM judge only                                                           |
+| `replay` | Replay engine only; error if no replay fixture or runner is available     |
+| `judge`  | LLM judge only                                                            |
 
 When replay is available, selftune stages the candidate skill content into a
 temporary local registry before running the real host/runtime replay. Claude

package/skill/workflows/Hook.md

@@ -44,7 +44,7 @@ canonical prompt record.
 Fires when a Claude Code session ends. Reads the session transcript JSONL and
 extracts process-level telemetry (tool calls, errors, skills triggered, token
 counts). Writes one record per session to SQLite with a JSONL backup. May
-trigger a reactive `selftune orchestrate` spawn if conditions are met.
+trigger a reactive `selftune run` spawn if conditions are met.
 
 ### skill-eval
 

package/skill/workflows/Improve.md

@@ -0,0 +1,168 @@
+# selftune Improve Workflow
+
+Use this when the user wants to make a skill better based on measured evidence.
+
+## What Improve Means
+
+`Improve` is the primary lifecycle workflow for bounded skill evolution.
+
+The lifecycle entrypoint is:
+
+```bash
+selftune improve --skill <name> --skill-path <path> [--scope auto|description|routing|body|package] [--agent AGENT] [--eval-set PATH] [--dry-run] [--validation-mode auto|replay|judge]
+```
+
+## Options
+
+| Flag | Description |
+|------|-------------|
+| `--scope` | Improvement scope: `auto`, `description`, `routing`, `body`, or `package` |
+| `--skill` | Skill name |
+| `--skill-path` | Path to `SKILL.md` |
+| `--agent` | Agent CLI to use; for body/routing this sets both teacher and student agents |
+| `--eval-set` | Override the eval set JSON path |
+| `--dry-run` | Validate candidate changes without deploying |
+| `--validation-mode` | Validation strategy: `auto`, `replay`, or `judge` |
+| `--help` | Show command help |
+
+`improve` chooses an underlying command surface:
+
+- `selftune evolve ...` for description and trigger-surface changes
+- `selftune evolve body ... --target routing` for workflow-routing changes
+- `selftune evolve body ... --target body` for larger body changes
+- `selftune search-run ...` for bounded package search across routing/body variants
+
+Always prefer the smallest mutation surface that matches the measured problem.
+
+## Preconditions
+
+Before improving a skill, make sure the skill is already verified enough to
+trust the result:
+
+- evals exist
+- unit tests exist when needed
+- replay evidence exists
+- baseline or equivalent value evidence exists when the change is high stakes
+
+If those are missing, route to `Verify` first.
+
+## Scope Selection
+
+### Description scope
+
+Use:
+
+```bash
+selftune improve --skill <name> --skill-path <path> --scope description --dry-run --validation-mode replay
+```
+
+Choose this when:
+
+- undertriggering is mostly a wording problem
+- missed queries cluster around synonyms or phrasing
+- the workflow itself is fine once the skill triggers
+
+### Routing scope
+
+Use:
+
+```bash
+selftune improve --skill <name> --skill-path <path> --scope routing --dry-run --validation-mode replay
+```
+
+Choose this when:
+
+- the skill triggers but chooses the wrong workflow
+- workflow routing is incomplete or ambiguous
+- the problem is structural routing, not top-level matching
+
+### Body scope
+
+Use:
+
+```bash
+selftune improve --skill <name> --skill-path <path> --scope body --dry-run --validation-mode replay
+```
+
+Choose this when:
+
+- the skill triggers and routes correctly but executes poorly
+- instructions inside the body are incomplete, misleading, or stale
+
+### Package scope
+
+Use:
+
+```bash
+selftune improve --skill <name> --skill-path <path> --scope package --eval-set <path>
+```
+
+Choose this when:
+
+- the measured gap spans routing and body together
+- you want frontier-backed candidate comparison instead of a single mutation
+- you need a bounded review loop before deciding what to publish
+
+Package scope always runs bounded search through the shared package evaluator.
+Without `--dry-run`, the winning candidate is promoted back into the draft
+package automatically. `--validation-mode judge` is not supported here.
+
+## Default Approach
+
+1. start with the smallest scope that matches the evidence
+2. let `--scope auto` choose bounded package search automatically when the
+   target already has package evidence or a draft package manifest; otherwise
+   it falls back to description-surface evolution
+3. use `--scope package` when the evidence points to a multi-surface package
+   problem and you want to force package search explicitly
+4. prefer `--dry-run` first
+5. use replay-backed validation when available
+6. only deploy once the proposal clears the trust bar
+7. after deployment, hand off to `Watch`
+
+## After Improve
+
+If a change is deployed, continue with:
+
+```bash
+selftune watch --skill <name> --skill-path <path>
+```
+
+For draft packages, use `Publish` instead of treating improve as the first ship
+path.
+
+## Which workflows to load next
+
+- missing trust evidence -> `workflows/Verify.md`
+- explicit description-only evolution details -> `workflows/Evolve.md`
+- explicit routing/body mutation details -> `workflows/EvolveBody.md`
+- monitoring and rollback -> `workflows/Watch.md`
+
+## Common Patterns
+
+**"Make this skill better."**
+
+> Use `Improve`. Pick the smallest scope that fits the measured gap, or start
+> with `--scope auto`. For draft packages or skills with package-frontier
+> evidence, `--scope auto` now routes into bounded package search by default.
+
+**"It undertriggers."**
+
+> Start with description scope unless evidence points to routing issues.
+
+**"The wrong workflow fires."**
+
+> Use routing scope, not description scope.
+
+**"The skill fires but performs badly."**
+
+> Use body scope after verify is in place.
+
+**"I want to compare a few full package candidates first."**
+
+> Use package scope so selftune runs bounded search instead of a single edit.
+
+Bounded package search now prefers reflective proposals first, then
+eval-informed targeted variants, then deterministic fallback. When routing and
+body both produce accepted improvements, it also evaluates a merged candidate
+before final winner selection.

package/skill/workflows/Initialize.md

@@ -255,7 +255,7 @@ selftune recover --full --force
 ### 9. Autonomy Scheduling
 
 Init automatically installs OS-level scheduling (launchd on macOS, cron/systemd
-on Linux) so `selftune orchestrate` runs in the background. This is equivalent
+on Linux) so `selftune run` runs in the background. This is equivalent
 to running `selftune cron setup` manually.
 
 Skip with `--no-autonomy` if you prefer manual orchestration only.
@@ -377,9 +377,9 @@ prompt/query text in addition to skill/session/evolution metadata.
 
 ### Upload Behavior
 
-Once enrolled, `selftune orchestrate` automatically uploads new session,
+Once enrolled, `selftune run` automatically uploads new session,
 invocation, and evolution data to the cloud API at the end of each run.
-This upload step is fail-open -- errors never block the orchestrate loop.
+This upload step is fail-open -- errors never block the autonomous loop.
 Use `selftune alpha upload` for manual uploads or `selftune alpha upload --dry-run`
 to preview what would be sent.
 

package/skill/workflows/Orchestrate.md

@@ -2,11 +2,18 @@
 
 Run the autonomy-first selftune loop in one command.
 
-`selftune orchestrate` is the primary closed-loop entrypoint. It runs
+This remains the underlying runtime, but the simplified product surface should
+teach it as `Run`.
+
+`selftune orchestrate` is the current closed-loop entrypoint. It runs
 source-truth sync, computes current skill health, selects candidates,
 deploys validated low-risk description changes autonomously, and watches
 recent changes with auto-rollback enabled.
 
+If the user asks to "run selftune", "run the loop", or "operate autonomously",
+route through `workflows/Run.md` first and use this file for the exact
+underlying behavior and flags.
+
 ## When to Use
 
 - You want the full autonomous loop, not isolated subcommands
@@ -17,6 +24,7 @@ recent changes with auto-rollback enabled.
 ## Default Command
 
 ```bash
+selftune run
 selftune orchestrate
 ```
 
@@ -57,6 +65,7 @@ proposalModel = haiku
 - Sync source-truth telemetry first
 - Auto-grade up to 5 ungraded skills that have session data (enables evolution on first run after ingest)
 - Prioritize critical/warning/ungraded skills with real missed-query signal
+- Select package-level search for skills with package evaluation evidence; fall back to description-level evolve otherwise
 - Deploy validated low-risk description changes automatically
 - Auto-grade and write grading baselines for freshly deployed skills
 - Generate review-first new skill proposals from strong workflow patterns
@@ -71,27 +80,27 @@ Use `--review-required` only when you want a stricter policy for a specific run.
 
 **User asks to improve skills or run the full loop**
 
-> Run `selftune orchestrate`. Parse the JSON output from stdout and the
+> Run `selftune run`. Parse the JSON output from stdout and the
 > phased report from stderr. Report the summary to the user.
 
 **User wants to preview changes before deploying**
 
-> Run `selftune orchestrate --dry-run`. Report the planned actions without
+> Run `selftune run --dry-run`. Report the planned actions without
 > making any changes.
 
 **User wants to focus on a single skill**
 
-> Run `selftune orchestrate --skill <name>`. This limits the loop to the
+> Run `selftune run --skill <name>`. This limits the loop to the
 > specified skill only.
 
 **User wants manual review before deployment**
 
-> Run `selftune orchestrate --review-required`. Validated changes stay in
+> Run `selftune run --review-required`. Validated changes stay in
 > review mode instead of auto-deploying.
 
 **Agent needs fresh source data before orchestrating**
 
-> Run `selftune orchestrate --sync-force`. This forces a full source replay
+> Run `selftune run --sync-force`. This forces a full source replay
 > before candidate selection.
 
 ## Output
@@ -168,12 +177,40 @@ In autonomous mode, orchestrate calls sub-workflows in this fixed order:
 1. **Sync** — refresh source-truth telemetry across all supported agents (`selftune sync`)
 2. **Status** — compute skill health using existing grade results (reads `grading.json` outputs from previous sessions)
 3. **Auto-grade** — grade up to `--max-auto-grade` (default 5) ungraded skills that have session data but no grades yet. Skipped during `--dry-run` (grading makes LLM calls). After grading, status is recomputed so candidate selection sees updated grades. Fail-open: individual grading errors are logged but never block the loop.
-4. **Evolve** — run evolution on selected candidates (pre-flight is skipped; Pareto mode uses 3 candidates; cheap-loop uses `haiku` for proposal + validation and `sonnet` for the final gate; adaptive gate escalation promotes risky proposals to `opus` + `high` effort; baseline and token-efficiency stay off)
-5. **Post-deploy grade + baseline** — for each freshly deployed skill, grade the most recent session and write a grading baseline to SQLite (`grading_baselines` table). The baseline records the measured pass rate and sample size, anchoring future grade regression detection. Fail-open: individual grading errors are logged but never block the loop.
-6. **Watch** — monitor recently evolved skills (auto-rollback enabled by default, `--recent-window` hours lookback). Skills freshly deployed in this run are included in the watch set immediately, so they are monitored in the same orchestrate cycle rather than waiting for the next run. These appear in `freshlyWatchedSkills` in the output. Grade watch (`enableGradeWatch: true`) runs alongside trigger regression for all watched skills.
-7. **Workflow proposals** — discover repeated multi-skill patterns and create review-first `new_skill` proposals when a workflow is strong enough to merit codification. These are never auto-deployed; they are surfaced as proposals for review.
-8. **Alpha Upload** — if enrolled in the alpha program (`config.alpha.enrolled === true`) and an API key is configured, stage new canonical records (sessions, invocations, evolution evidence, orchestrate runs) into `canonical_upload_staging`, build V2 push payloads, and flush to the cloud API (`POST /api/v1/push`) with Bearer auth. Fail-open: upload errors never block the orchestrate loop. Respects `--dry-run`.
-9. **Contribution relay flush** — if an API key is configured, flush any staged creator-directed contribution signals for opted-in skills. Fail-open: relay errors never block the orchestrate loop. Respects `--dry-run`.
+4. **Scope selection** — for each candidate, orchestrate decides whether to run description-level evolve or package-level search. The decision is evidence-driven: when an accepted package frontier exists or the canonical package evaluation shows room for improvement (weak replay, low baseline lift, or body/routing regressions), orchestrate prefers package search. Skills without package evaluation evidence fall back to description-level evolve. This selection happens automatically; there is no flag to force it.
+5. **Evolve or Package Search** — description-level candidates run the existing evolve path (pre-flight skipped; Pareto mode uses 3 candidates; cheap-loop uses `haiku` for proposal + validation and `sonnet` for the final gate; adaptive gate escalation promotes risky proposals to `opus` + `high` effort; baseline and token-efficiency stay off). Package-level candidates run bounded search: generate bounded mutations on routing and body surfaces, fingerprint each variant, evaluate through the package evaluator against the accepted frontier parent, and apply the winning candidate back into the draft package.
+6. **Post-deploy grade + baseline** — for each freshly deployed skill, grade the most recent session and write a grading baseline to SQLite (`grading_baselines` table). The baseline records the measured pass rate and sample size, anchoring future grade regression detection. Fail-open: individual grading errors are logged but never block the loop.
+7. **Watch** — monitor recently evolved skills (auto-rollback enabled by default, `--recent-window` hours lookback). Skills freshly deployed in this run are included in the watch set immediately, so they are monitored in the same orchestrate cycle rather than waiting for the next run. These appear in `freshlyWatchedSkills` in the output. Grade watch (`enableGradeWatch: true`) runs alongside trigger regression for all watched skills. Watch trust scoring feeds back into scope selection: observed regressions can demote accepted frontier candidates, influencing whether future runs prefer package search or description evolve for that skill.
+8. **Workflow proposals** — discover repeated multi-skill patterns and create review-first `new_skill` proposals when a workflow is strong enough to merit codification. These are never auto-deployed; they are surfaced as proposals for review.
+9. **Alpha Upload** — if enrolled in the alpha program (`config.alpha.enrolled === true`) and an API key is configured, stage new canonical records (sessions, invocations, evolution evidence, orchestrate runs) into `canonical_upload_staging`, build V2 push payloads, and flush to the cloud API (`POST /api/v1/push`) with Bearer auth. Fail-open: upload errors never block the orchestrate loop. Respects `--dry-run`.
+10. **Contribution relay flush** — if an API key is configured, flush any staged creator-directed contribution signals for opted-in skills. Fail-open: relay errors never block the orchestrate loop. Respects `--dry-run`.
+
+### Package Search in Orchestrate
+
+When orchestrate selects a candidate for package-level improvement, it
+delegates to the same bounded search flow available through
+`selftune improve --scope package` or `selftune search-run`. The flow is:
+
+1. **Generate bounded mutations** on routing and body surfaces using
+   eval-informed targeted variants first, then deterministic fallback
+   transforms, biasing the candidate budget toward the weaker measured surface
+   from the accepted frontier or canonical package evaluation.
+2. **Fingerprint** each variant to skip duplicates already in the candidate
+   registry.
+3. **Evaluate** each variant through the package evaluator against the
+   accepted frontier parent, comparing replay, baseline lift, routing
+   validation, body validation, and unit-test results.
+4. **Select winner** based on the highest positive measured delta across the
+   full evaluator contract (not replay-only).
+5. **Apply winner** back into the draft package and refresh the canonical
+   package-evaluation artifact from the accepted candidate cache.
+6. **Continue** to the watch phase, where post-deploy evidence can demote
+   the accepted frontier candidate if regressions are observed.
+
+Package search does not replace description evolve. It is selected
+automatically when the evidence points to package-level improvement
+opportunity. Skills without package evaluation history continue through
+description-level evolve as before.
 
 When orchestrate invokes evolve for a selected candidate, it always passes
 `confidenceThreshold: 0.6` and `maxIterations: 3`, plus the autonomous evolve

package/skill/workflows/Publish.md

@@ -0,0 +1,100 @@
+# selftune Publish Workflow
+
+Use this when the user wants to ship a skill safely after verification.
+
+## What Publish Means
+
+`Publish` is the lifecycle step that takes a verified skill into live use and
+starts post-deploy monitoring. For draft packages, the lifecycle entrypoint is:
+
+```bash
+selftune publish --skill-path <path> [--no-watch] [--ignore-watch-alerts] [--json]
+```
+
+## Options
+
+| Flag | Description |
+|------|-------------|
+| `--skill-path` | Path to a skill directory or `SKILL.md` file |
+| `--no-watch` | Skip the default watch handoff and return the next watch command instead |
+| `--ignore-watch-alerts` | Bypass publish-time watch gate warnings after watch runs |
+| `--json` | Emit the publish summary as JSON |
+| `--help` | Show command help |
+
+## When to Use
+
+- The user says "publish", "ship", "deploy", or "go live"
+- The user already has verification evidence and wants the next step
+- The user wants watch to begin immediately after shipping
+
+## Draft Package Path
+
+For a draft package that has already cleared verify:
+
+```bash
+selftune publish --skill-path <path>
+```
+
+This command:
+
+1. re-runs package replay
+2. re-runs package baseline
+3. hands the package into watch by default
+4. applies a measured publish-time watch gate after watch completes
+
+Use `--ignore-watch-alerts` only when you deliberately want to bypass that
+watch-trust gate after reviewing the output.
+
+If verification evidence is missing, do not force publish. Route back to
+`Verify`.
+
+## Existing Live Skill Path
+
+If the skill is already deployed and the user is shipping a new measured
+improvement, the current surface is still split:
+
+1. run `Improve`
+2. if deployed successfully, run:
+
+```bash
+selftune watch --skill <name> --skill-path <path>
+```
+
+Treat this as the live-skill version of publish until a unified publish command
+exists for both draft packages and iterative evolution.
+
+## What To Check Before Publish
+
+- the package or skill is not still blocked on `Create`
+- trust evidence is complete enough to be called `verified`
+- the next lifecycle step from status/check is publish rather than more prep
+- the user is not actually asking for a dry-run or improvement proposal review
+
+## Outcome
+
+`Publish` should leave the skill in one of these states:
+
+- `published`
+- `watching`
+- back to `Verify` if the draft is still blocked on `needs_spec_validation`, `needs_package_resources`, `needs_evals`, `needs_unit_tests`, `needs_routing_replay`, or `needs_baseline`
+
+## Which workflows to load next
+
+- missing trust proof -> `workflows/Verify.md`
+- post-deploy monitoring -> `workflows/Watch.md`
+- further iteration after ship -> `workflows/Improve.md`
+
+## Common Patterns
+
+**"Ship this draft skill."**
+
+> Use `selftune publish --skill-path <path>` if verify is green.
+
+**"Deploy and monitor it."**
+
+> Publish includes watch by default. Add `--no-watch` only when you want a
+> manual handoff.
+
+**"Can I skip straight to publish?"**
+
+> Only if the skill is already verified. Otherwise route back to `Verify`.

package/skill/workflows/Run.md

@@ -0,0 +1,72 @@
+# selftune Run Workflow
+
+Use this when the user wants the full autonomous selftune loop rather than a
+single lifecycle step.
+
+## What Run Means
+
+`Run` is the simplified lifecycle name for selftune's autonomy-first runtime.
+
+The lifecycle entrypoint is:
+
+```bash
+selftune run [--dry-run] [--review-required] [--auto-approve] [--skill NAME] [--max-skills N] [--recent-window HOURS] [--sync-force] [--max-auto-grade N] [--loop] [--loop-interval SECS]
+```
+
+## Options
+
+| Flag | Description |
+|------|-------------|
+| `--dry-run` | Preview actions without mutations |
+| `--review-required` | Validate candidates but require human review before deploy |
+| `--auto-approve` | Deprecated alias; autonomous mode is already the default |
+| `--skill` | Scope to a single skill |
+| `--max-skills` | Cap skills processed per run |
+| `--recent-window` | Hours to look back for watch targets |
+| `--sync-force` | Force a full rescan during sync |
+| `--max-auto-grade` | Max ungraded skills to auto-grade per run |
+| `--loop` | Run continuously |
+| `--loop-interval` | Seconds between loop iterations |
+| `--help` | Show command help |
+
+`run` delegates to the existing `selftune orchestrate` runtime while keeping
+the simpler lifecycle name.
+
+## When to Use
+
+- The user wants the full autonomous loop
+- The user says "run selftune", "improve all skills", or "operate continuously"
+- The user wants a dry-run of what selftune would do next
+
+## Default Commands
+
+```bash
+selftune run
+selftune run --dry-run
+selftune run --review-required
+selftune run --skill <name>
+selftune run --loop
+```
+
+## How To Explain It
+
+`Run` is not the same as a single improve action. It is the higher-level system
+runtime that:
+
+- syncs
+- computes status
+- grades when needed
+- improves selected skills
+- watches recent changes
+- flushes contribution/upload side effects
+
+For users who ask for one specific skill or one specific trust question, prefer
+`Status`, `Verify`, `Publish`, or `Improve` first.
+
+For users who ask for the whole closed loop, use `Run`.
+
+## Which workflow to load next
+
+- exact autonomy details and flags -> `workflows/Orchestrate.md`
+- trust questions for one skill -> `workflows/Verify.md`
+- package publishing -> `workflows/Publish.md`

package/skill/workflows/Schedule.md

@@ -19,10 +19,10 @@ For OpenClaw-specific scheduling, see `workflows/Cron.md`.
 The core selftune automation loop is one command:
 
 ```bash
-selftune orchestrate
+selftune run
 ```
 
-`selftune orchestrate` runs source-truth sync first, selects candidate skills,
+`selftune run` runs source-truth sync first, selects candidate skills,
 deploys validated low-risk description changes autonomously, and watches recent
 deployments with auto-rollback enabled.