[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P69EE2BQ5M7WF3CJ0V24P6":3,"skill-same:01M6P69EE2BQ5M7WF3CJ0V24P6":94},{"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":73,"commitSha":74,"skillDirectory":75,"forksCount":76,"repositoryHtmlUrl":77,"repositoryHomepageUrl":6,"ownerHtmlUrl":78,"ownerBlogUrl":79,"ownerDescription":6,"updatedAt":80,"install":81,"resources":93},"01M6P69EE2BQ5M7WF3CJ0V24P6","status-template",null,"Produces a comprehensive `.status.md` file using a 10-section schema that bridges heartbeat (current state), anatomy (directory structure), and checkup (health assessment) perspectives into one document. Use when: 'write a status report', 'give me the lay of the land', 'where are we right now', 'prepare a handoff document', 'document the current codebase state'.","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\u002Fsystem-health\u002Fskills\u002Fstatus-template\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"status","status template","template","bridging","directory","where are we","health assessment","sonnet","now","status report","anatomy","project","land","structure","me","write","heartbeat","perspectives","assessment","repository","2026-11-10 10:12:30",false,"---\nname: status-template\nmodel: sonnet\ndescription: \"Produces a comprehensive `.status.md` file using a 10-section schema that bridges heartbeat (current state), anatomy (directory structure), and checkup (health assessment) perspectives into one document. Use when: 'write a status report', 'give me the lay of the land', 'where are we right now', 'prepare a handoff document', 'document the current codebase state'.\"\ncategory: system-health\ntriggers:\n  - \"write a status report\"\n  - \"give me the lay of the land\"\n  - \"where are we right now\"\n  - \"prepare a handoff document\"\n  - \"document the current codebase state\"\ntier: 1\nagents:\n  - \"primary\"\ntool_dependencies:\n  - \"file_system\"\n\ninputs:\n  - name: repo_path\n    type: string\n    description: Path to the repository or project to write status for\n    required: true\noutputs:\n  - name: status_file\n    type: ref\n    format: cas-ref\n    description: Comprehensive .status.md using a 10-section schema bridging heartbeat, anatomy, and checkup perspectives\n---\n\n# Status Template Skill\n\n**Version:** 1.0\n**Created:** 2026-02-08\n**Author:** Cruz + Manus (Cowork)\n**Origin:** Elevated from the `repo-status` skill's status template reference, which was itself codified from a live status-writing + file-management + health-audit session.\n**Lineage:** status-writing (heartbeat) + file-management (anatomy) + health-audit (checkup) → repo-status → this standalone skill.\n\n---\n\n## I. The Philosophy: One Document, Three Perspectives\n\nProject status lives in too many places — Slack threads, standup notes, README footers, someone's head. When a new person (or agent) arrives and asks \"where are we?\", the answer is usually scattered, stale, or both.\n\nThis skill produces a single `.status.md` file that answers that question by looking at the project from three angles:\n\n- **Heartbeat (status-writing):** Is it alive? What's moving? What's stuck? Emoji-driven health indicators give an instant pulse check.\n- **Anatomy (file-management):** Where is everything? An annotated directory tree with per-folder status turns the filesystem into a map.\n- **Checkup (health-audit):** How healthy is it? Critical issues, security posture, and sustainability assessment tell you what needs attention.\n\nOne file. Three lenses. Updated over time.\n\n---\n\n## II. When to Use This Skill\n\n- **Writing a status report:** Monthly, per-release, or ad-hoc — this template gives you the structure.\n- **Onboarding someone to a project:** Instead of a 30-minute walkthrough, hand them a `.status.md`.\n- **Preparing a handoff:** Moving a project between teams or agents? This is the context document.\n- **Before a major decision:** Understanding the full state before deciding what to change.\n- **When a project feels opaque:** Structure reduces confusion. The template imposes coherence on complexity.\n- **After running the `repo-status` skill:** This template is Phase 4 of that workflow.\n\n---\n\n## III. The Template Structure\n\nThe status document has 10 sections. Each one has a specific job.\n\n### Section 1: Vision & Purpose\n**Job:** Anchor everything that follows. One sentence + core principles.\n\nWhy it matters: Without a stated purpose, status updates become lists of things. With one, they become a story about progress toward a goal.\n\n```markdown\n## 1. Vision & Purpose\n> [One sentence capturing what the project is and why it exists.]\n**Core Principles:** [3-5 comma-separated principles]\n```\n\n### Section 2: Current State\n**Job:** Instant pulse check. A table of major areas with emoji status and brief notes.\n\nWhy it matters: Someone glancing at this document for 5 seconds should know if things are healthy or on fire. The emoji table achieves this.\n\n```markdown\n## 2. Current State\n| Area | Status | Notes |\n| :--- | :--- | :--- |\n| **[Major Area]** | ✅\u002F?\u002F⚠️\u002F❌ | [One-line note] |\n```\n\n**Status Key:**\n- ✅ Complete\u002FHealthy\n- ? In Progress\n- ⏸️ Paused\n- ⚠️ Concern\n- ❌ Blocked\u002FCritical\n\n### Section 3: Directory Structure\n**Job:** Annotated filesystem map. Every significant directory gets a status emoji and note.\n\nWhy it matters: Most codebases lack a visual map of what's where. An annotated tree is worth a thousand words for spatial orientation.\n\nUse `?` for legacy\u002Fdeprecated directories. Use `—` for empty or minimal ones.\n\n### Section 4: Semantic Clusters\n**Job:** Group components by *what they do*, not where they live.\n\nWhy it matters: This is the behavioral architecture. A feature spans frontend + backend + database + tests. Clusters reveal the system's capabilities as cross-cutting concerns.\n\nIf using semantic clusters, invoke the `semantic-clusters` skill for the full framework. Otherwise, this section can be simplified to a feature list with health assessments.\n\nFor each cluster:\n```markdown\n### [emoji] [VERB] — [Short Description]\n> [One sentence explaining this capability.]\n| Component | Location | Status | LOC |\n|-----------|----------|--------|-----|\n**Health:** [emoji] [assessment]\n**Audit Notes:** [key technical details]\n```\n\n### Section 5: File Importance Ranking\n**Job:** Rank files by criticality so people know what not to break.\n\nWhy it matters: In a 500-file codebase, 10 files are critical, 10 are important, and the rest are supporting. Making this explicit prevents accidental damage to core files.\n\nFour tiers: Critical (system breaks without these), Important (features break), Supporting (graceful degradation), Knowledge (development-time only).\n\n### Section 6: Health Assessment\n**Job:** Honest checkup. Critical issues, security, sustainability.\n\nWhy it matters: This is the health-audit perspective. Every project has blind spots — security gaps, test coverage holes, manual processes that should be automated. This section forces them into the light.\n\nThree categories:\n- **Critical Issues:** Can it build? Critical vulnerabilities? Main branch broken?\n- **Security:** Secrets management, auth, encryption, access control.\n- **Sustainability:** Test coverage, CI\u002FCD, tech debt, documentation freshness.\n\n### Section 7: Active Workstreams\n**Job:** What's being worked on right now, by whom.\n\nA table: `Workstream | Owner | Status | Focus`\n\n### Section 8: Blockers & Dependencies\n**Job:** What's preventing progress. Be ruthlessly honest.\n\nIf nothing is blocking, say \"None.\" That's valuable information too.\n\n### Section 9: Next Steps\n**Job:** Concrete, actionable items. Numbered list with emoji status.\n\nNot aspirational goals — specific things that should happen next.\n\n### Section 10: Aggregate Statistics\n**Job:** Summary numbers table for quick reference.\n\nLOC, file counts, package counts, test coverage, migration counts, CI\u002FCD workflow counts, versions shipped.\n\n---\n\n## IV. How to Fill the Template\n\nRead `references\u002Fcomplete-template.md` for the full, copy-paste-ready template with all sections, placeholders, and HTML comments for guidance.\n\n**The filling process:**\n\n1. **Start with Section 1.** If you can't write the vision in one sentence, you don't understand the project well enough yet. Go back and read more.\n2. **Fill Section 2 next.** The current state table forces you to identify the major areas. This becomes your map for the rest.\n3. **Sections 3-4 require exploration.** Walk the filesystem, read key files, count LOC. This is the most time-consuming part.\n4. **Section 5 requires judgment.** Which 10 files, if deleted, would break the system? Which 10 more would break major features?\n5. **Section 6 requires honesty.** The health assessment is useless if it's all green. Every project has concerns. Find them.\n6. **Sections 7-9 require current knowledge.** Talk to the team, read recent PRs, check the issue tracker.\n7. **Section 10 is verification.** Run `find` and `wc -l` to get real numbers. Don't guess.\n\n---\n\n## V. Best Practices\n\n- **Dot-prefix the file.** Save as `.status.md` to keep it discoverable but out of the way. It complements (doesn't replace) a lightweight `STATUS.md`.\n- **Update incrementally.** After the first write, subsequent updates should diff against the existing document, not regenerate from scratch.\n- **Emoji consistency.** Use the same status key everywhere. Mixing conventions creates noise.\n- **Be concise in tables.** Each table cell should be scannable in under 3 seconds. Full sentences belong in prose sections, not tables.\n- **The directory tree should be 2-3 levels deep** for most directories, deeper only for architecturally significant subtrees.\n- **Statistics will drift.** Within 10% is accurate enough. Note the date so readers know how fresh the numbers are.\n- **Section 4 is optional for simple projects.** If the project has fewer than 50 files, skip semantic clusters and use a flat feature list instead.\n- **Section 5 is optional for small projects.** Below 100 files, importance ranking adds little value.\n\n---\n\n## VI. Adapting the Template\n\nNot every project needs all 10 sections. Here's a sizing guide:\n\n| Project Size | Sections to Include |\n|-------------|-------------------|\n| **Small** (\u003C 50 files) | 1, 2, 3, 6, 7, 9 |\n| **Medium** (50-300 files) | 1, 2, 3, 4 (simplified), 6, 7, 8, 9, 10 |\n| **Large** (300+ files) | All 10 sections |\n| **Monorepo** | All 10, with sub-sections per package\u002Fservice |\n\nFor non-software projects (documentation sites, design systems, data pipelines), adapt the vocabulary but keep the structure. Section 4 clusters might become \"capabilities\" or \"data flows\" instead of \"action verbs.\"\n\n---\n\n## VII. Quality Checklist\n\nBefore delivering the `.status.md`, confirm:\n\n- [ ] Vision statement is present, accurate, and one sentence\n- [ ] Current state table covers every major subsystem\n- [ ] Directory tree is annotated with status emojis\n- [ ] Health assessment is honest (not all green)\n- [ ] Active workstreams reflect actual current work (not aspirations)\n- [ ] Blockers section is truthful (empty or populated, not missing)\n- [ ] Next steps are concrete and actionable (not \"improve things\")\n- [ ] Statistics are programmatically verified (not guessed)\n- [ ] The document reads coherently top-to-bottom\n- [ ] The document is dated with `Last Updated`\n\n## Output\n- `.status.md` at the project root with all applicable sections from the 10-section schema. Section count adapts to project size (small projects use 6 sections; large projects use all 10).\n- The file complements but does not replace a lightweight `STATUS.md` — `.status.md` is the comprehensive agent-facing audit; `STATUS.md` is the human-facing dashboard.\n\n## Examples\n**Scenario 1:** \"Create a project overview before a strategy session\" → `.status.md` produced with all 10 sections. Vision and Purpose anchors everything. Current State table reveals 2 blocked areas. Health assessment honestly flags no CI\u002FCD and 8% test coverage as sustainability concerns.\n**Scenario 2:** \"Prepare a handoff doc for the incoming agent\" → `.status.md` covers a 120-file project. Sections 4 (Semantic Clusters) and 5 (File Importance Ranking) included. Incoming agent reads the document instead of spending 30 minutes on discovery.\n\n## Edge Cases\n- For projects under 50 files, skip Sections 4 and 5 (clusters and importance ranking) — they add little value at small scale, and the overhead of generating them exceeds the benefit.\n- For monorepos, use all 10 sections with sub-sections per package or service under each primary section.\n\n## Anti-Patterns\n- Treating the Current State table as aspirational — the emoji indicators must reflect actual verified state, not what the team wishes were true.\n- Generating statistics from memory or rough estimates — run `find` and `wc -l` to get real numbers; within 10% is accurate enough, but guessing is not.\n","# Status Template Skill\n\n**Version:** 1.0\n**Created:** 2026-02-08\n**Author:** Cruz + Manus (Cowork)\n**Origin:** Elevated from the `repo-status` skill's status template reference, which was itself codified from a live status-writing + file-management + health-audit session.\n**Lineage:** status-writing (heartbeat) + file-management (anatomy) + health-audit (checkup) → repo-status → this standalone skill.\n\n---\n\n## I. The Philosophy: One Document, Three Perspectives\n\nProject status lives in too many places — Slack threads, standup notes, README footers, someone's head. When a new person (or agent) arrives and asks \"where are we?\", the answer is usually scattered, stale, or both.\n\nThis skill produces a single `.status.md` file that answers that question by looking at the project from three angles:\n\n- **Heartbeat (status-writing):** Is it alive? What's moving? What's stuck? Emoji-driven health indicators give an instant pulse check.\n- **Anatomy (file-management):** Where is everything? An annotated directory tree with per-folder status turns the filesystem into a map.\n- **Checkup (health-audit):** How healthy is it? Critical issues, security posture, and sustainability assessment tell you what needs attention.\n\nOne file. Three lenses. Updated over time.\n\n---\n\n## II. When to Use This Skill\n\n- **Writing a status report:** Monthly, per-release, or ad-hoc — this template gives you the structure.\n- **Onboarding someone to a project:** Instead of a 30-minute walkthrough, hand them a `.status.md`.\n- **Preparing a handoff:** Moving a project between teams or agents? This is the context document.\n- **Before a major decision:** Understanding the full state before deciding what to change.\n- **When a project feels opaque:** Structure reduces confusion. The template imposes coherence on complexity.\n- **After running the `repo-status` skill:** This template is Phase 4 of that workflow.\n\n---\n\n## III. The Template Structure\n\nThe status document has 10 sections. Each one has a specific job.\n\n### Section 1: Vision & Purpose\n**Job:** Anchor everything that follows. One sentence + core principles.\n\nWhy it matters: Without a stated purpose, status updates become lists of things. With one, they become a story about progress toward a goal.\n\n```markdown\n## 1. Vision & Purpose\n> [One sentence capturing what the project is and why it exists.]\n**Core Principles:** [3-5 comma-separated principles]\n```\n\n### Section 2: Current State\n**Job:** Instant pulse check. A table of major areas with emoji status and brief notes.\n\nWhy it matters: Someone glancing at this document for 5 seconds should know if things are healthy or on fire. The emoji table achieves this.\n\n```markdown\n## 2. Current State\n| Area | Status | Notes |\n| :--- | :--- | :--- |\n| **[Major Area]** | ✅\u002F?\u002F⚠️\u002F❌ | [One-line note] |\n```\n\n**Status Key:**\n- ✅ Complete\u002FHealthy\n- ? In Progress\n- ⏸️ Paused\n- ⚠️ Concern\n- ❌ Blocked\u002FCritical\n\n### Section 3: Directory Structure\n**Job:** Annotated filesystem map. Every significant directory gets a status emoji and note.\n\nWhy it matters: Most codebases lack a visual map of what's where. An annotated tree is worth a thousand words for spatial orientation.\n\nUse `?` for legacy\u002Fdeprecated directories. Use `—` for empty or minimal ones.\n\n### Section 4: Semantic Clusters\n**Job:** Group components by *what they do*, not where they live.\n\nWhy it matters: This is the behavioral architecture. A feature spans frontend + backend + database + tests. Clusters reveal the system's capabilities as cross-cutting concerns.\n\nIf using semantic clusters, invoke the `semantic-clusters` skill for the full framework. Otherwise, this section can be simplified to a feature list with health assessments.\n\nFor each cluster:\n```markdown\n### [emoji] [VERB] — [Short Description]\n> [One sentence explaining this capability.]\n| Component | Location | Status | LOC |\n|-----------|----------|--------|-----|\n**Health:** [emoji] [assessment]\n**Audit Notes:** [key technical details]\n```\n\n### Section 5: File Importance Ranking\n**Job:** Rank files by criticality so people know what not to break.\n\nWhy it matters: In a 500-file codebase, 10 files are critical, 10 are important, and the rest are supporting. Making this explicit prevents accidental damage to core files.\n\nFour tiers: Critical (system breaks without these), Important (features break), Supporting (graceful degradation), Knowledge (development-time only).\n\n### Section 6: Health Assessment\n**Job:** Honest checkup. Critical issues, security, sustainability.\n\nWhy it matters: This is the health-audit perspective. Every project has blind spots — security gaps, test coverage holes, manual processes that should be automated. This section forces them into the light.\n\nThree categories:\n- **Critical Issues:** Can it build? Critical vulnerabilities? Main branch broken?\n- **Security:** Secrets management, auth, encryption, access control.\n- **Sustainability:** Test coverage, CI\u002FCD, tech debt, documentation freshness.\n\n### Section 7: Active Workstreams\n**Job:** What's being worked on right now, by whom.\n\nA table: `Workstream | Owner | Status | Focus`\n\n### Section 8: Blockers & Dependencies\n**Job:** What's preventing progress. Be ruthlessly honest.\n\nIf nothing is blocking, say \"None.\" That's valuable information too.\n\n### Section 9: Next Steps\n**Job:** Concrete, actionable items. Numbered list with emoji status.\n\nNot aspirational goals — specific things that should happen next.\n\n### Section 10: Aggregate Statistics\n**Job:** Summary numbers table for quick reference.\n\nLOC, file counts, package counts, test coverage, migration counts, CI\u002FCD workflow counts, versions shipped.\n\n---\n\n## IV. How to Fill the Template\n\nRead `references\u002Fcomplete-template.md` for the full, copy-paste-ready template with all sections, placeholders, and HTML comments for guidance.\n\n**The filling process:**\n\n1. **Start with Section 1.** If you can't write the vision in one sentence, you don't understand the project well enough yet. Go back and read more.\n2. **Fill Section 2 next.** The current state table forces you to identify the major areas. This becomes your map for the rest.\n3. **Sections 3-4 require exploration.** Walk the filesystem, read key files, count LOC. This is the most time-consuming part.\n4. **Section 5 requires judgment.** Which 10 files, if deleted, would break the system? Which 10 more would break major features?\n5. **Section 6 requires honesty.** The health assessment is useless if it's all green. Every project has concerns. Find them.\n6. **Sections 7-9 require current knowledge.** Talk to the team, read recent PRs, check the issue tracker.\n7. **Section 10 is verification.** Run `find` and `wc -l` to get real numbers. Don't guess.\n\n---\n\n## V. Best Practices\n\n- **Dot-prefix the file.** Save as `.status.md` to keep it discoverable but out of the way. It complements (doesn't replace) a lightweight `STATUS.md`.\n- **Update incrementally.** After the first write, subsequent updates should diff against the existing document, not regenerate from scratch.\n- **Emoji consistency.** Use the same status key everywhere. Mixing conventions creates noise.\n- **Be concise in tables.** Each table cell should be scannable in under 3 seconds. Full sentences belong in prose sections, not tables.\n- **The directory tree should be 2-3 levels deep** for most directories, deeper only for architecturally significant subtrees.\n- **Statistics will drift.** Within 10% is accurate enough. Note the date so readers know how fresh the numbers are.\n- **Section 4 is optional for simple projects.** If the project has fewer than 50 files, skip semantic clusters and use a flat feature list instead.\n- **Section 5 is optional for small projects.** Below 100 files, importance ranking adds little value.\n\n---\n\n## VI. Adapting the Template\n\nNot every project needs all 10 sections. Here's a sizing guide:\n\n| Project Size | Sections to Include |\n|-------------|-------------------|\n| **Small** (\u003C 50 files) | 1, 2, 3, 6, 7, 9 |\n| **Medium** (50-300 files) | 1, 2, 3, 4 (simplified), 6, 7, 8, 9, 10 |\n| **Large** (300+ files) | All 10 sections |\n| **Monorepo** | All 10, with sub-sections per package\u002Fservice |\n\nFor non-software projects (documentation sites, design systems, data pipelines), adapt the vocabulary but keep the structure. Section 4 clusters might become \"capabilities\" or \"data flows\" instead of \"action verbs.\"\n\n---\n\n## VII. Quality Checklist\n\nBefore delivering the `.status.md`, confirm:\n\n- [ ] Vision statement is present, accurate, and one sentence\n- [ ] Current state table covers every major subsystem\n- [ ] Directory tree is annotated with status emojis\n- [ ] Health assessment is honest (not all green)\n- [ ] Active workstreams reflect actual current work (not aspirations)\n- [ ] Blockers section is truthful (empty or populated, not missing)\n- [ ] Next steps are concrete and actionable (not \"improve things\")\n- [ ] Statistics are programmatically verified (not guessed)\n- [ ] The document reads coherently top-to-bottom\n- [ ] The document is dated with `Last Updated`\n\n## Output\n- `.status.md` at the project root with all applicable sections from the 10-section schema. Section count adapts to project size (small projects use 6 sections; large projects use all 10).\n- The file complements but does not replace a lightweight `STATUS.md` — `.status.md` is the comprehensive agent-facing audit; `STATUS.md` is the human-facing dashboard.\n\n## Examples\n**Scenario 1:** \"Create a project overview before a strategy session\" → `.status.md` produced with all 10 sections. Vision and Purpose anchors everything. Current State table reveals 2 blocked areas. Health assessment honestly flags no CI\u002FCD and 8% test coverage as sustainability concerns.\n**Scenario 2:** \"Prepare a handoff doc for the incoming agent\" → `.status.md` covers a 120-file project. Sections 4 (Semantic Clusters) and 5 (File Importance Ranking) included. Incoming agent reads the document instead of spending 30 minutes on discovery.\n\n## Edge Cases\n- For projects under 50 files, skip Sections 4 and 5 (clusters and importance ranking) — they add little value at small scale, and the overhead of generating them exceeds the benefit.\n- For monorepos, use all 10 sections with sub-sections per package or service under each primary section.\n\n## Anti-Patterns\n- Treating the Current State table as aspirational — the emoji indicators must reflect actual verified state, not what the team wishes were true.\n- Generating statistics from memory or rough estimates — run `find` and `wc -l` to get real numbers; within 10% is accurate enough, but guessing is not.\n",{"name":5,"tier":49,"model":31,"agents":50,"inputs":52,"outputs":58,"category":64,"triggers":65,"description":7,"tool_dependencies":71},1,[51],"primary",[53],{"name":54,"type":55,"required":56,"description":57},"repo_path","string",true,"Path to the repository or project to write status for",[59],{"name":60,"type":61,"format":62,"description":63},"status_file","ref","cas-ref","Comprehensive .status.md using a 10-section schema bridging heartbeat, anatomy, and checkup perspectives","system-health",[66,67,68,69,70],"write a status report","give me the lay of the land","where are we right now","prepare a handoff document","document the current codebase state",[72],"file_system","main","ff07df5fd8f75762c2a131e6e26d297e8ae403ee","plugins\u002Fsystem-health\u002Fskills\u002Fstatus-template",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":82,"prompt":92,"zipAvailable":56},[83,86,89],{"tool":84,"command":85},"npx","npx skills add DojoGenesis\u002Fgateway --skill status-template",{"tool":87,"command":88},"bunx","bunx skills add DojoGenesis\u002Fgateway --skill status-template",{"tool":90,"command":91},"pnpm","pnpm dlx skills add DojoGenesis\u002Fgateway --skill status-template","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fsystem-health\u002Fskills\u002Fstatus-template\u002FSKILL.md",[],[95,114,127,135,173,199],{"skillNo":96,"name":97,"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":98,"categories":99,"keywords":103,"publishedAt":44},"01M6P6J0WYSD1MTGA3ZX6MGGZ5","kata-test-echo","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-test-echo\u002FSKILL.md",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[104,105,106,107,108,109,110,111,112,113],"kata test echo","Echo","test","json","v1","output","input","structured","contracts","schema",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":123,"publishedAt":44},"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",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[124,125,126],"kata plain","prose skill","prose",{"skillNo":128,"name":129,"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":130,"categories":131,"keywords":132,"publishedAt":44},"01M6P6HH6Y7K8K6606MF7VZ1HB","kata-broken","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-broken\u002FSKILL.md",[],[133,134,111,112,105,113,107,106,110,108,109],"kata broken","broken",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":155,"publishedAt":44},"01M6P6GW520QJ03A6K7Y5PWJ52","voice-before-structure","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'.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fvoice-before-structure\u002FSKILL.md",[141,144,147,152],{"categoryNo":142,"categoryName":143,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":153,"categoryName":154,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000036","内容创作者",[156,37,157,158,159,160,161,162,35,163,164,165,166,167,168,169,170,171,172,39],"voice before structure","voice","manifests","ecosystem","false","authoring","structural","artifact","philosophy","design","writing","identity","documentation","create","projects","work","read",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":180,"publishedAt":44},"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",[179],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},[181,182,183,184,185,186,162,187,188,189,190,191,192,193,194,195,196,31,197,198],"system prompt archaeology","system prompt","prompt","system","behavioral","classify","decomposition","wisdom","patterns","engineer","decompose","evidence","ada","analyze","analysis","STRING","true","reverse",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":44},"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",[205],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},[207,208,209,210,211,212,213,28,214,215,216,217,218,163,219,220,221,222,223,26],"automation","session lifecycle automation","session lifecycle","lifecycle","session","markdown","configure","config","delegation","audit","SET","files","solo","across","scheduled","loops","up"]