Drive a Coding Agent with Your Map

The Handoff

A story map carries context that a card title alone does not: personas, open questions, risks the team discussed, decisions about scope. That context normally stays on the map while someone writes code from the card title and description alone.

A coding agent connected to Cartographer through the MCP server can read the whole card before it starts: the “Admin” persona tag, the sibling risk card about rate limiting, the comment thread where the team narrowed scope. This page covers how to give it that context, and how to keep the map updated as it works.

What You Need

• A coding agent, such as Claude Code, Cursor, or similar, with the Cartographer MCP server connected.
• A story map with implementable cards that have descriptions, persona tags, and customer associations.

Reading Cards for Context

Before writing any code, ask your coding agent to read the card. Using projects_get_card_details, it reads the title, description, card type, associated personas and customers, and the comment thread.

A card tagged with the “Admin” persona tells your coding agent to consider permissions and role checks. A sibling risk card about rate limiting means the implementation should handle that concern. A comment where the team decided “V1 is read-only” prevents over-building.

Picking Up Work

Ask your coding agent “what’s next?” and it reads the board using projects_list_all_cards, filtering by status to find cards that are ready for implementation. It suggests the highest-priority item based on position in the map.

You choose which card to work on. Your coding agent reads the full details, including any related cards in the same step, and starts implementation using that context. You do not need to copy requirements from one tool into another.

Updating the Map

As work completes, your coding agent updates the card status using cards_update and adds implementation notes as comments with comments_create. The map reflects what has been built, without you manually updating status fields.

When the team looks at the board the next morning, they see which cards moved to “Done” and can read the implementation notes on the card.

Example Session

1. Read the board. “What cards are ready to work on?” Your coding agent reads the board and lists candidates.
2. Pick a card. “Let’s work on the bulk export card.” Your coding agent reads the full card details, including the “Enterprise” customer tag and the related question card about CSV encoding.
3. Implement. Your coding agent writes the feature, informed by the card’s context. The customer tag means it handles large datasets. The question card means it defaults to UTF-8 with BOM for Excel compatibility.
4. Update status. Your coding agent marks the card as done and adds a comment: “Implemented bulk CSV export with UTF-8 BOM encoding. Handles up to 50k rows.”

Best Practices

• Write descriptions for the implementer. Write card descriptions as if the person reading them has no other context. The more you put on the card, the better the coding agent performs.
• Tag with personas. Persona tags give the agent hints about requirements it would not otherwise see. An “Admin” tag implies permission checks. A “New User” tag implies progressive disclosure and helpful defaults.
• Use sibling question and risk cards. Place open questions and known risks as separate cards next to the implementation card. The agent reads the full step, so it picks up these concerns.
• Align milestones with sprints. If your milestones match sprint boundaries, the agent can scope its work to the current milestone and avoid pulling in cards planned for later.