Foreman Plan Agent Skill
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.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/VisionForge-OU/foreman --skill foreman-planThe instruction itself
6 sections, as written by the authorforeman-plan
(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.
1. Explore before you plan
Assume the reader is a skilled engineer who knows almost nothing about this codebase.
Before proposing anything, learn the ground truth:
- Domain language: read
CONTEXT.md/CONTEXT-MAP.mdif present and use the
project's canonical terms throughout.
- Prior decisions: read
docs/adr/. Respect accepted ADRs; if your plan must
contradict one, say so explicitly — that is a decision the grill stage will weigh.
- The code itself: find the modules, seams, and tests your feature touches.
Verify your assumptions against what the code actually does.
2. Map the file structure first
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.
3. Write the plan
Cover, scaled to the feature's complexity:
- Goal — one or two sentences on what this builds and why.
- Approach & architecture — the design, the seams/interfaces involved, and the
key trade-offs. Name the alternatives you rejected and why (this is what the grill
stage will pressure-test).
- Data & interface changes — schema/state shape, public API or CLI changes,
migration/backfill and backward compatibility.
- Failure modes — partial failure, concurrency, idempotency, security/authz,
observability.
- Sequencing — the dependency-ordered slices a builder would tackle, thin enough
that each is independently verifiable (the raw material foreman-to-issues will
cut into issues). Keep this to the shape of the work, not a line-by-line script.
- Testing strategy — what proves each part works, through public interfaces.
- Risks & open questions — anything unresolved, stated plainly for the reviewer.
4. No placeholders
Every section must carry real content. These are plan failures — never write them:
- "TBD", "TODO", "implement later", "fill in details".
- "Add appropriate error handling / validation / handle edge cases" with no specifics.
- References to types, functions, or modules you never name.
5. Self-review before you stop
Read the request again with fresh eyes against your plan:
- Coverage — does every part of the request map to something in the plan?
- Placeholder scan — remove every vague-stub phrase above.
- Consistency — do the names, seams, and interfaces you use late in the plan
match what you introduced earlier?
Fix issues inline, then write the file and stop. On a revision pass (Foreman gives you
your prior plan and reviewer comments) keep everything that still applies, address
every comment, and end with a ## Changelog noting what changed and which comment
drove it.
Other skills for the same job
different authors, same section of the catalogue
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
Prepares and structurally reviews readiness evidence for ISO management-system and laboratory-competence standards - ISO 13485 medical device QMS, ISO 14971 device risk management, ISO/IEC 17025 testing and calibration laboratories, and ISO 15189 medical laboratories. Use when organizing declared scope, controlled documents, risk-management files, scope of accreditation, traceability, CAPA, external-provider controls, or bounded local evidence manifests, and when separating ISO certification from laboratory accreditation, FDA QMSR inspection, CLIA certification, MDSAP, and EU MDR/IVDR evidence boundaries. Not for legal applicability, compliance, certification, or accreditation decisions; contains no clause text.
Sample-size and statistical power calculations for planning studies. Use whenever someone asks "how many subjects/samples/replicates do I need", wants an a priori power analysis, a minimum detectable effect (MDE), a power curve, or needs to justify a sample size for a grant, IRB protocol, or pre-registration. Covers closed-form power for t-tests, ANOVA, proportions, correlations, chi-square, and regression, plus simulation-based (Monte Carlo) power for designs with no formula — logistic/Poisson regression, mixed models, cluster-randomized trials, survival, and interactions. Use this skill even when the request only mentions an effect size, alpha, or "80% power" without saying "power analysis" explicitly. For laying out the study (randomization, blocking, factorial/DOE, crossover, sequential designs) use experimental-design; for analyzing data already collected and reporting it use statistical-analysis.
Universal QA checklist for generated scientific plots: overlapping labels, clipped text, missing axes/legends, overcrowded data, and cross-journal resolution/format guidance.
Senior Elite Software Engineer (15+) and Senior Product Designer. Full workflow with planning, architecture, TDD, clean code, and pixel-perfect UX validation.
Run PinchBench benchmarks to evaluate OpenClaw agent performance across real-world tasks. Use when testing model capabilities, comparing models, submitting benchmark results to the leaderboard, or checking how well your OpenClaw setup handles calendar, email, research, coding, and multi-step workflows.
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
Verify PowerToys behavior end-to-end with the winapp CLI across two scenarios: (A) a module's release checklist against the installed build; (B) PR validation — derive each PR's checklist from its description + diff, then drive it against the installed build (a merged/shipped PR, or a whole release/hotfix set) or by building + sideloading the module when the PR isn't in the build yet (unmerged or not-yet-released). Drive each item via UIA invoke / Named Events / settings.json edits / clipboard / GPO / SendInput, and emit a structured PASS / FAIL / BLOCKED verdict per item with evidence (FAIL distinguishes product defects from stale/ambiguous checklist items). Use when asked to verify a module checklist, validate a PR, sign off a release/hotfix's PRs, or QA installed/sideloaded PowerToys bits. Combines generic winapp ui mechanics (references/winapp-ui-testing.md) with PT-specific recipes, per-scenario playbooks (references/scenarios/), and the helper .ps1 files shipped with this skill.
How to use it
Take visionforge-ou/foreman-plan from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
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.