Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
a9c86297aa
yoi/.yoi/tickets/00001KXKMX0QM/thread.md

28 KiB
Raw Blame History

作成

LocalTicketBackend によって作成されました。

Comment

Current implementation check: Skills support

現行の Skills support は存在するが、first-class Skill ではなく Workflow ingestion の一部として実装されている。

既にあるもの

  • crates/workflow/src/skill.rs に SKILL.md parser がある。
    • <skills-root>/<name>/SKILL.md を読む。
    • YAML frontmatter + Markdown body を要求する。
    • name / description は required。
    • name は parent directory name と一致する必要がある。
    • name は既存 Slug validation を通る必要がある。
    • description は non-empty かつ WORKFLOW_DESCRIPTION_HARD_CAP 以内。
    • license / compatibility / metadata / allowed-tools は parse 上は受理する。
    • unknown frontmatter fields は warning で無視する。
    • allowed-tools は warning を出すだけで enforcement しない。
  • load_skills_from_dir(root) がある。
    • root 直下の directory だけを見て、各 <name>/SKILL.md を読む。
    • broken skill は warning で skip し、siblings は読み続ける。
    • missing root は empty 扱い。
    • deterministic order で読み込む。
  • manifest に [skills] directories = [...] がある。
    • path は manifest/profile base から resolve される。
    • validation 後は absolute path required。
    • profile/manifest merge で directories は extend される。
  • Worker startup で [skills].directories が scope read allow に追加される。
    • skill root は recursive read allow になる。
    • SKILL.md / scripts/ / references/ / assets/ 全体を通常 Read できる。
  • Worker startup で Skills が workflow registry に取り込まれる。
    • SkillRecord::into_workflow_record() により Skill が WorkflowRecord に変換される。
    • model_invokation = true、user_invocable = true。
    • つまり Skill は /<slug> で呼べる Workflow として扱われる。
  • shadowing support がある。
    • internal/builtin/workspace Workflow が同 slug を持つ Skill より優先される。
    • 複数 skill directories 間では first-fed wins。
    • shadowed Skill は Worker notification に [Skill shadowed] ... として流れる。
  • tests は parser / directory loading / Workflow projection / scope allow / ingest_skills をある程度カバーしている。

現行の限界

  • Skill は first-class ではなく、WorkflowRecord へ projection されている。
    • Skill catalog / Skill activation / Skill provenance は Workflow registry に埋もれる。
    • Workflow 削除 Ticket と衝突する構造になっている。
  • .yoi/skills/ は implicit workspace Skill root ではない。
    • 現在は [skills].directories に明示された root だけを読む。
    • default workspace path として .yoi/skills を probe しない。
  • builtin skills はない。
    • resources/skills/<name>/SKILL.md のような bundled layout は未定義。
  • Progressive disclosure は不完全。
    • metadata は resident workflow entry として出るが、Skill catalog と full body activation が分離されていない。
    • full SKILL.md body は workflow invocation body として扱われるだけ。
    • references/ / scripts/ / assets/ はただ read-scope に入るだけで、Skill-aware access/tooling はない。
  • allowed-tools は authority に反映されない。
    • parser は認識するが warning のみ。
    • feature/tool permission と合成しない。
  • frontmatter optional fields は保持されない。
    • license / compatibility / metadata は parse acceptance のみで、SkillRecord / catalog には残らない。
  • lint surface が独立していない。
    • parser tests はあるが、yoi skill lint のような user-facing lint/check はない。
  • Skill resource safety は最小限。
    • skill root を recursive read allow にしているだけ。
    • relative references / nested reference chain / script execution policy は未実装。
  • Web Workspace UI / backend API はない。
    • .yoi/skills の list / validation / edit surface は未実装。
  • current docs/comments は Skill を Workflow ingestion として説明しており、今後の方針と逆。
    • crates/workflow/src/skill.rs の module docs も「ingests it as a Workflow」と明記している。

現在地まとめ

現在の Skills support は Agent Skills parser + manifest-configured directory ingest + Workflow compatibility projection まで。Agent Skills 標準の directory shape と basic frontmatter validation は部分的にあるが、Yoi の Skill としての lifecycle / catalog / activation / provenance / lint / UI / authority boundary は未実装。

この Ticket の実装では、まず Workflow projection から切り離して、.yoi/skills/<skill-name>/SKILL.md を workspace Skill authority として扱う first-class Skill loader/catalog へ移す必要がある。

Decision

Workspace backend を Skill discovery / lint / catalog / activation の authority とする。

.yoi/skills/ は tracked workspace data の保存場所だが、Runtime Worker が各自で直接 scan して別々の Skill view を持つ構造にはしない。Web Workspace UI、Runtime Worker、embedded Worker、CLI は Workspace backend API から同じ catalog / diagnostics / activation body を取得する。

これにより、Skill の override/provenance/lint diagnostics、Web からの編集・検証、Worker への progressive disclosure を同じ authority に寄せる。

Decision

Skill support should mirror the Ticket backend direction: Workspace backend owns the shared authority and exposes typed APIs for Worker / Runtime process / Web / CLI access.

Required API surface includes catalog/list, detail/read, lint/diagnostics, activation body retrieval, and resource access or backend-resolved authority for references/assets. Worker-local filesystem scanning must not become the primary authority when WorkspaceClient::Http is available.

Intake summary

Marked ready by yoi ticket state.

State changed

Marked ready by yoi ticket state.

State changed

Ticket を workspace-panel が queued にしました。

Decision

Routing decision: blocked_by_dependency

Reason:

  • Dashboard queue authorization was inspected, but this Ticket has explicit depends_on blockers。
  • 00001KXKJGYGD (Remove workflow tracking and workflow resources) is currently inprogress and still in reviewer/coder fix loop。
  • 00001KXKP2A71 (Remove Knowledge support) is still queued and was intentionally held until Workflow removal completes。
  • This Ticket’s body depends on both: Workflow projection must be gone, and obsolete Knowledge support should be removed before first-class Agent Skills support introduces new Skill/Knowledge boundaries and Workspace Skill APIs。
  • Therefore this routing pass leaves the Ticket queued and does not record queued -> inprogress, create a worktree, or spawn role Pods。

Evidence checked:

  • Ticket body / thread / relations。
  • TicketRelationQuery(00001KXKMX0QM): depends_on 00001KXKJGYGD and depends_on 00001KXKP2A71。
  • Ticket derived blocker view: 00001KXKJGYGD is inprogress, 00001KXKP2A71 is queued。
  • TicketOrchestrationPlanQuery(00001KXKMX0QM): no prior records; this pass recorded after entries and waiting note。
  • TicketList(inprogress): 00001KXKJGYGD active。
  • Orchestrator worktree status: clean。

Next action:

  • Finish 00001KXKJGYGD first。
  • Re-route and complete 00001KXKP2A71 second。
  • Re-route this Skills Ticket after both blockers are approved, merged, validated, and closed。

Escalate if:

  • Human explicitly requests a combined branch across Workflow removal / Knowledge removal / Skills support and accepts the larger review-boundary risk。

Decision

Routing decision: implementation_ready

Reason:

  • Explicit dependencies are now satisfied: 00001KXKJGYGD Workflow removal and 00001KXKP2A71 Knowledge removal are both approved, merged, final-validated, closed, and their implementation worktrees/branches cleaned。
  • TicketRelationQuery(00001KXKMX0QM) still records the outgoing depends_on edges, but the derived blocker view is empty because both targets are closed。
  • TicketOrchestrationPlanQuery(00001KXKMX0QM) contained earlier waiting notes for those blockers; this pass records an accepted implementation plan。
  • TicketList(inprogress) is 0 件。
  • Orchestrator worktree is clean and no existing 00001KXKMX0QM implementation worktree/branch was found。

Evidence checked:

  • Ticket body / thread / relations / orchestration plan。
  • Closed prerequisite Tickets 00001KXKJGYGD and 00001KXKP2A71。
  • Orchestrator worktree state / worktree list / branch list。

IntentPacket:

Intent:

  • Implement first-class Agent Skills support using Workspace backend authority。
  • .yoi/skills/<skill-name>/SKILL.md becomes tracked workspace Skill data, but Worker-local filesystem scan must not be the primary authority when Workspace backend/client is available。
  • Provide shared Skill catalog/lint/read/activation APIs for Worker / Runtime / Web / CLI and progressive disclosure of Skill metadata vs body/resources。

Binding decisions / invariants:

  • Skill is LLM-facing procedural guidance/resource, not external state authority, scheduler, script runner, queue runner, or worktree manager。
  • Ticket / Worker / workdir / repository / network external state changes remain in typed feature/tool surfaces。
  • Workflow projection semantics must not return: no WorkflowRecord, model_invokation, user_invocable, graph/invocation assumptions, or /workflow-slug compatibility path。
  • Knowledge has been removed as active support; do not rebuild Knowledge under Skill terminology。
  • Workspace backend is authority for Skill discovery/lint/catalog/activation。
  • Worker with WorkspaceClient::Http must receive Skill metadata/body via Workspace API, not local path scan。
  • Full SKILL.md body is loaded into Worker history/context only on activation/select, not always with the catalog。
  • allowed-tools is experimental; if implemented, it must not become independent authority without explicit integration with feature/tool permissions。

Requirements / acceptance criteria:

  • .yoi/skills/<skill-name>/SKILL.md is parsed/linted per Agent Skills required frontmatter and naming rules。
  • Workspace backend exposes Skill catalog/list, detail/read, lint/diagnostics, activation body, and resource access or backend-resolved resource authority as appropriate。
  • Builtin/workspace loading, override priority, provenance, invalid diagnostics, and non-default/workspace skill cases are covered by tests。
  • Worker / Web / CLI use the same Workspace backend Skill catalog view。
  • Activation appends/commits Skill body into Worker history before LLM context use。
  • Progressive disclosure is tested: catalog metadata is lightweight, full body/resources load only when requested/activated。
  • Role prompts/internal prompts/docs are updated to Skill terminology and no Workflow/Knowledge active guidance remains。
  • Initial implementation clearly marks unsupported decision points such as allowed-tools/scripts/resource execution if not implemented。

Implementation latitude:

  • Exact crate/module placement and API DTO shapes may follow current workspace-server / Worker WorkspaceClient patterns。
  • Builtin Skill resource layout can be chosen based on existing resource conventions, but must be tested and documented。
  • Workspace override policy may choose complete override or conflict diagnostic if documented and tested; prefer a simple deterministic rule。
  • Web UI editing can be deferred if backend/API/CLI tests cover catalog/lint/read/activation and Ticket does not require full editor implementation。

Escalate if:

  • Skill activation syntax (/skill-name vs explicit tool/API/UI activation) requires product decision beyond existing Ticket text。
  • Supporting scripts/ execution would require new authority/sandbox model; prefer unsupported/diagnostic unless explicitly scoped。
  • Implementing resource access needs broad backend protocol design beyond bounded read/detail endpoints。
  • Any path requires reintroducing Workflow or Knowledge active surfaces。

Validation:

  • git diff --check
  • Skill loader/lint/catalog tests in affected crate(s)。
  • cargo test -p yoi-workspace-server --lib if Workspace API is touched。
  • cargo test -p worker --lib --tests if Worker prompt/history/WorkspaceClient activation is touched。
  • cargo test -p yoi --tests if CLI/input activation is touched。
  • cd web/workspace && deno task check && deno task test if web/API types are touched。
  • cargo check -p yoi
  • yoi ticket doctor
  • nix build .#yoi --no-link

Critical risks / reviewer focus:

  • Worker-local scan becoming divergent authority。
  • Full Skill body being resident by default rather than activated/progressive。
  • Workflow/Knowledge surfaces returning under new names。
  • allowed-tools or scripts accidentally becoming authority bypass。
  • Skill resources leaking raw paths or bypassing Workspace backend authority。
  • External state control moving into Skill text instead of typed tools/features。

State changed

Dependencies Workflow removal and Knowledge removal are closed, no blockers remain, accepted plan recorded. Moving queued Ticket to inprogress before creating worktree or spawning role Pods.

Implementation report

Implementation progress report:

  • Coder Pod yoi-coder-00001KXKMX0QM-agent-skills completed implementation in /home/hare/Projects/yoi/.worktree/00001KXKMX0QM-agent-skills-support on branch work/00001KXKMX0QM-agent-skills-support。
  • Implementation commit: 62ef89a1634fd12a503156ce95baebbf037ef96f (feat: add workspace-backed agent skills)。
  • Orchestrator inspected worktree status, branch log, commit stats, and git diff --check 05c50e32..HEAD; worktree was clean and diff check passed。

Implementation summary:

  • Added first-class Skill schema/types and Workspace HTTP client support in worker。
  • Added Workspace backend Skill discovery/lint/catalog/detail/activation in yoi-workspace-server。
  • Added builtin Skill resource at resources/skills/agent-skills/SKILL.md。
  • Added Workspace server API endpoints:
    • GET /api/w/{workspace_id}/skills
    • GET /api/w/{workspace_id}/skills/lint
    • GET /api/w/{workspace_id}/skills/{name}
    • GET /api/w/{workspace_id}/skills/{name}/activate
  • Added yoi-workspace-server skills list|lint|show CLI surface。
  • Added Web Workspace API helpers/types for Skill catalog/detail/activation endpoints。
  • Added Worker Skill activation method using WorkspaceClient::Http; activation commits a SystemItem::SkillActivation and appends the Skill body into engine history before later LLM context use。
  • Added prompt guidance clarifying Skills are procedural LLM guidance only, not authority for external state changes。

Skill behavior:

  • Workspace Skills load from .yoi/skills/<skill-name>/SKILL.md。
  • Lint enforces required name / description, parent-dir match, name length/pattern, description bounds, optional license / compatibility / string-map metadata。
  • allowed-tools is parsed as metadata but emits explicit ignored/non-authoritative warning。
  • Builtin + workspace Skills are loaded by Workspace backend; workspace Skills deterministically override builtin Skills with path-free provenance such as builtin:agent-skills / workspace:debug-rust。
  • Catalog responses contain lightweight metadata only; full SKILL.md body is returned only from detail/activation endpoints。
  • References/assets/scripts are Skill-relative resource refs only; no raw absolute paths are exposed. Resource reads/execution are not implemented, scripts are explicitly non-executable diagnostics。
  • No /skill-name activation syntax, Workflow projection/compatibility path, or Knowledge active support was added。

Files/resources touched:

  • crates/workspace-server/src/skills.rs
  • crates/workspace-server/src/server.rs
  • crates/workspace-server/src/main.rs
  • crates/workspace-server/src/lib.rs
  • crates/worker/src/skill.rs
  • crates/worker/src/worker.rs
  • crates/worker/src/lib.rs
  • crates/session-store/src/system_item.rs
  • crates/tui/src/app.rs
  • web/workspace/src/lib/workspace/api/http.ts
  • web/workspace/src/lib/workspace/api/http.test.ts
  • resources/skills/agent-skills/SKILL.md
  • resources/prompts/common/tool-usage.md

Coder-reported validation passed:

  • cargo test -p yoi-workspace-server --lib
  • cargo test -p worker --lib --tests
  • cargo check -p yoi-workspace-server
  • cargo check -p yoi
  • cargo test -p yoi --tests
  • cd web/workspace && deno task check && deno task test (54 passed, existing App.svelte warnings only)
  • git diff --check
  • yoi ticket doctor
  • nix build .#yoi --no-link
  • rg "WorkflowRecord|model_invokation|user_invocable|KnowledgeQuery|kind = knowledge|#<slug>|workflow_invoke": no active regressions found。

Next action:

  • Route to external Reviewer Pod before merge/close decisions。

Review: request changes

External review result: request_changes

Blockers:

  1. Workflow/unsupported Skill frontmatter is silently accepted instead of linted/diagnosed。

    • A .yoi/skills/*/SKILL.md containing model_invokation, user_invocable, graph/invocation fields, etc. will deserialize successfully and can be returned/activated as body。
    • SkillFrontmatter only lists known fields and uses default serde unknown-field ignoring at crates/workspace-server/src/skills.rs:40-50, with parsing around :290-300。
    • This violates the acceptance that workflow projection fields are not accepted as active Skill semantics。

  2. Required Worker activation/history behavior lacks coverage。

    • Worker::activate_skill commits/appends at crates/worker/src/worker.rs:906-922。
    • Worker Skill tests only exercise HTTP catalog fetch at crates/worker/src/skill.rs:194-237。
    • Missing the stated acceptance test that activation appends/commits Skill body into Worker history before LLM context use。

Evidence / validation performed:

  • Inspected Ticket and touched files。
  • Checked route/API/provenance behavior。
  • Ran cargo test -p yoi-workspace-server skills --lib。
  • Ran cargo test -p worker skill --lib。
  • Confirmed implementation worktree remained clean。

Non-blocking note:

  • Catalog/detail progressive disclosure and path-free provenance generally look aligned。

Implementation report

Follow-up implementation progress report after request_changes:

  • Coder Pod yoi-coder-00001KXKMX0QM-agent-skills completed the review fixes in /home/hare/Projects/yoi/.worktree/00001KXKMX0QM-agent-skills-support。
  • Follow-up commit: 4ddfccee2d414a2dfe67a940906b505dd237132d (fix: reject unsupported skill fields)。
  • Orchestrator inspected worktree status, branch log, commit stats, and git diff --check 05c50e32..HEAD; worktree was clean and diff check passed。

Fix summary:

  • Added Skill frontmatter unsupported-key detection in crates/workspace-server/src/skills.rs。
  • Unknown frontmatter keys are now lint errors。
  • Workflow/projection/invocation-shaped keys such as model_invokation, user_invocable, graph, and invocation are explicitly rejected with unsupported_workflow_frontmatter_field。
  • Unsupported/unknown-field Skills no longer become active catalog/detail/activation entries。
  • Added regression tests for model_invokation, user_invocable, graph, invocation, and generic unknown frontmatter fields。
  • Added Worker activation/history coverage in crates/worker/src/worker.rs:
    • verifies Worker::activate_skill fetches activation through Workspace HTTP client;
    • verifies Skill body is appended to Worker engine history;
    • verifies committed SystemItem::SkillActivation content matches the history-visible Skill activation content。

Coder-reported validation passed:

  • cargo test -p yoi-workspace-server skills --lib
  • cargo test -p worker skill --lib
  • git diff --check
  • cargo check -p yoi
  • yoi ticket doctor
  • nix build .#yoi --no-link

Web/API types were not changed in this follow-up, so web checks were not rerun。

Review: approve

Focused re-review result: approve

Evidence:

  • Previous blockers fixed:
    • Skill frontmatter is now parsed through a raw YAML value。
    • Unsupported/workflow-shaped keys are diagnosed as errors (crates/workspace-server/src/skills.rs:290-302, 457-528)。
    • Error diagnostics prevent catalog/detail/activation (skills.rs:393-398)。
    • Regression coverage exists for model_invokation, user_invocable, graph, invocation, and generic unknown fields (skills.rs:687-743)。
    • Worker activation/history is covered by an HTTP-backed activation test verifying backend fetch, history append, and committed SystemItem::SkillActivation body equality (crates/worker/src/worker.rs:5971-6065)。
  • Focused validation passed:
    • cargo test -p yoi-workspace-server skills --lib
    • cargo test -p worker skill --lib
    • git diff --check
  • Worktree remained clean。
  • Rechecked acceptance focus:
    • Workspace backend remains the Skill catalog/detail/lint/activation authority。
    • builtin/workspace override/provenance/progressive disclosure behavior remains covered。
    • allowed-tools / scripts remain diagnostic/non-authoritative。
    • no raw-path resource leakage was introduced。
    • rg for removed Workflow/Knowledge surfaces only finds new rejection logic/tests。

Blockers: none。

Non-blocking note:

  • detail/activation for invalid Skills still surface as not-found while catalog/lint carries diagnostics; acceptable for this initial authority model。

Implementation report

Merge / final validation report:

  • Reviewer approved the implementation after unsupported Skill frontmatter and Worker activation/history fixes。
  • Merged branch work/00001KXKMX0QM-agent-skills-support into orchestration branch with merge commit 1611e04d merge: agent skills support。
  • Final validation was rerun in /home/hare/Projects/yoi/.worktree/orchestration after merge。

Validation passed:

  • Regression grep for WorkflowRecord|model_invokation|user_invocable|KnowledgeQuery|kind = knowledge|#<slug>|workflow_invoke with only expected Skill rejection logic/tests where applicable。
  • git diff --check
  • cargo test -p yoi-workspace-server --lib
  • cargo test -p worker --lib --tests
  • cargo test -p yoi --tests
  • cd web/workspace && deno task check
  • cd web/workspace && deno task test
  • cargo check -p yoi-workspace-server
  • cargo check -p yoi
  • yoi ticket doctor
  • nix build .#yoi --no-link

Validation log:

  • /run/user/1000/yoi/yoi-orchestrator/bash-output/agent-skills-final-validation-1784160679.txt

Reviewed/merged implementation commits:

  • 62ef89a1 feat: add workspace-backed agent skills
  • 4ddfccee fix: reject unsupported skill fields

Notes:

  • Workspace backend is the Skill catalog/detail/lint/activation authority。
  • Workspace Skills live under .yoi/skills/<skill-name>/SKILL.md; builtin Skill resources are supported with deterministic workspace override/provenance diagnostics。
  • Catalog is lightweight; detail/activation returns full body。
  • Worker activation through WorkspaceClient::Http commits/appends Skill body to history before later LLM context use。
  • allowed-tools and scripts/resources are diagnostic/non-authoritative in this initial implementation。
  • Workflow and Knowledge active surfaces were not reintroduced。
  • Per user instruction, no StopPod cleanup was performed。

State changed

Implementation was reviewed, merged into orchestration branch, and final validation passed. Moving to done before closure.

State changed

Ticket を closed にしました。

完了

Agent Skills support を実装・レビュー・merge・検証した。

実装内容:

  • first-class Skill schema/types と Workspace HTTP client support を追加。
  • Workspace backend に Skill discovery / lint / catalog / detail / activation を追加。
  • Workspace API endpoints を追加:
    • GET /api/w/{workspace_id}/skills
    • GET /api/w/{workspace_id}/skills/lint
    • GET /api/w/{workspace_id}/skills/{name}
    • GET /api/w/{workspace_id}/skills/{name}/activate
  • yoi-workspace-server skills list|lint|show CLI surface を追加。
  • Web Workspace API helpers/types を追加。
  • builtin Skill resource resources/skills/agent-skills/SKILL.md を追加。
  • Worker Skill activation method を追加し、WorkspaceClient::Http 経由で Skill activation を取得し、SystemItem::SkillActivation を commit し、Skill body を engine history に append するようにした。
  • Prompt guidance を更新し、Skills は procedural LLM guidance であり external state authority ではないことを明示。

Skill behavior:

  • Workspace Skills are read from .yoi/skills/<skill-name>/SKILL.md。
  • Lint validates required name / description, parent-dir match, name length/pattern, description bounds, optional license / compatibility / string-map metadata。
  • Unknown frontmatter keys are lint errors。
  • Workflow/projection/invocation-shaped keys such as model_invokation, user_invocable, graph, invocation are explicitly rejected with unsupported_workflow_frontmatter_field。
  • allowed-tools is parsed/diagnosed as experimental ignored/non-authoritative metadata。
  • Builtin and workspace Skills are loaded deterministically; workspace Skills override builtin Skills with path-free provenance。
  • Catalog responses contain lightweight metadata only; detail/activation returns full SKILL.md body。
  • References/assets/scripts are Skill-relative and non-executable/non-authoritative; no raw absolute paths are exposed。
  • No /skill-name syntax, Workflow compatibility path, or Knowledge active support was added。

Review:

  • Initial review requested changes for silently accepted unsupported Workflow frontmatter and missing Worker activation/history coverage。
  • 4ddfccee fix: reject unsupported skill fields added unsupported-key diagnostics/regression tests and Worker activation/history tests。
  • Focused re-review approved with no blockers。
  • Non-blocking note: detail/activation for invalid Skills returns not-found while catalog/lint carries diagnostics; acceptable for this initial authority model。

Merge / validation:

  • Merge commit: 1611e04d merge: agent skills support。
  • Final validation passed:
    • Regression grep for removed Workflow/Knowledge active surfaces。
    • git diff --check
    • cargo test -p yoi-workspace-server --lib
    • cargo test -p worker --lib --tests
    • cargo test -p yoi --tests
    • cd web/workspace && deno task check
    • cd web/workspace && deno task test
    • cargo check -p yoi-workspace-server
    • cargo check -p yoi
    • yoi ticket doctor
    • nix build .#yoi --no-link
  • Validation log: /run/user/1000/yoi/yoi-orchestrator/bash-output/agent-skills-final-validation-1784160679.txt

Cleanup:

  • Implementation worktree/branch cleanup will be performed after close commit。
  • Per user instruction, StopPod is not used。