本文へ移動
cccskills
無料GitHub で公開

agent-core-dev

Use when developing in packages/agent-core-v2 (the DI × Scope agent engine) — adding or modifying a domain Service, choosing a LifecycleScope, wiring DI dependencies, splitting a domain across scopes, owning or migrating a config section, gating behavior behind an experimental flag, raising coded errors, working on the permission system, writing DI/Scope tests, porting business logic from agent-core (v1) to v2, triaging a main-branch commit against v2, or exposing a v2 domain over server-v2 while keeping the /api/v1 wire contract compatible with released clients. Self-contained guide organized by development stage (orient → design → implement → test → verify) plus align workflows for v1→v2 migration, main-branch commit triage, and server-v2 wire exposure; each file carries the rules, examples, and red lines for its step.

インストール方法を見る

含まれるファイル(13)

  • SKILL.md8.8 KB
  • align.md14.9 KB
  • config.md25.6 KB
  • design.md16.4 KB
  • domain-boundaries.md10.5 KB
  • edge-exposure.md10.7 KB
  • orient.md5.5 KB
  • permission.md16.7 KB
  • server-align.md18.6 KB
  • service-authoring.md20.8 KB
  • telemetry.md8.4 KB
  • test.md15.2 KB
  • verify.md2.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

agent-core-dev

Develop packages/agent-core-v2 by lifecycle stage. This skill is self-contained: every rule, recipe, and red line lives in the stage files below — it does not delegate to packages/agent-core-v2/docs/.

agent-core-v2 is the new agent engine built on the DI × Scope architecture (a port of packages/agent-core). Everything resolves through the container: a service declares an identity, its dependencies, and a lifetime; the container decides construction, singleton-per-scope, ordering, and disposal. The stage files restate the rules in imperative form so you can work without reading the source docs.

Lifecycle at a glance

Orient → Design → Implement → Test → Verify
  │        │          │          │        │
  │        │          │          │        └─ lint:imports · typecheck · test · dep graph · red lines
  │        │          │          └─ test.md
  │        │          └─ implement.md (+ errors.md · flags.md · permission.md)
  │        └─ design.md
  └─ orient.md

Stages are ordered but not strictly linear: a test failure (stage 4) that reveals a wrong scope sends you back to design (stage 2); a CyclicDependencyError sends you to design.md §dependency-direction and implement.md §cycles.

Workflows

End-to-end procedures that span the stages. Reach for these before reading the stage files individually.

  • Align (port agent-core → agent-core-v2): split a v1 class into semantic units, fix each unit's domain / scope / Service / dependencies, then migrate the logic and tests. Use when the task is "move feature X from v1 to v2" or "port IXxxService to v2".
  • Commit align (triage a main commit against v2): given one main commit hash + a short note, find the v1 logic it changed, check whether v2 already has the corresponding implementation, bucket it (aligned / partial / missing / not-applicable), and recommend a minimal fix. Use in the pythinker-code-v2-catching-up-to-main phase, for one commit at a time; escalate to align.md if the gap is a whole domain.
  • Server align (expose agent-core-v2 over server-v2): wire a v2 domain into packages/agent-gateway over /api/v2 (native) and /api/v1 (v1-compatible mirror), keep the wire schema byte-compatible with the established v1 contract by sharing the @pymodel/protocol schema, and isolate v1-only behavior in a <domain>Legacy edge adapter instead of distorting the native v2 Service. Use when the task is "expose the new v2 Service on the server", "add a route to the /api/v1 surface", or "keep server-v2 wire-compatible with released v1 clients".

Stages

  • Stage 1 — Orient: the DI black box (identity / dependencies / lifetime), the three LifecycleScope tiers and visibility, the separate workspace program lifetime, and the no-comment convention. Read before touching business code.
  • Stage 2 — Design a service: pick a scope, split a domain across scopes, choose a calling style (direct call vs event vs hook), and direct dependencies. Decide where things live and who knows whom before coding.
    • Topic: Domain boundaries vs Scope — keep session / agent / turn from becoming god objects; data-ownership test and their split conclusions.
    • Topic: Persistence layering — the three-layer Store → Storage → backend model, naming Stores by access pattern, and which layer business code should depend on.
    • Topic: Edge exposure — resource:action + WS events — which Services are exposed over /api/v2 (per-scope action map) and which events stream over WS; what to wrap in a facade.
  • Stage 3 — Implement: the standard Service recipe and the DI building blocks — interface + identity, constructor injection, scoped registration, Disposable, eager vs delayed, invokeFunction, createInstance, child scopes, and the cycle-refactor playbook.
    • Topic: Service authoring — file layout, naming, contract vs impl contents, interface style, constructor/field conventions, events, multi-Service domains, comment rules.
    • Topic: Config — the section-registry model, App vs Session split, owning a config section, the TOML format, and the env overlay.
    • Topic: Errors — co-located XxxError, the central code registry, wire serialization, boundary translation.
    • Topic: Flags — registerFlagDefinition, IFlagService.enabled(id), the [experimental] config section, resolution precedence.
    • Topic: Permission — risk-only chain-of-responsibility kernel, harness constraints and product reviews as domain onBeforeExecuteTool veto listeners (veto / allow / pass / cold waitUntil factories), shared toolApproval round-trip, policy registry + composer, modes/agentTypes metadata, resolveExecution/accesses.
    • Topic: Telemetry — emitting events via ITelemetryService, context propagation, and appender destinations (ConsoleAppender / CloudAppender).
  • Stage 4 — Test: resolve the system under test by interface, pick TestInstantiationService vs createScopedTestHost, shared stubs, service groups, teardown.
  • Stage 5 — Verify & submit: lint:imports, typecheck, test, and the pre-submit checklist.

How to use this skill

Jump to the stage you are in and read that one file; each is self-contained and ends with its own red lines. Skim the global red lines below before submitting — they catch most mistakes across every stage. The repo's source of truth remains the code in packages/agent-core-v2/src/; this skill codifies the same rules so you do not have to re-derive them.

Global red lines

Invariants that hold across every stage. Each is expanded in the stage file noted.

  1. No new on a class whose constructor carries @IService deps — inject with @IX or accessor.get(IX). (implement.md)
  2. @IX decorates constructor parameters only; parameter order depends on construction (static-first for createInstance, @IX-first for scoped services). (service-authoring.md)
  3. Both interface and impl carry _serviceBrand; the createDecorator name is globally unique. (implement.md)
  4. Parent scope never depends on child scope — short-lived may inject long-lived, never the reverse. (orient.md)
  5. No cyclic dependencies — refactor (extract a third Service / use an event / re-scope); activation timing does not break dependency cycles. (design.md, implement.md)
  6. ServicesAccessor is valid only during invokeFunction — never stash it for async use. (implement.md)
  7. Scope follows state identity — no Map<sessionId, …> at App to fake per-session state. (design.md)
  8. Foundational layers never know upstream ones; business code never depends on the edge layer (gateway/rpc). (design.md)
  9. Throw coded errors; register codes centrally; branch on code across the wire, never instanceof. (errors.md)
  10. Gate unreleased behavior behind a flag contributed via registerFlagDefinition and resolved through IFlagService.enabled(id); no ad-hoc env toggles. (flags.md)
  11. Tests resolve the SUT by interface; shared stubs live under test/, never src/. (test.md)
  12. Config is the preference registry: only preferences that are persistable, schema'd, and user/operator-facing go in IConfigService. Domain-specific config (including env-only operational toggles) goes through registerConfigSection + envOverlay. Facts → IBootstrapService, and host invocation arguments (CLI flags, host identity headers, prompt identity) → BootstrapInput.args / IBootstrapService.args — never new per-domain runtime-options services; domain runtime state (cron/flags/model) never goes onto IBootstrapService; session state → Session scope; constants → code. Business domains never call IBootstrapService.getEnv() directly. (config.md)

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.

日本語の概要は準備中です。原文の説明を表示しています。

PyModel/pythinker-code292026年10月10日 更新

Apply an approved sub-skill grouping by moving user-specified skills into a parent bundle, with timestamped backups of every modified directory.

日本語の概要は準備中です。原文の説明を表示しています。

PyModel/pythinker-code292026年10月10日 更新

dogfood

無料

Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to "dogfood", "QA", "exploratory test", "find issues", "bug hunt", "test this app/site/platform", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.

日本語の概要は準備中です。原文の説明を表示しています。

PyModel/pythinker-code292026年10月10日 更新

electron

無料

Automate Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify, etc.) using agent-browser via Chrome DevTools Protocol. Use when the user needs to interact with an Electron app, automate a desktop app, connect to a running app, control a native app, or test an Electron application. Triggers include "automate Slack app", "control VS Code", "interact with Discord app", "test this Electron app", "connect to desktop app", or any task requiring automation of a native Electron application.

日本語の概要は準備中です。原文の説明を表示しています。

PyModel/pythinker-code292026年10月10日 更新

Use when generating changesets in the pythinker-code repository — deciding whether to write one, which package to list, the bump level, the wording, and the confirmation workflow.

日本語の概要は準備中です。原文の説明を表示しています。

PyModel/pythinker-code292026年10月10日 更新

gen-docs

無料

Update Pythinker Code CLI user documentation after meaningful code changes that affect product behavior or user experience.

日本語の概要は準備中です。原文の説明を表示しています。

PyModel/pythinker-code292026年10月10日 更新

PyModel のスキルをすべて見る

このスキルの問題を報告する