[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P5P1RN4DFK5633EWHJR6TM":3,"skill-same:01M6P5P1RN4DFK5633EWHJR6TM":110},{"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":89,"commitSha":90,"skillDirectory":91,"forksCount":92,"repositoryHtmlUrl":93,"repositoryHomepageUrl":6,"ownerHtmlUrl":94,"ownerBlogUrl":95,"ownerDescription":6,"updatedAt":96,"install":97,"resources":109},"01M6P5P1RN4DFK5633EWHJR6TM","mcp-server-builder",null,"Scaffolds production-ready MCP servers from OpenAPI specs with schema validation, named tool definitions, and versioning strategy. Use when: 'build MCP server from API', 'create tool server from OpenAPI', 'expose REST API to LLM agent', 'scaffold MCP from spec', 'convert API contract to tools'.","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\u002Fmcp-server-builder\u002FSKILL.md",[18,23,26,31],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000037","律师与法务",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"mcp server","server","builder","MCP","mcp server builder","versioning","for","production-ready","sonnet","URL","create tool","api contract","ready","tool","system","forge","create","python","typescript","directory","2026-11-10 10:12:30",false,"---\nname: mcp-server-builder\nmodel: sonnet\ndescription: \"Scaffolds production-ready MCP servers from OpenAPI specs with schema validation, named tool definitions, and versioning strategy. Use when: 'build MCP server from API', 'create tool server from OpenAPI', 'expose REST API to LLM agent', 'scaffold MCP from spec', 'convert API contract to tools'.\"\ncategory: skill-forge\ntriggers:\n  - \"build MCP server from API\"\n  - \"create tool server from OpenAPI\"\n  - \"expose REST API to LLM agent\"\n  - \"scaffold MCP from spec\"\n  - \"convert API contract to tools\"\ntier: 1\nagents:\n  - \"primary\"\ntool_dependencies:\n  - \"file_system\"\n\ninputs:\n  - name: openapi_spec\n    type: string\n    description: Path or URL to the OpenAPI spec (JSON or YAML) to convert into MCP tool definitions\n    required: true\n  - name: server_name\n    type: string\n    description: Canonical name for the MCP server (used in tool manifests and package naming)\n    required: true\n  - name: language\n    type: string\n    description: Implementation language — \"python\" or \"typescript\"\n    required: false\noutputs:\n  - name: mcp_scaffold\n    type: ref\n    format: directory\n    description: MCP server scaffold with tool manifest (JSON), starter server code (Python or TypeScript), and validation report\n---\n\n# MCP Server Builder\n\nScaffolds production-ready MCP servers from OpenAPI specs. Treats the API contract as the source of truth and generates tool manifests + starter code with quality gates before publication.\n\n## Description\n\nConverts OpenAPI paths\u002Foperations into named MCP tool definitions, generates server scaffolds in Python or TypeScript, enforces naming and description quality, validates manifests against common production failures, and applies a versioning strategy for safe evolution. Distinct from `mcp-cloudflare-builder` (Cloudflare-specific deployment) and `mcp-builder` (general MCP concepts) — this skill is spec-driven and language-agnostic.\n\n## When to Use\n\n- Exposing an internal or external REST API to LLM agents via MCP\n- Replacing brittle browser automation with typed, validated tools\n- Sharing one MCP server across multiple teams or assistants\n- Bootstrapping from an existing OpenAPI spec rather than hand-writing tool definitions\n- Running quality checks before publishing MCP tools to a registry\n\n## Workflow\n\n### Step 1: Parse the OpenAPI Spec\n\nRead the spec and extract:\n- Paths and HTTP methods\n- `operationId` (use as canonical tool name when available)\n- Request parameters and body schemas\n- Response schemas\n- Authentication requirements\n\n### Step 2: Generate Tool Manifest\n\nFor each operation, create an MCP tool definition:\n\n```json\n{\n  \"name\": \"get_user\",\n  \"description\": \"Retrieve a user by ID. Returns full profile including email and role.\",\n  \"inputSchema\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"user_id\": { \"type\": \"string\", \"description\": \"The user's UUID\" }\n    },\n    \"required\": [\"user_id\"]\n  }\n}\n```\n\n**Naming rules:**\n- Use `operationId` when available (preferred)\n- Otherwise derive from method + path: `GET \u002Fusers\u002F{id}` → `get_user`\n- Use snake_case; avoid raw path segments (`get__v1__users___id` is wrong)\n- One intent per tool; avoid mega-tools combining unrelated operations\n\n**Description rules:**\n- Lead with action verb + object\n- Include what the tool returns, not just what it does\n- Note any side effects for mutating operations\n\n### Step 3: Scaffold Server Code\n\nGenerate starter implementation in the chosen language:\n\n**Python (FastMCP):**\n```python\nfrom mcp.server.fastmcp import FastMCP\n\nmcp = FastMCP(\"billing-mcp\")\n\n@mcp.tool()\ndef get_user(user_id: str) -> dict:\n    \"\"\"Retrieve a user by ID. Returns full profile.\"\"\"\n    response = requests.get(f\"{BASE_URL}\u002Fusers\u002F{user_id}\", headers=AUTH_HEADERS)\n    response.raise_for_status()\n    return response.json()\n```\n\n**TypeScript (MCP SDK):**\n```typescript\nimport { McpServer } from \"@modelcontextprotocol\u002Fsdk\u002Fserver\u002Fmcp.js\";\nimport { z } from \"zod\";\n\nconst server = new McpServer({ name: \"billing-mcp\", version: \"1.0.0\" });\n\nserver.tool(\"get_user\", { user_id: z.string() }, async ({ user_id }) => {\n  const res = await fetch(`${BASE_URL}\u002Fusers\u002F${user_id}`, { headers: AUTH_HEADERS });\n  return { content: [{ type: \"text\", text: await res.text() }] };\n});\n```\n\n### Step 4: Validate the Manifest\n\nBefore integration, check for:\n- Duplicate tool names\n- Missing or empty descriptions\n- Parameters with no types\n- Ambiguous schemas (no `required` fields on non-trivial inputs)\n- Tool names that expose secret values\n- Destructive operations without explicit confirmation parameters\n\nFix all validation errors before proceeding.\n\n### Step 5: Apply Auth and Safety Controls\n\n- Store secrets in environment variables, never in tool schemas\n- Allowlist outbound hosts explicitly; do not proxy arbitrary user-provided URLs\n- Return structured errors: `{ \"code\": \"NOT_FOUND\", \"message\": \"...\", \"details\": {...} }`\n- Add explicit confirmation parameters to destructive operations\n- Rate-limit high-cost tools and add request timeouts\n\n### Step 6: Versioning Strategy\n\n- Additive fields only for non-breaking updates\n- Never rename a tool name in-place — introduce a new tool ID for breaking behavior changes\n- Maintain a changelog of tool contract changes per release\n- Validate backward compatibility in CI using strict mode\n\n## Contract Quality Gates\n\nBefore publishing the manifest, confirm:\n\n1. Every tool has a verb-first, clear name\n2. Every description explains intent AND expected result\n3. Every required field is explicitly typed\n4. Destructive actions include a confirmation parameter\n5. Error payload format is consistent across all tools\n6. Validator returns zero errors in strict mode\n\n## Runtime Selection\n\n| Constraint | Choose |\n|-----------|--------|\n| Fast iteration, data-heavy backend | Python |\n| Shared types with JS stack | TypeScript |\n| Single server, simple ops | Python FastMCP |\n| Split domain servers with strict contracts | TypeScript + Zod |\n\n## Common Pitfalls\n\n1. Tool names derived from raw paths: `get__v1__users___id` — fix with clean `operationId`\n2. Missing operation descriptions — agents choose tools poorly without them\n3. Ambiguous schemas with no `required` fields\n4. Mixing transport errors and domain errors in one opaque message\n5. Exposing secret values in tool contracts\n6. Breaking clients by changing schema keys without versioning\n\n## Output\n\nAn MCP server scaffold directory containing:\n- `tool_manifest.json` — all tool definitions with names, descriptions, and schemas\n- `server.py` or `server.ts` — starter implementation with stubs for each tool\n- `CHANGELOG.md` — initial entry for v1.0.0 contract\n- Validation report listing any issues found\n","# MCP Server Builder\n\nScaffolds production-ready MCP servers from OpenAPI specs. Treats the API contract as the source of truth and generates tool manifests + starter code with quality gates before publication.\n\n## Description\n\nConverts OpenAPI paths\u002Foperations into named MCP tool definitions, generates server scaffolds in Python or TypeScript, enforces naming and description quality, validates manifests against common production failures, and applies a versioning strategy for safe evolution. Distinct from `mcp-cloudflare-builder` (Cloudflare-specific deployment) and `mcp-builder` (general MCP concepts) — this skill is spec-driven and language-agnostic.\n\n## When to Use\n\n- Exposing an internal or external REST API to LLM agents via MCP\n- Replacing brittle browser automation with typed, validated tools\n- Sharing one MCP server across multiple teams or assistants\n- Bootstrapping from an existing OpenAPI spec rather than hand-writing tool definitions\n- Running quality checks before publishing MCP tools to a registry\n\n## Workflow\n\n### Step 1: Parse the OpenAPI Spec\n\nRead the spec and extract:\n- Paths and HTTP methods\n- `operationId` (use as canonical tool name when available)\n- Request parameters and body schemas\n- Response schemas\n- Authentication requirements\n\n### Step 2: Generate Tool Manifest\n\nFor each operation, create an MCP tool definition:\n\n```json\n{\n  \"name\": \"get_user\",\n  \"description\": \"Retrieve a user by ID. Returns full profile including email and role.\",\n  \"inputSchema\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"user_id\": { \"type\": \"string\", \"description\": \"The user's UUID\" }\n    },\n    \"required\": [\"user_id\"]\n  }\n}\n```\n\n**Naming rules:**\n- Use `operationId` when available (preferred)\n- Otherwise derive from method + path: `GET \u002Fusers\u002F{id}` → `get_user`\n- Use snake_case; avoid raw path segments (`get__v1__users___id` is wrong)\n- One intent per tool; avoid mega-tools combining unrelated operations\n\n**Description rules:**\n- Lead with action verb + object\n- Include what the tool returns, not just what it does\n- Note any side effects for mutating operations\n\n### Step 3: Scaffold Server Code\n\nGenerate starter implementation in the chosen language:\n\n**Python (FastMCP):**\n```python\nfrom mcp.server.fastmcp import FastMCP\n\nmcp = FastMCP(\"billing-mcp\")\n\n@mcp.tool()\ndef get_user(user_id: str) -> dict:\n    \"\"\"Retrieve a user by ID. Returns full profile.\"\"\"\n    response = requests.get(f\"{BASE_URL}\u002Fusers\u002F{user_id}\", headers=AUTH_HEADERS)\n    response.raise_for_status()\n    return response.json()\n```\n\n**TypeScript (MCP SDK):**\n```typescript\nimport { McpServer } from \"@modelcontextprotocol\u002Fsdk\u002Fserver\u002Fmcp.js\";\nimport { z } from \"zod\";\n\nconst server = new McpServer({ name: \"billing-mcp\", version: \"1.0.0\" });\n\nserver.tool(\"get_user\", { user_id: z.string() }, async ({ user_id }) => {\n  const res = await fetch(`${BASE_URL}\u002Fusers\u002F${user_id}`, { headers: AUTH_HEADERS });\n  return { content: [{ type: \"text\", text: await res.text() }] };\n});\n```\n\n### Step 4: Validate the Manifest\n\nBefore integration, check for:\n- Duplicate tool names\n- Missing or empty descriptions\n- Parameters with no types\n- Ambiguous schemas (no `required` fields on non-trivial inputs)\n- Tool names that expose secret values\n- Destructive operations without explicit confirmation parameters\n\nFix all validation errors before proceeding.\n\n### Step 5: Apply Auth and Safety Controls\n\n- Store secrets in environment variables, never in tool schemas\n- Allowlist outbound hosts explicitly; do not proxy arbitrary user-provided URLs\n- Return structured errors: `{ \"code\": \"NOT_FOUND\", \"message\": \"...\", \"details\": {...} }`\n- Add explicit confirmation parameters to destructive operations\n- Rate-limit high-cost tools and add request timeouts\n\n### Step 6: Versioning Strategy\n\n- Additive fields only for non-breaking updates\n- Never rename a tool name in-place — introduce a new tool ID for breaking behavior changes\n- Maintain a changelog of tool contract changes per release\n- Validate backward compatibility in CI using strict mode\n\n## Contract Quality Gates\n\nBefore publishing the manifest, confirm:\n\n1. Every tool has a verb-first, clear name\n2. Every description explains intent AND expected result\n3. Every required field is explicitly typed\n4. Destructive actions include a confirmation parameter\n5. Error payload format is consistent across all tools\n6. Validator returns zero errors in strict mode\n\n## Runtime Selection\n\n| Constraint | Choose |\n|-----------|--------|\n| Fast iteration, data-heavy backend | Python |\n| Shared types with JS stack | TypeScript |\n| Single server, simple ops | Python FastMCP |\n| Split domain servers with strict contracts | TypeScript + Zod |\n\n## Common Pitfalls\n\n1. Tool names derived from raw paths: `get__v1__users___id` — fix with clean `operationId`\n2. Missing operation descriptions — agents choose tools poorly without them\n3. Ambiguous schemas with no `required` fields\n4. Mixing transport errors and domain errors in one opaque message\n5. Exposing secret values in tool contracts\n6. Breaking clients by changing schema keys without versioning\n\n## Output\n\nAn MCP server scaffold directory containing:\n- `tool_manifest.json` — all tool definitions with names, descriptions, and schemas\n- `server.py` or `server.ts` — starter implementation with stubs for each tool\n- `CHANGELOG.md` — initial entry for v1.0.0 contract\n- Validation report listing any issues found\n",{"name":5,"tier":60,"model":43,"agents":61,"inputs":63,"outputs":75,"category":80,"triggers":81,"description":7,"tool_dependencies":87},1,[62],"primary",[64,69,72],{"name":65,"type":66,"required":67,"description":68},"openapi_spec","string",true,"Path or URL to the OpenAPI spec (JSON or YAML) to convert into MCP tool definitions",{"name":70,"type":66,"required":67,"description":71},"server_name","Canonical name for the MCP server (used in tool manifests and package naming)",{"name":73,"type":66,"required":56,"description":74},"language","Implementation language — \"python\" or \"typescript\"",[76],{"name":77,"type":78,"format":54,"description":79},"mcp_scaffold","ref","MCP server scaffold with tool manifest (JSON), starter server code (Python or TypeScript), and validation report","skill-forge",[82,83,84,85,86],"build MCP server from API","create tool server from OpenAPI","expose REST API to LLM agent","scaffold MCP from spec","convert API contract to tools",[88],"file_system","main","ff07df5fd8f75762c2a131e6e26d297e8ae403ee","plugins\u002Fskill-forge\u002Fskills\u002Fmcp-server-builder",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":98,"prompt":108,"zipAvailable":67},[99,102,105],{"tool":100,"command":101},"npx","npx skills add DojoGenesis\u002Fgateway --skill mcp-server-builder",{"tool":103,"command":104},"bunx","bunx skills add DojoGenesis\u002Fgateway --skill mcp-server-builder",{"tool":106,"command":107},"pnpm","pnpm dlx skills add DojoGenesis\u002Fgateway --skill mcp-server-builder","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fskill-forge\u002Fskills\u002Fmcp-server-builder\u002FSKILL.md",[],[111,130,141,149,187,212],{"skillNo":112,"name":113,"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":114,"categories":115,"keywords":119,"publishedAt":55},"01M6P6J0WYSD1MTGA3ZX6MGGZ5","kata-test-echo","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-test-echo\u002FSKILL.md",[116],{"categoryNo":117,"categoryName":118,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[120,121,122,123,124,125,126,127,128,129],"kata test echo","Echo","test","json","v1","output","input","structured","contracts","schema",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":137,"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",[136],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[138,139,140],"kata plain","prose skill","prose",{"skillNo":142,"name":143,"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":144,"categories":145,"keywords":146,"publishedAt":55},"01M6P6HH6Y7K8K6606MF7VZ1HB","kata-broken","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-broken\u002FSKILL.md",[],[147,148,127,128,121,129,123,122,126,124,125],"kata broken","broken",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":167,"publishedAt":55},"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",[155,158,161,164],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":159,"categoryName":160,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":162,"categoryName":163,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师",{"categoryNo":165,"categoryName":166,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,51,183,184,185,186],"voice before structure","structure","voice","manifests","ecosystem","false","authoring","structural","project","artifact","philosophy","design","writing","identity","documentation","projects","work","read","write",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":194,"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",[193],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[195,196,197,49,198,199,175,200,201,202,203,204,205,206,207,208,209,43,210,211],"system prompt archaeology","system prompt","prompt","behavioral","classify","decomposition","wisdom","patterns","engineer","decompose","evidence","ada","analyze","analysis","STRING","true","reverse",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":219,"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",[218],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[220,221,222,223,224,225,226,54,227,228,229,230,231,177,232,233,234,235,236,237],"automation","session lifecycle automation","session lifecycle","lifecycle","session","markdown","configure","config","delegation","audit","SET","files","solo","across","scheduled","loops","up","template"]