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

14 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.