[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HEP8TMAE8BGBPRQEB4S4P":3,"skill-same:01M71HEP8TMAE8BGBPRQEB4S4P":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71HEP8TMAE8BGBPRQEB4S4P","seed-conventions",null,"Generate CLAUDE.md and CONVENTIONS.md for a brand-new project through a brief interview, and create the specs\u002F directory with evolved bigpowers structure (product\u002F, tech-architecture\u002F, verifications\u002F, epics\u002Farchive\u002F). Entry point for greenfield projects. Use when starting a new project from scratch, when user asks to set up AI agent conventions, or when there is no CLAUDE.md yet.","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",292,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.codebuddy\u002Fskills\u002Fseed-conventions\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"conventions","seed conventions","seed","interview","new project","sonnet","directory","generate","product","structure","create","architecture","when","ai agent","new","up","project","projects","brief","SET","2026-11-10 10:12:30",false,"---\nname: seed-conventions\nmodel: sonnet\ndescription: \"Generate CLAUDE.md and CONVENTIONS.md for a brand-new project through a brief interview, and create the specs\u002F directory with evolved bigpowers structure (product\u002F, tech-architecture\u002F, verifications\u002F, epics\u002Farchive\u002F). Entry point for greenfield projects. Use when starting a new project from scratch, when user asks to set up AI agent conventions, or when there is no CLAUDE.md yet.\"\n---\n\n\u003C!-- story: e10s01 -->\n\u003C!-- story: e47s02 -->\n\u003C!-- story: e10s02 -->\n\u003C!-- story: e51s02 -->\n\u003C!-- story: e45s21 -->\n\u003C!-- story: e79s03 -->\n\n\n# Seed Conventions\n> **HARD GATE** — Before any new code lands, confirm the project conventions are understood. Ask: 'What does a good commit message look like in this project?'\n\nBootstrap a new project with the AI agent conventions it needs. Run this once at the start of a greenfield project.\n\n## What this creates\n\n- `CLAUDE.md` — Claude Code session config (project-specific)\n- `CONVENTIONS.md` — shared rules for all AI agents\n- `specs\u002F` — the specs directory where all planning output will live\n- `AGENTS.md` — for OpenCode and other agents (optional)\n- `GEMINI.md` — for Gemini CLI (optional)\n\n## Interview\n\nAsk the user these questions (one at a time, wait for each answer):\n\n1. **Project name and one-sentence description** — \"What is this project? One sentence.\"\n2. **Stack** — \"What language, framework, and runtime? (e.g. TypeScript \u002F Next.js \u002F Node 22)\"\n2b. **Stack profile (optional)** — Offer: `swift`, `typescript-vue`, `node-service`, or none. If chosen, merge the matching fragment from `profiles\u002F\u003Cname>.md` into generated `CONVENTIONS.md`.\n3. **Commands** — \"What commands do you use for: run, test, build, lint?\"\n3b. **Preflight (optional)** — \"What command runs test, lint, and build together? If none, chain Test + Lint + Build into one **Preflight** row.\"\n4. **Architecture** — \"Key modules and relationships in 1–2 sentences.\"\n5. **Conventions** — \"Any naming, file organization, or patterns all agents must follow?\"\n6. **Never-do list** — \"What are the hard stops? Things an agent must never touch?\"\n7. **Defensive code categories** — \"Which apply? (Rate limit \u002F Retry \u002F Circuit breaker \u002F Timeout \u002F Graceful degradation)\"\n8. **Local tool wiring (optional)** — \"Wire bigpowers for project-local tools? (Cursor, OpenCode, Cline, Aider, Codex CLI)\" If yes, generate AGENTS.md spine artifacts per [REFERENCE.md](REFERENCE.md) §Local tool wiring and §AGENTS.md spine. If no, skip — standard seed output unchanged (no AGENTS.md spine unless opted in).\n\n## Agentic STE for generated prose (e79s03)\n\nWhen writing instructional lines in `CLAUDE.md`, `AGENTS.md`, or `CONVENTIONS.md`, follow [AGENTIC-STE.md](..\u002F..\u002Fdocs\u002FAGENTIC-STE.md):\n\n- Use directive vocabulary: MUST, MUST NOT, NEVER, ALWAYS, DO, DO NOT\n- Do NOT use hedge modals listed in AGENTIC-STE.md Rule 3\n- Cap each instruction sentence at 20 words\n- Write imperative, active-voice lines — one instruction per line\n- Do NOT apply Agentic STE to `terse-mode` (output compression is out of scope)\n\nAfter generation, run `bash scripts\u002Fvalidate-agentic-ste.sh --strict CLAUDE.md CONVENTIONS.md` when those files exist in the target project.\n\n## Generate files\n\nAfter the interview, generate each file using the templates in [REFERENCE.md](REFERENCE.md):\n- `AGENTS.md` — from `docs\u002Ftemplates\u002FAGENTS.md` Reach Template (canonical spine source)\n- `CLAUDE.md` — symlink to `AGENTS.md` (copy fallback on Windows when symlink fails)\n- `GEMINI.md` — symlink to `AGENTS.md` when Gemini wiring opted in\n- `opencode.json` — with `\"instructions\": [\"AGENTS.md\"]` when OpenCode opted in\n- `.aider.conf.yml` — with `read: AGENTS.md` when Aider opted in\n- `CONVENTIONS.md` — bigpowers standard template + project defensive code categories\n\n### `specs\u002F` directory\n\n```bash\nmkdir -p specs\u002Fproduct specs\u002Fproduct\u002Fsnapshots specs\u002Fepics\u002Farchive\nmkdir -p specs\u002Ftech-architecture specs\u002Fadr specs\u002Fverifications specs\u002Fbugs\ntouch specs\u002Fproduct\u002FSCOPE_LATEST.yaml specs\u002Fproduct\u002FVISION_LATEST.yaml specs\u002Fproduct\u002FGLOSSARY_LATEST.yaml\ntouch specs\u002Frelease-plan.yaml specs\u002Fexecution-status.yaml specs\u002Fplanning-status.yaml specs\u002Fstate.yaml\ntouch specs\u002Ftech-architecture\u002Ftech-stack.md specs\u002Ftech-architecture\u002FSECURITY_PLAN_LATEST.md\ntouch specs\u002Ftech-architecture\u002FTEST_PLAN_LATEST.md specs\u002Ftech-architecture\u002FDESIGN_PLAN_LATEST.md\ntouch specs\u002Ftech-architecture\u002FREFACTOR_LATEST.md specs\u002Ftech-architecture\u002FIMPACT_LATEST.md\ntouch specs\u002Fbugs\u002Fregistry.yaml\necho \"# Specs\\n\\nAll planning documents for this project.\" > specs\u002FREADME.md\n```\n\n**Note:** `specs\u002Fstate.yaml.lock` is NOT pre-created — acquired\u002Freleased dynamically.\n\n`specs\u002Fstate.yaml` carries top-level `workflow_mode` (`team-pr` | `solo-git`, default `solo-git`).\nThis is the **canonical integrate-mode signal** for all skills.\nSet it once here. Skills such as `release-branch` read this file instead of sniffing profiles.\n\nWhen generating `CLAUDE.md`, chain Test + Lint + Build into one **Preflight** row if the user named no Preflight command.\n\n### Self-installing fenced markers (e45s21)\n\nSkills that write into `CLAUDE.md` or `AGENTS.md` MUST use **fenced HTML comment markers** so handwritten content outside the fence is never clobbered:\n\n```markdown\n\u003C!-- BEGIN bigpowers:section-id -->\n…agent-managed content only…\n\u003C!-- END bigpowers:section-id -->\n```\n\n**Merge rule:** On update, replace only content between matching `BEGIN`\u002F`END` pairs.\nIf a marker pair is missing, append a new fenced block at file end.\nNever rewrite the whole file.\n\n**Standard marker IDs** for seeded projects (see [REFERENCE.md](REFERENCE.md) § Fenced markers):\n\n| Marker ID | Owner skill | Purpose |\n|-----------|-------------|---------|\n| `project` | seed-conventions | Project, Commands, Architecture |\n| `context-routing` | seed-conventions | Glob → sub-AGENTS.md routing table |\n| `learned-preferences` | session-state | Learned User Preferences + Workspace Facts |\n| `tooling` | setup-environment, guard-git | sqz\u002Frtk\u002Fhook blocks installed by tooling skills |\n\nEmit these fences in `AGENTS.md` (and therefore `CLAUDE.md` symlink) from `docs\u002Ftemplates\u002FAGENTS.md`. User prose outside fences is sacred.\n\n- [ ] CLAUDE.md exists and is populated\n- [ ] CONVENTIONS.md exists and includes specs\u002F output convention\n- [ ] specs\u002Fproduct\u002F exists with SCOPE_LATEST.yaml, VISION_LATEST.yaml, GLOSSARY_LATEST.yaml\n- [ ] specs\u002Ftech-architecture\u002F exists with tech-stack.md, security.md, test.md, design.md\n- [ ] specs\u002Fverifications\u002F exists\n- [ ] specs\u002Fepics\u002Farchive\u002F exists\n- [ ] specs\u002Fbugs\u002Fregistry.yaml exists\n- [ ] Confirm with user: \"Does CLAUDE.md accurately describe your project?\"\n\n---\n\n# story: e51s02 e37s01 e37s03 e37s14\n# story: e45s21\n# Seed Conventions — Reference Templates\n\n## Navigation\n\n| Lines | Section |\n|-------|---------|\n| 1 | Title |\n| 5–29 | Navigation |\n| 30–53 | Fenced markers (e45s21) |\n| 54–65 | AGENTS.md spine (Reach Template — e37s01) |\n| 66–77 | Agent config template (legacy — prefer AGENTS.md spine) |\n| 78–81 | Project |\n| 82–91 | Commands |\n| 92–94 | Architecture |\n| 95–98 | Conventions |\n| 99–104 | Never |\n| 105–114 | Agent Rules |\n| 115–123 | opencode.json template |\n| 124–133 | Aider — `.aider.conf.yml` bridge (e37s03) |\n| 134–146 | Codex CLI — project-local `.codex\u002Fconfig.toml` + AGENTS.md (e37s14) |\n| 147–156 | CONVENTIONS.md |\n| 157–160 | Stack profile fragments |\n| 161–164 | Local tool wiring (optional interview step 8) |\n| 165–173 | Cursor — project-local `.cursor\u002Frules` symlink |\n| 174–187 | OpenCode — project-local `opencode.json` + `AGENTS.md` |\n| 188–190 | When to offer |\n\n## Fenced markers (e45s21)\n\nSelf-installing blocks prevent skills from overwriting user-authored prose. Pattern:\n\n```markdown\n\u003C!-- BEGIN bigpowers:section-id -->\n…managed content…\n\u003C!-- END bigpowers:section-id -->\n```\n\n**Merge algorithm:**\n\n1. If `BEGIN bigpowers:\u003Cid>` exists → replace inner content only.\n2. If missing → append new fenced block at EOF.\n3. Never delete content outside fences.\n\nSeed these marker IDs in generated `AGENTS.md`:\n\n| ID | Initial content |\n|----|-----------------|\n| `project` | Project, Commands, Architecture, Conventions, Never, Agent Rules |\n| `context-routing` | Glob → sub-AGENTS.md table (see CLAUDE.md e45s22) |\n| `learned-preferences` | Empty Learned User Preferences + Workspace Facts lists |\n\n## AGENTS.md spine (Reach Template — e37s01)\n\nCanonical source: copy from `docs\u002Ftemplates\u002FAGENTS.md` in the bigpowers repo (Reach Template).\nDo not invent structure ad hoc — the template includes multi-agent preamble, Preflight, Test\u002FLint\u002FBuild sections.\n\nWhen local tool wiring is opted in:\n1. Copy Reach Template → project root `AGENTS.md`, fill interview placeholders\n2. `ln -sf AGENTS.md CLAUDE.md` (or content copy on Windows when symlink fails)\n3. Write `opencode.json` with `\"instructions\": [\"AGENTS.md\"]`\n\nWhen user **opts out** of local tool wiring, do not emit AGENTS.md spine artifacts.\n\n## Agent config template (legacy — prefer AGENTS.md spine)\n\nAll three files use the same structure — only the header differs:\n- `CLAUDE.md` → `# [Project Name] — Claude Code` (or symlink to AGENTS.md)\n- `GEMINI.md` → `# [Project Name] — Gemini CLI`\n- `AGENTS.md` → `# [Project Name] — AI Agents` (Reach Template header)\n\n```markdown\n# [Project Name] — [Agent]\n\nRead CONVENTIONS.md before any GitHub or git operation.\n\n## Project\n[One sentence description]\nStack: [language, framework, runtime]\n\n## Commands\n| Action | Command |\n|--------|---------|\n| Run    | `[cmd]` |\n| Test   | `[cmd]` |\n| Build  | `[cmd]` |\n| Lint   | `[cmd]` |\n| Preflight | `[test && lint && build chain — or user-named full-green cmd]` |\n| CI     | `gh pr checks` (when a PR is open) |\n\n## Architecture\n[1–2 sentences. Key modules and their relationships.]\n\n## Conventions\n- [convention 1]\n- [convention 2]\n\n## Never\n- Never dismiss reproducible gate failures as pre-existing or out of scope\n- Never proceed on red Preflight or red CI — invoke quick-fix or fix-bug first\n- [hard stop 1]\n- [hard stop 2]\n\n## Agent Rules\n- **Workflow Mandate:** You MUST use the bigpowers skills (e.g. `plan-work`, `develop-tdd`, `orchestrate-project`) to perform tasks. DO NOT write code directly in response to a user prompt like \"build this feature\".\n- **Always Green:** Preflight and CI must be green before forward work. Reproducible gate failures require **fix-or-log** (quick-fix → fix-bug) per CONVENTIONS § Discovered Defects.\n- Read specs\u002F before writing code.\n- All planning and specifications MUST be written to `specs\u002F` (`product\u002FSCOPE_LATEST.yaml`, `release-plan.yaml`, `epics\u002F`) before any code is generated.\n- Write the minimum code that solves the stated problem. Nothing extra.\n- Run tests after every change. Show evidence before declaring done.\n- One clarifying question beats a wrong assumption baked into 200 lines.\n```\n\n## opencode.json template\n\n```json\n{\n  \"$schema\": \"https:\u002F\u002Fopencode.ai\u002Fconfig.json\",\n  \"instructions\": [\"AGENTS.md\"]\n}\n```\n\n## Aider — `.aider.conf.yml` bridge (e37s03)\n\nWhen Aider wiring is opted in:\n\n```yaml\nread: AGENTS.md\n```\n\nUpstream: [Aider-AI\u002Faider](https:\u002F\u002Fgithub.com\u002FAider-AI\u002Faider) (not paul-gauthier\u002Faider).\n\n## Codex CLI — project-local `.codex\u002Fconfig.toml` + AGENTS.md (e37s14)\n\nSource: https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fguides\u002Fagents-md\n\nCodex is instruction-file-only — no slash skills. When Codex wiring is opted in:\n\n```toml\n# .codex\u002Fconfig.toml\ninstructions = [\"AGENTS.md\"]\n```\n\nUse AGENTS.md header `# [Project Name] — AI Agents` (shared with OpenCode\u002FCline). Single AGENTS.md serves dual-tool projects.\n\n## CONVENTIONS.md\n\nUse the standard bigpowers CONVENTIONS.md as the base. Fill in the project-specific defensive code categories from the interview answers.\n\n**Always embed** these doctrine sections from bigpowers (adapt commands only):\n\n- **§ Always Green \u002F Shift Left** — 1-10-100 rationale, Preflight + CI green definitions\n- **§ Discovered Defects** — fix-or-log ladder (quick-fix → fix-bug), separate commits for discovered fixes\n- **Banned dismissive phrases** table — pre-existing, unrelated to session, not introduced by my changes, out of scope (ignoring a red gate)\n\n## Stack profile fragments\n\nIf the user selected a stack profile, merge the matching `profiles\u002F\u003Cname>.md` fragment into the generated `CONVENTIONS.md` under a `## Stack Conventions` section. Profiles supply language-specific commands, architecture patterns, and never-do additions.\n\n## Local tool wiring (optional interview step 8)\n\nOffered after the standard interview. Covers the two tools that global install (`scripts\u002Finstall.sh`) structurally cannot reach because they read project-root config, not global paths.\n\n### Cursor — project-local `.cursor\u002Frules` symlink\n\n```bash\n# From the project root:\nln -sfn \u003Cbigpowers-install-path>\u002F.cursor\u002Frules .cursor\u002Frules\n```\n\nCursor reads `.cursor\u002Frules\u002F` from the project root. This symlink gives every project access to bigpowers skills as Cursor rules without duplicating the files. Run once per project.\n\n### OpenCode — project-local `opencode.json` + `AGENTS.md`\n\n`opencode.json` (project root):\n```json\n{\n  \"$schema\": \"https:\u002F\u002Fopencode.ai\u002Fconfig.json\",\n  \"instructions\": [\".cursor\u002Frules\u002F*.mdc\", \"AGENTS.md\"]\n}\n```\n\nOpenCode reads `opencode.json` from the project root, NOT from a global path. The `instructions` array points to the local `.cursor\u002Frules` symlink (from the Cursor step above) and the project's `AGENTS.md`. Both must exist in the project for OpenCode to see bigpowers skills.\n\n`AGENTS.md` is already generated by the standard interview (step 2 of Generate Files). When local tool wiring is opted in, ensure `AGENTS.md` includes the standard agent-config template header `# [Project Name] — OpenCode`.\n\n### When to offer\n\nOnly offer local tool wiring when the user's project will be opened in Cursor or OpenCode. These tools are project-root scoped by design — no global installer can solve them. Global install (`install.sh`) already handles Claude Code, Gemini CLI, and pi globally. Do not offer for tools that read global config.\n","\u003C!-- story: e10s01 -->\n\u003C!-- story: e47s02 -->\n\u003C!-- story: e10s02 -->\n\u003C!-- story: e51s02 -->\n\u003C!-- story: e45s21 -->\n\u003C!-- story: e79s03 -->\n\n\n# Seed Conventions\n> **HARD GATE** — Before any new code lands, confirm the project conventions are understood. Ask: 'What does a good commit message look like in this project?'\n\nBootstrap a new project with the AI agent conventions it needs. Run this once at the start of a greenfield project.\n\n## What this creates\n\n- `CLAUDE.md` — Claude Code session config (project-specific)\n- `CONVENTIONS.md` — shared rules for all AI agents\n- `specs\u002F` — the specs directory where all planning output will live\n- `AGENTS.md` — for OpenCode and other agents (optional)\n- `GEMINI.md` — for Gemini CLI (optional)\n\n## Interview\n\nAsk the user these questions (one at a time, wait for each answer):\n\n1. **Project name and one-sentence description** — \"What is this project? One sentence.\"\n2. **Stack** — \"What language, framework, and runtime? (e.g. TypeScript \u002F Next.js \u002F Node 22)\"\n2b. **Stack profile (optional)** — Offer: `swift`, `typescript-vue`, `node-service`, or none. If chosen, merge the matching fragment from `profiles\u002F\u003Cname>.md` into generated `CONVENTIONS.md`.\n3. **Commands** — \"What commands do you use for: run, test, build, lint?\"\n3b. **Preflight (optional)** — \"What command runs test, lint, and build together? If none, chain Test + Lint + Build into one **Preflight** row.\"\n4. **Architecture** — \"Key modules and relationships in 1–2 sentences.\"\n5. **Conventions** — \"Any naming, file organization, or patterns all agents must follow?\"\n6. **Never-do list** — \"What are the hard stops? Things an agent must never touch?\"\n7. **Defensive code categories** — \"Which apply? (Rate limit \u002F Retry \u002F Circuit breaker \u002F Timeout \u002F Graceful degradation)\"\n8. **Local tool wiring (optional)** — \"Wire bigpowers for project-local tools? (Cursor, OpenCode, Cline, Aider, Codex CLI)\" If yes, generate AGENTS.md spine artifacts per [REFERENCE.md](REFERENCE.md) §Local tool wiring and §AGENTS.md spine. If no, skip — standard seed output unchanged (no AGENTS.md spine unless opted in).\n\n## Agentic STE for generated prose (e79s03)\n\nWhen writing instructional lines in `CLAUDE.md`, `AGENTS.md`, or `CONVENTIONS.md`, follow [AGENTIC-STE.md](..\u002F..\u002Fdocs\u002FAGENTIC-STE.md):\n\n- Use directive vocabulary: MUST, MUST NOT, NEVER, ALWAYS, DO, DO NOT\n- Do NOT use hedge modals listed in AGENTIC-STE.md Rule 3\n- Cap each instruction sentence at 20 words\n- Write imperative, active-voice lines — one instruction per line\n- Do NOT apply Agentic STE to `terse-mode` (output compression is out of scope)\n\nAfter generation, run `bash scripts\u002Fvalidate-agentic-ste.sh --strict CLAUDE.md CONVENTIONS.md` when those files exist in the target project.\n\n## Generate files\n\nAfter the interview, generate each file using the templates in [REFERENCE.md](REFERENCE.md):\n- `AGENTS.md` — from `docs\u002Ftemplates\u002FAGENTS.md` Reach Template (canonical spine source)\n- `CLAUDE.md` — symlink to `AGENTS.md` (copy fallback on Windows when symlink fails)\n- `GEMINI.md` — symlink to `AGENTS.md` when Gemini wiring opted in\n- `opencode.json` — with `\"instructions\": [\"AGENTS.md\"]` when OpenCode opted in\n- `.aider.conf.yml` — with `read: AGENTS.md` when Aider opted in\n- `CONVENTIONS.md` — bigpowers standard template + project defensive code categories\n\n### `specs\u002F` directory\n\n```bash\nmkdir -p specs\u002Fproduct specs\u002Fproduct\u002Fsnapshots specs\u002Fepics\u002Farchive\nmkdir -p specs\u002Ftech-architecture specs\u002Fadr specs\u002Fverifications specs\u002Fbugs\ntouch specs\u002Fproduct\u002FSCOPE_LATEST.yaml specs\u002Fproduct\u002FVISION_LATEST.yaml specs\u002Fproduct\u002FGLOSSARY_LATEST.yaml\ntouch specs\u002Frelease-plan.yaml specs\u002Fexecution-status.yaml specs\u002Fplanning-status.yaml specs\u002Fstate.yaml\ntouch specs\u002Ftech-architecture\u002Ftech-stack.md specs\u002Ftech-architecture\u002FSECURITY_PLAN_LATEST.md\ntouch specs\u002Ftech-architecture\u002FTEST_PLAN_LATEST.md specs\u002Ftech-architecture\u002FDESIGN_PLAN_LATEST.md\ntouch specs\u002Ftech-architecture\u002FREFACTOR_LATEST.md specs\u002Ftech-architecture\u002FIMPACT_LATEST.md\ntouch specs\u002Fbugs\u002Fregistry.yaml\necho \"# Specs\\n\\nAll planning documents for this project.\" > specs\u002FREADME.md\n```\n\n**Note:** `specs\u002Fstate.yaml.lock` is NOT pre-created — acquired\u002Freleased dynamically.\n\n`specs\u002Fstate.yaml` carries top-level `workflow_mode` (`team-pr` | `solo-git`, default `solo-git`).\nThis is the **canonical integrate-mode signal** for all skills.\nSet it once here. Skills such as `release-branch` read this file instead of sniffing profiles.\n\nWhen generating `CLAUDE.md`, chain Test + Lint + Build into one **Preflight** row if the user named no Preflight command.\n\n### Self-installing fenced markers (e45s21)\n\nSkills that write into `CLAUDE.md` or `AGENTS.md` MUST use **fenced HTML comment markers** so handwritten content outside the fence is never clobbered:\n\n```markdown\n\u003C!-- BEGIN bigpowers:section-id -->\n…agent-managed content only…\n\u003C!-- END bigpowers:section-id -->\n```\n\n**Merge rule:** On update, replace only content between matching `BEGIN`\u002F`END` pairs.\nIf a marker pair is missing, append a new fenced block at file end.\nNever rewrite the whole file.\n\n**Standard marker IDs** for seeded projects (see [REFERENCE.md](REFERENCE.md) § Fenced markers):\n\n| Marker ID | Owner skill | Purpose |\n|-----------|-------------|---------|\n| `project` | seed-conventions | Project, Commands, Architecture |\n| `context-routing` | seed-conventions | Glob → sub-AGENTS.md routing table |\n| `learned-preferences` | session-state | Learned User Preferences + Workspace Facts |\n| `tooling` | setup-environment, guard-git | sqz\u002Frtk\u002Fhook blocks installed by tooling skills |\n\nEmit these fences in `AGENTS.md` (and therefore `CLAUDE.md` symlink) from `docs\u002Ftemplates\u002FAGENTS.md`. User prose outside fences is sacred.\n\n- [ ] CLAUDE.md exists and is populated\n- [ ] CONVENTIONS.md exists and includes specs\u002F output convention\n- [ ] specs\u002Fproduct\u002F exists with SCOPE_LATEST.yaml, VISION_LATEST.yaml, GLOSSARY_LATEST.yaml\n- [ ] specs\u002Ftech-architecture\u002F exists with tech-stack.md, security.md, test.md, design.md\n- [ ] specs\u002Fverifications\u002F exists\n- [ ] specs\u002Fepics\u002Farchive\u002F exists\n- [ ] specs\u002Fbugs\u002Fregistry.yaml exists\n- [ ] Confirm with user: \"Does CLAUDE.md accurately describe your project?\"\n\n---\n\n# story: e51s02 e37s01 e37s03 e37s14\n# story: e45s21\n# Seed Conventions — Reference Templates\n\n## Navigation\n\n| Lines | Section |\n|-------|---------|\n| 1 | Title |\n| 5–29 | Navigation |\n| 30–53 | Fenced markers (e45s21) |\n| 54–65 | AGENTS.md spine (Reach Template — e37s01) |\n| 66–77 | Agent config template (legacy — prefer AGENTS.md spine) |\n| 78–81 | Project |\n| 82–91 | Commands |\n| 92–94 | Architecture |\n| 95–98 | Conventions |\n| 99–104 | Never |\n| 105–114 | Agent Rules |\n| 115–123 | opencode.json template |\n| 124–133 | Aider — `.aider.conf.yml` bridge (e37s03) |\n| 134–146 | Codex CLI — project-local `.codex\u002Fconfig.toml` + AGENTS.md (e37s14) |\n| 147–156 | CONVENTIONS.md |\n| 157–160 | Stack profile fragments |\n| 161–164 | Local tool wiring (optional interview step 8) |\n| 165–173 | Cursor — project-local `.cursor\u002Frules` symlink |\n| 174–187 | OpenCode — project-local `opencode.json` + `AGENTS.md` |\n| 188–190 | When to offer |\n\n## Fenced markers (e45s21)\n\nSelf-installing blocks prevent skills from overwriting user-authored prose. Pattern:\n\n```markdown\n\u003C!-- BEGIN bigpowers:section-id -->\n…managed content…\n\u003C!-- END bigpowers:section-id -->\n```\n\n**Merge algorithm:**\n\n1. If `BEGIN bigpowers:\u003Cid>` exists → replace inner content only.\n2. If missing → append new fenced block at EOF.\n3. Never delete content outside fences.\n\nSeed these marker IDs in generated `AGENTS.md`:\n\n| ID | Initial content |\n|----|-----------------|\n| `project` | Project, Commands, Architecture, Conventions, Never, Agent Rules |\n| `context-routing` | Glob → sub-AGENTS.md table (see CLAUDE.md e45s22) |\n| `learned-preferences` | Empty Learned User Preferences + Workspace Facts lists |\n\n## AGENTS.md spine (Reach Template — e37s01)\n\nCanonical source: copy from `docs\u002Ftemplates\u002FAGENTS.md` in the bigpowers repo (Reach Template).\nDo not invent structure ad hoc — the template includes multi-agent preamble, Preflight, Test\u002FLint\u002FBuild sections.\n\nWhen local tool wiring is opted in:\n1. Copy Reach Template → project root `AGENTS.md`, fill interview placeholders\n2. `ln -sf AGENTS.md CLAUDE.md` (or content copy on Windows when symlink fails)\n3. Write `opencode.json` with `\"instructions\": [\"AGENTS.md\"]`\n\nWhen user **opts out** of local tool wiring, do not emit AGENTS.md spine artifacts.\n\n## Agent config template (legacy — prefer AGENTS.md spine)\n\nAll three files use the same structure — only the header differs:\n- `CLAUDE.md` → `# [Project Name] — Claude Code` (or symlink to AGENTS.md)\n- `GEMINI.md` → `# [Project Name] — Gemini CLI`\n- `AGENTS.md` → `# [Project Name] — AI Agents` (Reach Template header)\n\n```markdown\n# [Project Name] — [Agent]\n\nRead CONVENTIONS.md before any GitHub or git operation.\n\n## Project\n[One sentence description]\nStack: [language, framework, runtime]\n\n## Commands\n| Action | Command |\n|--------|---------|\n| Run    | `[cmd]` |\n| Test   | `[cmd]` |\n| Build  | `[cmd]` |\n| Lint   | `[cmd]` |\n| Preflight | `[test && lint && build chain — or user-named full-green cmd]` |\n| CI     | `gh pr checks` (when a PR is open) |\n\n## Architecture\n[1–2 sentences. Key modules and their relationships.]\n\n## Conventions\n- [convention 1]\n- [convention 2]\n\n## Never\n- Never dismiss reproducible gate failures as pre-existing or out of scope\n- Never proceed on red Preflight or red CI — invoke quick-fix or fix-bug first\n- [hard stop 1]\n- [hard stop 2]\n\n## Agent Rules\n- **Workflow Mandate:** You MUST use the bigpowers skills (e.g. `plan-work`, `develop-tdd`, `orchestrate-project`) to perform tasks. DO NOT write code directly in response to a user prompt like \"build this feature\".\n- **Always Green:** Preflight and CI must be green before forward work. Reproducible gate failures require **fix-or-log** (quick-fix → fix-bug) per CONVENTIONS § Discovered Defects.\n- Read specs\u002F before writing code.\n- All planning and specifications MUST be written to `specs\u002F` (`product\u002FSCOPE_LATEST.yaml`, `release-plan.yaml`, `epics\u002F`) before any code is generated.\n- Write the minimum code that solves the stated problem. Nothing extra.\n- Run tests after every change. Show evidence before declaring done.\n- One clarifying question beats a wrong assumption baked into 200 lines.\n```\n\n## opencode.json template\n\n```json\n{\n  \"$schema\": \"https:\u002F\u002Fopencode.ai\u002Fconfig.json\",\n  \"instructions\": [\"AGENTS.md\"]\n}\n```\n\n## Aider — `.aider.conf.yml` bridge (e37s03)\n\nWhen Aider wiring is opted in:\n\n```yaml\nread: AGENTS.md\n```\n\nUpstream: [Aider-AI\u002Faider](https:\u002F\u002Fgithub.com\u002FAider-AI\u002Faider) (not paul-gauthier\u002Faider).\n\n## Codex CLI — project-local `.codex\u002Fconfig.toml` + AGENTS.md (e37s14)\n\nSource: https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fguides\u002Fagents-md\n\nCodex is instruction-file-only — no slash skills. When Codex wiring is opted in:\n\n```toml\n# .codex\u002Fconfig.toml\ninstructions = [\"AGENTS.md\"]\n```\n\nUse AGENTS.md header `# [Project Name] — AI Agents` (shared with OpenCode\u002FCline). Single AGENTS.md serves dual-tool projects.\n\n## CONVENTIONS.md\n\nUse the standard bigpowers CONVENTIONS.md as the base. Fill in the project-specific defensive code categories from the interview answers.\n\n**Always embed** these doctrine sections from bigpowers (adapt commands only):\n\n- **§ Always Green \u002F Shift Left** — 1-10-100 rationale, Preflight + CI green definitions\n- **§ Discovered Defects** — fix-or-log ladder (quick-fix → fix-bug), separate commits for discovered fixes\n- **Banned dismissive phrases** table — pre-existing, unrelated to session, not introduced by my changes, out of scope (ignoring a red gate)\n\n## Stack profile fragments\n\nIf the user selected a stack profile, merge the matching `profiles\u002F\u003Cname>.md` fragment into the generated `CONVENTIONS.md` under a `## Stack Conventions` section. Profiles supply language-specific commands, architecture patterns, and never-do additions.\n\n## Local tool wiring (optional interview step 8)\n\nOffered after the standard interview. Covers the two tools that global install (`scripts\u002Finstall.sh`) structurally cannot reach because they read project-root config, not global paths.\n\n### Cursor — project-local `.cursor\u002Frules` symlink\n\n```bash\n# From the project root:\nln -sfn \u003Cbigpowers-install-path>\u002F.cursor\u002Frules .cursor\u002Frules\n```\n\nCursor reads `.cursor\u002Frules\u002F` from the project root. This symlink gives every project access to bigpowers skills as Cursor rules without duplicating the files. Run once per project.\n\n### OpenCode — project-local `opencode.json` + `AGENTS.md`\n\n`opencode.json` (project root):\n```json\n{\n  \"$schema\": \"https:\u002F\u002Fopencode.ai\u002Fconfig.json\",\n  \"instructions\": [\".cursor\u002Frules\u002F*.mdc\", \"AGENTS.md\"]\n}\n```\n\nOpenCode reads `opencode.json` from the project root, NOT from a global path. The `instructions` array points to the local `.cursor\u002Frules` symlink (from the Cursor step above) and the project's `AGENTS.md`. Both must exist in the project for OpenCode to see bigpowers skills.\n\n`AGENTS.md` is already generated by the standard interview (step 2 of Generate Files). When local tool wiring is opted in, ensure `AGENTS.md` includes the standard agent-config template header `# [Project Name] — OpenCode`.\n\n### When to offer\n\nOnly offer local tool wiring when the user's project will be opened in Cursor or OpenCode. These tools are project-root scoped by design — no global installer can solve them. Global install (`install.sh`) already handles Claude Code, Gemini CLI, and pi globally. Do not offer for tools that read global config.\n",{"name":5,"model":29,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".codebuddy\u002Fskills\u002Fseed-conventions",23,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add danielvm-git\u002Fbigpowers --skill seed-conventions",{"tool":64,"command":65},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill seed-conventions",{"tool":67,"command":68},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill seed-conventions","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.codebuddy\u002Fskills\u002Fseed-conventions\u002FSKILL.md",true,[],[73,90,97,124,146,167],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":80,"publishedAt":44},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[79],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[81,82,83,84,85,86,87,88,89],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":91,"name":92,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[96,86],"negative path",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":106,"publishedAt":44},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",[107,108,109,110,111,112,113,114,115,116,117,36,118,119,29,120,121,122,30,123],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","use","minimal","bold","integrity","organize","sync","guides",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":44},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[131,132,133,116,134,117,135,136,137,138,29,139,140,141,142,143,144,36,40,145],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","scripts",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":44},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[153,154,155,156,157,158,159,160,161,162,163,116,164,88,131,29,165,166],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":184,"publishedAt":44},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[173,176,181],{"categoryNo":174,"categoryName":175,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":177,"categoryName":178,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":182,"categoryName":183,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000033","数据分析师",[185,186,187,188,189,190,191,192,193,29,194,195,196,197,198,199,35,40,200,201],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","api","project status","http api"]