菜单
Adopt existing external-memory onboarding as the first ledgered memory baseline after resolving context, checking drift, and requiring explicit acceptance when onboarding is not proven current.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The agent lifecycles: one lifecycle per agent type, under one roof. Routes every session by exactly three conditions (spawn-role env -> fresh role brief -> otherwise free-chat launcher), carries the minimal lifecycle frame (the six lifecycle signals every session shares), and houses the self-contained per-role lifecycles (architect, orchestrator, designer, strategist, manager, worker, curator, system-specialist, adversarial reviewer) plus the report-template library and the reviewer criteria catalogs. Solo work is the degenerate portfolio. Supersedes and replaces both l-01-session-job-lifecycle and l-02-agent-orchestration.
After the harness starter package and MCP server are wired and the harness has restarted, run/verify runtime_install, set up the memory repo, bootstrap onboarding when scaffolding new, and configure providers to index the code and memory.
Create, attach to, report on, integrate, finalize, and clean up Agents Remember worktree-backed tasks while preserving delegated/human approval gates and external-memory compatibility.
Close out approved Agents Remember edits by preserving the applicable approval authority, missing-onboarding checks, external-memory onboarding refresh, memory quality, ledger alignment, and no automatic push for worktree-backed tasks.
Create and maintain file-level onboarding and repo entity catalogs. Enforces strict 1-to-1 source mapping, governing overview links, metadata, and references, and routes package/module/source-slice create, refresh, move, or delete cases to the c-03-repo-bootstrap skill.
In-between task workflow for work that needs a durable task file, distinct implementation examples, and an approval gate but still fits a single-page implementation plan as a rule of thumb.
| name | c-10-adopt-memory-baseline |
| description | Adopt existing external-memory onboarding as the first ledgered memory baseline after resolving context, checking drift, and requiring explicit acceptance when onboarding is not proven current. |
Use this skill when an external memory repo already contains onboarding content and the developer wants to create the initial memory.md ledger from that content.
This skill does not decide that stale onboarding is true. It makes the trust boundary explicit: the c-02-memory-quality-control skill's drift is checked first, and actionable drift blocks adoption unless the developer explicitly accepts the current onboarding as the baseline.
Use the Agents Remember MCP memory baseline tools as the normal installed runtime entry point:
Preview first.
memory_baseline_adoptnow applies by default. Call it once withdry_run=trueto preview, confirm, then run the real apply (omitdry_run).
memory_baseline_status(repo_id="<repo-id>")
memory_baseline_adopt(repo_id="<repo-id>", accept_drift=false, dry_run=true) # preview
memory_baseline_adopt(repo_id="<repo-id>", accept_drift=true) # apply
Use memory_baseline_status first. Use memory_baseline_adopt only after the
developer approves the baseline decision. The skill tree is instruction-only;
installed and development workflows use the MCP/package route.
c-08-ar-coordination-context-resolver skill and confirm external topology.c-02-memory-quality-control skill's drift classification against the resolved onboarding root; its reusable report is written under the c-08-ar-coordination-context-resolver skill's resolved temp root.memory.md.accept_drift=true is part of the approved memory_baseline_adopt request.c-09-git-worktree-manager skill so the existing onboarding/system/docs content becomes the memory content commit and memory.md maps current code HEAD to that memory commit.ready: no ledger exists and drift is clean enough to adopt.blocked-drift: drift has actionable findings and accept_drift=true was not supplied.already-ledgered: memory.md already exists.adopted: the baseline ledger was created.would-adopt: dry run would create the baseline.c-10-adopt-memory-baseline skill may create the initial memory repo Git history and memory.md through the c-09-git-worktree-manager skill.c-10-adopt-memory-baseline skill must not refresh onboarding content itself; use the c-05-create-or-update-onboarding-files skill for that.c-10-adopt-memory-baseline skill must not overwrite an existing memory.md.accept_drift=true means the developer is asserting the current onboarding content is factual enough to become the baseline despite the c-02-memory-quality-control skill's warnings.