How do I install the Map The Route skill?

Run npx skillmds@latest add alphazede/map-the-route in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Map The Route safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Map The Route?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Map The Route free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Map The Route?

alphazede (@alphazede) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Map The Route by alphazede — Agent Skill

Name: Map The Route
Author: alphazede

Map The Route

Create or resume Bearing's complete five-artifact planning package after material decisions are settled. Use for Map the Route or missing planning artifacts. Do not use to implement, select models, self-approve, or bypass the single integrated owner review.

alphazede 3f88882 2 files · 11.7 KB Updated Sep 17, 2026

File contents

Map the Route

Fresh planning node. The Router writes Journey state and owns owner conversation.

Match, inputs, and non-match

Match: material intent is settled and any technical-plan, design, SEIT, implementation graph, or review HTML is missing.
Inputs: confirmed decisions, repository map and evidence, artifact status, requirements register, repository rules, proposed owner-supplied lineup and review_cadence: at-end, plus the return schema.
Non-match: unresolved material scope, behavior, authority, risk, or acceptance intent returns REROUTE_GATHER_SUPPLIES; generate no implementation.json or review.html.

Procedure

Derive <journey-topic>-technical-plan.md from the confirmed title; ask only on ambiguity or collision. Establish whether a requirements register exists; if repository evidence cannot decide, return NEEDS_OWNER_DECISION. Never infer one. Registered identities remain references; author only Journey-local criteria; author the needed Journey-level proof or return NEEDS_OWNER_DECISION when register authority is unclear.
Author and prospectively check, in dependency order, the testable technical-plan, design.md, and seit.json. Preserve IDs and do not drop Journey-level proof or published-standard clause coverage.
Map the implementation graph and propose the Explorer Journey or Expedition, active/standby/unused role states, lineup, reasoning, and review_cadence: at-end. Bind the planning-review slots to owner-supplied primary and ordered fallback route references under one candidate ref, revision, and digest. Use supplied identities; never invent them.
After those stable source inputs, generate implementation.json and the self-contained offline review.html together. Each includes the proposed route, lineup, role states, reasoning, cadence, traceability, waves, recovery, approval boundaries, and register references versus Journey-local requirements. Two review.html states: planning-review and final-closeout.
Give every slice stable requirement/design/SEIT IDs, dependencies, exact write set, authority, role, session rule, evidence, recovery, and stop rule.
Open and verify final HTML, then request exactly one integrated owner review of outcome, design, route, lineup, cadence, and plan. Dispatch remains prohibited until approval. An owner change regenerates affected artifacts, then returns to this same gate; never insert a lineup or route-review pause.

Return and recovery

Return PLAN_REVIEW_READY, REROUTE_GATHER_SUPPLIES, NEEDS_OWNER_DECISION, or VALIDATION_FAILED with paths, evidence, blocker, and next action. Owner-decision pauses do not consume correction rounds. At most three evidence-changing correction rounds; never implement or invent approval.

---name: map-the-routedescription: Create or resume Bearing's complete five-artifact planning package after material decisions are settled. Use for Map the Route or missing planning artifacts. Do not use to implement, select models, self-approve, or bypass the single integrated owner review.---# Map the RouteFresh planning node. The Router writes Journey state and owns owner conversation.## Match, inputs, and non-match- **Match:** material intent is settled and any technical-plan, design, SEIT, implementation graph, or review HTML is missing.- **Inputs:** confirmed decisions, repository map and evidence, artifact status, requirements register, repository rules, proposed owner-supplied lineup and `review_cadence: at-end`, plus the return schema.- **Non-match:** unresolved material scope, behavior, authority, risk, or acceptance intent returns `REROUTE_GATHER_SUPPLIES`; generate no `implementation.json` or `review.html`.## Procedure1. Derive `<journey-topic>-technical-plan.md` from the confirmed title; ask only on ambiguity or collision. Establish whether a requirements register exists; if repository evidence cannot decide, return `NEEDS_OWNER_DECISION`. Never infer one. Registered identities remain references; author only Journey-local criteria; author the needed Journey-level proof or return `NEEDS_OWNER_DECISION` when register authority is unclear.2. Author and prospectively check, in dependency order, the testable technical-plan, `design.md`, and `seit.json`. Preserve IDs and do not drop Journey-level proof or published-standard clause coverage.3. Map the implementation graph and propose the Explorer Journey or Expedition, active/standby/unused role states, lineup, reasoning, and `review_cadence: at-end`. Bind the planning-review slots to owner-supplied primary and ordered fallback route references under one candidate ref, revision, and digest. Use supplied identities; never invent them.4. After those stable source inputs, generate `implementation.json` and the self-contained offline `review.html` together. Each includes the proposed route, lineup, role states, reasoning, cadence, traceability, waves, recovery, approval boundaries, and register references versus Journey-local requirements. Two `review.html` states: `planning-review` and `final-closeout`.5. Give every slice stable requirement/design/SEIT IDs, dependencies, exact write set, authority, role, session rule, evidence, recovery, and stop rule.6. Open and verify final HTML, then request exactly one integrated owner review of outcome, design, route, lineup, cadence, and plan. Dispatch remains prohibited until approval. An owner change regenerates affected artifacts, then returns to this same gate; never insert a lineup or route-review pause.## Return and recoveryReturn `PLAN_REVIEW_READY`, `REROUTE_GATHER_SUPPLIES`,`NEEDS_OWNER_DECISION`, or `VALIDATION_FAILED` with paths, evidence, blocker,and next action. Owner-decision pauses do not consume correction rounds. Atmost three evidence-changing correction rounds; never implement or invent approval.

Frequently asked questions