Run any Skill in Manus with one click

Get Started

rdm-document

Stars0

Forks0

UpdatedMarch 22, 2026 at 19:12

Generate user documentation from a completed rdm roadmap

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

edpaget

edpaget/bot-showalter

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	rdm-document
description	Generate user documentation from a completed rdm roadmap
allowed-tools	["Read","Bash","Glob","Grep","Write","Edit","mcp__rdm__rdm_roadmap_show","mcp__rdm__rdm_phase_list","mcp__rdm__rdm_phase_show"]

Generate user-facing documentation from a completed rdm roadmap. $ARGUMENTS should be <roadmap-slug> [--out <path>].

Principles

Read docs/principles.md before starting. It contains project conventions that should guide your work.

Steps

Parse arguments: extract the roadmap slug and optional --out <path> from $ARGUMENTS. Default output path is docs/<slug>.md.
Read the roadmap: use the mcp__rdm__rdm_roadmap_show tool with project: "fbm" and roadmap: <slug> to get the overview and phase list.
Validate completion: all phases must be done. If any phase is not done, abort with a clear message listing incomplete phases.
Read each phase: use the mcp__rdm__rdm_phase_show tool with project: "fbm", roadmap: <slug>, and phase: <stem> for each phase. Collect titles, bodies, and commit SHAs.
Gather code changes from commit SHAs (the commit field in phase output):
- If SHAs are available: git log --oneline <first_sha>~1..<last_sha> and git diff --stat <first_sha>~1..<last_sha> in the source repo
- Single commit: git show --stat <sha>
- Missing SHAs: warn and fall back to phase descriptions only — do not abort
Cross-reference phase descriptions with actual code changes to ensure accuracy.
Draft documentation structured as:
- Overview — what the feature is
- Motivation — why it was built
- Usage — concrete examples (CLI commands, config options)
- How it works (optional) — architecture/internals for complex features
- Limitations (optional) — known gaps
Write the documentation to the output path.
Present the draft to the user for review before considering done.

Guidelines

Write for users, not developers — focus on what they can do
The Usage section is the most important — include real, working examples
Internal/refactoring phases: mention in "How it works" if relevant, omit from Usage
Derive content from both phase descriptions (intent) and code diffs (what shipped)
If phases lack commit SHAs, note which ones and rely on descriptions alone

More from this repository

same repository

rdm-implement

edpaget/bot-showalter

Implement the next phase of an rdm roadmap

2026-03-220

rdm-review

edpaget/bot-showalter

Review implementation of an rdm phase or task

2026-03-220

rdm-roadmap

edpaget/bot-showalter

Create an rdm roadmap with phases for a topic

2026-03-220

rdm-tasks

edpaget/bot-showalter

Work on rdm tasks

2026-03-220

fbm

edpaget/bot-showalter

Run fantasy baseball projection commands — predict, evaluate, compare systems, look up player projections/valuations, manage cached datasets, evaluate keeper league trades and optimization, run draft boards and mock drafts, and use Yahoo Fantasy integration for rosters, draft tracking, and keeper cost derivation. Use this when the user asks to run projections, compare systems, evaluate accuracy, look up a player, check valuations, manage/rebuild cached datasets, evaluate keeper league decisions/trades/optimization, view draft boards, run mock drafts, sync Yahoo league data, or manage Yahoo-derived keeper costs.

2026-03-110

experiment-breakout-bust

edpaget/bot-showalter

Run an autonomous feature-engineering experiment loop on the breakout-bust classification model. Tests candidate features against P(breakout) and P(bust) probability targets using marginal-value with auto-logging. Use when the user asks to "experiment on breakout-bust", "improve breakout-bust", or "explore features for breakout".

2026-03-060

name	rdm-document
description	Generate user documentation from a completed rdm roadmap
allowed-tools	["Read","Bash","Glob","Grep","Write","Edit","mcp__rdm__rdm_roadmap_show","mcp__rdm__rdm_phase_list","mcp__rdm__rdm_phase_show"]

Generate user-facing documentation from a completed rdm roadmap. $ARGUMENTS should be <roadmap-slug> [--out <path>].

Principles

Read docs/principles.md before starting. It contains project conventions that should guide your work.

Steps

Parse arguments: extract the roadmap slug and optional --out <path> from $ARGUMENTS. Default output path is docs/<slug>.md.
Read the roadmap: use the mcp__rdm__rdm_roadmap_show tool with project: "fbm" and roadmap: <slug> to get the overview and phase list.
Validate completion: all phases must be done. If any phase is not done, abort with a clear message listing incomplete phases.
Read each phase: use the mcp__rdm__rdm_phase_show tool with project: "fbm", roadmap: <slug>, and phase: <stem> for each phase. Collect titles, bodies, and commit SHAs.
Gather code changes from commit SHAs (the commit field in phase output):
- If SHAs are available: git log --oneline <first_sha>~1..<last_sha> and git diff --stat <first_sha>~1..<last_sha> in the source repo
- Single commit: git show --stat <sha>
- Missing SHAs: warn and fall back to phase descriptions only — do not abort
Cross-reference phase descriptions with actual code changes to ensure accuracy.
Draft documentation structured as:
- Overview — what the feature is
- Motivation — why it was built
- Usage — concrete examples (CLI commands, config options)
- How it works (optional) — architecture/internals for complex features
- Limitations (optional) — known gaps
Write the documentation to the output path.
Present the draft to the user for review before considering done.

Guidelines

Write for users, not developers — focus on what they can do
The Usage section is the most important — include real, working examples
Internal/refactoring phases: mention in "How it works" if relevant, omit from Usage
Derive content from both phase descriptions (intent) and code diffs (what shipped)
If phases lack commit SHAs, note which ones and rely on descriptions alone