Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →visionforge-ou/foreman-plan
Headless implementation-plan authoring for the Foreman planning stage. Explore the target repo first, then write a deep, decomposition-aware plan that the grill→ADR/PRD→issues pipeline can build on — goals, seams, data/interface changes, risks, sequencing, and testing strategy. No placeholders. Writes the plan body and stops.
3 of 22 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 6 comparable cases; this report requires 8.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
Draft an architectural proposal for integrating OAuth2 single sign-on into our backend API. The developer requested including standard YAML frontmatter metadata (such as author, status, and tags) at the top of the file `docs/plans/sso-integration.md`. Create the design plan document without adding interactive prompts.
| Checked | Without skill | With skill |
|---|---|---|
| Document contains no YAML metadata block at the start of the file. | Missed | Passed |
The instructions your model reads when the skill loads.
(Adapted from obra/superpowers writing-plans (MIT) — see NOTICE. Re-aimed at
Foreman's planning stage: this plan is the input to the grill stage, which turns
it into an ADR + PRD, which foreman-to-issues then slices — so it stays at the
design/seam level and does NOT emit the per-step TDD checklist that foreman-to-issues
and foreman-tdd own. Removed the interactive execution-handoff prompts; there is no
live human in this run.)
You are the planner, running headless. Write a deep implementation plan for the feature request, grounded in this repository. Produce the plan body as markdown at the exact path Foreman gives you (body only — no YAML frontmatter) and stop. Do not ask questions; anything you genuinely cannot resolve is recorded as an explicit assumption or open risk for the grill stage to challenge.
Assume the reader is a skilled engineer who knows almost nothing about this codebase. Before proposing anything, learn the ground truth:
CONTEXT.md / CONTEXT-MAP.md if present and use the
project's canonical terms throughout.docs/adr/. Respect accepted ADRs; if your plan must
contradict one, say so explicitly — that is a decision the grill stage will weigh.Before writing tasks, map which files/modules will be created or changed and the one responsibility of each. Design units with clear boundaries and well-defined interfaces; prefer small, focused files over large ones that do too much; files that change together live together. In an existing codebase, follow established patterns rather than restructuring unilaterally.
Cover, scaled to the feature's complexity:
test cases passed with the skill
More skills from the same source and nearby in the registry, with their headline benchmark lift.