team-topologies
Organize business and technology teams for fast flow using Skelton & Pais''s "Team Topologies". Use when the user mentions "team topologies", "Conway''s law", "platform team", "stream-aligned team", "team boundaries", "cognitive load", "how should we split teams", "who owns this service", "team dependencies", or "reorg". Also trigger when reorganizing engineering teams, aligning team and service boundaries, splitting a monolith and deciding ownership, reducing cross-team handoffs, or designing an internal platform. Covers the four team types, three interaction modes, the inverse Conway maneuve
npx skills add wondelai/skills --skill team-topologies --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Instructs the agent to help organize teams according to Team Topologies concepts: four team types (stream-aligned, enabling, complicated-subsystem, platform), three interaction modes (collaboration, X-as-a-Service, facilitating), Conway's Law considerations, and cognitive load management. It emphasizes sizing teams to cognitive load, aligning teams to streams of business change, and treating topology as a living architecture decision that evolves with the system and market.
How it works
The skill presents Core Principles and a Framework:
- Conway's Law and the Inverse Conway Maneuver: design architecture first, then shape teams; use architectural review for reorgs.
- The Four Fundamental Team Types: assign streams to stream-aligned teams; use enabling teams to transfer capabilities; keep complicated-subsystem teams to a minimum; employ platform teams to reduce cognitive load.
- The Three Interaction Modes: for every pair, declare one mode (Collaboration, X-as-a-Service, Facilitating) and bound coordination cost.
- Team Cognitive Load and Team-Sized Software: match responsibilities to intrinsic, extraneous, and germane loads; size software to the team and maintain Dunbar-like groupings (~5-9 per team).
- Fracture Planes: split software along natural seams (default: business-domain bounded contexts); avoid monolith-driven splits; ensure each artifact has one owner.
- Platform as a Product and Sensing/Evolving: run the platform as an internal product; start with Thinnest Viable Platform; track adoption and developer experience; revisit topology quarterly based on signals.
When to use it
Triggered when reorganizing engineering teams, aligning team and service boundaries, splitting a monolith and deciding ownership, reducing cross-team handoffs, or designing an internal platform. Use when user mentions terms from the framework (team topologies, Conway's law, platform team, stream-aligned team, team boundaries, cognitive load, how should we split teams, who owns this service, team dependencies, reorg).
What it can touch
Tools allowed: claude-code. The skill guides the agent to analyze organizational structure, propose team types, interaction modes, and fracture planes, and to assess cognitive load and ownership models. It relies on the four team types, three interaction modes, inverse Conway maneuver, and fracture planes to shape recommendations.
Caveats
License: MIT. See license note in the descriptor. No explicit outcomes promised; changes are design recommendations based on the stated framework, not guaranteed results.
# Team Topologies A team-first approach to organization design from Matthew Skelton and Manuel Pais's *Team Topologies*: four fundamental team types, three interaction modes, and deliberate attention to Conway's law and team cognitive load. Use it to structure engineering organizations for fast flow of change — and to keep evolving them as the system, technology, and market shift. ## Core Principle **The team is the unit of delivery, and organizations ship their communication structure.** Conway's law guarantees that system architecture mirrors how teams actually communicate, so team boundaries and interactions must be designed as deliberately as the software itself. Size each team's responsibilities to its cognitive load, align most teams to streams of business change, declare how teams interact, and treat the resulting topology as a living architecture decision that optimizes for fast flow. ## Scoring **Goal: 10/10.** Rate org and team designs 0-10 against the principles below. Report the current score and the specific changes needed to reach 10/10. - **9-10:** Stream-aligned teams own end-to-end slices sized to cognitive load; platform, enabling, and complicated-subsystem teams
- Core Principle
- Scoring
- Framework
- 1. Conway's Law and the Inverse Conway Maneuver
- 2. The Four Fundamental Team Types
- 3. The Three Interaction Modes
- 4. Team Cognitive Load and Team-Sized Software
- 5. Fracture Planes: Splitting Software for Team Ownership
- 6. Platform as a Product and Sensing/Evolving
- Common Mistakes
- Quick Diagnostic
- Further Reading
- About the Authors
What does the team-topologies skill do?
Organize business and technology teams for fast flow using Skelton & Pais''s "Team Topologies". Use when the user mentions "team topologies", "Conway''s law", "platform team", "stream-aligned team", "team boundaries", "cognitive load", "how should we split teams", "who owns this service", "team dependencies", or "reorg". Also trigger when reorganizing engineering teams, aligning team and service boundaries, splitting a monolith and deciding ownership, reducing cross-team handoffs, or designing an internal platform. Covers the four team types, three interaction modes, the inverse Conway maneuve
How do I install it?
Run `npx skills add wondelai/skills --skill team-topologies --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From wondelai/skills, a repository with 1,835 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.