Create Ecosystem Map

Common Contract (Load First)

When this skill is activated, first load skill-common and apply the shared conventions it defines: canonical section order, frontmatter rules, anti-pattern guidance, and the Review In Mind loop in review-in-mind. This skill adds only domain-specific rules below.

Who

System Architects, Business Analysts, and AI Agents. The agent uses this skill to map dependencies and boundaries.

What

This skill implements the Ecosystem Map from the Requirements Modeling Language (RML). It analyzes requirements text to identify the System Under Design (SUD) and every external system, API, or human actor it interacts with. It outputs a Mermaid.js graph visualizing these relationships.

When

Invoke this skill during scope definition or early architectural design. Trigger phrases include: "create an ecosystem map," "what systems does this touch," "map the dependencies," or "draw a context diagram."

Where

Applies to Product Requirements Documents (PRDs), architectural design docs, and system integration plans.

Why

When teams focus only on the features they are building, they forget the systems they must integrate with. An Ecosystem Map forces the team to acknowledge (and plan for) every data feed, legacy database, and third-party API that touches their system.

Inputs

• Requirements documents, PRDs, or architecture descriptions.

Output (Logical Evidence)

• A Mermaid.js graph diagram (Ecosystem Map).
• A list of defined interfaces.

Optimization Readiness

• Failure Signals: Internal components leak into the map, arrows lack data labels, the SUD is not treated as a black box, or externals are missed because the scope was not bounded.
• Evidence To Collect: External-entity lists, labeled adjacency definitions, Mermaid drafts, and examples showing whether each interface was correctly treated as upstream, downstream, or human.
• Safe Mutation Boundaries: Refine entity-scanning prompts, interface labeling guidance, and graph-format advice without changing the core black-box ecosystem mapping model.
• Acceptance Criteria: Accept revisions only if the map shows the SUD at the center, all externals are truly external, and every arrow carries a meaningful label.
• Rejected Revision Handling: Record internal-component leaks, unlabeled arrows, and missing external entities so they are not repeated.
• Transfer Check: Verify the workflow still works for both text-only adjacency lists and Mermaid graph outputs.
• Stop Rule: If the system appears standalone with no real external interactions, stop and tell the user the map is trivial.

Constraints (Logical Boundaries)

• Do not map the internal components of the System Under Design. The SUD is a black box in this model. Only map external interactions.
• Differentiate between human actors and software systems.
• Keep execution guidance in plain language; Mermaid output is optional representation, not a required execution prerequisite.
• If rendering tools are unavailable, produce the same ecosystem map as a structured text adjacency list.

One More Thing

If the input text describes a purely standalone script with no external inputs or outputs, inform the user that an Ecosystem Map is trivial and unnecessary.

How (Structural Workflow)

Phase 1: Identify the Center

1. Identify the System Under Design (SUD). This is the application or service being built or modified. It goes in the center of the map.

Phase 2: Identify Externals

2. Scan the text for nouns representing external entities:
   • Upstream Systems: Systems that send data to the SUD.
   • Downstream Systems: Systems that receive data from the SUD.
   • Human Actors: User classes that interact directly with the SUD.

Phase 3: Define Interfaces

3. For every connection between the SUD and an external entity, define the nature of the data flowing across it (e.g., "Sends Order Data", "Returns Auth Token").

Phase 4: Visualization

4. Output the map using Mermaid.js graph or flowchart syntax.

Resources

• Ecosystem Map Template

Review In Mind (ReviewInMindGenie)

Execute the common review loop in review-in-mind before delivering.

Review lens for this skill:

• Is the System Under Design distinguished from every external system and actor?
• Are all upstream/downstream interactions from the source text represented?
• Is the Mermaid graph valid and free of invented integrations?

Validation

1. Verify the Mermaid syntax is valid.
2. Ensure the SUD is treated as a black box (no internal modules are shown).
3. Ensure every arrow has a label describing the data/interaction.