[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73BVC5FSJ6NNKTK5WXJS5M9":3,"skill-same:01M73BVC5FSJ6NNKTK5WXJS5M9":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M73BVC5FSJ6NNKTK5WXJS5M9","create-variant",null,"Guides creation of a new workspace variant (Phase A independent prototype). Use when: creating a new co-\u003Cname> variant, scaffolding a new domain-specific AI team.","5throck\u002Fai-workspace-standards","5throck","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F10958964?v=4","01M73BFEH0V0VS483TW4JD49JW","01M73BFEJ5VQZJHJSFTVPAZGDM",25,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fcreate-variant\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: create-variant\ndescription: >\n  Guides creation of a new workspace variant (Phase A independent prototype).\n  Use when: creating a new co-\u003Cname> variant, scaffolding a new domain-specific AI team.\nstatus: active\nscope: common\nl2_propagate: false\nversion: 1.4.3\nowner: pm\nlast_reviewed: 2026-11-08\nrelates_to:\n  - skill: promote-variant\n    type: enables\n  - skill: documentation-writing\n    type: follows\nmetadata:\n  type: process\n  triggers:\n    - create variant\n    - new variant\n    - variant creation\n    - scaffold new variant\n    - new co- project\n---\n\n# Skill: create-variant\n\n## When to Use\n\nUse this skill when creating a new workspace variant (e.g., co-safety, co-legal, co-finance).\nA variant is a domain-specific AI team configuration built on the workspace common infrastructure.\n\n**Prerequisites**:\n- Workspace root access (the cloned `ai_workspace` repository)\n- `bun` installed (`bun --version`)\n- `git` installed\n\n---\n\n## Phase A Process\n\n### Step 0: Pre-flight checks\n\n- [ ] Variant name is unique: check `Projects\u002F` and `templates\u002F` — no existing `co-\u003Cname>`\n- [ ] Variant name format: lowercase, alphanumeric + hyphens only (e.g., `safety-os`, `legal-ai`)\n- [ ] Domain type decided: `security` | `development` | `design` | `consulting` | `collaboration` | `lecture` | `game` | `abap-development` | `safety` (registry: `scripts\u002Fhelpers\u002Fregistries\u002Fvariant-type-registry.ts`; an unregistered value silently falls back to `collaboration`)\n- [ ] Target country decided: a specific jurisdiction (`--country \u003CCODE>`, e.g. `KR`) or region-neutral (default - omit the flag)\n- [ ] i18n locale set decided (which of the schema's `i18n.locale_codes` translation zones the variant supports, e.g. `ko`\u002F`ja` docs): the language axis is independent of the country axis - a variant may be multi-language and region-neutral, single-language with country profiles, or any combination (see the Country vs. Language principle in `templates\u002Fcommon\u002Fdocs\u002Fcountry-profiles.md`, shipped into the project as `docs\u002Fcountry-profiles.md`)\n\n### Step 1: Run scaffold script\n\n```bash\n# From the workspace root\nbun scripts\u002Fcreate-l3-scaffold.ts \u003Cvariant-name> --domain \u003Ctype> [--country \u003CCODE>]\n\n# Example:\nbun scripts\u002Fcreate-l3-scaffold.ts safety-os --domain safety\n\n# Example (domain anchored to a specific jurisdiction):\nbun scripts\u002Fcreate-l3-scaffold.ts labor-kr --domain hr --country KR\n```\n\n> **Target country**: pass `--country \u003CCODE>` (ISO 3166-1 alpha-2 or a well-known region code such as `EU`) when the domain is anchored to a specific jurisdiction. This deploys that country's scoped skills into the draft (e.g. `KR` deploys all six `k-*` skills registered under `country_scoped_assets` in `docs\u002Fworkspace-schema.json`: `k-law`, `k-dart`, `k-kosis`, `k-opendata`, `k-ecos`, `k-krx`) and records the selection. Omit the flag for a region-neutral variant - country-scoped skills are then pruned from the scaffold. See `templates\u002Fcommon\u002Fdocs\u002Fcountry-profiles.md` (shipped into the project as `docs\u002Fcountry-profiles.md`).\n\nThis creates `Projects\u002F\u003Cvariant-name>\u002F` with:\n- All common infrastructure (.claude\u002F, .gemini\u002F, scripts\u002F, skills\u002F) — every top-level file\u002Fdir under `templates\u002Fcommon\u002F` is copied by default except a short, documented exclusion list (`COMMON_OVERLAY_EXCLUDE` in the script), so new common files show up automatically without needing a script change\n- `docs\u002Fcontext.md` (the immutable common project-context file, placeholders substituted) + `docs\u002F_common\u002F*` (all `docs\u002F...` paths referenced by skills — `context.md`, `user-guide.md`, `phase-definitions.md`, `engagement-orchestration.md`, `team-configuration-guide.md`, `_common\u002Fsecurity.md`, etc. — exist inside a generated variant project, not at workspace root)\n- `.gitattributes` with a `docs\u002Fcontext.md merge=ours` protection rule\n- Git initialized + .githooks configured\n- bun install complete\n- trail repo index built (`trail build`, Step 8.5\u002F§7.7 in the scaffold scripts — the retired graft-era bunx spelling removed from the scaffold path 2026-11-01 per design 2026-10-31-graft-trail-migration R2.5 addendum, trigger met: L0 trail init complete — the shipped MCP surfaces (`.mcp.json`, `opencode.json`, `.codex\u002Fconfig.toml`) now speak trail-era entries, while `.claude` hooks\u002Fhelpers\u002Fskill and `.gemini` MCP stay self-managed and regenerate at each project's own `trail init`; ADR-0076). Non-fatal if trail is unavailable\n- stub files (_ORIGIN.md, variant.json, PROMOTION_CHECKLIST.md, etc.)\n- A post-scaffold `bun scripts\u002Faudit.ts` run — non-fatal, but surfaces problems immediately instead of waiting for the first `\u002Fsync`\n\n> **Fork Model**: After scaffold completes, this `Projects\u002F\u003Cname>\u002F` draft (L3) evolves independently from L1. L1 changes will NOT automatically propagate to it. To get L1 updates later, re-run `create-l3-scaffold.ts` or manually copy needed files. See [ADR-0031](..\u002F..\u002Fdocs\u002Fadr\u002F0031-l1-l2-fork-model.md).\n\n### Step 2: Add variant section to CLAUDE.md\n\nOpen `Projects\u002F\u003Cvariant-name>\u002FCLAUDE.md` and add at the end:\n\n```markdown\n## \u003CVariantName> Context\n\n### Role Override: \u003CRole Title>\n[Describe how PM agent is overridden for this domain]\n\n### Domain\n[Describe the domain and applicable laws\u002Fstandards - jurisdiction-neutral prose; country-specific statutes, regulators, and formats go in docs\u002Fcountries\u002F\u003CCODE>.md profiles]\n\n### \u003CVariantName> Lifecycle Rules\n| Modified file(s) | Required follow-up actions |\n|-----------------|---------------------------|\n| [domain files] | [domain-specific checks] |\n\n### Legal\u002FDomain Disclaimer\n[Appropriate disclaimer for the domain]\n```\n\n> **Reconcile survival**: This section makes CLAUDE.md differ from workspace root — required for Phase B pipeline.\n\n> **Country vs. domain**: keep base variant content jurisdiction-neutral. Country-specific statutes, regulators, and operational formats belong in country profiles (`docs\u002Fcountries\u002F\u003CCODE>.md` - format specified in `docs\u002Fcountry-profiles.md`, shipped from `templates\u002Fcommon\u002Fdocs\u002F`). If the domain requires jurisdiction anchoring, author the profiles, declare `country_config` in `variant.json` (Step 7), and scaffold with `--country \u003CCODE>` (Step 1). Country profiles are advisory knowledge loaded at engagement start (Phase 0 intake) - they are never auto-executed.\n\n### Step 3: Add identical section to GEMINI.md (Antigravity parity)\n\nCopy the exact same `## \u003CVariantName> Context` section to `GEMINI.md`.\n\n> **P-01 parity**: CLAUDE.md and GEMINI.md must have identical heading structure.\n\n**Antigravity coverage checklist** (verify before proceeding to Step 4):\n- [ ] `Projects\u002F\u003Cvariant-name>\u002F.gemini\u002Fcommands\u002F` — all commands mirrored from `.claude\u002Fcommands\u002F`\n- [ ] `Projects\u002F\u003Cvariant-name>\u002F.gemini\u002Fskills\u002F` — all skills mirrored from `.claude\u002Fskills\u002F`\n- [ ] `Projects\u002F\u003Cvariant-name>\u002F.gemini\u002Fsettings.json` — exists with equivalent hooks\n- [ ] `Projects\u002F\u003Cvariant-name>\u002FGEMINI.md` — has identical `## \u003CVariantName> Context` section\n- [ ] `Projects\u002F\u003Cvariant-name>\u002Fagents\u002F*.md` — each agent has **Section C: Antigravity Integration**\n\n> ⚠️ **Antigravity is not optional**: Variants that skip Antigravity coverage will fail the Phase B platform parity check (PROMOTION_CHECKLIST Condition 5).\n\n### Step 4: Clean AGENTS.md\n\n`Projects\u002F\u003Cvariant-name>\u002FAGENTS.md` was copied from workspace root — it contains workspace agents (auditor, lifecycle-manager, architect, etc.) that don't exist in this project.\n\n- Remove all workspace agent table entries\n- Keep the header and §PM Gateway Policy\n- Keep the tool-managed trail instruction block (`trail:start`\u002F`trail:end` markers since the 2026-11-01 trail-era flip; pre-migration projects may still carry `graft:start`\u002F`graft:end` spellings, rewritten in place by the project's `trail init` — design 2026-10-31-graft-trail-migration; scaffold-appended from the L1 baseline, upgrade MERGE pass keeps it in sync — ADR-0076). Do NOT hand-edit it: it is tool-managed\n- Add `## \u003CVariantName> Agents` section with variant agent stubs\n\nVerify:\n```bash\ncd Projects\u002F\u003Cvariant-name> && bun run agent:verify\n# Should show: \"Total agent files: 0, Documented agents: 0\" (before creating agents)\n```\n\n### Step 5: Create domain agent files\n\nFor each agent in `Projects\u002F\u003Cvariant-name>\u002Fagents\u002F`, create `\u003Cagent-name>.md` using the **3-Section structure**:\n\n```markdown\n## Section A: Role & Responsibility\n# Platform-agnostic\n# Role, responsibilities, I\u002FO contract, legal\u002Fdomain basis\n\n## Section B: Claude Code Integration\n# Skill invocation, Agent tool usage, tools used\n\n## Section C: Antigravity Integration\n# activate_skill, agent_manager, tool equivalents\n```\n\nRun after each agent:\n```bash\nbun run agent:verify\n```\n\n### Step 6: Create domain skills\n\nFor each domain-specific skill, create `Projects\u002F\u003Cvariant-name>\u002Fskills\u002F\u003Cskill-name>\u002FSKILL.md`.\n\nCommon skills from `templates\u002Fcommon\u002Fskills\u002F` are already present — only create domain-specific ones.\n\n### Step 6.5: Regenerate README\n\n`create-l3-scaffold.ts` rendered `README.md`\u002F`README_ko.md` from the workspace README Standard template at scaffold time (Step 1), but with an empty agent roster and empty skills. Now that agents (Step 5) and skills (Step 6) exist, regenerate so the **Meet the AI Team** and **Skills** sections render real content:\n\n```bash\nbun scripts\u002Fgenerate-l3-readme.ts --l3-path Projects\u002F\u003Cvariant-name>\n```\n\nRe-run this command after **any** later agent, skill, or `variant.json` change — it reads the live project state via `scanL3Project()` each time. In particular, re-run after Step 7 once `variant.json → description` is filled, so the README tagline no longer reads `TODO: describe…`. This is the Phase A self-service renderer; Phase B's `templates\u002Fco-*\u002F` README standard is enforced separately by `WS-08` in `validate-templates.ts`.\n\n### Step 7: Complete variant.json\n\nEdit `Projects\u002F\u003Cvariant-name>\u002Fvariant.json`:\n- `description`: clear description of the variant's purpose\n- `variant_type`: `security` | `development` | `design` | `consulting` | `collaboration` | `lecture` | `game` | `abap-development` | `safety`\n- `agent_overrides.pm.reason`: describe the PM role override\n- `skill_manifest.variant_specific`: list domain skills with `used_by_agents` and `phases`\n- `country_config`: declare supported country profiles if the variant ships `docs\u002Fcountries\u002F\u003CCODE>.md` (keep `default: null` - region-neutral is the required default state)\n\n### Step 8: Define PROMOTION_CHECKLIST.md conditions\n\nEdit `Projects\u002F\u003Cvariant-name>\u002FPROMOTION_CHECKLIST.md` to replace placeholder conditions with domain-specific ones:\n- Condition 3: specify which domain artifacts must be complete with which fields\n- Condition 4: specify the domain audit script name\n- Add domain-specific agent\u002Fskill checklists\n- Keep the bilingual user-guide condition: Phase B promotion requires `docs\u002Fuser-guide.md` + `docs\u002Fuser-guide_ko.md` (validate-templates WS-11) — author them in Phase A so promotion isn't blocked\n\n**Domain-checklist wiring requirement (T-20261013-004)**: a domain checklist is not\ndocumentation until it is wired — ship every variant checklist with all three hooks,\nmirroring `templates\u002Fco-abap\u002Fdocs\u002Fsap-globalization-checklist.md` (first instance) and\n`templates\u002Fco-export\u002Fdocs\u002Fexport-engagement-checklist.md` (second):\n1. **Agent report-format line** — the producing agent's Output Format carries a\n   `\u003Cchecklist> Check: \u003Creviewed, gates pass | reviewed with exceptions: #N | n\u002Fa>` line;\n2. **Numbered mandatory rule** — a Constraints rule names the checklist file and states\n   that a failed or unnamed gate blocks finalization;\n3. **QA gate row** — the verifying skill\u002Fworkflow re-runs one gate per deliverable.\nA checklist added without these hooks is a promotion-review finding.\n\n### Step 9: Configure git hooks\n\n```bash\ncd Projects\u002F\u003Cvariant-name>\ngit config core.hooksPath .githooks\n# Test:\ngit status\n```\n\n> If setup.sh already ran (Step 1), git is already initialized. Just verify.\n\n### Step 10: Update CHANGELOG.md\n\nManually add an entry to `Projects\u002F\u003Cvariant-name>\u002FCHANGELOG.md`:\n\n```markdown\n## [Unreleased]\n\n### Added\n- Phase A scaffold created via create-l3-scaffold.ts\n- [List domain-specific files created]\n```\n\n> Note: The `\u002Fsync` pipeline is not available until Phase B promotion. Update CHANGELOG manually.\n\n---\n\n## Verification Checklist\n\nBefore moving to Phase B (`promote-variant`):\n\n```bash\ncd Projects\u002F\u003Cvariant-name>\n\n# 1. All agents registered and files exist\nbun run agent:verify\n\n# 2. Domain skills valid (if validate-skills.ts applies)\nbun scripts\u002Fvalidate-skills.ts\n\n# 3. Domain audit passes\nbun scripts\u002Faudit.ts   # or domain-specific audit script\n\n# 4. Platform parity (CLAUDE.md \u003C-> GEMINI.md)\n# Manual check: heading structure must match\ngrep \"^## \" CLAUDE.md\ngrep \"^## \" GEMINI.md\n```\n\n> **Note**: `new-project.ts` auto-detects variants dynamically from `templates\u002F` at runtime — no manual update to that script is required when adding a new variant.\n\n- [ ] Run `bun scripts\u002Fverify-scripts.ts --verify` in the `Projects\u002F\u003Cname>\u002F` draft (L3) — must exit 0 with 0 errors (confirms SCRIPTS.md has no ghost entries or PAIR MISSING warnings)\n- [ ] Tool surface present (ADR-0076; trail-era MCP entries since the 2026-11-01 flip, design 2026-10-31-graft-trail-migration R2.5 addendum — pre-migration projects may still carry the graft-era spellings, read by trail-era tools as their trail equivalents): `.mcp.json` + `opencode.json` + `.codex\u002Fconfig.toml` at project root, self-managed Claude\u002FGemini mirrors + helpers regenerate at the project's own `trail init`, tool-managed blocks in `CLAUDE.md`\u002F`GEMINI.md`\u002F`AGENTS.md`, `\u002Fgraft\u002F` + `.trail\u002Fcache\u002F` in `.gitignore`, and a built repo index (`trail build --check` passes or is skipped)\n- [ ] Regenerate the README via `bun scripts\u002Fgenerate-l3-readme.ts --l3-path Projects\u002F\u003Cvariant-name>` and confirm **zero `TODO:` markers** remain in `README.md`\u002F`README_ko.md` (the `variant.json → description` must be filled first, in Step 7, or the tagline still reads `TODO: describe…`)\n\n---\n\n## Next Step\n\nWhen all PROMOTION_CHECKLIST.md conditions are met:\n-> Use `skills\u002Fpromote-variant\u002FSKILL.md`\n\n---\n\n## Common Pitfalls (from co-safety experience)\n\n| Pitfall | Prevention |\n|---|---|\n| CLAUDE.md\u002FGEMINI.md identical to workspace root -> stripped by reconcile | Always add variant-specific section |\n| AGENTS.md contains workspace agents -> agent:verify fails | Clean AGENTS.md in Step 4 |\n| workflows\u002F not in pipeline scan scope | Document in _ORIGIN.md §Manual Phase B Steps |\n| bun install not run -> scripts fail | Handled by scaffold script Step 8 |\n| CHANGELOG.md not updated | Update manually after each Phase A session |\n| Antigravity .gemini\u002F files not mirrored from .claude\u002F | Check .gemini\u002F after Step 3 Antigravity checklist |\n| agents\u002F*.md missing Section C: Antigravity Integration | Add Section C to every agent during Step 5 |\n| README.md\u002FREADME_ko.md left as scaffold stub (empty Meet-the-AI-Team \u002F Skills sections) | Run `bun scripts\u002Fgenerate-l3-readme.ts` after Step 6, and again after any later agent\u002Fskill change |\n\n## Skill Graph Note\n\nThe new variant ships its scope graph (`docs\u002Fskill-graph.json`) inherited from the\ntemplate, and the workspace's next `\u002Fsync` (step 4.65) regenerates all scopes. If you\nadded skills or procedures during Phase A, refresh immediately with:\n`bun scripts\u002Fgenerate-skill-graph.ts --scope co-\u003Cname> && bun scripts\u002Fverify-skill-graph.ts --scope co-\u003Cname>`\n(ADR-0060 Amendment 6; relations flow variant skill → L1 or same-variant targets only).\n","# Skill: create-variant\n\n## When to Use\n\nUse this skill when creating a new workspace variant (e.g., co-safety, co-legal, co-finance).\nA variant is a domain-specific AI team configuration built on the workspace common infrastructure.\n\n**Prerequisites**:\n- Workspace root access (the cloned `ai_workspace` repository)\n- `bun` installed (`bun --version`)\n- `git` installed\n\n---\n\n## Phase A Process\n\n### Step 0: Pre-flight checks\n\n- [ ] Variant name is unique: check `Projects\u002F` and `templates\u002F` — no existing `co-\u003Cname>`\n- [ ] Variant name format: lowercase, alphanumeric + hyphens only (e.g., `safety-os`, `legal-ai`)\n- [ ] Domain type decided: `security` | `development` | `design` | `consulting` | `collaboration` | `lecture` | `game` | `abap-development` | `safety` (registry: `scripts\u002Fhelpers\u002Fregistries\u002Fvariant-type-registry.ts`; an unregistered value silently falls back to `collaboration`)\n- [ ] Target country decided: a specific jurisdiction (`--country \u003CCODE>`, e.g. `KR`) or region-neutral (default - omit the flag)\n- [ ] i18n locale set decided (which of the schema's `i18n.locale_codes` translation zones the variant supports, e.g. `ko`\u002F`ja` docs): the language axis is independent of the country axis - a variant may be multi-language and region-neutral, single-language with country profiles, or any combination (see the Country vs. Language principle in `templates\u002Fcommon\u002Fdocs\u002Fcountry-profiles.md`, shipped into the project as `docs\u002Fcountry-profiles.md`)\n\n### Step 1: Run scaffold script\n\n```bash\n# From the workspace root\nbun scripts\u002Fcreate-l3-scaffold.ts \u003Cvariant-name> --domain \u003Ctype> [--country \u003CCODE>]\n\n# Example:\nbun scripts\u002Fcreate-l3-scaffold.ts safety-os --domain safety\n\n# Example (domain anchored to a specific jurisdiction):\nbun scripts\u002Fcreate-l3-scaffold.ts labor-kr --domain hr --country KR\n```\n\n> **Target country**: pass `--country \u003CCODE>` (ISO 3166-1 alpha-2 or a well-known region code such as `EU`) when the domain is anchored to a specific jurisdiction. This deploys that country's scoped skills into the draft (e.g. `KR` deploys all six `k-*` skills registered under `country_scoped_assets` in `docs\u002Fworkspace-schema.json`: `k-law`, `k-dart`, `k-kosis`, `k-opendata`, `k-ecos`, `k-krx`) and records the selection. Omit the flag for a region-neutral variant - country-scoped skills are then pruned from the scaffold. See `templates\u002Fcommon\u002Fdocs\u002Fcountry-profiles.md` (shipped into the project as `docs\u002Fcountry-profiles.md`).\n\nThis creates `Projects\u002F\u003Cvariant-name>\u002F` with:\n- All common infrastructure (.claude\u002F, .gemini\u002F, scripts\u002F, skills\u002F) — every top-level file\u002Fdir under `templates\u002Fcommon\u002F` is copied by default except a short, documented exclusion list (`COMMON_OVERLAY_EXCLUDE` in the script), so new common files show up automatically without needing a script change\n- `docs\u002Fcontext.md` (the immutable common project-context file, placeholders substituted) + `docs\u002F_common\u002F*` (all `docs\u002F...` paths referenced by skills — `context.md`, `user-guide.md`, `phase-definitions.md`, `engagement-orchestration.md`, `team-configuration-guide.md`, `_common\u002Fsecurity.md`, etc. — exist inside a generated variant project, not at workspace root)\n- `.gitattributes` with a `docs\u002Fcontext.md merge=ours` protection rule\n- Git initialized + .githooks configured\n- bun install complete\n- trail repo index built (`trail build`, Step 8.5\u002F§7.7 in the scaffold scripts — the retired graft-era bunx spelling removed from the scaffold path 2026-11-01 per design 2026-10-31-graft-trail-migration R2.5 addendum, trigger met: L0 trail init complete — the shipped MCP surfaces (`.mcp.json`, `opencode.json`, `.codex\u002Fconfig.toml`) now speak trail-era entries, while `.claude` hooks\u002Fhelpers\u002Fskill and `.gemini` MCP stay self-managed and regenerate at each project's own `trail init`; ADR-0076). Non-fatal if trail is unavailable\n- stub files (_ORIGIN.md, variant.json, PROMOTION_CHECKLIST.md, etc.)\n- A post-scaffold `bun scripts\u002Faudit.ts` run — non-fatal, but surfaces problems immediately instead of waiting for the first `\u002Fsync`\n\n> **Fork Model**: After scaffold completes, this `Projects\u002F\u003Cname>\u002F` draft (L3) evolves independently from L1. L1 changes will NOT automatically propagate to it. To get L1 updates later, re-run `create-l3-scaffold.ts` or manually copy needed files. See [ADR-0031](..\u002F..\u002Fdocs\u002Fadr\u002F0031-l1-l2-fork-model.md).\n\n### Step 2: Add variant section to CLAUDE.md\n\nOpen `Projects\u002F\u003Cvariant-name>\u002FCLAUDE.md` and add at the end:\n\n```markdown\n## \u003CVariantName> Context\n\n### Role Override: \u003CRole Title>\n[Describe how PM agent is overridden for this domain]\n\n### Domain\n[Describe the domain and applicable laws\u002Fstandards - jurisdiction-neutral prose; country-specific statutes, regulators, and formats go in docs\u002Fcountries\u002F\u003CCODE>.md profiles]\n\n### \u003CVariantName> Lifecycle Rules\n| Modified file(s) | Required follow-up actions |\n|-----------------|---------------------------|\n| [domain files] | [domain-specific checks] |\n\n### Legal\u002FDomain Disclaimer\n[Appropriate disclaimer for the domain]\n```\n\n> **Reconcile survival**: This section makes CLAUDE.md differ from workspace root — required for Phase B pipeline.\n\n> **Country vs. domain**: keep base variant content jurisdiction-neutral. Country-specific statutes, regulators, and operational formats belong in country profiles (`docs\u002Fcountries\u002F\u003CCODE>.md` - format specified in `docs\u002Fcountry-profiles.md`, shipped from `templates\u002Fcommon\u002Fdocs\u002F`). If the domain requires jurisdiction anchoring, author the profiles, declare `country_config` in `variant.json` (Step 7), and scaffold with `--country \u003CCODE>` (Step 1). Country profiles are advisory knowledge loaded at engagement start (Phase 0 intake) - they are never auto-executed.\n\n### Step 3: Add identical section to GEMINI.md (Antigravity parity)\n\nCopy the exact same `## \u003CVariantName> Context` section to `GEMINI.md`.\n\n> **P-01 parity**: CLAUDE.md and GEMINI.md must have identical heading structure.\n\n**Antigravity coverage checklist** (verify before proceeding to Step 4):\n- [ ] `Projects\u002F\u003Cvariant-name>\u002F.gemini\u002Fcommands\u002F` — all commands mirrored from `.claude\u002Fcommands\u002F`\n- [ ] `Projects\u002F\u003Cvariant-name>\u002F.gemini\u002Fskills\u002F` — all skills mirrored from `.claude\u002Fskills\u002F`\n- [ ] `Projects\u002F\u003Cvariant-name>\u002F.gemini\u002Fsettings.json` — exists with equivalent hooks\n- [ ] `Projects\u002F\u003Cvariant-name>\u002FGEMINI.md` — has identical `## \u003CVariantName> Context` section\n- [ ] `Projects\u002F\u003Cvariant-name>\u002Fagents\u002F*.md` — each agent has **Section C: Antigravity Integration**\n\n> ⚠️ **Antigravity is not optional**: Variants that skip Antigravity coverage will fail the Phase B platform parity check (PROMOTION_CHECKLIST Condition 5).\n\n### Step 4: Clean AGENTS.md\n\n`Projects\u002F\u003Cvariant-name>\u002FAGENTS.md` was copied from workspace root — it contains workspace agents (auditor, lifecycle-manager, architect, etc.) that don't exist in this project.\n\n- Remove all workspace agent table entries\n- Keep the header and §PM Gateway Policy\n- Keep the tool-managed trail instruction block (`trail:start`\u002F`trail:end` markers since the 2026-11-01 trail-era flip; pre-migration projects may still carry `graft:start`\u002F`graft:end` spellings, rewritten in place by the project's `trail init` — design 2026-10-31-graft-trail-migration; scaffold-appended from the L1 baseline, upgrade MERGE pass keeps it in sync — ADR-0076). Do NOT hand-edit it: it is tool-managed\n- Add `## \u003CVariantName> Agents` section with variant agent stubs\n\nVerify:\n```bash\ncd Projects\u002F\u003Cvariant-name> && bun run agent:verify\n# Should show: \"Total agent files: 0, Documented agents: 0\" (before creating agents)\n```\n\n### Step 5: Create domain agent files\n\nFor each agent in `Projects\u002F\u003Cvariant-name>\u002Fagents\u002F`, create `\u003Cagent-name>.md` using the **3-Section structure**:\n\n```markdown\n## Section A: Role & Responsibility\n# Platform-agnostic\n# Role, responsibilities, I\u002FO contract, legal\u002Fdomain basis\n\n## Section B: Claude Code Integration\n# Skill invocation, Agent tool usage, tools used\n\n## Section C: Antigravity Integration\n# activate_skill, agent_manager, tool equivalents\n```\n\nRun after each agent:\n```bash\nbun run agent:verify\n```\n\n### Step 6: Create domain skills\n\nFor each domain-specific skill, create `Projects\u002F\u003Cvariant-name>\u002Fskills\u002F\u003Cskill-name>\u002FSKILL.md`.\n\nCommon skills from `templates\u002Fcommon\u002Fskills\u002F` are already present — only create domain-specific ones.\n\n### Step 6.5: Regenerate README\n\n`create-l3-scaffold.ts` rendered `README.md`\u002F`README_ko.md` from the workspace README Standard template at scaffold time (Step 1), but with an empty agent roster and empty skills. Now that agents (Step 5) and skills (Step 6) exist, regenerate so the **Meet the AI Team** and **Skills** sections render real content:\n\n```bash\nbun scripts\u002Fgenerate-l3-readme.ts --l3-path Projects\u002F\u003Cvariant-name>\n```\n\nRe-run this command after **any** later agent, skill, or `variant.json` change — it reads the live project state via `scanL3Project()` each time. In particular, re-run after Step 7 once `variant.json → description` is filled, so the README tagline no longer reads `TODO: describe…`. This is the Phase A self-service renderer; Phase B's `templates\u002Fco-*\u002F` README standard is enforced separately by `WS-08` in `validate-templates.ts`.\n\n### Step 7: Complete variant.json\n\nEdit `Projects\u002F\u003Cvariant-name>\u002Fvariant.json`:\n- `description`: clear description of the variant's purpose\n- `variant_type`: `security` | `development` | `design` | `consulting` | `collaboration` | `lecture` | `game` | `abap-development` | `safety`\n- `agent_overrides.pm.reason`: describe the PM role override\n- `skill_manifest.variant_specific`: list domain skills with `used_by_agents` and `phases`\n- `country_config`: declare supported country profiles if the variant ships `docs\u002Fcountries\u002F\u003CCODE>.md` (keep `default: null` - region-neutral is the required default state)\n\n### Step 8: Define PROMOTION_CHECKLIST.md conditions\n\nEdit `Projects\u002F\u003Cvariant-name>\u002FPROMOTION_CHECKLIST.md` to replace placeholder conditions with domain-specific ones:\n- Condition 3: specify which domain artifacts must be complete with which fields\n- Condition 4: specify the domain audit script name\n- Add domain-specific agent\u002Fskill checklists\n- Keep the bilingual user-guide condition: Phase B promotion requires `docs\u002Fuser-guide.md` + `docs\u002Fuser-guide_ko.md` (validate-templates WS-11) — author them in Phase A so promotion isn't blocked\n\n**Domain-checklist wiring requirement (T-20261013-004)**: a domain checklist is not\ndocumentation until it is wired — ship every variant checklist with all three hooks,\nmirroring `templates\u002Fco-abap\u002Fdocs\u002Fsap-globalization-checklist.md` (first instance) and\n`templates\u002Fco-export\u002Fdocs\u002Fexport-engagement-checklist.md` (second):\n1. **Agent report-format line** — the producing agent's Output Format carries a\n   `\u003Cchecklist> Check: \u003Creviewed, gates pass | reviewed with exceptions: #N | n\u002Fa>` line;\n2. **Numbered mandatory rule** — a Constraints rule names the checklist file and states\n   that a failed or unnamed gate blocks finalization;\n3. **QA gate row** — the verifying skill\u002Fworkflow re-runs one gate per deliverable.\nA checklist added without these hooks is a promotion-review finding.\n\n### Step 9: Configure git hooks\n\n```bash\ncd Projects\u002F\u003Cvariant-name>\ngit config core.hooksPath .githooks\n# Test:\ngit status\n```\n\n> If setup.sh already ran (Step 1), git is already initialized. Just verify.\n\n### Step 10: Update CHANGELOG.md\n\nManually add an entry to `Projects\u002F\u003Cvariant-name>\u002FCHANGELOG.md`:\n\n```markdown\n## [Unreleased]\n\n### Added\n- Phase A scaffold created via create-l3-scaffold.ts\n- [List domain-specific files created]\n```\n\n> Note: The `\u002Fsync` pipeline is not available until Phase B promotion. Update CHANGELOG manually.\n\n---\n\n## Verification Checklist\n\nBefore moving to Phase B (`promote-variant`):\n\n```bash\ncd Projects\u002F\u003Cvariant-name>\n\n# 1. All agents registered and files exist\nbun run agent:verify\n\n# 2. Domain skills valid (if validate-skills.ts applies)\nbun scripts\u002Fvalidate-skills.ts\n\n# 3. Domain audit passes\nbun scripts\u002Faudit.ts   # or domain-specific audit script\n\n# 4. Platform parity (CLAUDE.md \u003C-> GEMINI.md)\n# Manual check: heading structure must match\ngrep \"^## \" CLAUDE.md\ngrep \"^## \" GEMINI.md\n```\n\n> **Note**: `new-project.ts` auto-detects variants dynamically from `templates\u002F` at runtime — no manual update to that script is required when adding a new variant.\n\n- [ ] Run `bun scripts\u002Fverify-scripts.ts --verify` in the `Projects\u002F\u003Cname>\u002F` draft (L3) — must exit 0 with 0 errors (confirms SCRIPTS.md has no ghost entries or PAIR MISSING warnings)\n- [ ] Tool surface present (ADR-0076; trail-era MCP entries since the 2026-11-01 flip, design 2026-10-31-graft-trail-migration R2.5 addendum — pre-migration projects may still carry the graft-era spellings, read by trail-era tools as their trail equivalents): `.mcp.json` + `opencode.json` + `.codex\u002Fconfig.toml` at project root, self-managed Claude\u002FGemini mirrors + helpers regenerate at the project's own `trail init`, tool-managed blocks in `CLAUDE.md`\u002F`GEMINI.md`\u002F`AGENTS.md`, `\u002Fgraft\u002F` + `.trail\u002Fcache\u002F` in `.gitignore`, and a built repo index (`trail build --check` passes or is skipped)\n- [ ] Regenerate the README via `bun scripts\u002Fgenerate-l3-readme.ts --l3-path Projects\u002F\u003Cvariant-name>` and confirm **zero `TODO:` markers** remain in `README.md`\u002F`README_ko.md` (the `variant.json → description` must be filled first, in Step 7, or the tagline still reads `TODO: describe…`)\n\n---\n\n## Next Step\n\nWhen all PROMOTION_CHECKLIST.md conditions are met:\n-> Use `skills\u002Fpromote-variant\u002FSKILL.md`\n\n---\n\n## Common Pitfalls (from co-safety experience)\n\n| Pitfall | Prevention |\n|---|---|\n| CLAUDE.md\u002FGEMINI.md identical to workspace root -> stripped by reconcile | Always add variant-specific section |\n| AGENTS.md contains workspace agents -> agent:verify fails | Clean AGENTS.md in Step 4 |\n| workflows\u002F not in pipeline scan scope | Document in _ORIGIN.md §Manual Phase B Steps |\n| bun install not run -> scripts fail | Handled by scaffold script Step 8 |\n| CHANGELOG.md not updated | Update manually after each Phase A session |\n| Antigravity .gemini\u002F files not mirrored from .claude\u002F | Check .gemini\u002F after Step 3 Antigravity checklist |\n| agents\u002F*.md missing Section C: Antigravity Integration | Add Section C to every agent during Step 5 |\n| README.md\u002FREADME_ko.md left as scaffold stub (empty Meet-the-AI-Team \u002F Skills sections) | Run `bun scripts\u002Fgenerate-l3-readme.ts` after Step 6, and again after any later agent\u002Fskill change |\n\n## Skill Graph Note\n\nThe new variant ships its scope graph (`docs\u002Fskill-graph.json`) inherited from the\ntemplate, and the workspace's next `\u002Fsync` (step 4.65) regenerates all scopes. If you\nadded skills or procedures during Phase A, refresh immediately with:\n`bun scripts\u002Fgenerate-skill-graph.ts --scope co-\u003Cname> && bun scripts\u002Fverify-skill-graph.ts --scope co-\u003Cname>`\n(ADR-0060 Amendment 6; relations flow variant skill → L1 or same-variant targets only).\n",{"name":5,"owner":23,"scope":24,"status":25,"version":26,"metadata":27,"relates_to":35,"description":42,"l2_propagate":19,"last_reviewed":43},"pm","common","active","1.4.3",{"type":28,"triggers":29},"process",[30,31,32,33,34],"create variant","new variant","variant creation","scaffold new variant","new co- project",[36,39],{"type":37,"skill":38},"enables","promote-variant",{"type":40,"skill":41},"follows","documentation-writing","Guides creation of a new workspace variant (Phase A independent prototype). Use when: creating a new co-\u003Cname> variant, scaffolding a new domain-specific AI team.\n",1794096000000,"main","1162ccc568cf90c01b3886d6143cbfd851a37883",".codex\u002Fskills\u002Fcreate-variant",9,"https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards","https:\u002F\u002Fgithub.com\u002F5throck","Experienced in digital transformation, enterprise IT, startup acceleration, and business strategy. Focused on building practical systems that connect technolo","2026-11-14 21:22:34",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add 5throck\u002Fai-workspace-standards --skill create-variant",{"tool":58,"command":59},"bunx","bunx skills add 5throck\u002Fai-workspace-standards --skill create-variant",{"tool":61,"command":62},"pnpm","pnpm dlx skills add 5throck\u002Fai-workspace-standards --skill create-variant","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fcreate-variant\u002FSKILL.md",true,[],[67,75,80,85,90,95],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":74},"01M7BBJDYHJMGTJYSC37JVWY8S","i18n-layout","Text layout and encoding guidance: character encoding (UTF-8, legacy Korean code pages, BOM hazards), line endings, RTL\u002Fbidi handling, and script-specific font selection (Hangul focus). Use when: encoding is corrupted or mojibake appears, an RTL locale must render correctly, fonts must be chosen for a script, or CRLF\u002FBOM issues surface.","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],"2026-11-15 14:19:17",{"skillNo":76,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":74},"01M7BBJ9XHAAS1AVGKZZ841VBZ","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.hermes\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],{"skillNo":81,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":74},"01M7BBJ5C3X8TKFKG5R9P9P49W","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.gemini\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],{"skillNo":86,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":74},"01M7BBJ1B52X0QMJ2QVBMPJB37","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.codex\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],{"skillNo":91,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":74},"01M7BBHX91BW2Q2R276MRX5AW3","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.claude\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],{"skillNo":96,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":74},"01M7BBHQWGXPSFRWN1PRC2NMMV","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.agents\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[]]