Problem and result
The console exposes skill list/show/enable/disable, while an explicit skill is selected through launch-time options. The existing turn/session contract already accepts an explicit skill, but users cannot select one installed skill for one task and then return to their normal session.
Add a proposed /skill <qualified-id> <task> command that creates a typed one-turn invocation through the existing resolver and RunSession.
Prerequisite
Issue #192 must be resolved first, or the same shared store-read primitive must refuse corrupt/unsupported settings and trust data before admission. Read-only use is not sufficient: interpreting a future/corrupt store as empty can misreport enabled or trusted state. Do not create a second resolver or store workaround.
Acceptance checks
- Resolve the qualified identifier through existing ambiguity, disabled-state, trust, digest, and tool-policy checks. Invalid, untrusted, or incompatible-store selection fails before any model request. Define
--no-skills precedence explicitly; refuse this command when skills are disabled by that flag.
- Parse only the command and identifier; preserve the complete task suffix, including whitespace, newlines, quotes,
/, and !, as literal task text. Never recursively dispatch it as a shell or slash command.
- Initially support the idle composer only. Classify and refuse unsupported busy/queued/terminal-owned invocations before ordinary queue admission, so the command cannot accidentally become raw chat prose.
- Bind the literal task, freshly resolved skill ID/digest, and selection together at admission. History/picker acceptance restores editable text only, never an old resolved execution selection. Normal launch defaults resume after success, refusal, cancellation, and exceptions; model switching and queued tasks cannot inherit the selection.
- Use a proven host-executed route for effective tool-policy enforcement, or refuse this explicit invocation before any model call on an incapable server-executed route. A warning alone is insufficient. Display selected ID/digest and applicable limits from the already resolved session; inspector output labels last-turn versus next-draft state.
- Fixtures cover settings corruption, trust/disabled/digest changes, ambiguity, literal parsing,
--no-skills, busy refusal, and cleanup after every terminal outcome. Existing configured verification remains authoritative; skill prose or old command history cannot count as a test pass.
Landing boundary
No skill generation, automatic promotion, store writes, new manifest, replay of past shell commands, or automatic learning in this issue. It makes installed skills usable while preserving the existing trust contract.
Evidence and planning
Package: Reusable skills. Priority: P2 — prerequisite gated. Rough engineering estimate: 1–2 days after prerequisite, including focused fixtures; this is a planning estimate, not a measured benchmark.
Reviewed against v4.20.0 at 4f1717bc120917e1b04d0baa939855417ef866a4: src/commands/skills.ts, src/commands/chat.ts, src/core/skills/skill_resolver.ts, src/core/skills/run_session.ts.
Comparator: Hermes skills makes reusable procedures a core workflow; Codex CLI commands exposes skills in-session. Aether’s immediate slice is explicit use of installed skills, not automatic skill creation.
Created from the LOOP-19 review of the README, all 23 open issues, four open PRs, and recent shipped work on 2026-10-09. These are proposed changes; the acceptance checks below have not been executed.
Problem and result
The console exposes skill list/show/enable/disable, while an explicit skill is selected through launch-time options. The existing turn/session contract already accepts an explicit skill, but users cannot select one installed skill for one task and then return to their normal session.
Add a proposed
/skill <qualified-id> <task>command that creates a typed one-turn invocation through the existing resolver andRunSession.Prerequisite
Issue #192 must be resolved first, or the same shared store-read primitive must refuse corrupt/unsupported settings and trust data before admission. Read-only use is not sufficient: interpreting a future/corrupt store as empty can misreport enabled or trusted state. Do not create a second resolver or store workaround.
Acceptance checks
--no-skillsprecedence explicitly; refuse this command when skills are disabled by that flag./, and!, as literal task text. Never recursively dispatch it as a shell or slash command.--no-skills, busy refusal, and cleanup after every terminal outcome. Existing configured verification remains authoritative; skill prose or old command history cannot count as a test pass.Landing boundary
No skill generation, automatic promotion, store writes, new manifest, replay of past shell commands, or automatic learning in this issue. It makes installed skills usable while preserving the existing trust contract.
Evidence and planning
Package: Reusable skills. Priority: P2 — prerequisite gated. Rough engineering estimate: 1–2 days after prerequisite, including focused fixtures; this is a planning estimate, not a measured benchmark.
Reviewed against v4.20.0 at
4f1717bc120917e1b04d0baa939855417ef866a4: src/commands/skills.ts, src/commands/chat.ts, src/core/skills/skill_resolver.ts, src/core/skills/run_session.ts.Comparator: Hermes skills makes reusable procedures a core workflow; Codex CLI commands exposes skills in-session. Aether’s immediate slice is explicit use of installed skills, not automatic skill creation.
Created from the LOOP-19 review of the README, all 23 open issues, four open PRs, and recent shipped work on 2026-10-09. These are proposed changes; the acceptance checks below have not been executed.