Immutable. This exact content is served forever at /api/v1/blob/1098d2599356a1a6.
--- name: 024-context-mapping description: Use when a problem under exploration needs its surrounding system context identified before design begins — Existing systems, Integrations, Ownership, and External dependencies. This should trigger when an issue's Context Mapping point of view needs evaluation, or when a maintainer directly asks to map the systems, integrations, owners, and external dependencies relevant to a problem. Part of Plinth Toolkit license: Apache-2.0 metadata: author: Juan Antonio Breña Moral version: 0.18.0 --- # Context Mapping Guide identification of Existing systems, Integrations, Ownership, and External dependencies relevant to a problem under exploration. **This is an interactive SKILL**. **What is covered in this Skill?** - Identifying existing systems that already touch the problem area - Mapping integrations and data flows between those systems - Naming ownership: who operates, maintains, or is accountable for each system or integration - Identifying external dependencies (third-party services, other teams, contracts) outside the team's direct control - Feeding context-mapping findings into `025-quality-attribute-discovery` and the remaining Functional Specification lenses ## Constraints Map the surrounding context before any design decision assumes a system boundary. When this technique is orchestrated by another workflow, the orchestrator owns clarifying-question sequencing; when applied standalone, ask directly. - **MUST** read `references/024-context-mapping.md` before applying Context Mapping guidance - **MUST** identify existing systems that already touch the problem area, not only the system expected to change - **MUST** identify integrations and data flows between the identified systems - **MUST** name an owner (team or role) for each identified system or integration when known - **MUST** identify external dependencies outside the team's direct control, such as third-party services, other teams, or contracts - **MUST NOT** invent a system, integration, owner, or external dependency when the available content is vague or ambiguous; flag the gap for a clarifying question instead ## When to use this skill - Map the systems and integrations around this problem - Identify ownership for these systems - List the external dependencies for this issue - Apply context mapping before design begins - Draft the Context Mapping section of a Functional Specification ## Workflow 1. **Read the Reference** Read `references/024-context-mapping.md`, then review the problem frame for systems already implicated by the problem. 2. **Identify Existing Systems** List existing systems that already touch the problem area, including systems that are affected but not expected to change. 3. **Map Integrations** Identify integrations and data flows between the identified systems. 4. **Name Ownership** Name an owning team or role for each identified system or integration when known. 5. **Identify External Dependencies** Identify third-party services, other teams, or contracts outside the team's direct control that the problem or its resolution depends on. 6. **Report the Context Map** Report Existing systems, Integrations, Ownership, and External dependencies, and flag any item left open pending a clarifying answer. ## Reference For detailed guidance, examples, and constraints, see [references/024-context-mapping.md](references/024-context-mapping.md).