recoup-platform-build-os

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Recoup — Build Label OS

Recoup — 构建唱片公司OS

The point is not the folders — it's to scaffold a system that both manages itself and improves itself. It keeps its own state current (never-stale) and gets better at its own job over time: compounding knowledge, promoting repeated work into new skills, and improving its own machinery. Hold that as the goal of every phase below; the structure only exists to serve it.

Concretely, turn a kickoff input into a living operating system: a folder + file structure, a self-managing

CLAUDE.md

(mirrored to

AGENTS.md

), a

plugin/

directory (an in-place installable plugin with skills inside), a never-stale janitor backed by a read-only doctor, a compound-learning loop, and a self-improvement loop. The plugin is named

{DOMAIN_SLUG}-os

by default and includes manifests/adapters for Claude, Cursor, and Codex.

This builder skill is for the agent running it. Follow the phases in order. Don't stop halfway — drive to a working OS, then report. Read the references as you reach each phase.

核心并非文件夹，而是搭建一套既能自我管理又能自我优化的系统。 它能保持自身状态实时更新（永不失效），同时随着时间推移不断提升工作能力：积累知识、将重复工作转化为新技能、优化自身机制。请将这一点作为以下每个阶段的目标；结构仅为服务于此目标而存在。

具体而言，将启动输入转化为一个活的操作系统：文件夹+文件结构、自管理的

CLAUDE.md

（与

AGENTS.md

镜像同步）、

plugin/

目录（包含内置可安装插件及技能）、由只读检查器doctor支持的永不失效清理器janitor、复合学习循环以及自我改进循环。插件默认命名为

{DOMAIN_SLUG}-os

，并包含适用于Claude、Cursor和Codex的清单/适配器。

此构建技能供运行它的Agent使用。请按顺序执行各阶段。不要半途而废——直至构建出可运行的OS，再进行汇报。执行到每个阶段时，请阅读对应的参考文档。

Recoup specialization — this is a music-company OS [read before Phase 0]

Recoup 专属化——这是一款音乐公司操作系统 [第0阶段前必读]

This skill is

workspace-os

(by Sidney Swift) locked to one domain — a music company / independent label — and wired into Recoup. The phases below are unchanged; apply them with these Recoup rules layered on top.

The domain is fixed — don't re-infer it. Core unit: the artist (and their releases). Entities folder: top-level
```
artists/
```
. The release lifecycle (
```
demo -> A&R -> signed -> production -> release -> promo -> catalog
```
) is tracked per release under
```
artists/{slug}/releases/
```
(stage in
```
RELEASE.md
```
) — there is no separate top-level
```
pipeline/
```
; unsigned candidates live in
```
prospects/
```
. Spend Phase 0's effort understanding this specific label (roster, genres, deal posture, content motion, team), not which archetype it is.
The repo is one org/label. This runs inside a single org's git repo, so artists live at top-level
artists/{artist-slug}/
— no
```
orgs/
```
nesting (the repo already is the org).
Seed Recoup's conventions exactly — other recoup skills depend on them:
- ```
artists/{artist-slug}/RECOUP.md
```
  — identity file, frontmatter
```
artistName
```
  /
```
artistSlug
```
  /
```
artistId
```
  (artistId = the Recoup
```
account_id
```
  ). Same shape
```
recoup-roster-list-artists
```
  ,
```
recoup-roster-add-artist
```
  read/write.
- ```
releases/{release-slug}/RELEASE.md
```
  and
```
releases/top-tracks.md
```
  per artist.
- ```
slugify
```
  = lowercase-kebab; never append IDs to folder names.
Secrets stay out of the shared repo. Always seed
```
.env.example
```
(documenting
```
RECOUP_API_KEY
```
or
```
RECOUP_ACCESS_TOKEN
```
,
```
RECOUP_ORG_ID
```
, optional
```
RECOUP_API_URL
```
) and a
```
.gitignore
```
that ignores
```
.env
```
. Real credentials live outside the repo (env vars /
```
~/.claude/recoup.env
```
); never commit them — the repo is shared across the label's team.
The Recoup API is the system of record; the repo is the brain. Get the real roster from the live account — never invent one:
1. Connect the machine first by chaining recoup-platform-connect-account
  (mints/loads the credential:
```
RECOUP_API_KEY
```
  or
```
RECOUP_ACCESS_TOKEN
```
  , optional
```
RECOUP_ORG_ID
```
  ).
2. If the roster is empty (0 artists), hand off to
  recoup-roster-onboard
  to bootstrap it (it fans
```
recoup-roster-add-artist
```
  out across parallel subagents); otherwise materialize the existing roster into
```
artists/
```
  yourself:
```
GET /api/organizations
```
  (or use
```
RECOUP_ORG_ID
```
  ) ->
```
GET /api/artists?org_id=…
```
  ->
```
mkdir -p artists/{slugify(name)}
```
  and write
```
RECOUP.md
```
  per artist (
```
artistName
```
  /
```
artistSlug
```
  /
```
artistId
```
  from
```
account_id
```
  ); skip existing. Use recoup-roster-list-artists
  to inventory first and recoup-platform-api-access
  for the call shapes.
3. Write
```
operations/sync.md
```
  with the contract: DB owns structured entities (roster, socials, metrics, releases-as-records, billing); the repo owns the unstructured brain (knowledge, research, plans, drafts). Entity creation is API-first — onboard a new artist with recoup-roster-add-artist
  (the 8-call create -> enrich chain), then its folder appears; never create an artist by
```
mkdir
```
  alone. Use recoup-platform-api-access
  for raw REST / connector calls. Empty orgs+artists usually means a throwaway key, not a blank label — surface it, don't fabricate a roster.
Reuse the platform; don't reinvent it. In Phase 4, do not author
```
plugin/skills/
```
that duplicate Recoup capabilities — wire to the installed
```
recoup-*
```
skills: roster (
```
recoup-roster-*
```
), research (
```
recoup-research-*
```
), content (
```
recoup-content-*
```
), release (
```
recoup-release-*
```
), song (
```
recoup-song-*
```
), catalog (
```
recoup-catalog-*
```
). The OS's own
```
plugin/skills/
```
should be label-specific glue (this label's routines/orchestration) plus the standard maintenance organs (doctor/janitor/learn/reflect/skillify/intake). Default the plugin name to
```
{label-slug}-os
```
.
Still scaffold everything else a music company needs. Beyond the core (
```
artists/
```
,
```
knowledge/
```
,
```
library/
```
,
```
work/
```
,
```
artifacts/
```
,
```
plugin/
```
,
```
operations/
```
), add optional folders only with real material:
```
content/
```
(the flywheel),
```
deals/
```
(catalog acquisitions),
```
contacts/
```
(industry network),
```
proof/
```
(press/milestones),
```
business/
```
(splits/royalties/contracts),
```
prospects/
```
(A&R funnel),
```
reference/
```
(label bible). Mark inferred items "draft — confirm". See
```
references/blueprint.md
```
for the full tree.
Filling the generic templates (doctor/dashboard/janitor). When you generate them from
```
assets/
```
, the entity is
```
artists/
```
and there is no pipeline folder — leave
```
{PIPELINE}
```
empty, or set it to
```
prospects/
```
only if the label does A&R. The doctor reads release status from each
```
artists/{slug}/releases/
```
(stage in
```
RELEASE.md
```
), not a top-level funnel.

此技能是Sidney Swift开发的

workspace-os

锁定在单一领域的版本——音乐公司/独立唱片公司——并与Recoup集成。以下阶段流程保持不变；请在其基础上遵循Recoup的规则。

领域固定——无需重新推断。 核心单元：艺人（及其发行作品）。实体文件夹：顶级目录
```
artists/
```
。作品发行生命周期（
```
demo -> A&R -> 签约 -> 制作 -> 发行 -> 推广 ->  catalog
```
）在
```
artists/{slug}/releases/
```
下按单个作品追踪（状态记录在
```
RELEASE.md
```
中）——没有单独的顶级目录
```
pipeline/
```
；未签约候选艺人存放在
```
prospects/
```
中。第0阶段需专注了解这家特定唱片公司（艺人名单、流派、合作姿态、内容运营、团队），而非其所属的类型。
仓库对应单个组织/唱片公司。 此系统运行在单个组织的Git仓库内，因此艺人存放在顶级目录
artists/{artist-slug}/
——无需嵌套
```
orgs/
```
（仓库本身即代表该组织）。
严格遵循Recoup的约定——其他recoup技能依赖这些约定：
- ```
artists/{artist-slug}/RECOUP.md
```
  ——身份文件，前置元数据包含
```
artistName
```
  /
```
artistSlug
```
  /
```
artistId
```
  （artistId = Recoup的
```
account_id
```
  ）。格式与
```
recoup-roster-list-artists
```
  、
```
recoup-roster-add-artist
```
  的读写格式一致。
- 每位艺人对应
```
releases/{release-slug}/RELEASE.md
```
  和
```
releases/top-tracks.md
```
  。
- ```
slugify
```
  规则：小写短横线分隔；切勿在文件夹名称后追加ID。
敏感信息请勿存入共享仓库。 务必初始化
```
.env.example
```
（记录
```
RECOUP_API_KEY
```
或
```
RECOUP_ACCESS_TOKEN
```
、
```
RECOUP_ORG_ID
```
、可选的
```
RECOUP_API_URL
```
）以及忽略
```
.env
```
的
```
.gitignore
```
文件。真实凭据存放在仓库外部（环境变量 /
```
~/.claude/recoup.env
```
）；切勿提交这些凭据——仓库为唱片公司团队共享。
Recoup API为记录系统；仓库为智能大脑。 从实时账户获取真实艺人名单——切勿虚构：
1. 首先通过链式调用**
```
recoup-platform-connect-account
```
  **连接系统（生成/加载凭据：
```
RECOUP_API_KEY
```
  或
```
RECOUP_ACCESS_TOKEN
```
  、可选的
```
RECOUP_ORG_ID
```
  ）。
2. 若艺人名单为空（0位艺人），则移交至
  recoup-roster-onboard
  进行引导（它会并行调用多个子Agent执行
```
recoup-roster-add-artist
```
  ）；否则自行将现有艺人名单同步到
```
artists/
```
  ：
```
GET /api/organizations
```
  （或使用
```
RECOUP_ORG_ID
```
  ）->
```
GET /api/artists?org_id=…
```
  ->
```
mkdir -p artists/{slugify(name)}
```
  并为每位艺人编写
```
RECOUP.md
```
  （从
```
account_id
```
  获取
```
artistName
```
  /
```
artistSlug
```
  /
```
artistId
```
  ）；跳过已存在的艺人。请先使用**
```
recoup-roster-list-artists
```
  盘点，再使用
```
recoup-platform-api-access
```
  **获取调用格式。
3. 编写
```
operations/sync.md
```
  明确契约：数据库负责结构化实体（艺人名单、社交账号、数据指标、发行记录、账单）；仓库负责非结构化智能内容（知识、调研、计划、草稿）。实体创建遵循API优先原则——使用**
```
recoup-roster-add-artist
```
  （包含8步创建->丰富流程）完成新艺人入职，之后再创建对应的文件夹；切勿仅通过
  mkdir
  创建艺人。使用
```
recoup-platform-api-access
```
  **进行原始REST/连接器调用。空组织+空艺人名单通常意味着临时密钥，而非空白唱片公司——请如实反馈，切勿编造艺人名单。
复用现有平台；切勿重复造轮子。 在第4阶段，请勿编写与Recoup功能重复的
```
plugin/skills/
```
——请与已安装的
```
recoup-*
```
技能集成：艺人名单（
```
recoup-roster-*
```
）、调研（
```
recoup-research-*
```
）、内容（
```
recoup-content-*
```
）、发行（
```
recoup-release-*
```
）、歌曲（
```
recoup-song-*
```
）、 catalog（
```
recoup-catalog-*
```
）。OS自身的
```
plugin/skills/
```
应包含唱片公司专属的衔接逻辑（该公司的常规流程/编排）以及标准维护组件（doctor/janitor/learn/reflect/skillify/intake）。插件默认命名为
```
{label-slug}-os
```
。
仍需搭建音乐公司所需的所有其他内容。 除核心目录（
```
artists/
```
、
```
knowledge/
```
、
```
library/
```
、
```
work/
```
、
```
artifacts/
```
、
```
plugin/
```
、
```
operations/
```
）外，仅当有真实内容时才添加可选文件夹：
```
content/
```
（内容飞轮）、
```
deals/
```
（catalog收购）、
```
contacts/
```
（行业人脉）、
```
proof/
```
（媒体报道/里程碑）、
```
business/
```
（分成/版税/合同）、
```
prospects/
```
（A&R漏斗）、
```
reference/
```
（唱片公司指南）。推断的内容请标记为「草稿——待确认」。完整目录结构请参考
```
references/blueprint.md
```
。
填充通用模板（doctor/dashboard/janitor）。 从
```
assets/
```
生成这些模板时，实体目录为
```
artists/
```
，且无pipeline文件夹——将
```
{PIPELINE}
```
留空，或仅当唱片公司开展A&R业务时设置为
```
prospects/
```
。doctor从每个
```
artists/{slug}/releases/
```
读取作品发行状态（记录在
```
RELEASE.md
```
中），而非从顶级漏斗目录读取。

Operating beliefs (apply to every OS you build)

核心理念（适用于所有构建的OS）

Every belief below serves one goal: a system that manages itself (stays current) and improves itself (compounds its knowledge, its capabilities, and its own machinery).

Separate what compounds from what flows. Compounding = reusable assets that improve every time (templates, knowledge base, skills, proof). Flowing = instances moving through stages (deals, tickets, releases, experiments). Wire feedback so every flowing instance deposits back into a compounding asset.
Never stale. It is the agent's job to manage state. Any time new input arrives OR the user works in the OS, every file/folder that should change gets touched in the same turn. A janitor skill + scheduled task is the safety net.
Compound learning. Every session makes the system smarter — capture decisions, recurring answers, and patterns into the knowledge base. Never solve the same thing twice.
Skillify proven repeatable work. After finishing work, ask whether it will be done again or maintained. If yes, promote the proven process into a staged, verified skill before it lands in
```
plugin/skills/
```
. One-off work stays in
```
work/
```
(dated) — it never becomes its own top-level folder.
Self-describing. Every folder explains its own purpose;
```
CLAUDE.md
```
encodes where new things go and how to keep the system current.
Evidence over confidence. "Done", "consistent", and "reachable" are decided by a checkable surface — a
```
{domain}-doctor
```
run, a skill's verification, a reachable trigger — not the agent's feeling. And the OS improves itself over time (
```
{domain}-reflect
```
), not just its contents.

以下每一条理念都服务于同一个目标：构建一套自我管理（保持实时更新）且自我优化（积累知识、提升能力、优化自身机制）的系统。

区分可积累资产与流动事务。 可积累资产=可重复使用且持续优化的资源（模板、知识库、技能、成果证明）。流动事务=处于不同阶段的实例（合作项目、工单、发行作品、实验）。建立反馈机制，让每个流动事务都能为可积累资产贡献内容。
永不失效。 Agent负责管理状态。每当有新输入或用户在OS中操作时，所有应更新的文件/文件夹都需在同一轮操作中完成更新。janitor技能+定时任务是安全保障。
复合学习。 每次会话都能让系统更智能——将决策、常见问题答案和模式存入知识库。切勿重复解决同一问题。
将已验证的重复工作转化为技能。 完成工作后，判断该工作是否会重复进行或需要维护。若是，则在将其存入
```
plugin/skills/
```
前，将已验证的流程转化为分阶段的可验证技能。一次性工作存放在
```
work/
```
（带日期）——切勿将其提升为顶级目录。
自我描述。 每个文件夹都需说明自身用途；
```
CLAUDE.md
```
需明确新内容的存放位置及系统维护方式。
基于证据而非主观判断。 「完成」「一致」「可实现」需通过可检查的依据来判定——
```
{domain}-doctor
```
的运行结果、技能的验证、可触发的动作——而非Agent的主观感受。且OS需随时间自我优化（通过
```
{domain}-reflect
```
），而非仅优化其内容。

Phase 0 — Understand the project deeply (always first)

第0阶段——深入理解项目（始终优先执行）

Read

references/domain-inference.md

Ingest ALL kickoff input (files, transcripts, prompt). If files exist, read them fully.
Determine the domain archetype and the core unit of work (e.g. consulting -> deals/clients, product -> features/releases, record label -> artists/releases, research -> questions/experiments).
If input is rich, derive structure from the material. If input is sparse (just a prompt), use best judgment: infer the domain, predict the entities, stages, assets, routines, and metrics the project will need, and anticipate them rather than waiting — but express that preparation as stubs and subfolders inside a lean root (see Phase 1), not as extra top-level directories.
Produce a short Understanding Brief: domain, core unit, lifecycle stages, key entities, compounding assets, recurring tasks (skill candidates), metrics, and likely external tools.
Confirm the brief with the user only if something material is ambiguous; otherwise proceed.

阅读

references/domain-inference.md

。

导入所有启动输入（文件、转录文本、提示词）。若存在文件，请完整阅读。
确定领域类型和核心工作单元（例如：咨询->合作项目/客户、产品->功能/发行、唱片公司->艺人/发行作品、调研->问题/实验）。
若输入丰富，则从现有材料中提炼结构。若输入稀疏（仅提示词），则运用最佳判断：推断领域、预测项目所需的实体、阶段、资产、常规流程和指标，并提前准备——但请将这些准备内容作为存根和子文件夹放在精简的根目录下（见第1阶段），而非添加额外的顶级目录。
生成简短的理解简报：领域、核心单元、生命周期阶段、关键实体、可积累资产、重复任务（技能候选）、指标、可能的外部工具。
仅当存在重大歧义时才与用户确认简报；否则直接推进。

Phase 1 — Design the taxonomy

第1阶段——设计分类体系

Read

references/blueprint.md

Start from the small core the loops maintain: the flowing stores (a staged pipeline folder + an entity folder like
```
clients/
```
/
```
artists/
```
/
```
features/
```
), the compounding stores
```
knowledge/
```
and
```
library/
```
,
```
work/
```
(non-recurring output, by project),
```
artifacts/
```
(finalized recurring outputs like the dashboard),
```
plugin/
```
(the in-place plugin), and
```
operations/
```
(routines, sync, health, improvements).
Add an optional top-level folder only when the domain has real material for it now —
```
reference/
```
(canon/source),
```
proof/
```
(outcomes),
```
content/
```
(a real content motion),
```
business/
```
(legal/finance/metrics). When unsure, leave it out; adding later is one
```
mkdir
```
.
Keep every top-level folder name to one lowercase word (
```
operations
```
, not
```
operating-system
```
;
```
knowledge
```
, not
```
knowledge-base
```
). Rename to the domain's language but keep it a single word. (Skill folders inside
```
plugin/skills/
```
stay kebab-case — a different convention.)
Don't reproduce the whole anatomy by reflex, and don't promote one-off work to a top-level folder — ad-hoc tasks live in
```
work/
```
; only work that repeats or needs upkeep becomes a skill in
```
plugin/
```
. Push over-preparation into subfolders and stubs, not a row of empty top-level dirs.

阅读

references/blueprint.md

。

从循环维护的小型核心目录开始：流动存储（分阶段的pipeline文件夹+实体文件夹如
```
clients/
```
/
```
artists/
```
/
```
features/
```
）、可积累存储
```
knowledge/
```
和
```
library/
```
、
```
work/
```
（非重复输出，按项目分类）、
```
artifacts/
```
（最终的重复输出如仪表盘）、
```
plugin/
```
（内置插件）、
```
operations/
```
（常规流程、同步、健康检查、改进）。
仅当领域当前有真实内容时才添加可选顶级目录——
```
reference/
```
（标准/来源）、
```
proof/
```
（成果）、
```
content/
```
（真实内容运营）、
```
business/
```
（法务/财务/指标）。若不确定，则暂不添加；后续只需执行
```
mkdir
```
即可添加。
所有顶级目录名称保持单个小写单词（
```
operations
```
，而非
```
operating-system
```
；
```
knowledge
```
，而非
```
knowledge-base
```
）。可根据领域术语重命名，但需保持单个单词。（
```
plugin/skills/
```
内的技能文件夹保持短横线分隔格式——这是不同的约定。）
切勿机械照搬完整结构，且切勿将一次性工作提升为顶级目录——临时任务存放在
```
work/
```
；仅重复进行或需要维护的工作才会成为
```
plugin/
```
中的技能。将过度准备的内容放入子文件夹和存根，而非创建一排空的顶级目录。

Phase 2 — Scaffold structure + the brain

第2阶段——搭建结构与核心大脑

Create only the folders the taxonomy calls for (lean root). Give every non-obvious folder a short
```
README.md
```
stub stating what belongs there.

Write

artifacts/dashboard.html

from

assets/dashboard.html.tmpl

(HTML, not md). Seed

operations/health.md

(empty — the

{domain}-doctor

fills it) and

operations/improvements.md

(a header for the

{domain}-reflect

ledger).

Write the self-managing
```
CLAUDE.md
```
from
```
assets/CLAUDE.md.tmpl
```
, customized to the domain (filing decision tree, the auto-manage loop, never-stale contract, repetition-to-skill rule). Read
```
references/self-management.md
```
for what the contract must contain.
Create
```
AGENTS.md
```
as a symlink to
```
CLAUDE.md
```
(
```
ln -s CLAUDE.md AGENTS.md
```
) so agent runners that look for either file get the same brain. If symlinks aren't supported, write an
```
AGENTS.md
```
that says "See CLAUDE.md" — but prefer the symlink.

仅创建分类体系要求的文件夹（精简根目录）。为每个非显而易见的文件夹添加简短的
```
README.md
```
存根，说明其用途。

从

assets/dashboard.html.tmpl

生成

artifacts/dashboard.html

（HTML格式，而非md）。初始化

operations/health.md

（空文件——由

{domain}-doctor

填充）和

operations/improvements.md

（

{domain}-reflect

记录的标题）。

从
```
assets/CLAUDE.md.tmpl
```
编写自管理的
```
CLAUDE.md
```
，针对领域定制（归档决策树、自动管理循环、永不失效契约、重复工作转技能规则）。请阅读
```
references/self-management.md
```
了解契约必须包含的内容。
创建
```
AGENTS.md
```
作为
```
CLAUDE.md
```
的符号链接（
```
ln -s CLAUDE.md AGENTS.md
```
），以便查找任一文件的Agent运行器都能获取相同的核心大脑。若不支持符号链接，则编写
```
AGENTS.md
```
并注明「参见CLAUDE.md」——但优先使用符号链接。

Phase 3 — Seed compounding assets

第3阶段——初始化可积累资产

Populate
```
library/
```
(blank instruments you reuse — templates, scripts, checklists) and
```
knowledge/
```
(settled answers you read back — faqs, insights, decisions, sops). Rule of thumb: if you'd use it to make something it's
```
library/
```
; if you'd consult it to decide something it's
```
knowledge/
```
.
Extract this material from the input. With sparse input, seed sensible starter templates for the domain and mark them "draft — confirm".

填充
```
library/
```
（可重复使用的空白工具——模板、脚本、检查清单）和
```
knowledge/
```
（可查阅的既定答案——常见问题、洞察、决策、标准操作流程）。经验法则：若用于创建内容则存入
```
library/
```
；若用于辅助决策则存入
```
knowledge/
```
。
从输入中提取这些材料。若输入稀疏，则为领域初始化合理的起始模板，并标记为「草稿——待确认」。

Phase 4 — Author skills (the in-place

plugin/

)

第4阶段——编写技能（内置

plugin/

）

Read

references/skill-authoring.md

and

references/skillifying-work.md

(promotion workflow).

Derive the plugin name from the domain as
```
{DOMAIN_SLUG}-os
```
(kebab-case) unless the user explicitly gave a name. Use that same name in every manifest.

Scaffold

plugin/

as a real plugin in place:

plugin/.claude-plugin/plugin.json

from

assets/claude-plugin.json.tmpl

plugin/.codex-plugin/plugin.json

from

assets/codex-plugin.json.tmpl

, and a

plugin/skills/

directory. The Codex manifest must include

"skills": "./skills/"

; see

references/packaging.md

Create
```
.agents/skills
```
as a symlink to
```
../plugin/skills
```
so Cursor and Codex can discover the same project skills. If symlinks aren't supported, copy
```
plugin/skills/
```
there and note that it is a compatibility mirror.
For each recurring task in the brief, author
```
plugin/skills/{name}/SKILL.md
```
(frontmatter
```
name
```
+ description with real trigger phrases, then imperative steps referencing the workspace paths).
Always include the maintenance skills (the OS's feedback organs), generated from the templates:
- a doctor (
```
assets/doctor-SKILL.md.tmpl
```
  ) — the read-only verification surface (health score + punch list to
```
operations/health.md
```
  ); the janitor and the build report are gated on it. Also generate
```
operations/doctor.py
```
  from
```
assets/doctor.py.tmpl
```
  (fill the
```
PIPELINE
```
  /
```
ENTITY
```
  /slug) as its deterministic fast path — so the mechanical checks ship with the build instead of being reinvented later.
- a janitor (
```
assets/janitor-SKILL.md.tmpl
```
  ) — run the doctor, then reconcile and fix what's safe.
- a compound-learn skill (
```
assets/compound-learn-SKILL.md.tmpl
```
  ) — capture decisions/answers/patterns into
```
knowledge/
```
  after each work session.
- a reflect skill (
```
assets/reflect-SKILL.md.tmpl
```
  ) — improve the OS itself (skills, routing, checks, templates) into
```
operations/improvements.md
```
  ; the 50/50 budget.
- a skillify skill (
```
assets/skillify-SKILL.md.tmpl
```
  ) — promote proven repeatable work into staged, verified skills.
Also include an orchestrator skill (the auto-manage loop as one trigger) named
```
{domain}-intake
```
.
Routing stays lean: rely on each skill's
```
description
```
for routing while the pack is small; add a
```
plugin/skills/RESOLVER.md
```
(trigger -> skill table) only once skills grow enough that descriptions overlap or the doctor's reachability check flags ambiguity.
Author a skill only for work that repeats or needs upkeep — one-off builds belong in
```
work/
```
, not a throwaway skill. For skills created from completed work, follow the skillify loop: prove provenance, extract the repeatable process, stage in
```
work/
```
, verify with the strongest domain-appropriate check, ask before moving into
```
plugin/skills/
```
, then repackage.

阅读

references/skill-authoring.md

和

references/skillifying-work.md

（晋升流程）。

根据领域将插件命名为
```
{DOMAIN_SLUG}-os
```
（短横线分隔格式），除非用户明确指定名称。所有清单均使用此名称。

现场搭建

plugin/

作为真实插件：从

assets/claude-plugin.json.tmpl

生成

plugin/.claude-plugin/plugin.json

，从

assets/codex-plugin.json.tmpl

生成

plugin/.codex-plugin/plugin.json

，并创建

plugin/skills/

目录。Codex清单必须包含

"skills": "./skills/"

；请参考

references/packaging.md

。

创建
```
.agents/skills
```
作为
```
../plugin/skills
```
的符号链接，以便Cursor和Codex能发现相同的项目技能。若不支持符号链接，则将
```
plugin/skills/
```
复制到该目录，并注明这是兼容性镜像。
针对简报中的每个重复任务，编写
```
plugin/skills/{name}/SKILL.md
```
（前置元数据包含
```
name
```
+带真实触发短语的描述，然后是引用工作空间路径的命令式步骤）。
务必包含从模板生成的维护技能（OS的反馈组件）：
- doctor（
```
assets/doctor-SKILL.md.tmpl
```
  ）——只读验证界面（健康评分+待办事项存入
```
operations/health.md
```
  ）；janitor和构建报告需以此为前提。同时从
```
assets/doctor.py.tmpl
```
  生成
```
operations/doctor.py
```
  （填充
```
PIPELINE
```
  /
```
ENTITY
```
  /slug）作为确定性快速路径——这样机械检查可随构建一起交付，无需后续重新开发。
- janitor（
```
assets/janitor-SKILL.md.tmpl
```
  ）——运行doctor，然后协调并修复安全的问题。
- compound-learn技能（
```
assets/compound-learn-SKILL.md.tmpl
```
  ）——每次工作会话后将决策/答案/模式存入
```
knowledge/
```
  。
- reflect技能（
```
assets/reflect-SKILL.md.tmpl
```
  ）——将OS自身的改进（技能、路由、检查、模板）存入
```
operations/improvements.md
```
  ；遵循50/50预算。
- skillify技能（
```
assets/skillify-SKILL.md.tmpl
```
  ）——将已验证的重复工作转化为分阶段的可验证技能。
还需包含一个编排器技能（自动管理循环作为单一触发器），命名为
```
{domain}-intake
```
。
路由保持精简： 在插件规模较小时，依赖每个技能的
```
description
```
进行路由；仅当技能数量增长到描述重叠或doctor的可触达性检查标记歧义时，才添加
```
plugin/skills/RESOLVER.md
```
（触发词->技能对照表）。
仅为重复进行或需要维护的工作编写技能——一次性构建存放在
```
work/
```
，而非创建临时技能。对于从已完成工作创建的技能，请遵循skillify循环：证明来源、提取可重复流程、存入
```
work/
```
分阶段处理、通过最适合领域的检查进行验证、移入
```
plugin/skills/
```
前征求用户同意，然后重新打包。

Phase 5 — Package the plugin

第5阶段——打包插件

Read

references/packaging.md

Run
```
{domain}-doctor
```
first — packaging is gated on a clean (or explained) report.
The workspace
```
plugin/
```
directory is already the installable plugin — no copying. Validate it: every
```
plugin/skills/*/
```
has a
```
SKILL.md
```
; both plugin manifests are valid JSON and share the
```
{DOMAIN_SLUG}-os
```
name; the Codex manifest points at
```
./skills/
```
; no angle brackets in any description; no stray non-skill folders in
```
plugin/skills/
```
;
```
.agents/skills
```
points to or mirrors
```
plugin/skills/
```
. Fix before packaging.
```
zip
```
the contents of
```
plugin/
```
to
```
/tmp
```
first, then copy the
```
.plugin
```
to the outputs folder and present it for install.

阅读

references/packaging.md

。

首先运行
```
{domain}-doctor
```
——打包需以干净（或已说明）的报告为前提。
工作空间的
```
plugin/
```
目录本身即为可安装插件——无需复制。验证内容：每个
```
plugin/skills/*/
```
都包含
```
SKILL.md
```
；两个插件清单均为有效JSON且共享
```
{DOMAIN_SLUG}-os
```
名称；Codex清单指向
```
./skills/
```
；所有描述中无尖括号；
```
plugin/skills/
```
中无无关非技能文件夹；
```
.agents/skills
```
指向或镜像
```
plugin/skills/
```
。打包前修复所有问题。
先将
```
plugin/
```
的内容压缩到
```
/tmp
```
，然后将
```
.plugin
```
文件复制到输出文件夹并供用户安装。

Phase 6 — Wire the never-stale schedule

第6阶段——配置永不失效的定时任务

Try to create a scheduled task that runs the janitor skill (default weekly) so the workspace self-reconciles even when the user isn't looking.
If no scheduling tool is available, or the user declines: this is not a failure. Record the intended cadence in
```
operations/routines.md
```
, AND drop a ready-to-use schedule from
```
assets/janitor-schedule.tmpl
```
(GitHub Actions / cron / launchd / agent-runner task) so enabling it later is a single copy, not a research project. The OS is still complete — the janitor also runs on demand — but until the schedule is armed, the doctor keeps a standing low "schedule armed" finding, because "self-reconciles when no one is looking" is only true once it actually runs unattended.
Don't block or leave the build "unfinished" over scheduling; treat it as the one optional step.

尝试创建定时任务（默认每周运行）执行janitor技能，以便即使用户未操作，工作空间也能自动协调。
若无可用调度工具，或用户拒绝： 这并非失败。请在
```
operations/routines.md
```
中记录预期的执行频率，并从
```
assets/janitor-schedule.tmpl
```
提供现成的调度配置（GitHub Actions / cron / launchd / agent-runner任务），以便后续启用时只需复制即可，无需重新调研。OS仍视为完整——janitor也可按需运行——但在调度启用前，doctor会持续标记「调度未启用」的低优先级问题，因为「无人操作时自动协调」仅在调度实际无人值守运行时才成立。
切勿因调度问题阻碍或标记构建为「未完成」；将其视为可选步骤。

Phase 7 — Report

第7阶段——汇报

Run

{domain}-doctor

and report its score as the build's verification surface — "done" is a clean (or explained) doctor run, not a feeling. Summarize: the structure created, the skills authored, the plugin produced, the schedule set, and the health score. List what was inferred vs. confirmed so the user can correct any assumptions.

运行

{domain}-doctor

并将其评分作为构建的验证依据——「完成」的标准是doctor运行结果干净（或已说明），而非主观感受。总结：创建的结构、编写的技能、生成的插件、设置的调度、健康评分。列出推断内容与已确认内容，以便用户纠正任何假设。

Guardrails

约束规则

Don't invent domain facts the user must own — mark inferred items "draft — confirm".
Leave nothing stale: if you touched the project, update the dashboard, boards, and any affected README in the same turn.
Prefer improving a template/skill over a one-off instance.

切勿编造需用户确认的领域事实——推断内容请标记为「草稿——待确认」。
切勿留下失效内容：若你修改了项目，请在同一轮操作中更新仪表盘、看板及所有受影响的README。
优先优化模板/技能，而非一次性实例。",

recoup-platform-build-os

Original

Translation

Recoup — Build Label OS

Recoup — 构建唱片公司OS

Recoup specialization — this is a music-company OS [read before Phase 0]

Recoup 专属化——这是一款音乐公司操作系统 [第0阶段前必读]

Operating beliefs (apply to every OS you build)

核心理念（适用于所有构建的OS）

Phase 0 — Understand the project deeply (always first)

第0阶段——深入理解项目（始终优先执行）

Phase 1 — Design the taxonomy

第1阶段——设计分类体系

Phase 2 — Scaffold structure + the brain

第2阶段——搭建结构与核心大脑

Phase 3 — Seed compounding assets

第3阶段——初始化可积累资产

Phase 4 — Author skills (the in-place
`plugin/`
)

第4阶段——编写技能（内置
`plugin/`
）

Phase 5 — Package the plugin

第5阶段——打包插件

Phase 6 — Wire the never-stale schedule

第6阶段——配置永不失效的定时任务

Phase 7 — Report

第7阶段——汇报

Guardrails

约束规则

recoup-platform-build-os

Original

Translation

Recoup — Build Label OS

Recoup — 构建唱片公司OS

Recoup specialization — this is a music-company OS [read before Phase 0]

Recoup 专属化——这是一款音乐公司操作系统 [第0阶段前必读]

Operating beliefs (apply to every OS you build)

核心理念（适用于所有构建的OS）

Phase 0 — Understand the project deeply (always first)

第0阶段——深入理解项目（始终优先执行）

Phase 1 — Design the taxonomy

第1阶段——设计分类体系

Phase 2 — Scaffold structure + the brain

第2阶段——搭建结构与核心大脑

Phase 3 — Seed compounding assets

第3阶段——初始化可积累资产

Phase 4 — Author skills (the in-place plugin/)

第4阶段——编写技能（内置plugin/）

Phase 5 — Package the plugin

第5阶段——打包插件

Phase 6 — Wire the never-stale schedule

第6阶段——配置永不失效的定时任务

Phase 7 — Report

第7阶段——汇报

Guardrails

约束规则

Phase 4 — Author skills (the in-place
`plugin/`
)

第4阶段——编写技能（内置
`plugin/`
）