[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GV61N0F34CMFA7F4AT7C2D":3,"skill-same:01M6GV61N0F34CMFA7F4AT7C2D":81},{"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":18,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":14,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":44,"install":45,"resources":58},"01M6GV61N0F34CMFA7F4AT7C2D","elegy-doc-practices",null,"Use when an agent or contributor needs to classify, place, scaffold, or validate documentation in the Elegy ecosystem — the central doctrine for ADRs, specs, guides, notes, and roadmap material across Elegy and downstream repos.","Sofreshx\u002FElegy","Sofreshx","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F46634397?v=4","01M6GV3ACQ2VKGTY22KKQDDPPG","Sfrsh","01M6GV3AYZA1GPCMY0JP2PQSVC",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-doc-practices\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"doc","elegy doc practices","validate","repos","scaffold","documentation","notes","use","roadmap","doctrine","across","classify","material","guides","ecosystem","2026-11-10 10:12:30",false,"---\nname: elegy-doc-practices\ndescription: Use when an agent or contributor needs to classify, place, scaffold, or validate documentation in the Elegy ecosystem — the central doctrine for ADRs, specs, guides, notes, and roadmap material across Elegy and downstream repos.\n---\n\n# Elegy Documentation Practices\n\n> **Readiness: concept; not agent-routable.** This source guidance has no reviewed clean-install and non-fixture task receipt.\n\n> Use when a contributor or agent needs to apply the central Elegy documentation\n> doctrine: decide whether a change needs an ADR, spec, guide, note, or roadmap\n> entry, scaffold it with the right template, and validate it objectively.\n\nThe central doctrine lives in Elegy. Downstream repos adopt it by referencing\nthis skill and configuring local paths and triggers through\n`.elegy\u002Fdocs.yaml`. The doctrine is durable; the per-repo configuration is local.\n\n## Quick start\n\n1. **Classify the change** — read the [Documentation practices architecture\n   doc](..\u002F..\u002F..\u002Farchitecture\u002Fdocumentation-practices.md) and decide whether the\n   work needs an ADR (durable decision), a spec (implementation-facing behavior),\n   a guide (recurring instructions), a note (narrow local context), or a\n   roadmap entry (multi-slice future work).\n2. **Scaffold the artifact** — use `elegy docs new adr --title \"...\"` or\n   `elegy docs new spec --title \"...\"` to get a file with required frontmatter.\n3. **Adopt locally** — copy the snippets in\n   `skills\u002Felegy-doc-practices\u002Fadoption\u002F` into the consuming repo's\n   `.elegy\u002Fdocs.yaml` and CI workflow.\n4. **Validate objectively** — run `elegy-documentation check --project . --json`\n   to surface missing frontmatter, invalid statuses, broken links, unparseable\n   dates, and freshness warnings. The CLI does not score prose quality.\n5. **Treat prose review as human work** — automation covers objective failures\n   only. Reasoning, structure, and architecture taste stay with humans.\n\n## Document types\n\n| Type | When to use | Authority root | Status values |\n| --- | --- | --- | --- |\n| **ADR** | Durable architecture or governance decision with alternatives and consequences. | `docs\u002Fadr\u002F` | `proposed`, `accepted`, `superseded`, `rejected` |\n| **Spec** | Implementation-facing behavior with acceptance criteria and validation evidence. | `docs\u002Fspecs\u002F` | `draft`, `active`, `completed`, `superseded`, `deprecated` |\n| **Guide** | Recurring contributor or operator instructions. | `docs\u002Farchitecture\u002F` (current) | `active`, `superseded` |\n| **Note** | Narrow local context that does not justify stronger governance. | `docs\u002Farchitecture\u002F` (current) | `active`, `archived` |\n| **Roadmap** | Ordered future work across multiple slices. | `docs\u002Froadmaps\u002F` | `active`, `completed` |\n\nUse the lightest type that captures the work. Do not force every change into\nan ADR or spec.\n\n## Placement\n\n- **Shared doctrine and cross-project conventions** belong in Elegy\n  (`docs\u002Farchitecture\u002F`, `docs\u002Fadr\u002F`, `docs\u002Fspecs\u002F`).\n- **Product-specific ADRs and specs** belong in the owning repo.\n- **Cross-repo decisions** belong centrally and are linked locally from\n  affected repos.\n\nDo not duplicate the shared doctrine into every downstream repo.\n\n## Required frontmatter\n\nEvery current-authority doc must carry non-empty frontmatter for:\n\n- `title`\n- `status`\n- `owner`\n\nEvery spec additionally needs `doc_kind` (one of `adr`, `spec`, `guide`,\n`reference`, `planning`, `research`, `generated`, `index`, `system`).\n`created` and `updated` are recommended for freshness tracking.\n\n## Local adoption\n\nDownstream repos such as `holon` and `elegy-copilot` should:\n\n1. Reference this skill from their `.github\u002Finstructions\u002F` or equivalent.\n2. Define only local path, trigger, and exception overrides in\n   `.elegy\u002Fdocs.yaml`.\n3. Keep product ADRs and specs local unless the decision is cross-repo.\n\nSee `skills\u002Felegy-doc-practices\u002Fadoption\u002F` for copy-paste snippets.\n\n## Validation\n\n```bash\nelegy-documentation inspect --project . --json\nelegy-documentation map --project . --json\nelegy-documentation check --project . --json\nelegy-documentation export llms --project . --output .elegy\u002Fllms.txt\nelegy-documentation export bundle --project . --output .elegy\u002Fdocs-bundle.json\n```\n\nThe CLI covers only objective failures. Prose quality, architecture taste, and\ncorrectness of reasoning require human review.\n\n## Enforcement phases\n\n- **Phase 1** — PR checklist; contributor instructions for documentation impact.\n- **Phase 2** — non-blocking `elegy-documentation check` in CI.\n- **Phase 3** — blocking CI only for objective failures and explicitly\n  configured high-impact changes.\n\nDo not block automatically on subjective document quality.\n\n## Companion skills\n\n- `elegy-skill-authoring` — for creating and auditing SKILL.md content.\n- `elegy-planning` — for durable planning state (goals, roadmaps, plans).\n- `elegy-mcp` — for MCP descriptor authoring and analysis.\n\n## Related\n\n- [Centralize documentation practices doctrine ADR](..\u002F..\u002F..\u002Fadr\u002F2026-05-25-centralize-documentation-practices-doctrine.md)\n- [Documentation practices architecture doc](..\u002F..\u002F..\u002Farchitecture\u002Fdocumentation-practices.md)\n- [Documentation practices skill and CLI spec](..\u002F..\u002F..\u002Fspecs\u002Fdocumentation-practices-skill-and-cli.md)\n","# Elegy Documentation Practices\n\n> **Readiness: concept; not agent-routable.** This source guidance has no reviewed clean-install and non-fixture task receipt.\n\n> Use when a contributor or agent needs to apply the central Elegy documentation\n> doctrine: decide whether a change needs an ADR, spec, guide, note, or roadmap\n> entry, scaffold it with the right template, and validate it objectively.\n\nThe central doctrine lives in Elegy. Downstream repos adopt it by referencing\nthis skill and configuring local paths and triggers through\n`.elegy\u002Fdocs.yaml`. The doctrine is durable; the per-repo configuration is local.\n\n## Quick start\n\n1. **Classify the change** — read the [Documentation practices architecture\n   doc](..\u002F..\u002F..\u002Farchitecture\u002Fdocumentation-practices.md) and decide whether the\n   work needs an ADR (durable decision), a spec (implementation-facing behavior),\n   a guide (recurring instructions), a note (narrow local context), or a\n   roadmap entry (multi-slice future work).\n2. **Scaffold the artifact** — use `elegy docs new adr --title \"...\"` or\n   `elegy docs new spec --title \"...\"` to get a file with required frontmatter.\n3. **Adopt locally** — copy the snippets in\n   `skills\u002Felegy-doc-practices\u002Fadoption\u002F` into the consuming repo's\n   `.elegy\u002Fdocs.yaml` and CI workflow.\n4. **Validate objectively** — run `elegy-documentation check --project . --json`\n   to surface missing frontmatter, invalid statuses, broken links, unparseable\n   dates, and freshness warnings. The CLI does not score prose quality.\n5. **Treat prose review as human work** — automation covers objective failures\n   only. Reasoning, structure, and architecture taste stay with humans.\n\n## Document types\n\n| Type | When to use | Authority root | Status values |\n| --- | --- | --- | --- |\n| **ADR** | Durable architecture or governance decision with alternatives and consequences. | `docs\u002Fadr\u002F` | `proposed`, `accepted`, `superseded`, `rejected` |\n| **Spec** | Implementation-facing behavior with acceptance criteria and validation evidence. | `docs\u002Fspecs\u002F` | `draft`, `active`, `completed`, `superseded`, `deprecated` |\n| **Guide** | Recurring contributor or operator instructions. | `docs\u002Farchitecture\u002F` (current) | `active`, `superseded` |\n| **Note** | Narrow local context that does not justify stronger governance. | `docs\u002Farchitecture\u002F` (current) | `active`, `archived` |\n| **Roadmap** | Ordered future work across multiple slices. | `docs\u002Froadmaps\u002F` | `active`, `completed` |\n\nUse the lightest type that captures the work. Do not force every change into\nan ADR or spec.\n\n## Placement\n\n- **Shared doctrine and cross-project conventions** belong in Elegy\n  (`docs\u002Farchitecture\u002F`, `docs\u002Fadr\u002F`, `docs\u002Fspecs\u002F`).\n- **Product-specific ADRs and specs** belong in the owning repo.\n- **Cross-repo decisions** belong centrally and are linked locally from\n  affected repos.\n\nDo not duplicate the shared doctrine into every downstream repo.\n\n## Required frontmatter\n\nEvery current-authority doc must carry non-empty frontmatter for:\n\n- `title`\n- `status`\n- `owner`\n\nEvery spec additionally needs `doc_kind` (one of `adr`, `spec`, `guide`,\n`reference`, `planning`, `research`, `generated`, `index`, `system`).\n`created` and `updated` are recommended for freshness tracking.\n\n## Local adoption\n\nDownstream repos such as `holon` and `elegy-copilot` should:\n\n1. Reference this skill from their `.github\u002Finstructions\u002F` or equivalent.\n2. Define only local path, trigger, and exception overrides in\n   `.elegy\u002Fdocs.yaml`.\n3. Keep product ADRs and specs local unless the decision is cross-repo.\n\nSee `skills\u002Felegy-doc-practices\u002Fadoption\u002F` for copy-paste snippets.\n\n## Validation\n\n```bash\nelegy-documentation inspect --project . --json\nelegy-documentation map --project . --json\nelegy-documentation check --project . --json\nelegy-documentation export llms --project . --output .elegy\u002Fllms.txt\nelegy-documentation export bundle --project . --output .elegy\u002Fdocs-bundle.json\n```\n\nThe CLI covers only objective failures. Prose quality, architecture taste, and\ncorrectness of reasoning require human review.\n\n## Enforcement phases\n\n- **Phase 1** — PR checklist; contributor instructions for documentation impact.\n- **Phase 2** — non-blocking `elegy-documentation check` in CI.\n- **Phase 3** — blocking CI only for objective failures and explicitly\n  configured high-impact changes.\n\nDo not block automatically on subjective document quality.\n\n## Companion skills\n\n- `elegy-skill-authoring` — for creating and auditing SKILL.md content.\n- `elegy-planning` — for durable planning state (goals, roadmaps, plans).\n- `elegy-mcp` — for MCP descriptor authoring and analysis.\n\n## Related\n\n- [Centralize documentation practices doctrine ADR](..\u002F..\u002F..\u002Fadr\u002F2026-05-25-centralize-documentation-practices-doctrine.md)\n- [Documentation practices architecture doc](..\u002F..\u002F..\u002Farchitecture\u002Fdocumentation-practices.md)\n- [Documentation practices skill and CLI spec](..\u002F..\u002F..\u002Fspecs\u002Fdocumentation-practices-skill-and-cli.md)\n",{"name":5,"description":7},"main","cdaaaccc462c986f4a2c0032b75698f15c71f62b","skills\u002Felegy-doc-practices","https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy","https:\u002F\u002Fgithub.com\u002FSofreshx","2026-11-02 22:33:10",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add Sofreshx\u002FElegy --skill elegy-doc-practices",{"tool":51,"command":52},"bunx","bunx skills add Sofreshx\u002FElegy --skill elegy-doc-practices",{"tool":54,"command":55},"pnpm","pnpm dlx skills add Sofreshx\u002FElegy --skill elegy-doc-practices","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-doc-practices\u002FSKILL.md",true,[59,65,69,73,77],{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"adoption\u002Fdownstream-repo.md","REFERENCE","参考文档",1468,"https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-doc-practices\u002Fadoption\u002Fdownstream-repo.md",{"path":66,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":67,"sourceHtmlUrl":68},"readiness.json",713,"https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-doc-practices\u002Freadiness.json",{"path":70,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":71,"sourceHtmlUrl":72},"README.md",311,"https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-doc-practices\u002FREADME.md",{"path":74,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":75,"sourceHtmlUrl":76},"templates\u002Fadr.md",471,"https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-doc-practices\u002Ftemplates\u002Fadr.md",{"path":78,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":79,"sourceHtmlUrl":80},"templates\u002Fspec.md",579,"https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-doc-practices\u002Ftemplates\u002Fspec.md",[82,101,122,147,163,182],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":93,"publishedAt":34},"01M6GV77GEYNKPE96EFA282AY0","elegy-skill-authoring","Doctrine for drafting, auditing, and fixing Elegy skills. Use when creating a new skill, running an audit against an existing one, or triaging structural and content findings.","https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-skill-authoring\u002FSKILL.md",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[94,95,96,97,98,28,26,99,100],"elegy skill authoring","skill authoring","authoring","structural","new skill","audit","content",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":110,"publishedAt":34},"01M6GV6VG31WQVTQ0RGEEEWKQ8","elegy-plugin-authoring","Use when creating or reviewing an Elegy system-adapter plugin that connects an agent to a data source, database, platform, API, local system, or executable boundary.","https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-plugin-authoring\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000010","后端与接口",[111,112,96,113,114,115,116,26,117,118,119,120,121],"plugin","plugin authoring","elegy plugin authoring","local","adapter","platform","system","api","boundary","data","database",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":34},"01M6GV6FK50JQ7XPFA0EVCFDBJ","elegy-obsidian","Read, write, and search a local Obsidian vault via the official Obsidian Desktop CLI (v1.12.7+). Non-authoritative convenience layer; durable planning state continues to flow through elegy-planning and SQLite. User-invoked; do not auto-load.","https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fskills\u002Felegy-obsidian\u002FSKILL.md",[],[129,130,131,132,133,114,134,135,136,137,138,139,140,141,142,143,144,145,146,25],"elegy obsidian","obsidian","true","tags","tasks","do","auto","obsidian vault","sqlite","vault","desktop","planning","state","search","mirror","load","official","cli",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":157,"publishedAt":34},"01M6GV5RR6R3XF7Q1EP9QZ4GVK","test-skill","A test skill for the app-binding fixture.","https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fshared\u002Fplugin-sdk\u002Ftests\u002Ffixtures\u002Fapp-binding-plugin\u002Fskills\u002Ftest-skill\u002FSKILL.md",[153,156],{"categoryNo":154,"categoryName":155,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[158,159,160,161,162],"test","Test Skill","binding","app","fixture",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":34},"01M6GV59H2X6CJAYJCX7S4ERJE","elegy-planning","Use when an agent needs to create, inspect, update, validate, or export durable planning state — goals, roadmaps, plans, work points, todos, issues, review points, insights, and project runs — through the dedicated elegy-planning CLI over SQLite.","https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fplugins\u002Fplanning\u002Fskills\u002Felegy-planning\u002FSKILL.md",[],[140,170,146,171,21,172,173,174,175,176,177,26,178,137,179,141,180,181],"elegy planning","review","goals","inspect","insights","plans","project","export","work","issues","update","create",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":34},"01M6GV4X2GKY7SF0RM1FCHMXHF","elegy-observe","Observe desktop and OS state for agentic workflows. Snapshot running processes, track foreground and visible windows, capture screen, read clipboard, diff filesystem changes, and query system information.","https:\u002F\u002Fgithub.com\u002FSofreshx\u002FElegy\u002Fblob\u002Fmain\u002Fplugins\u002Fobserve\u002Fskills\u002Felegy-observe\u002FSKILL.md",[],[189,190,191,192,193,194,195,196,197,198,199,200,201,117,141,139,202,203,204,205],"elegy observe","observe","snapshot","information","capture screen","processes","screen","os","clipboard","diff","read","capture","filesystem","windows","agentic workflows","workflows","agentic"]