[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P6GW520QJ03A6K7Y5PWJ52":3,"skill-same:01M6P6GW520QJ03A6K7Y5PWJ52":107},{"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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":86,"commitSha":87,"skillDirectory":88,"forksCount":89,"repositoryHtmlUrl":90,"repositoryHomepageUrl":6,"ownerHtmlUrl":91,"ownerBlogUrl":92,"ownerDescription":6,"updatedAt":93,"install":94,"resources":106},"01M6P6GW520QJ03A6K7Y5PWJ52","voice-before-structure",null,"Read the project's design language and philosophy before writing structural artifacts. Ground manifests, READMEs, and descriptions in the project's voice, not boilerplate. Use when creating manifests or READMEs for established projects, writing ecosystem-level documentation, building plugin descriptions or marketplace metadata, or authoring metadata that carries a project's identity. Trigger phrases: 'write the manifest', 'create a README', 'describe this plugin', 'ground yourself in the philosophy', 'ecosystem-level work'.","DojoGenesis\u002Fgateway","DojoGenesis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273886418?v=4","01M6P54RXMD3TZ2082Z3Z4JMQP","Cruz Morales (TresPies)","01M6P54S269YR0ZZZ96WGQM439",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fvoice-before-structure\u002FSKILL.md",[18,23,26,31],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"voice before structure","voice","structure","philosophy","manifests","ecosystem","false","authoring","structural","project","artifact","design","write","read","work","projects","create","documentation","identity","writing","2026-11-10 10:12:30",false,"---\nname: voice-before-structure\nmodel: sonnet\ndescription: \"Read the project's design language and philosophy before writing structural artifacts. Ground manifests, READMEs, and descriptions in the project's voice, not boilerplate. Use when creating manifests or READMEs for established projects, writing ecosystem-level documentation, building plugin descriptions or marketplace metadata, or authoring metadata that carries a project's identity. Trigger phrases: 'write the manifest', 'create a README', 'describe this plugin', 'ground yourself in the philosophy', 'ecosystem-level work'.\"\ncategory: wisdom-garden\ntriggers:\n  - \"write the manifest\"\n  - \"create a README\"\n  - \"describe this plugin\"\n  - \"ground yourself in the philosophy\"\n  - \"ecosystem-level work\"\ntier: 1\nagents:\n  - \"primary\"\ntool_dependencies:\n  - \"file_system\"\n\ninputs:\n  - name: project_context\n    type: string\n    description: Description of the project whose design language and philosophy to read before writing\n    required: true\n  - name: artifact_type\n    type: string\n    description: Type of artifact to produce — manifest, README, description, or metadata\n    required: false\noutputs:\n  - name: voiced_artifact\n    type: string\n    description: Project-voice-grounded artifact (manifest, README, description, or metadata) written in the established design language\n---\n# Voice Before Structure\n\n## Philosophy\n\nStructure without voice is generic cargo. A manifest read aloud should unmistakably belong to *this* project, not any project. The voice — the project's design language, founding tensions, philosophy — informs the naming, descriptions, and framing of everything you build.\n\nWhen you write structural artifacts (manifests, READMEs, descriptions) in a vacuum, you get rewrite cycles. When you ground them in the philosophy first, they land. The difference between \"strategic planning tools\" and \"begin with a tension, not a solution\" is the difference between cargo and cargo with identity.\n\n## When to Use\n\n- **Starting ecosystem-level work**: plugin builds, marketplace setup, documentation overhauls\n- **Creating identity-bearing documents**: manifests, READMEs, descriptions, schemas\n- **Writing for established projects**: ones with recognizable design language or founding philosophy\n- **Metadata authoring**: anything that carries the project's identity outward\n\nAvoid using this when working on utility code or implementation details that don't need to express the project's voice.\n\n## Workflow\n\n### Before Writing Structure\n\n1. **Identify philosophy documents** in the project (README, design language docs, founding reflections, core principles, vision statements)\n\n2. **Read 2-3 documents** — enough to *hear* the voice, not so many that you stall execution\n   - What tensions does this project address?\n   - What language does it use repeatedly?\n   - What does it refuse to do?\n   - What's the underlying philosophy?\n\n3. **Absorb the voice** — not just facts, but *how* the project thinks\n   - Naming conventions and style\n   - Metaphors it uses\n   - Values it prioritizes\n   - Problems it frames differently than standard industry language\n\n4. **Draft the structural artifact** with voice as a constraint, not an afterthought\n   - Use the project's language for concepts\n   - Match the tone and cadence\n   - Reference the founding tensions or philosophy where relevant\n\n5. **Read aloud** — the quality check\n   - Does it sound like it belongs to this project?\n   - Could it belong to any project (generic = failed)?\n   - Would someone familiar with the philosophy recognize these descriptions?\n\n## Best Practices\n\n- **Read before writing**, not while writing. You need the voice internalized, not consulted.\n- **Read selectively**. 2-3 documents is the sweet spot — enough context, not analysis paralysis.\n- **Listen for what's unique**, not just what's stated. Tone, metaphors, and refusals reveal philosophy.\n- **Check specificity**. If your descriptions could apply to any project, you haven't grounded them yet.\n- **Test for recognition**. Imagine someone who built this project reading what you wrote. Would they nod?\n- **Use concrete language** from the project. Borrow the vocabulary; don't invent parallel terminology.\n\n## Quality Checklist\n\n- [ ] Philosophy documents identified and read (at least 2-3)\n- [ ] Project's core tensions or design principles understood\n- [ ] Artifact uses language\u002Fmetaphors from philosophy docs\n- [ ] Descriptions are specific to *this* project, not generic\n- [ ] Read-aloud test: sounds like it belongs here\n- [ ] Someone familiar with the project would recognize it\n- [ ] Tone and cadence match the project's established voice\n\n## Common Pitfalls\n\n**Generic boilerplate**: Writing a description that could apply to any project. Test: remove the project name. Does it still make sense? If yes, it's too generic.\n\n**Over-reading**: Spending hours absorbing philosophy instead of drafting. 2-3 documents, then write. Iteration refines the voice further.\n\n**Mismatching tone**: Writing formally when the project is conversational, or vice versa. Listen for how the philosophy docs talk, not just what they say.\n\n**Forcing the voice**: Trying to sound like the project when you don't understand it yet. Return to the philosophy docs; let understanding come first.\n\n**Treating structure as separate**: Writing the manifest first, then trying to add voice afterward. Voice must inform structure from the start.\n\n## Related Skills\n\n- **memory-garden**: Preserves the philosophy and design language that this skill reads\n- **seed-extraction**: Extracts patterns that become part of the project's voice\n- **specification-writer**: Benefits from voice grounding when writing identity-bearing sections\n- **compression-ritual**: Preserves the \"why\" that feeds future voice grounding\n\n---\n\n## Output\n\n- The identity-bearing artifact itself (manifest, README, plugin description, marketplace metadata) written in the project's established voice\n- A brief voice-grounding note (1-2 sentences in-line or as a comment) citing which philosophy documents were read and what language was adopted\n\n## Examples\n\n**Scenario 1:** User says \"write the manifest for this plugin\" on a project that has a PHILOSOPHY.md → reads PHILOSOPHY.md and one other founding doc, then writes `plugin.json` descriptions that use the project's own vocabulary and framing rather than generic boilerplate.\n\n**Scenario 2:** User says \"describe this plugin for the marketplace\" → reads 2-3 design language docs, identifies core tensions and metaphors, drafts the description, and passes the read-aloud test before finalizing.\n\n## Edge Cases\n\n- If no philosophy documents exist in the project, ask the user for 2-3 sentences describing the project's design philosophy before drafting. Do not invent the voice.\n- If the project has conflicting philosophy documents (e.g., an old VISION.md and a newer README with different framing), surface the conflict to the user before choosing which to ground in.\n\n## Anti-Patterns\n\n- Writing the manifest first and then \"adding voice\" afterward — voice must inform structure from the start, not be layered on top.\n- Reading too many documents before drafting — more than 3 documents causes analysis paralysis. 2-3 is the ceiling; start drafting.\n\n---\n\n**Origin**: Marketplace Build Sprint. Cruz's mid-sprint interrupt — \"before you write the manifest make sure you ground yourself in the philosophy\" — was the single highest-leverage moment of the sprint.\n","# Voice Before Structure\n\n## Philosophy\n\nStructure without voice is generic cargo. A manifest read aloud should unmistakably belong to *this* project, not any project. The voice — the project's design language, founding tensions, philosophy — informs the naming, descriptions, and framing of everything you build.\n\nWhen you write structural artifacts (manifests, READMEs, descriptions) in a vacuum, you get rewrite cycles. When you ground them in the philosophy first, they land. The difference between \"strategic planning tools\" and \"begin with a tension, not a solution\" is the difference between cargo and cargo with identity.\n\n## When to Use\n\n- **Starting ecosystem-level work**: plugin builds, marketplace setup, documentation overhauls\n- **Creating identity-bearing documents**: manifests, READMEs, descriptions, schemas\n- **Writing for established projects**: ones with recognizable design language or founding philosophy\n- **Metadata authoring**: anything that carries the project's identity outward\n\nAvoid using this when working on utility code or implementation details that don't need to express the project's voice.\n\n## Workflow\n\n### Before Writing Structure\n\n1. **Identify philosophy documents** in the project (README, design language docs, founding reflections, core principles, vision statements)\n\n2. **Read 2-3 documents** — enough to *hear* the voice, not so many that you stall execution\n   - What tensions does this project address?\n   - What language does it use repeatedly?\n   - What does it refuse to do?\n   - What's the underlying philosophy?\n\n3. **Absorb the voice** — not just facts, but *how* the project thinks\n   - Naming conventions and style\n   - Metaphors it uses\n   - Values it prioritizes\n   - Problems it frames differently than standard industry language\n\n4. **Draft the structural artifact** with voice as a constraint, not an afterthought\n   - Use the project's language for concepts\n   - Match the tone and cadence\n   - Reference the founding tensions or philosophy where relevant\n\n5. **Read aloud** — the quality check\n   - Does it sound like it belongs to this project?\n   - Could it belong to any project (generic = failed)?\n   - Would someone familiar with the philosophy recognize these descriptions?\n\n## Best Practices\n\n- **Read before writing**, not while writing. You need the voice internalized, not consulted.\n- **Read selectively**. 2-3 documents is the sweet spot — enough context, not analysis paralysis.\n- **Listen for what's unique**, not just what's stated. Tone, metaphors, and refusals reveal philosophy.\n- **Check specificity**. If your descriptions could apply to any project, you haven't grounded them yet.\n- **Test for recognition**. Imagine someone who built this project reading what you wrote. Would they nod?\n- **Use concrete language** from the project. Borrow the vocabulary; don't invent parallel terminology.\n\n## Quality Checklist\n\n- [ ] Philosophy documents identified and read (at least 2-3)\n- [ ] Project's core tensions or design principles understood\n- [ ] Artifact uses language\u002Fmetaphors from philosophy docs\n- [ ] Descriptions are specific to *this* project, not generic\n- [ ] Read-aloud test: sounds like it belongs here\n- [ ] Someone familiar with the project would recognize it\n- [ ] Tone and cadence match the project's established voice\n\n## Common Pitfalls\n\n**Generic boilerplate**: Writing a description that could apply to any project. Test: remove the project name. Does it still make sense? If yes, it's too generic.\n\n**Over-reading**: Spending hours absorbing philosophy instead of drafting. 2-3 documents, then write. Iteration refines the voice further.\n\n**Mismatching tone**: Writing formally when the project is conversational, or vice versa. Listen for how the philosophy docs talk, not just what they say.\n\n**Forcing the voice**: Trying to sound like the project when you don't understand it yet. Return to the philosophy docs; let understanding come first.\n\n**Treating structure as separate**: Writing the manifest first, then trying to add voice afterward. Voice must inform structure from the start.\n\n## Related Skills\n\n- **memory-garden**: Preserves the philosophy and design language that this skill reads\n- **seed-extraction**: Extracts patterns that become part of the project's voice\n- **specification-writer**: Benefits from voice grounding when writing identity-bearing sections\n- **compression-ritual**: Preserves the \"why\" that feeds future voice grounding\n\n---\n\n## Output\n\n- The identity-bearing artifact itself (manifest, README, plugin description, marketplace metadata) written in the project's established voice\n- A brief voice-grounding note (1-2 sentences in-line or as a comment) citing which philosophy documents were read and what language was adopted\n\n## Examples\n\n**Scenario 1:** User says \"write the manifest for this plugin\" on a project that has a PHILOSOPHY.md → reads PHILOSOPHY.md and one other founding doc, then writes `plugin.json` descriptions that use the project's own vocabulary and framing rather than generic boilerplate.\n\n**Scenario 2:** User says \"describe this plugin for the marketplace\" → reads 2-3 design language docs, identifies core tensions and metaphors, drafts the description, and passes the read-aloud test before finalizing.\n\n## Edge Cases\n\n- If no philosophy documents exist in the project, ask the user for 2-3 sentences describing the project's design philosophy before drafting. Do not invent the voice.\n- If the project has conflicting philosophy documents (e.g., an old VISION.md and a newer README with different framing), surface the conflict to the user before choosing which to ground in.\n\n## Anti-Patterns\n\n- Writing the manifest first and then \"adding voice\" afterward — voice must inform structure from the start, not be layered on top.\n- Reading too many documents before drafting — more than 3 documents causes analysis paralysis. 2-3 is the ceiling; start drafting.\n\n---\n\n**Origin**: Marketplace Build Sprint. Cruz's mid-sprint interrupt — \"before you write the manifest make sure you ground yourself in the philosophy\" — was the single highest-leverage moment of the sprint.\n",{"name":5,"tier":60,"model":61,"agents":62,"inputs":64,"outputs":73,"category":77,"triggers":78,"description":7,"tool_dependencies":84},1,"sonnet",[63],"primary",[65,70],{"name":66,"type":67,"required":68,"description":69},"project_context","string",true,"Description of the project whose design language and philosophy to read before writing",{"name":71,"type":67,"required":56,"description":72},"artifact_type","Type of artifact to produce — manifest, README, description, or metadata",[74],{"name":75,"type":67,"description":76},"voiced_artifact","Project-voice-grounded artifact (manifest, README, description, or metadata) written in the established design language","wisdom-garden",[79,80,81,82,83],"write the manifest","create a README","describe this plugin","ground yourself in the philosophy","ecosystem-level work",[85],"file_system","main","ff07df5fd8f75762c2a131e6e26d297e8ae403ee","plugins\u002Fwisdom-garden\u002Fskills\u002Fvoice-before-structure",0,"https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway","https:\u002F\u002Fgithub.com\u002FDojoGenesis","dojogenesis.com","2026-10-25 22:59:58",{"source":8,"skillName":5,"commands":95,"prompt":105,"zipAvailable":68},[96,99,102],{"tool":97,"command":98},"npx","npx skills add DojoGenesis\u002Fgateway --skill voice-before-structure",{"tool":100,"command":101},"bunx","bunx skills add DojoGenesis\u002Fgateway --skill voice-before-structure",{"tool":103,"command":104},"pnpm","pnpm dlx skills add DojoGenesis\u002Fgateway --skill voice-before-structure","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fvoice-before-structure\u002FSKILL.md",[],[108,127,140,148,174,201],{"skillNo":109,"name":110,"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":111,"categories":112,"keywords":116,"publishedAt":55},"01M6P6J0WYSD1MTGA3ZX6MGGZ5","kata-test-echo","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-test-echo\u002FSKILL.md",[113],{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[117,118,119,120,121,122,123,124,125,126],"test","kata test echo","Echo","v1","output","input","structured","contracts","schema","json",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":136,"publishedAt":55},"01M6P6HQJNGG4WPZW0DEWMAY2N","kata-plain","An ordinary prose skill; not dispatchable.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-plain\u002FSKILL.md",[133],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[137,138,139],"kata plain","prose","prose skill",{"skillNo":141,"name":142,"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":143,"categories":144,"keywords":145,"publishedAt":55},"01M6P6HH6Y7K8K6606MF7VZ1HB","kata-broken","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-broken\u002FSKILL.md",[],[146,147,117,120,121,122,123,124,119,125,126],"broken","kata broken",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":55},"01M6P6GMNA4HJ4D5RRM3BQZ73M","system-prompt-archaeology","Produces a named ADA disposition preset (YAML) and a layered behavioral analysis (structural decomposition + evidence-cited classifications) from a system prompt. Use when: \"analyze this system prompt\", \"extract disposition from prompt\", \"reverse-engineer agent behavior\", \"what patterns does this prompt use\", \"build a preset from this prompt\".","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsystem-prompt-archaeology\u002FSKILL.md",[154],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},[156,157,158,159,160,43,161,162,163,61,164,165,166,167,168,169,170,171,172,173],"system prompt archaeology","system prompt","prompt","system","ada","STRING","classify","decomposition","true","reverse","wisdom","patterns","analyze","decompose","evidence","behavioral","analysis","engineer",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":181,"publishedAt":55},"01M6P6G2D70T9R00HX6K154X5Y","session-lifecycle-automation","Designs and configures all three loops of solo-operator session automation — session bookends, background maintenance agents, and a delegation flywheel. Use when setting up a new workspace, recovering from the 44% zero-artifact session leak, or preparing to scale delegation across multiple concurrent agents.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsession-lifecycle-automation\u002FSKILL.md",[180],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},[182,183,184,185,186,187,188,189,190,191,192,193,45,194,195,196,197,198,199,200],"session lifecycle automation","session","lifecycle","automation","session lifecycle","config","directory","delegation","solo","scheduled","loops","across","files","up","template","configure","markdown","SET","audit",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":208,"publishedAt":55},"01M6P6FSW7J2P40CDZGFTBYC6W","session-compression","Produces updated memory artifacts by compressing a session's key decisions, changes, and context into the structured memory garden. Use when: \"compress this session\", \"save context\", \"end of session\", \"update memory\", \"wrap up\".","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsession-compression\u002FSKILL.md",[207],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},[209,210,183,195,211,212,61,161,213,214,194,215,216,217,198,218,219,220,221,188],"session compression","compression","memory garden","path","end","memories","context","text","compress","open","save","update","memory"]