mago

Name: mago
Availability: InStock
Author: ginmp

Generate canonical planning artifacts under BOARD_ROOT/specs/<spec_id>/ from governance intake and repository truth.

Updated Apr 27, 2026

Search Tags:#planning #architecture #evidence #handoff #spec #board

Ready to run

npx skills add https://github.com/ginmp8/rhapsodia --skill mago

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: mago
Source: https://github.com/ginmp8/rhapsodia/tree/main/skills/mago
Command: npx skills add https://github.com/ginmp8/rhapsodia --skill mago

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) and assets (resource) components.

What problem does it solve?

MAGO helps tech-lead teams transform governance intake and repository evidence into canonical planning artifacts that guide board/spec planning, independent of runtime execution.

Core Features & Use Cases

Normalize and align planning documents across board and specs (manifest.yaml, prd.md, tasks.md, notes.md, validation.md, and technical-design.md when needed).
Capture evidence provenance and traceability to support downstream Magia execution while preserving planning boundaries.
Produce ready-to-use planning packages under BOARD_ROOT/specs/<spec_id>/ for downstream refinement and governance.

Quick Start

Seed BOARD_ROOT and board context, then MAGO will generate a complete planning package for the selected spec.

Frequently Asked Questions about mago

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I generate canonical planning artifacts like PRD and technical design from repository evidence?▼

To generate canonical planning artifacts, apply governance intake and repository truth to a resolved BOARD_ROOT. This produces a complete planning package including manifest.yaml, prd.md, tasks.md, and technical-design.md under BOARD_ROOT/specs/<spec_id>/.

What is the best way to normalize planning documents across board specs?▼

Normalizing planning documents across board specs requires aligning manifest.yaml, prd.md, tasks.md, notes.md, and validation.md into a canonical format. This process captures evidence provenance and traceability to support downstream execution while preserving planning boundaries.

Do I need a resolved BOARD_ROOT with board_id and cycle_version to start planning?▼

Yes, you need a resolved BOARD_ROOT populated with board_id and cycle_version to start planning. Optionally selecting a spec_id allows the tool to produce the ready-to-use planning package structured under the BOARD_ROOT/specs/<spec_id>/ directory.

Does this planning approach handle runtime execution evidence?▼

No, this planning approach does not handle runtime execution evidence. It strictly focuses on producing canonical repository planning artifacts, meaning execution and runtime evidence remain explicitly outside its processing scope.

Can I use this to capture evidence provenance and traceability for downstream execution?▼

Yes, you can use this to capture evidence provenance and traceability for downstream execution. It transforms governance intake and repository evidence into normalized planning artifacts that explicitly support downstream refinement while maintaining strict planning boundaries.