[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P5R2VTMPT582M5MWRV8VRA":3,"skill-same:01M6P5R2VTMPT582M5MWRV8VRA":97},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":76,"commitSha":77,"skillDirectory":78,"forksCount":79,"repositoryHtmlUrl":80,"repositoryHomepageUrl":6,"ownerHtmlUrl":81,"ownerBlogUrl":82,"ownerDescription":6,"updatedAt":83,"install":84,"resources":96},"01M6P5R2VTMPT582M5MWRV8VRA","skill-maintenance",null,"Produces a maintained skills directory with updated names, unified terminology, repaired cross-references, and a git commit documenting every change and what was preserved. Use when: 'update these skill names', 'refactor the skills directory', 'clean up skill references', 'rename this skill', 'audit the skills ecosystem', 'deprecate this skill', 'add version history to a skill'.","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\u002Fskill-forge\u002Fskills\u002Fskill-maintenance\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"skill maintenance","maintenance","up","sonnet","ecosystem","add","rename","maintain","clean","references","directory","Bash","refactor","forge","audit","git","update","documentation","commit","change","2026-11-10 10:12:30",false,"---\nname: skill-maintenance\nmodel: sonnet\ndescription: \"Produces a maintained skills directory with updated names, unified terminology, repaired cross-references, and a git commit documenting every change and what was preserved. Use when: 'update these skill names', 'refactor the skills directory', 'clean up skill references', 'rename this skill', 'audit the skills ecosystem', 'deprecate this skill', 'add version history to a skill'.\"\ncategory: skill-forge\ntriggers:\n  - \"update these skill names\"\n  - \"refactor the skills directory\"\n  - \"clean up skill references\"\n  - \"rename this skill\"\n  - \"audit the skills ecosystem\"\n  - \"deprecate this skill\"\ntier: 1\nagents:\n  - \"primary\"\ntool_dependencies:\n  - \"file_system\"\n  - \"bash\"\n\ninputs:\n  - name: skills_directory\n    type: string\n    description: Path to the skills directory to maintain and audit\n    required: true\noutputs:\n  - name: maintenance_report\n    type: string\n    description: Maintained skills directory with updated names, unified terminology, repaired cross-references, and git commit documentation\n---\n\n# Skill Maintenance Ritual\n\n## I. The Workflow\n\nThis is a 9-step workflow for maintaining the skills directory.\n\n---\n\n### **Step 1: Recognize the Need for Maintenance**\n\n**Goal:** Identify when skill maintenance is needed.\n\n**Triggers:**\n- User requests skill renames or refactors\n- You notice unclear or inconsistent skill names\n- New skills are added that reference outdated names\n- Terminology changes in the broader ecosystem (e.g., tool names, industry standards)\n- Periodic audit schedule (e.g., quarterly)\n\n**Actions:**\n1. Pause and clarify the scope with the user\n2. Ask: What specifically needs to change?\n3. Ask: What should stay the same?\n4. Document the maintenance goal clearly\n\n**Output:** Clear understanding of maintenance scope\n\n**Key Insight:** Always pause and clarify scope before large refactors. Avoid over-refactoring by understanding what actually needs to change.\n\n---\n\n### **Step 2: Read Before Proposing**\n\n**Goal:** Understand what the skills actually do before suggesting changes.\n\n**Actions:**\n1. Read all skills that will be affected by the maintenance\n2. Understand the actual purpose and workflow of each skill\n3. Note any cross-references between skills\n4. Identify patterns in naming or terminology\n\n**Tools:**\n- `file` tool (read action) for each skill\n- Take notes on what each skill does\n\n**Output:** Deep understanding of affected skills\n\n**Key Insight:** Never propose renames or refactors without reading the actual content first. Names should reflect reality, not assumptions.\n\n---\n\n### **Step 3: Propose Clear, Descriptive Changes**\n\n**Goal:** Suggest changes that improve clarity and consistency.\n\n**Actions:**\n1. For renames: Propose names following the \"verb-object\" pattern\n   - Examples: `release-specification`, `implementation-prompt`\n2. For terminology refactors: Identify what should change and what should stay\n3. Create a table showing old → new with rationale\n4. Get user confirmation before proceeding\n\n**Tools:**\n- `message` tool (ask type) to propose and get feedback\n\n**Output:** Agreed-upon changes\n\n**Key Insight:** Good naming is good documentation. Descriptive names reduce cognitive load and make skills immediately understandable.\n\n---\n\n### **Step 4: Execute Renames Systematically**\n\n**Goal:** Rename skill directories and update internal references.\n\n**Actions:**\n1. Rename skill directories using `mv` command\n2. Update `name` field in each SKILL.md frontmatter\n3. Update title (H1 heading) in each SKILL.md\n4. Verify renames with `ls` command\n\n**Tools:**\n- `shell` tool for directory renames\n- `file` tool (edit action) for content updates\n\n**Output:** Renamed skills with updated metadata\n\n**Key Insight:** Rename both the directory and the internal metadata. Inconsistency between directory name and skill name causes confusion.\n\n---\n\n### **Step 5: Search and Catalog References**\n\n**Goal:** Find all instances of terminology or names that need updating.\n\n**Actions:**\n1. Use `grep -r -i \"\u003Cterm>\"` to find all references\n2. Count references by directory: `grep -r -i \"\u003Cterm>\" | cut -d: -f1 | sed 's|^\\.\u002F||' | cut -d\u002F -f1 | sort | uniq -c | sort -rn`\n3. Identify which references need updating (skills directory) vs. which should stay (historical docs)\n4. Confirm scope with user if needed\n\n**Tools:**\n- `shell` tool with grep for searching\n- `wc -l` to count references\n- `cut`, `sort`, `uniq -c` to categorize\n\n**Output:** Catalog of references to update\n\n**Key Insight:** Always catalog before refactoring. Understanding the scope prevents over-refactoring or missing references.\n\n---\n\n### **Step 6: Read Context and Determine Strategy**\n\n**Goal:** Understand which references should change and which should stay.\n\n**Actions:**\n1. Use `match` tool (grep action) to view references with context\n2. Analyze each usage to determine if it should be updated\n3. Create a refactoring strategy:\n   - What should be replaced?\n   - What should be preserved?\n   - What replacement text should be used?\n4. Document the strategy\n\n**Tools:**\n- `match` tool (grep action) with leading\u002Ftrailing context\n\n**Output:** Refactoring strategy document\n\n**Example Strategy:**\n- Replace \"Zenflow prompt\" → \"implementation prompt\"\n- Replace \"Zenflow\" (as executor) → \"implementation agent\"\n- Preserve \"Zenflow\" when listing multiple tools: \"Zenflow, Claude Code, etc.\"\n- Preserve \"Zenflow\" in routing decisions: \"Zenflow: Strategic implementation\"\n\n**Key Insight:** Not all references should be changed. Preserve tool-specific references when contextually appropriate.\n\n---\n\n### **Step 7: Execute Refactor with Batch Edits**\n\n**Goal:** Update all references systematically using batch edits.\n\n**Actions:**\n1. For each affected skill file:\n   - Create a list of find\u002Freplace pairs\n   - Use `file` tool (edit action) with multiple edits\n   - Set `all: true` to replace all occurrences\n2. Verify changes with `grep` after each file\n3. Keep a count of replacements per file\n\n**Tools:**\n- `file` tool (edit action) with multiple edits\n- `shell` tool with grep to verify\n\n**Output:** Updated skill files\n\n**Example Edit:**\n```json\n{\n  \"edits\": [\n    {\"all\": true, \"find\": \"Zenflow prompt\", \"replace\": \"implementation prompt\"},\n    {\"all\": true, \"find\": \"Zenflow\", \"replace\": \"implementation agent\"}\n  ]\n}\n```\n\n**Key Insight:** Batch edits are more efficient than one-by-one replacements. Use `all: true` to replace all occurrences in a single operation.\n\n---\n\n### **Step 8: Verify and Commit**\n\n**Goal:** Ensure all changes are correct and commit with comprehensive documentation.\n\n**Actions:**\n1. Verify no unintended references remain: `grep -i \"\u003Cold term>\" \u003Cdirectory>`\n2. Check git status: `git status`\n3. Stage changes: `git add skills\u002F`\n4. Write comprehensive commit message:\n   - Summary of changes\n   - File-by-file breakdown\n   - Rationale for changes\n   - What was preserved and why\n5. Commit: `git commit -m \"\u003Cmessage>\"`\n6. Push to remote: `git push origin main`\n\n**Tools:**\n- `shell` tool with git commands\n\n**Output:** Committed and pushed changes\n\n**Commit Message Template:**\n```\n\u003CAction> in skills directory\n\n\u003CSummary paragraph>\n\nChanges:\n- \u003Cfile1> (\u003CN> replacements)\n  - \u003Cchange 1>\n  - \u003Cchange 2>\n  \n- \u003Cfile2> (\u003CN> replacements)\n  - \u003Cchange 1>\n\nKept \u003Cterm> only when:\n- \u003Ccontext 1>\n- \u003Ccontext 2>\n\n\u003CRationale paragraph>\n```\n\n**Key Insight:** Comprehensive commit messages are documentation. Future maintainers need to understand *why* changes were made, not just *what* changed.\n\n---\n\n### **Step 9: Document the Process**\n\n**Goal:** Create summary documents for future reference.\n\n**Actions:**\n1. Create a summary document with:\n   - Overview of changes\n   - Refactoring strategy\n   - Files modified\n   - Benefits of the changes\n   - Reflection on the process\n2. Deliver summary to user with `message` tool\n\n**Tools:**\n- `file` tool (write action)\n- `message` tool (result type)\n\n**Output:** Documentation for future reference\n\n**Key Insight:** Document the process immediately after completing it. Details fade quickly from memory.\n\n## Output\n\n- Renamed skill directories with updated `name` field and H1 heading in each SKILL.md\n- All cross-references updated to the new names or terminology\n- Zero stale references remaining (verified by grep)\n- A git commit with a structured message: what changed, why, what was preserved\n- Optional: a summary document delivered to the user if the scope was large\n\n## Examples\n\n**Scenario 1:** \"Rename `zenflow-prompt` to `implementation-prompt` and update all references\" → Read the skill, propose the rename following verb-object pattern, execute directory mv + metadata update, grep for all cross-references, batch-edit and verify, commit with per-file replacement counts.\n\n**Scenario 2:** \"Deprecate `old-pipeline` skill — it's been replaced by `batch-normalize-and-package`\" → Add a `deprecated: true` field to frontmatter, add a deprecation notice at the top of the body pointing to the replacement, update any skills that link to it, commit.\n\n## Edge Cases\n\n- User requests a rename but the new name is already taken by another skill — surface the conflict, propose a resolution, and get confirmation before executing\n- Terminology refactor touches historical documents (retrospectives, plans) outside the skills directory — catalog them but do not change them unless the user explicitly expands the scope\n- A skill has no cross-references in the rest of the directory — rename is safe; note this in the commit message\n- User wants to \"clean up\" a skill without changing its name — treat as in-place refactoring: read, propose specific changes, get confirmation, then edit\n\n## Anti-Patterns\n\n- **Over-refactoring:** Changing references that are contextually appropriate (e.g., tool-specific mentions in routing docs) because they happen to match the search term — always read the surrounding context before replacing\n- **Proposing without reading:** Suggesting renames based on the directory name alone without reading what the skill actually does — names should reflect reality, not assumptions\n- **Relying on memory for references:** Skipping grep and trusting recall to find all instances — always catalog systematically before refactoring\n- **Vague commit messages:** Writing \"updated skills\" without a per-file breakdown — commit messages are the only audit trail for future maintainers\n","# Skill Maintenance Ritual\n\n## I. The Workflow\n\nThis is a 9-step workflow for maintaining the skills directory.\n\n---\n\n### **Step 1: Recognize the Need for Maintenance**\n\n**Goal:** Identify when skill maintenance is needed.\n\n**Triggers:**\n- User requests skill renames or refactors\n- You notice unclear or inconsistent skill names\n- New skills are added that reference outdated names\n- Terminology changes in the broader ecosystem (e.g., tool names, industry standards)\n- Periodic audit schedule (e.g., quarterly)\n\n**Actions:**\n1. Pause and clarify the scope with the user\n2. Ask: What specifically needs to change?\n3. Ask: What should stay the same?\n4. Document the maintenance goal clearly\n\n**Output:** Clear understanding of maintenance scope\n\n**Key Insight:** Always pause and clarify scope before large refactors. Avoid over-refactoring by understanding what actually needs to change.\n\n---\n\n### **Step 2: Read Before Proposing**\n\n**Goal:** Understand what the skills actually do before suggesting changes.\n\n**Actions:**\n1. Read all skills that will be affected by the maintenance\n2. Understand the actual purpose and workflow of each skill\n3. Note any cross-references between skills\n4. Identify patterns in naming or terminology\n\n**Tools:**\n- `file` tool (read action) for each skill\n- Take notes on what each skill does\n\n**Output:** Deep understanding of affected skills\n\n**Key Insight:** Never propose renames or refactors without reading the actual content first. Names should reflect reality, not assumptions.\n\n---\n\n### **Step 3: Propose Clear, Descriptive Changes**\n\n**Goal:** Suggest changes that improve clarity and consistency.\n\n**Actions:**\n1. For renames: Propose names following the \"verb-object\" pattern\n   - Examples: `release-specification`, `implementation-prompt`\n2. For terminology refactors: Identify what should change and what should stay\n3. Create a table showing old → new with rationale\n4. Get user confirmation before proceeding\n\n**Tools:**\n- `message` tool (ask type) to propose and get feedback\n\n**Output:** Agreed-upon changes\n\n**Key Insight:** Good naming is good documentation. Descriptive names reduce cognitive load and make skills immediately understandable.\n\n---\n\n### **Step 4: Execute Renames Systematically**\n\n**Goal:** Rename skill directories and update internal references.\n\n**Actions:**\n1. Rename skill directories using `mv` command\n2. Update `name` field in each SKILL.md frontmatter\n3. Update title (H1 heading) in each SKILL.md\n4. Verify renames with `ls` command\n\n**Tools:**\n- `shell` tool for directory renames\n- `file` tool (edit action) for content updates\n\n**Output:** Renamed skills with updated metadata\n\n**Key Insight:** Rename both the directory and the internal metadata. Inconsistency between directory name and skill name causes confusion.\n\n---\n\n### **Step 5: Search and Catalog References**\n\n**Goal:** Find all instances of terminology or names that need updating.\n\n**Actions:**\n1. Use `grep -r -i \"\u003Cterm>\"` to find all references\n2. Count references by directory: `grep -r -i \"\u003Cterm>\" | cut -d: -f1 | sed 's|^\\.\u002F||' | cut -d\u002F -f1 | sort | uniq -c | sort -rn`\n3. Identify which references need updating (skills directory) vs. which should stay (historical docs)\n4. Confirm scope with user if needed\n\n**Tools:**\n- `shell` tool with grep for searching\n- `wc -l` to count references\n- `cut`, `sort`, `uniq -c` to categorize\n\n**Output:** Catalog of references to update\n\n**Key Insight:** Always catalog before refactoring. Understanding the scope prevents over-refactoring or missing references.\n\n---\n\n### **Step 6: Read Context and Determine Strategy**\n\n**Goal:** Understand which references should change and which should stay.\n\n**Actions:**\n1. Use `match` tool (grep action) to view references with context\n2. Analyze each usage to determine if it should be updated\n3. Create a refactoring strategy:\n   - What should be replaced?\n   - What should be preserved?\n   - What replacement text should be used?\n4. Document the strategy\n\n**Tools:**\n- `match` tool (grep action) with leading\u002Ftrailing context\n\n**Output:** Refactoring strategy document\n\n**Example Strategy:**\n- Replace \"Zenflow prompt\" → \"implementation prompt\"\n- Replace \"Zenflow\" (as executor) → \"implementation agent\"\n- Preserve \"Zenflow\" when listing multiple tools: \"Zenflow, Claude Code, etc.\"\n- Preserve \"Zenflow\" in routing decisions: \"Zenflow: Strategic implementation\"\n\n**Key Insight:** Not all references should be changed. Preserve tool-specific references when contextually appropriate.\n\n---\n\n### **Step 7: Execute Refactor with Batch Edits**\n\n**Goal:** Update all references systematically using batch edits.\n\n**Actions:**\n1. For each affected skill file:\n   - Create a list of find\u002Freplace pairs\n   - Use `file` tool (edit action) with multiple edits\n   - Set `all: true` to replace all occurrences\n2. Verify changes with `grep` after each file\n3. Keep a count of replacements per file\n\n**Tools:**\n- `file` tool (edit action) with multiple edits\n- `shell` tool with grep to verify\n\n**Output:** Updated skill files\n\n**Example Edit:**\n```json\n{\n  \"edits\": [\n    {\"all\": true, \"find\": \"Zenflow prompt\", \"replace\": \"implementation prompt\"},\n    {\"all\": true, \"find\": \"Zenflow\", \"replace\": \"implementation agent\"}\n  ]\n}\n```\n\n**Key Insight:** Batch edits are more efficient than one-by-one replacements. Use `all: true` to replace all occurrences in a single operation.\n\n---\n\n### **Step 8: Verify and Commit**\n\n**Goal:** Ensure all changes are correct and commit with comprehensive documentation.\n\n**Actions:**\n1. Verify no unintended references remain: `grep -i \"\u003Cold term>\" \u003Cdirectory>`\n2. Check git status: `git status`\n3. Stage changes: `git add skills\u002F`\n4. Write comprehensive commit message:\n   - Summary of changes\n   - File-by-file breakdown\n   - Rationale for changes\n   - What was preserved and why\n5. Commit: `git commit -m \"\u003Cmessage>\"`\n6. Push to remote: `git push origin main`\n\n**Tools:**\n- `shell` tool with git commands\n\n**Output:** Committed and pushed changes\n\n**Commit Message Template:**\n```\n\u003CAction> in skills directory\n\n\u003CSummary paragraph>\n\nChanges:\n- \u003Cfile1> (\u003CN> replacements)\n  - \u003Cchange 1>\n  - \u003Cchange 2>\n  \n- \u003Cfile2> (\u003CN> replacements)\n  - \u003Cchange 1>\n\nKept \u003Cterm> only when:\n- \u003Ccontext 1>\n- \u003Ccontext 2>\n\n\u003CRationale paragraph>\n```\n\n**Key Insight:** Comprehensive commit messages are documentation. Future maintainers need to understand *why* changes were made, not just *what* changed.\n\n---\n\n### **Step 9: Document the Process**\n\n**Goal:** Create summary documents for future reference.\n\n**Actions:**\n1. Create a summary document with:\n   - Overview of changes\n   - Refactoring strategy\n   - Files modified\n   - Benefits of the changes\n   - Reflection on the process\n2. Deliver summary to user with `message` tool\n\n**Tools:**\n- `file` tool (write action)\n- `message` tool (result type)\n\n**Output:** Documentation for future reference\n\n**Key Insight:** Document the process immediately after completing it. Details fade quickly from memory.\n\n## Output\n\n- Renamed skill directories with updated `name` field and H1 heading in each SKILL.md\n- All cross-references updated to the new names or terminology\n- Zero stale references remaining (verified by grep)\n- A git commit with a structured message: what changed, why, what was preserved\n- Optional: a summary document delivered to the user if the scope was large\n\n## Examples\n\n**Scenario 1:** \"Rename `zenflow-prompt` to `implementation-prompt` and update all references\" → Read the skill, propose the rename following verb-object pattern, execute directory mv + metadata update, grep for all cross-references, batch-edit and verify, commit with per-file replacement counts.\n\n**Scenario 2:** \"Deprecate `old-pipeline` skill — it's been replaced by `batch-normalize-and-package`\" → Add a `deprecated: true` field to frontmatter, add a deprecation notice at the top of the body pointing to the replacement, update any skills that link to it, commit.\n\n## Edge Cases\n\n- User requests a rename but the new name is already taken by another skill — surface the conflict, propose a resolution, and get confirmation before executing\n- Terminology refactor touches historical documents (retrospectives, plans) outside the skills directory — catalog them but do not change them unless the user explicitly expands the scope\n- A skill has no cross-references in the rest of the directory — rename is safe; note this in the commit message\n- User wants to \"clean up\" a skill without changing its name — treat as in-place refactoring: read, propose specific changes, get confirmation, then edit\n\n## Anti-Patterns\n\n- **Over-refactoring:** Changing references that are contextually appropriate (e.g., tool-specific mentions in routing docs) because they happen to match the search term — always read the surrounding context before replacing\n- **Proposing without reading:** Suggesting renames based on the directory name alone without reading what the skill actually does — names should reflect reality, not assumptions\n- **Relying on memory for references:** Skipping grep and trusting recall to find all instances — always catalog systematically before refactoring\n- **Vague commit messages:** Writing \"updated skills\" without a per-file breakdown — commit messages are the only audit trail for future maintainers\n",{"name":5,"tier":52,"model":30,"agents":53,"inputs":55,"outputs":61,"category":65,"triggers":66,"description":7,"tool_dependencies":73},1,[54],"primary",[56],{"name":57,"type":58,"required":59,"description":60},"skills_directory","string",true,"Path to the skills directory to maintain and audit",[62],{"name":63,"type":58,"description":64},"maintenance_report","Maintained skills directory with updated names, unified terminology, repaired cross-references, and git commit documentation","skill-forge",[67,68,69,70,71,72],"update these skill names","refactor the skills directory","clean up skill references","rename this skill","audit the skills ecosystem","deprecate this skill",[74,75],"file_system","bash","main","ff07df5fd8f75762c2a131e6e26d297e8ae403ee","plugins\u002Fskill-forge\u002Fskills\u002Fskill-maintenance",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":85,"prompt":95,"zipAvailable":59},[86,89,92],{"tool":87,"command":88},"npx","npx skills add DojoGenesis\u002Fgateway --skill skill-maintenance",{"tool":90,"command":91},"bunx","bunx skills add DojoGenesis\u002Fgateway --skill skill-maintenance",{"tool":93,"command":94},"pnpm","pnpm dlx skills add DojoGenesis\u002Fgateway --skill skill-maintenance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fskill-forge\u002Fskills\u002Fskill-maintenance\u002FSKILL.md",[],[98,117,128,136,175,201],{"skillNo":99,"name":100,"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":101,"categories":102,"keywords":106,"publishedAt":47},"01M6P6J0WYSD1MTGA3ZX6MGGZ5","kata-test-echo","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-test-echo\u002FSKILL.md",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[107,108,109,110,111,112,113,114,115,116],"kata test echo","Echo","test","json","v1","output","input","structured","contracts","schema",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":124,"publishedAt":47},"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",[123],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[125,126,127],"kata plain","prose skill","prose",{"skillNo":129,"name":130,"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":131,"categories":132,"keywords":133,"publishedAt":47},"01M6P6HH6Y7K8K6606MF7VZ1HB","kata-broken","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-broken\u002FSKILL.md",[],[134,135,114,115,108,116,110,109,113,111,112],"kata broken","broken",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":156,"publishedAt":47},"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",[142,145,148,153],{"categoryNo":143,"categoryName":144,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":146,"categoryName":147,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":154,"categoryName":155,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000036","内容创作者",[157,158,159,160,31,161,162,163,164,165,166,167,168,169,44,170,171,172,173,174],"voice before structure","structure","voice","manifests","false","authoring","structural","project","artifact","philosophy","design","writing","identity","create","projects","work","read","write",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":47},"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",[181],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[183,184,185,186,187,188,163,189,190,191,192,193,194,195,196,197,198,30,199,200],"system prompt archaeology","system prompt","prompt","system","behavioral","classify","decomposition","wisdom","patterns","engineer","decompose","evidence","ada","analyze","analysis","STRING","true","reverse",{"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":47},"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",[207],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[209,210,211,212,213,214,215,37,216,217,41,218,219,165,220,221,222,223,29,224],"automation","session lifecycle automation","session lifecycle","lifecycle","session","markdown","configure","config","delegation","SET","files","solo","across","scheduled","loops","template"]