Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

plan-to-ralph-spec

Étoiles3

Forks2

Mis à jour13 avril 2026 à 03:47

Convert a markdown implementation plan to a JSON spec file for ralph.sh execution

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

samjmarshall

samjmarshall/rekurve

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	plan-to-ralph-spec
description	Convert a markdown implementation plan to a JSON spec file for ralph.sh execution

Plan to Spec

Convert a markdown implementation plan into a structured .spec.json file that ralph.sh uses for execution.

Invocation

The user provides a path to a markdown plan:

/plan-to-ralph-spec thoughts/plans/2026-04-01-code-review-best-practices-checklist.md

Steps

Read the markdown plan file completely
Identify all leaf-level sections that contain checkbox task items (- [ ] lines)
For each section, extract:
- id: A normalized, stable, unique identifier derived from the heading structure (e.g., "1.1", "p2.cat1", "task-1"). Use numeric IDs when headings have numbers; use slugified IDs when they don't.
- title: The human-readable section title (heading text without the # prefix or numbering)
- tasks: Array of task strings from checkbox items (- [ ] lines), stripped of the - [ ] prefix
- files: Array of file paths mentioned in the section body (backtick-quoted paths matching src/, e2e/, scripts/, .claude/, .github/, thoughts/, docs/, or common extensions)
- verify: Array of make/shell commands from the section's success criteria. Default to ["make check"] if none specified
Skip sections with zero checkbox items — log a warning for each
Phases or groups (e.g., "Phase 1", "Phase 2") become ID prefixes on their child sections, not sections themselves. Only leaf-level items with tasks become sections.
Set all state fields to "pending"
Write to the same directory as the plan, replacing .md with .spec.json
Print a summary: section count, any warnings

Output Schema

{
  "version": 1,
  "plan": "<relative path to source markdown plan>",
  "title": "<plan title from first H1>",
  "sections": [
    {
      "id": "1.1",
      "title": "Section Title",
      "tasks": ["Task description 1", "Task description 2"],
      "files": ["src/app/page.tsx", "src/lib/utils.ts"],
      "verify": ["make check"],
      "state": "pending"
    }
  ]
}

Rules

Do NOT modify the original markdown plan
Heading format does not matter — handle ####, ###, ##, #####, numbered (1.1), named (Category 1:), etc.
The spec file must be valid JSON (use jq . to verify before writing)
If a section's success criteria mention specific commands (make test, make build, make test_e2e), include those in verify instead of the default
File paths in files should be relative to the repo root
IDs must be unique across all sections in the spec

Plus depuis ce dépôt

même dépôt

quality-control

samjmarshall/rekurve

Design-smell review of a diff — matches the changes since a fixed point (commit, branch, tag, or merge-base) against a fixed baseline of Fowler code smells (Refactoring, ch.3) and reports judgement-call findings. Complements /code-review (bugs, documented standards) and /validate_plan (spec conformance); use for the design-quality lens neither covers, or when the user asks for a "smell review".

2026-07-183

grilling

samjmarshall/rekurve

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

2026-07-183

improve-codebase-architecture

samjmarshall/rekurve

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

2026-07-183

commit

samjmarshall/rekurve

git commit code changes with clear messages

2026-07-153

document-feature

samjmarshall/rekurve

Interview a developer to produce a living feature doc at docs/feature/{slug}.md, capturing user value, architecture (with ADR links), and data/user flow with at least one Mermaid diagram. Use when the user says "document this feature", "write a feature doc", "create docs/feature/X", "explain feature X for new devs", or asks to onboard future engineers onto a shipped feature. Different from /write-plan (forward-looking design) and Epics (scope/sprint planning) — this is the present-tense "what does this thing do today" doc for engineers reading the codebase cold.

2026-07-153

pull-request

samjmarshall/rekurve

Create or update a Pull Request with a description tailored to its conventional-commit type (feat, fix, refactor, chore, perf, or trivial). Auto-detects whether to create or update based on branch state, detects type from branch/commits/issues, fills the matching bundled template, and runs verification only for what CI does not cover. Use when invoking /pull-request, when the user asks to open or update a PR, or after pushing work that needs a PR.

2026-07-153

Plan to Spec

Convert a markdown implementation plan into a structured .spec.json file that ralph.sh uses for execution.

Invocation

The user provides a path to a markdown plan:

/plan-to-ralph-spec thoughts/plans/2026-04-01-code-review-best-practices-checklist.md

Steps

Read the markdown plan file completely

Identify all leaf-level sections that contain checkbox task items (- [ ] lines)

For each section, extract:

id: A normalized, stable, unique identifier derived from the heading structure (e.g., "1.1", "p2.cat1", "task-1"). Use numeric IDs when headings have numbers; use slugified IDs when they don't.
title: The human-readable section title (heading text without the # prefix or numbering)
tasks: Array of task strings from checkbox items (- [ ] lines), stripped of the - [ ] prefix
files: Array of file paths mentioned in the section body (backtick-quoted paths matching src/, e2e/, scripts/, .claude/, .github/, thoughts/, docs/, or common extensions)
verify: Array of make/shell commands from the section's success criteria. Default to ["make check"] if none specified

Skip sections with zero checkbox items — log a warning for each

Phases or groups (e.g., "Phase 1", "Phase 2") become ID prefixes on their child sections, not sections themselves. Only leaf-level items with tasks become sections.

Set all state fields to "pending"

Write to the same directory as the plan, replacing .md with .spec.json

Print a summary: section count, any warnings

Output Schema

{ "version": 1, "plan": "<relative path to source markdown plan>", "title": "<plan title from first H1>", "sections": [ { "id": "1.1", "title": "Section Title", "tasks": ["Task description 1", "Task description 2"], "files": ["src/app/page.tsx", "src/lib/utils.ts"], "verify": ["make check"], "state": "pending" } ] }

Rules

Do NOT modify the original markdown plan

Heading format does not matter — handle ####, ###, ##, #####, numbered (1.1), named (Category 1:), etc.

The spec file must be valid JSON (use jq . to verify before writing)

If a section's success criteria mention specific commands (make test, make build, make test_e2e), include those in verify instead of the default

File paths in files should be relative to the repo root

IDs must be unique across all sections in the spec