[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NVFDKG765KWCW6DZP2Q2QZ":3,"skill-same:01M6NVFDKG765KWCW6DZP2Q2QZ":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6NVFDKG765KWCW6DZP2Q2QZ","team-shape",null,"Assess team structure against Skelton's Team Topologies. Evaluate cognitive load, interaction modes, and Conway's Law alignment.","haabe\u002Fmycelium","haabe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2988921?v=4","01M6NTRKFVVHQG4RF09EB5FRB4","Håvard Bartnes","01M6NTRKKSM94X8BRYCYE2D80Y",52,"MIT","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Fplugins\u002Fmycelium\u002Fskills\u002Fteam-shape\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"team shape","team","shape","structure","modes","load","standalone","team structure","assess","interaction","gates","mycelium","canvas","alignment","use","install","harness","framework","state","run","2026-11-10 10:12:30",false,"---\nname: team-shape\ndescription: \"Assess team structure against Skelton's Team Topologies. Evaluate cognitive load, interaction modes, and Conway's Law alignment.\"\nmetadata:\n  instruction_budget: \"26\"\n  framework_dependency: \"mycelium\"\n  framework_dependency_note: \"This skill is designed to run within the Mycelium framework (https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: \u002Fplugin install mycelium@haabe-mycelium.\"\n---\n\n# Team Shape Assessment\n\nEvaluate organizational design for fast flow. Source: Skelton & Pais, *Team Topologies*,\n**2nd edition (IT Revolution, 23 Sept 2025, ISBN 9781966280002)**.\n\n**Model re-verified against primary sources 2026-09-01** — teamtopologies.com\u002Fkey-concepts, the\n2nd-edition publisher page, and the 2026 AI material (QCon London keynote 17 Mar 2026; \"AI ROI\"\nexecutive report 12 Aug 2026). It is still **four** fundamental team types and **three**\ninteraction modes. The authors have added no AI-specific team type, and their stated position is\nthat none is needed. Third parties do propose new ones (SAFe, various blogs) and InfoQ's QCon\nreport names an \"Innovation and Practices Enabling Team\" — read the name: that is a *named\nspecialization of the existing enabling team*, not a fifth fundamental type. Do not add either to\nthe enum in `schemas\u002Fcanvas\u002Fteam-shape.schema.json`.\n\nTwo caveats worth carrying: the 2nd edition adds **platform grouping** (a platform team may itself\nbe one or more teams), and the live site renders the third interaction mode \"Facilitation\" while\nthe book says \"facilitating\" — which is why that enum is deliberately unpinned.\n\n## Preflight: Read target canvas file(s) before any Write\u002FEdit\n\n**Hard rule.** Before issuing `Write` or `Edit` against any `.claude\u002Fcanvas\u002F*.yml`, use the **Read tool** on that file in this session. Claude Code's Read-before-Write check requires the `Read` tool specifically — `cat`\u002F`head`\u002F`grep` via Bash do NOT satisfy it.\n\n**Edit vs Write — different cost profiles** (verified 2026-05-14):\n- **`Edit`** (exact-string replacement): `Read` with `limit: 1` satisfies the check at ~50 tokens. State-tracking is per-file, not per-byte — subsequent `Edit` calls work anywhere in the file. Use this for partial updates against large canvas files (e.g., `purpose.yml` at 800+ lines).\n- **`Write`** (full replacement): do a **full Read** first. Write obliterates the file; you should see what you're about to replace. The `limit:1` shortcut is *not* appropriate here.\n\n**ID-bearing entries — scan the ID space before assigning** (added 2026-05-15, v0.23.19): When adding a new component, opportunity, solution, or any other ID-bearing entry to a canvas file, run a Bash grep first to confirm the next ID in your prefix sequence is actually free:\n\n```\ngrep -o \"\u003Cprefix>-[0-9][0-9]*\" .claude\u002Fcanvas\u002F\u003Cfile>.yml | sort -u -t- -k2 -n | tail -3\n```\n\nReplace `\u003Cprefix>` with the canvas's ID prefix (`comp` for landscape, `opp` for opportunities, `sol` for solutions, `ht` for human-tasks, etc.). Then pick the next free integer, **matching the zero-padding already used in that file**. The sort is NUMERIC (`-t- -k2 -n`) rather than lexical, and that is not pedantry: a plain `sort -u` orders `ht-1` after `ht-080`, so on a canvas with inconsistent padding it reports the wrong maximum and the next ID collides. Verified on the dogfood repo 2026-08-13, where lexical sort returned `ht-1` as the highest human-task ID against an actual `ht-080`. `grep -o` is also deliberate: it matches IDs wherever they appear, including cross-references and prose, so an ID that was promised somewhere but not yet defined is not handed out twice. `validate_canvas.py` has a per-file duplicate-ID check (it reports `duplicate id '\u003Cid>'`) that catches the failure on CI, but a duplicate can persist in the working tree for days if CI isn't run between edit and discovery; that happened on 2026-05-15, when a duplicate ID was created in `landscape.yml`.\n\nOriginal failure mode: anti-pattern #7 instance #5, 2026-05-09 — agent conflated Bash `head` with the Read tool, lost ~14k tokens to a Write-fail → remedial-full-Read → re-Write loop. The `limit:1` discipline (graduated 2026-05-14, v0.23.18) prevents the second-order cost where the agent *correctly* follows the rule but full-Reads every time. The ID-scan discipline (graduated 2026-05-15, v0.23.19) prevents the related class where the agent reads enough of the file to satisfy the Edit check but not enough to see existing ID assignments — kin to anti-pattern #8 (Stale State Read).\n\nIf this skill writes to multiple canvas files, register each one first (limit:1 for Edit-only paths; full Read for Write paths) AND ID-scan any prefix you intend to assign.\n\nSee `${CLAUDE_PLUGIN_ROOT}\u002Fengine\u002Fagent-operating-contract.md` *Canvas writes — Read before Write* for the canonical rule.\n\n## Assessment Workflow\n\n### 1. Map Current Teams\nFor each team, classify:\n- **Stream-aligned**: Owns a user journey or business domain (most teams should be this)\n- **Enabling**: Helps other teams acquire capabilities (temporary engagement)\n- **Complicated subsystem**: Deep specialist knowledge (only when cognitive load justifies)\n- **Platform**: Internal product that reduces cognitive load for stream-aligned teams\n\n### 2. Evaluate Cognitive Load\nFor each team, assess:\n- **Intrinsic load**: Problem complexity (can't reduce, only manage)\n- **Extraneous load**: Bad tools\u002Fprocesses (SHOULD reduce -- platform teams help here)\n- **Germane load**: Learning new relevant things (encourage)\n- If team is overloaded: shrink domain, move complexity to platform, or split\n\n### 3. Audit Interaction Modes\nBetween each pair of collaborating teams:\n- **Collaboration**: Working closely together (time-box this -- it's expensive)\n- **X-as-a-Service**: Consuming\u002Fproviding via API (ideal steady state)\n- **Facilitating**: Helping another team learn (enabling teams do this)\n\n### 4. Conway's Law Check\n\nConway's Law (1968): \"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's **communication** structure.\" Note: it's communication structures, not org chart hierarchy — two teams in the same org with poor communication will still produce fragmented systems.\n\n**Inverse Conway Maneuver** (James Lewis, popularized by Skelton & Pais): Deliberately design team communication structures to match the desired system architecture, rather than letting architecture drift to match existing teams.\n\n- Does architecture mirror team structure intentionally?\n- Do team boundaries align with security boundaries?\n- Do team APIs match system APIs?\n- If architecture doesn't match team structure: is the mismatch intentional or a Conway's Law drift?\n\n### 4b. Fracture Planes (Skelton & Pais)\n\nWhen a team's cognitive load exceeds capacity, use fracture planes to identify the cleanest split point. The fracture plane that aligns with the most criteria wins:\n\n| Fracture Plane | Description |\n|---|---|\n| Business domain | DDD bounded context boundary |\n| Regulatory compliance | Different compliance requirements = different teams |\n| Change cadence | Fast-moving vs stable components |\n| Team location | Co-located vs distributed |\n| Technology | Different tech stacks |\n| User personas | Different user segments |\n| Risk | High-risk vs low-risk components |\n| Performance isolation | Components with different scaling\u002Flatency requirements |\n\n*Source: Skelton & Pais (Team Topologies, Chapter 6)*\n\n### 5. Recommendations\n- Teams without clear type -> needs redesign\n- Collaboration lasting > 1 quarter -> should evolve to X-as-a-Service\n- Stream-aligned team with > 2 cross-team dependencies -> architecture needs decoupling\n- Cognitive load exceeding capacity -> use fracture planes to identify split point\n\n### 5. Bounded Context Alignment (DDD)\nIf the product has multiple domains or services:\n- Are bounded contexts identified? (Check .claude\u002Fcanvas\u002Fbounded-contexts.yml)\n- Does each stream-aligned team own a coherent bounded context?\n- If a context is split across teams: handoff friction. Fix team boundaries.\n- If a team owns unrelated contexts: cognitive overload. Split the team or contexts.\n- Context map relationships should match team interaction modes:\n  Partnership = Collaboration, Customer-Supplier = X-as-a-Service, ACL = translation layer\n*Source: Evans (DDD), \"Architecture for Flow\" (DDD + Wardley + Team Topologies)*\n\n### 6. Capability Gap Diagnosis (DASA)\nWhen DORA metrics indicate capability gaps, use the DASA DevOps Competency Framework's 12 skill areas to identify which team skills need development (e.g., courage, teambuilding, continuous improvement, business value optimization).\n\n## Bounded Agency (Skelton, 2025-2026)\n\nSkelton's \"Infrastructure for Agency\" framing describes how organizations should provide **boundaries that enable autonomy** rather than control that restricts it. Mycelium implements bounded agency for AI agents using the same structural principles:\n\n| Skelton concept | Mycelium mechanism |\n|---|---|\n| Boundaries that enable | Guardrails (BLOCK\u002FREVIEW\u002FNUDGE — constrain without micromanaging) |\n| Shared state | Canvas (single source of truth every agent reads; only the lead agent writes it, and on Claude Code a subagent's write is refused) |\n| Stable interfaces | Theory gates (predictable checkpoints with explicit pass\u002Ffail) |\n| Aligned domains | Diamonds (scoped units of work with clear ownership) |\n| Bounded workers | Fan-out agents (isolated worktrees, scoped mandate, report back) |\n\nAgency without boundaries produces chaos; boundaries without agency produces bureaucracy. The target is the middle.\n\n*Source: Skelton (Infrastructure for Agency, 2025-2026)*\n\n## Output\n\n- Update `.claude\u002Fcanvas\u002Fteam-shape.yml` and `.claude\u002Fcanvas\u002Fbounded-contexts.yml` with assessment results.\n- **APPEND** a `### Team Shape Assessment` entry to `.claude\u002Fharness\u002Fdecision-log.md` with: team types identified, cognitive load findings, Conway alignment, recommendations. (MANDATORY per G-P4)\n\n## Postflight: Verify-After-Write (claim matches state)\n\n**Hard rule** (per the operating contract's Communication Rules, anti-pattern #7 *write-narration-verification* — mechanism Check 42, graduated v0.39.18; enforced surface expanded to this skill v0.44.0). This skill mandates multi-field canvas updates. Before narrating \"updated \u002F wrote \u002F refreshed [canvas]\" in any user-facing summary, RE-READ the value fields this skill's MANDATORY says to update and confirm they actually changed — not just `_meta.last_validated` or a freshness stamp. Each field you claim to have updated must reflect its new value. The symmetric half of the Read-before-Write Preflight: that one protects what gets read before a write; this one protects that the write matches the claim. Worked failures: 2026-06-05 #18 (`\u002Fdora-check` narrated \"updated\" with value fields unchanged) + #19 (`\u002Fretrospective` left a cycle-history aggregate un-propagated).\n","# Team Shape Assessment\n\nEvaluate organizational design for fast flow. Source: Skelton & Pais, *Team Topologies*,\n**2nd edition (IT Revolution, 23 Sept 2025, ISBN 9781966280002)**.\n\n**Model re-verified against primary sources 2026-09-01** — teamtopologies.com\u002Fkey-concepts, the\n2nd-edition publisher page, and the 2026 AI material (QCon London keynote 17 Mar 2026; \"AI ROI\"\nexecutive report 12 Aug 2026). It is still **four** fundamental team types and **three**\ninteraction modes. The authors have added no AI-specific team type, and their stated position is\nthat none is needed. Third parties do propose new ones (SAFe, various blogs) and InfoQ's QCon\nreport names an \"Innovation and Practices Enabling Team\" — read the name: that is a *named\nspecialization of the existing enabling team*, not a fifth fundamental type. Do not add either to\nthe enum in `schemas\u002Fcanvas\u002Fteam-shape.schema.json`.\n\nTwo caveats worth carrying: the 2nd edition adds **platform grouping** (a platform team may itself\nbe one or more teams), and the live site renders the third interaction mode \"Facilitation\" while\nthe book says \"facilitating\" — which is why that enum is deliberately unpinned.\n\n## Preflight: Read target canvas file(s) before any Write\u002FEdit\n\n**Hard rule.** Before issuing `Write` or `Edit` against any `.claude\u002Fcanvas\u002F*.yml`, use the **Read tool** on that file in this session. Claude Code's Read-before-Write check requires the `Read` tool specifically — `cat`\u002F`head`\u002F`grep` via Bash do NOT satisfy it.\n\n**Edit vs Write — different cost profiles** (verified 2026-05-14):\n- **`Edit`** (exact-string replacement): `Read` with `limit: 1` satisfies the check at ~50 tokens. State-tracking is per-file, not per-byte — subsequent `Edit` calls work anywhere in the file. Use this for partial updates against large canvas files (e.g., `purpose.yml` at 800+ lines).\n- **`Write`** (full replacement): do a **full Read** first. Write obliterates the file; you should see what you're about to replace. The `limit:1` shortcut is *not* appropriate here.\n\n**ID-bearing entries — scan the ID space before assigning** (added 2026-05-15, v0.23.19): When adding a new component, opportunity, solution, or any other ID-bearing entry to a canvas file, run a Bash grep first to confirm the next ID in your prefix sequence is actually free:\n\n```\ngrep -o \"\u003Cprefix>-[0-9][0-9]*\" .claude\u002Fcanvas\u002F\u003Cfile>.yml | sort -u -t- -k2 -n | tail -3\n```\n\nReplace `\u003Cprefix>` with the canvas's ID prefix (`comp` for landscape, `opp` for opportunities, `sol` for solutions, `ht` for human-tasks, etc.). Then pick the next free integer, **matching the zero-padding already used in that file**. The sort is NUMERIC (`-t- -k2 -n`) rather than lexical, and that is not pedantry: a plain `sort -u` orders `ht-1` after `ht-080`, so on a canvas with inconsistent padding it reports the wrong maximum and the next ID collides. Verified on the dogfood repo 2026-08-13, where lexical sort returned `ht-1` as the highest human-task ID against an actual `ht-080`. `grep -o` is also deliberate: it matches IDs wherever they appear, including cross-references and prose, so an ID that was promised somewhere but not yet defined is not handed out twice. `validate_canvas.py` has a per-file duplicate-ID check (it reports `duplicate id '\u003Cid>'`) that catches the failure on CI, but a duplicate can persist in the working tree for days if CI isn't run between edit and discovery; that happened on 2026-05-15, when a duplicate ID was created in `landscape.yml`.\n\nOriginal failure mode: anti-pattern #7 instance #5, 2026-05-09 — agent conflated Bash `head` with the Read tool, lost ~14k tokens to a Write-fail → remedial-full-Read → re-Write loop. The `limit:1` discipline (graduated 2026-05-14, v0.23.18) prevents the second-order cost where the agent *correctly* follows the rule but full-Reads every time. The ID-scan discipline (graduated 2026-05-15, v0.23.19) prevents the related class where the agent reads enough of the file to satisfy the Edit check but not enough to see existing ID assignments — kin to anti-pattern #8 (Stale State Read).\n\nIf this skill writes to multiple canvas files, register each one first (limit:1 for Edit-only paths; full Read for Write paths) AND ID-scan any prefix you intend to assign.\n\nSee `${CLAUDE_PLUGIN_ROOT}\u002Fengine\u002Fagent-operating-contract.md` *Canvas writes — Read before Write* for the canonical rule.\n\n## Assessment Workflow\n\n### 1. Map Current Teams\nFor each team, classify:\n- **Stream-aligned**: Owns a user journey or business domain (most teams should be this)\n- **Enabling**: Helps other teams acquire capabilities (temporary engagement)\n- **Complicated subsystem**: Deep specialist knowledge (only when cognitive load justifies)\n- **Platform**: Internal product that reduces cognitive load for stream-aligned teams\n\n### 2. Evaluate Cognitive Load\nFor each team, assess:\n- **Intrinsic load**: Problem complexity (can't reduce, only manage)\n- **Extraneous load**: Bad tools\u002Fprocesses (SHOULD reduce -- platform teams help here)\n- **Germane load**: Learning new relevant things (encourage)\n- If team is overloaded: shrink domain, move complexity to platform, or split\n\n### 3. Audit Interaction Modes\nBetween each pair of collaborating teams:\n- **Collaboration**: Working closely together (time-box this -- it's expensive)\n- **X-as-a-Service**: Consuming\u002Fproviding via API (ideal steady state)\n- **Facilitating**: Helping another team learn (enabling teams do this)\n\n### 4. Conway's Law Check\n\nConway's Law (1968): \"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's **communication** structure.\" Note: it's communication structures, not org chart hierarchy — two teams in the same org with poor communication will still produce fragmented systems.\n\n**Inverse Conway Maneuver** (James Lewis, popularized by Skelton & Pais): Deliberately design team communication structures to match the desired system architecture, rather than letting architecture drift to match existing teams.\n\n- Does architecture mirror team structure intentionally?\n- Do team boundaries align with security boundaries?\n- Do team APIs match system APIs?\n- If architecture doesn't match team structure: is the mismatch intentional or a Conway's Law drift?\n\n### 4b. Fracture Planes (Skelton & Pais)\n\nWhen a team's cognitive load exceeds capacity, use fracture planes to identify the cleanest split point. The fracture plane that aligns with the most criteria wins:\n\n| Fracture Plane | Description |\n|---|---|\n| Business domain | DDD bounded context boundary |\n| Regulatory compliance | Different compliance requirements = different teams |\n| Change cadence | Fast-moving vs stable components |\n| Team location | Co-located vs distributed |\n| Technology | Different tech stacks |\n| User personas | Different user segments |\n| Risk | High-risk vs low-risk components |\n| Performance isolation | Components with different scaling\u002Flatency requirements |\n\n*Source: Skelton & Pais (Team Topologies, Chapter 6)*\n\n### 5. Recommendations\n- Teams without clear type -> needs redesign\n- Collaboration lasting > 1 quarter -> should evolve to X-as-a-Service\n- Stream-aligned team with > 2 cross-team dependencies -> architecture needs decoupling\n- Cognitive load exceeding capacity -> use fracture planes to identify split point\n\n### 5. Bounded Context Alignment (DDD)\nIf the product has multiple domains or services:\n- Are bounded contexts identified? (Check .claude\u002Fcanvas\u002Fbounded-contexts.yml)\n- Does each stream-aligned team own a coherent bounded context?\n- If a context is split across teams: handoff friction. Fix team boundaries.\n- If a team owns unrelated contexts: cognitive overload. Split the team or contexts.\n- Context map relationships should match team interaction modes:\n  Partnership = Collaboration, Customer-Supplier = X-as-a-Service, ACL = translation layer\n*Source: Evans (DDD), \"Architecture for Flow\" (DDD + Wardley + Team Topologies)*\n\n### 6. Capability Gap Diagnosis (DASA)\nWhen DORA metrics indicate capability gaps, use the DASA DevOps Competency Framework's 12 skill areas to identify which team skills need development (e.g., courage, teambuilding, continuous improvement, business value optimization).\n\n## Bounded Agency (Skelton, 2025-2026)\n\nSkelton's \"Infrastructure for Agency\" framing describes how organizations should provide **boundaries that enable autonomy** rather than control that restricts it. Mycelium implements bounded agency for AI agents using the same structural principles:\n\n| Skelton concept | Mycelium mechanism |\n|---|---|\n| Boundaries that enable | Guardrails (BLOCK\u002FREVIEW\u002FNUDGE — constrain without micromanaging) |\n| Shared state | Canvas (single source of truth every agent reads; only the lead agent writes it, and on Claude Code a subagent's write is refused) |\n| Stable interfaces | Theory gates (predictable checkpoints with explicit pass\u002Ffail) |\n| Aligned domains | Diamonds (scoped units of work with clear ownership) |\n| Bounded workers | Fan-out agents (isolated worktrees, scoped mandate, report back) |\n\nAgency without boundaries produces chaos; boundaries without agency produces bureaucracy. The target is the middle.\n\n*Source: Skelton (Infrastructure for Agency, 2025-2026)*\n\n## Output\n\n- Update `.claude\u002Fcanvas\u002Fteam-shape.yml` and `.claude\u002Fcanvas\u002Fbounded-contexts.yml` with assessment results.\n- **APPEND** a `### Team Shape Assessment` entry to `.claude\u002Fharness\u002Fdecision-log.md` with: team types identified, cognitive load findings, Conway alignment, recommendations. (MANDATORY per G-P4)\n\n## Postflight: Verify-After-Write (claim matches state)\n\n**Hard rule** (per the operating contract's Communication Rules, anti-pattern #7 *write-narration-verification* — mechanism Check 42, graduated v0.39.18; enforced surface expanded to this skill v0.44.0). This skill mandates multi-field canvas updates. Before narrating \"updated \u002F wrote \u002F refreshed [canvas]\" in any user-facing summary, RE-READ the value fields this skill's MANDATORY says to update and confirm they actually changed — not just `_meta.last_validated` or a freshness stamp. Each field you claim to have updated must reflect its new value. The symmetric half of the Read-before-Write Preflight: that one protects what gets read before a write; this one protects that the write matches the claim. Worked failures: 2026-06-05 #18 (`\u002Fdora-check` narrated \"updated\" with value fields unchanged) + #19 (`\u002Fretrospective` left a cycle-history aggregate un-propagated).\n",{"name":5,"metadata":54,"description":7},{"instruction_budget":55,"framework_dependency":40,"framework_dependency_note":56},"26","This skill is designed to run within the Mycelium framework (https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: \u002Fplugin install mycelium@haabe-mycelium.","main","d44421b0667bb71ad515ae7576dfc0f47b00504f","plugins\u002Fmycelium\u002Fskills\u002Fteam-shape",6,"https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Fdocs\u002Fget-started.md","https:\u002F\u002Fgithub.com\u002Fhaabe","https:\u002F\u002Feccera.com\u002F","Building platform tooling for AI-assisted product development.","2026-11-07 04:07:58",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add haabe\u002Fmycelium --skill team-shape",{"tool":73,"command":74},"bunx","bunx skills add haabe\u002Fmycelium --skill team-shape",{"tool":76,"command":77},"pnpm","pnpm dlx skills add haabe\u002Fmycelium --skill team-shape","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Fplugins\u002Fmycelium\u002Fskills\u002Fteam-shape\u002FSKILL.md",true,[],[82,94,107,118,124,131],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":89,"publishedAt":49},"01M6NVR17TVR7WM0MJD1TPY0CW","good_skill","Valid frontmatter.","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_8\u002Fvalid\u002Fplugins\u002Fmycelium\u002Fskills\u002Fgood_skill\u002FSKILL.md",[88],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[90,91,92,93],"good skill","good","frontmatter","valid",{"skillNo":95,"name":96,"nameZh":6,"description":97,"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":101,"publishedAt":49},"01M6NVQPDAP1S4JQ5XFCT6P4PG","bad_skill","Has description but no name field.","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_8\u002Fmissing_name\u002Fplugins\u002Fmycelium\u002Fskills\u002Fbad_skill\u002FSKILL.md",[100],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[102,103,104,105,106],"bad skill","bad","name","but","no name",{"skillNo":108,"name":109,"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":110,"categories":111,"keywords":115,"publishedAt":49},"01M6NVQHEZAMP2JB45CA6Y3G1B","canvas-update","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_5\u002Fmissing_canvas_in_mapping\u002Fplugins\u002Fmycelium\u002Fskills\u002Fcanvas-update\u002FSKILL.md",[112],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[41,116,117],"update","canvas update",{"skillNo":119,"name":109,"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":120,"categories":121,"keywords":123,"publishedAt":49},"01M6NVQDX6GEEHJ48WEPK0EG1Q","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_5\u002Fall_present\u002Fplugins\u002Fmycelium\u002Fskills\u002Fcanvas-update\u002FSKILL.md",[122],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},[41,116,117],{"skillNo":125,"name":126,"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":127,"categories":128,"keywords":129,"publishedAt":49},"01M6NVQ5BH3VN7P9Q185Z2TMRN","ice-score","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_45\u002Fmissing_marker\u002Fplugins\u002Fmycelium\u002Fskills\u002Fice-score\u002FSKILL.md",[],[130],"ice score",{"skillNo":132,"name":133,"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":134,"categories":135,"keywords":136,"publishedAt":49},"01M6NVPTQY2QMDABA1GJW5H1EG","bvssh-check","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_45\u002Fmissing_marker\u002Fplugins\u002Fmycelium\u002Fskills\u002Fbvssh-check\u002FSKILL.md",[],[137,138],"bvssh check","check"]