mcpbeat

Foreman To Issues

visionforge-ou/foreman-to-issues

Break an approved PRD into small, dependency-ordered, vertically-sliced implementation issues written as local files in the Foreman feature directory. Each issue ships a runnable acceptance check and a declared file footprint. No GitHub, no live quizzing of the user — emits files matching Foreman's issue schema with PRD traceability.

1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
427
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/VisionForge-OU/foreman --skill foreman-to-issues

The instruction itself

8 sections, as written by the author

foreman-to-issues

(Adapted from mattpocock/skills to-issues — see NOTICE. Removed: all gh CLI

usage, GitHub labels/triage vocabulary, and the interactive "quiz the user" loop.

Issues are emitted as local files; the human reviews them in Foreman's queue-review

screen instead.)

Break the approved PRD into independently-grabbable issues using vertical

slices (tracer bullets). Run headless: produce the files and stop. The human will

reorder/edit/delete/add in Foreman's queue-review screen — do not ask them

anything here.

Process

1. Gather context

Read the approved prd.md (path injected by Foreman) — its body, user stories,

and user flows. Read the approved plan.md and adr.md too for decisions.

2. Explore the codebase

Understand the current state so titles and descriptions use the project's domain

glossary (CONTEXT.md) and respect ADRs in the area you're touching.

3. Draft vertical slices

Break the PRD into tracer-bullet issues. Each issue is a thin vertical slice

that cuts through ALL integration layers end-to-end (schema → logic → API → UI →

tests), NOT a horizontal slice of one layer.

<vertical-slice-rules>

  • Each slice delivers a narrow but COMPLETE path through every layer.
  • A completed slice is demoable or verifiable on its own.
  • Prefer many thin slices over few thick ones.
  • Order slices by dependency: a slice that others build on comes first.
  • Every slice traces back to one or more PRD sections / user stories.

</vertical-slice-rules>

4. Emit one file per slice

Write each slice to .foreman/features/<slug>/issues/ISS-NNN.md, numbered from

001 in dependency order (blockers first, so depends_on can reference real

ids). Each file is YAML frontmatter + markdown body in exactly this schema:

---
id: ISS-001
title: <short descriptive name>
status: queued
depends_on: []            # list of blocking issue ids, e.g. ["ISS-001"]
branch: feature/<slug>/iss-001
attempts: 0
budget: { max_turns: 80, max_cost_usd: 5.00, timeout_min: 45 }
prd_refs: ["PRD §<section>", "Story #<n>"]   # traceability back to the PRD
acceptance_check: tests/<area>/test_<slice>.py   # runnable check (REQUIRED)
touches: ["src/<area>/...", "tests/<area>/..."]  # declared file footprint
kind: feature
---
## Goal

A concise description of this vertical slice — the end-to-end behavior, not a
layer-by-layer implementation plan. Avoid file paths and code snippets (they go
stale); a prototype-derived decision snippet may be inlined if it encodes a
decision more precisely than prose.

## Acceptance criteria (testable)

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Out of scope

- What this slice deliberately does not do.

Rules:

  • id is ISS- + zero-padded three-digit number, unique within the feature.
  • branch is feature/<slug>/iss-NNN (lowercase).
  • budget defaults come from the feature's config run_budget; only deviate when

a slice is clearly bigger or smaller, and say why in the body if you do.

  • prd_refs MUST be present and non-empty — every issue traces to the PRD.
  • depends_on MUST be acyclic and reference only earlier issues.

acceptance_check — the executable form of acceptance (REQUIRED)

Every issue MUST carry a runnable acceptance_check derived **directly from a PRD

acceptance criterion**, so "done" is executable, not prose. It is either:

  • a bare test-file path (Foreman runs it with the project's test command),

e.g. acceptance_check: tests/todo/test_done.py; or

  • a command (more than one token), e.g.

acceptance_check: "pytest tests/todo/test_done.py::test_marks_complete".

If the check is a dedicated test the slice must add, write that test file into a

canonical issues/ISS-NNN.check/ directory (same relative path it should have in

the repo, e.g. issues/ISS-001.check/tests/todo/test_done.py). Foreman re-installs

it into the worktree before verifying so the worker cannot weaken or delete it.

An issue with no acceptance_check is rejected from the queue.

touches — the declared file footprint (for safe parallelism)

List the files/dirs/modules the slice will create or modify. Foreman builds a

conflict graph from these and never runs two overlapping issues concurrently, so

maximise disjointness when slicing — prefer slices whose footprints don't

overlap. An empty/unknown footprint is treated as conflicting with everything

(the safe default), which serialises the slice — so always declare it.

Do not create any external tickets. Do not modify the PRD.

How to use it

Copy the folder

Take visionforge-ou/foreman-to-issues from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.