create-team-api

Create Team API

Defines a team's "Team API": the explicit interface other teams use to work with it. Describes the team using Team Topologies (Skelton and Pais), capturing its team type, ownership boundaries, the services it provides, its inputs and outputs, its dependencies, and the interaction modes it uses with adjacent teams.

Where a charter says why a team exists and how it works internally, the Team API says how the rest of the organization interacts with it. Making the interface explicit lets other teams use the team's work through stable contracts instead of ad hoc asks, which is required for fast, independent flow.

Prerequisites

• A team name provided as $1, or stated in context. If omitted, ask for it.
• The team's charter, ideally produced by /create-team-charter, for purpose and responsibilities. If absent, derive purpose and responsibilities from context and flag the gap.
• Awareness of adjacent teams (their charters or APIs, if available) to map dependencies and interaction modes accurately.
• For engineering teams: the services, repositories, and systems the team owns.

Steps

1. Resolve the team name and slug, and confirm the output path (default teams/<team-slug>/team-api.md).
2. Classify the Team type per Team Topologies: stream-aligned, platform, enabling, or complicated-subsystem. If unsure, choose the closest and justify it in a sentence. A team's type can change as the organization evolves.
3. State the team's Purpose in one sentence, the reason its API exists. Reuse the charter's purpose verbatim when one exists.
4. Define Ownership boundaries: what the team owns outright (services, repositories, domains, data, infrastructure, on-call) and what it does not own. Ownership means the team is the approver of changes and the responder for incidents for that thing.
5. Define Services provided: the capabilities the team offers to the rest of the organization, each framed as a consumable service with a one-line description (for example, "Hosted CI pipeline", "User identity API", "Onboarding enablement engagement").
6. Define Inputs: what the team needs from others and in what form (for example, feature requests via an intake form, dependency upgrades via tickets, decisions via named owners). An input without a stated form invites unstructured interruptions.
7. Define Outputs: what the team produces and how others receive it (deployed services with an API contract, versioned libraries, documentation, an SLA). Outputs should have a stable, discoverable form.
8. Map Dependencies: upstream teams this team depends on, and downstream teams that depend on it, with the nature of each dependency.
9. Assign Interaction modes to each dependency per Team Topologies:
   • x-as-a-service (default for steady state): another team uses a stable, versioned interface with low communication overhead.
   • collaboration (high-bandwidth, temporary): used during exploration or when a boundary is unclear; narrow in scope and time-boxed so it does not become a permanent merger.
   • facilitating (an enabling team helping this team learn a capability): time-boxed, and it ends when the capability is transferred. Default to x-as-a-service wherever possible; reserve collaboration for genuine uncertainty.
10. Define the Request and communication interface: the single intake path for work requests, the expected response time or SLA, the primary channel, and how breaking changes to the team's outputs are announced and versioned.
11. Record Evolution: expected changes as the team or org matures (for example, a platform team moving a service from collaboration to x-as-a-service once the API stabilizes, or a stream-aligned team splitting as scope grows).
12. Record Open questions: unresolved ownership, missing dependencies, interfaces still being negotiated.
13. Write the output to teams/<team-slug>/team-api.md using the Output Format below.
14. Include session_link: http://localhost:10000/?session=<id> in the frontmatter, using the current session ID from context. If no session ID is available, omit the field.