共有プロファイルのスキーマ

Apothem の共有プロファイルは、~/.config/apothem/profile.yaml にある YAML ファイル、または --profile PATH で指定したパスにある YAML ファイルです。これは、アイデンティティ、設定、共有ルール、ハーネスごとのオーバーライド、ハーネスの除外についての、意味論上の信頼できる情報源です。アダプターは、このプロファイルとパッケージ化された Apothem ペイロード cohort から、ハーネスネイティブなファイルを派生させます。

ランタイムモデルは src/apothem/lib/profile.py です。JSON スキーマは src/apothem/schemas/profile.schema.json です。

最小の有効なプロファイル

唯一の必須フィールドは identity.name です。

identity:
  name: "Example User"

`profile init` が書き出すスキャフォールド

apothem profile init は、やや充実したスキャフォールド——操作者が個人化することが期待されるプレースホルダーのアイデンティティフィールド——を書き出し、成功を報告する前にそれを検証します。

identity:
  name: "Example User"
  email: "[email protected]"
  github: "example-user"

このコマンドは、これらのフィールドを名指しする個人化の促しを表示します。プレースホルダーのままのアイデンティティが後で install や update に到達した場合、それらのコマンドは助言的な注記を 1 つ表示して続行します——Apothem はプレースホルダーのアイデンティティを決して捏造せず、そのために停止することもありません。

正規のフィールド

フィールド	必須	デフォルト	注記
`identity.name`	はい	なし	空でない操作者の表示名。
`identity.role`	いいえ	`senior software engineer`	共有のロールテキスト。
`identity.email`	いいえ	省略	存在する場合はメール形式でなければなりません。
`identity.website`	いいえ	省略	存在する場合は URI 形式でなければなりません。
`identity.github`	いいえ	省略	`@` を含まない GitHub ユーザー名。
`preferences.language`	いいえ	`python`	小文字に正規化されます。
`preferences.style`	いいえ	`concise`	`concise`、`verbose`、`balanced` のいずれか。
`preferences.formatter`	いいえ	省略	存在する場合は空でない文字列。
`preferences.test_framework`	いいえ	省略	存在する場合は空でない文字列。
`rules`	いいえ	`[]`	一意で空でない文字列。改行は LF に正規化されます。
`seriousness`	いいえ	`PERSONAL_USE`	`EXPLORING`、`PERSONAL_USE`、`SHARED`、`PUBLIC_LAUNCH` のいずれか。
`harnesses`	いいえ	`{}`	サポートされるハーネス ID をキーとする、ハーネスごとのオーバーライド。
`exclude_harnesses`	いいえ	`[]`	`--harness all` から除外される、サポートされるハーネス ID。

ハーネスキー

スキーマは、ちょうど次の 17 個のハーネス ID を受け入れます。

antigravity
claude-code
codebuddy
codex
cursor
gemini-cli
github-copilot
glm
hermes
kimi-code
kiro
open-claw
opencode
qwen-code
trae
windsurf
zed

未知のトップレベルフィールド、未知のハーネスキー、誤った値の型、重複する除外、そして形式の不正なアイデンティティフィールドは、install または update の書き込みより前に失敗します。想定されるエラーには、フィールド、理由、修正方法、有用な場合には編集済みの安全な値、そして検証失敗時の files_written: [] が含まれます。

プロファイルフィールドからネイティブファイルへ

プロファイルは何をであり、アダプターはどのようにです。エンドツーエンドの流れを理解すれば、なぜ 1 つの YAML ファイルへの単一の編集が、インストール済みのすべてのハーネスを作り変えうるのかが説明できます。

プロファイルフィールドが運ぶのは意味論的な意図であり、文字どおりの設定スニペットではありません。 identity.name は「操作者が誰か」であって、JSON の 1 行ではありません。パッケージ化されたペイロード cohort（commands、rules、skills、hooks、 templates、statuslines、output-styles、agents）は、Apothem 独自の中立的な形式で振る舞いの内容を運びます。フィールドも cohort も、いずれのハーネスの設定がどう見えるかを知りません——その知識はアダプターだけに属します。

apothem update を実行すると、流れは次のとおりです。

JSON スキーマに照らしてプロファイルを読み込み、検証します。プロファイル全体が有効になるまでは何も書き込まれないため、タイプミスが中途半端にインストールされることは決してありません。
中央レジストリを通じて、選択されたハーネス（または all。ただし任意の exclude_harnesses を差し引いたもの）についてアダプターを解決します。
物質化します——各アダプターが同じプロファイルと同じ cohort を読み取り、それらを自分のハーネスの方言へ変換します。preferences.style のようなフィールドは、あるハーネスではネイティブな設定値になり、別のハーネスではレンダリングされた指示コンテキストになります。rules[] 内の 1 つのルールは、Cursor には .mdc ファイルに、Copilot にはリポジトリ全体の指示の一節に、あるいはハーネスにネイティブなルール面がない場合はサポートツリーのエントリーになります。
ネイティブファイルを書き込みます——レンダリングされた単一の設定、変換された cohort、またはハーネスのネイティブアンカーから参照されるサポートサブツリー。

同じプロファイルがすべてのハーネスを駆動するため、各物質化が意図について食い違うことはありません。ハーネスがサポートしていない（または依然として発見待ちの）能力単元は、いかなる書き込みよりも前に構造化された警告として浮かび上がり、存在しないベンダー面へと臆造されることはありません。これこそが「一度の編集、多くのハーネス」という保証を本物たらしめるものです。プロファイルは一度だけ編集され、各アダプターはその単一の情報源からネイティブファイルを再派生します。