How do I install the Bmh Plan Work skill?

Run npx skillmds@latest add vinilana/bmh-plan-work in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Bmh Plan Work safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Bmh Plan Work?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Bmh Plan Work free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Bmh Plan Work?

vinilana (@vinilana) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Bmh Plan Work by vinilana — Agent Skill

Name: Bmh Plan Work
Author: vinilana

Bmh Plan Work

Always use when planning, designing, scoping, estimating, or proposing any Bench My Harness feature, refactor, adapter, schema, CLI command, benchmark behavior, test suite, ADR, or implementation approach. Enforces Spec Driven Development, TDD-first planning, hexagonal architecture boundaries, v1 Codex/Claude Code scope, and explicit acceptance criteria before code changes.

vinilana Updated Sep 17, 2026

File contents

BMH Plan Work

Workflow

Identify the smallest valuable change and classify it: domain, application use case, adapter, CLI, storage, schema, tests, docs, or ADR.
Read the relevant specs/ADRs before proposing code. Use references/planning-gates.md to choose required documents.
State whether existing specs/ADRs are sufficient. If behavior is new or changes architecture, update docs before implementation.
Define acceptance criteria as tests first. Name the expected test files and fixtures.
Preserve hexagonal boundaries: domain has no provider, filesystem, CLI, process, or framework imports.
Keep v1 scope to Codex and Claude Code unless an explicit ADR changes scope.
Identify risks: observability gaps, token/context source confidence, redaction, global config mutation, hook latency, idempotency, and comparability.
Only then outline implementation steps.

Planning Rules

Do not plan production code before defining the failing tests.
Do not introduce a dependency without naming why local patterns or standard APIs are insufficient.
Do not let Codex or Claude Code raw schemas leak into domain models.
Do not create broad refactors during feature work unless required by the acceptance criteria.
Do not promise native token/context data unless the source proves it.
Prefer fake harnesses and local fixtures over real Codex/Claude execution in tests.

Required Output

Every plan must include:

relevant specs/ADRs consulted;
acceptance tests to add or update;
affected ports/use cases/adapters;
data/source confidence implications;
implementation sequence;
verification commands.

---name: bmh-plan-workdescription: Always use when planning, designing, scoping, estimating, or proposing any Bench My Harness feature, refactor, adapter, schema, CLI command, benchmark behavior, test suite, ADR, or implementation approach. Enforces Spec Driven Development, TDD-first planning, hexagonal architecture boundaries, v1 Codex/Claude Code scope, and explicit acceptance criteria before code changes.---# BMH Plan Work## Workflow1. Identify the smallest valuable change and classify it: domain, application use case, adapter, CLI, storage, schema, tests, docs, or ADR.2. Read the relevant specs/ADRs before proposing code. Use `references/planning-gates.md` to choose required documents.3. State whether existing specs/ADRs are sufficient. If behavior is new or changes architecture, update docs before implementation.4. Define acceptance criteria as tests first. Name the expected test files and fixtures.5. Preserve hexagonal boundaries: domain has no provider, filesystem, CLI, process, or framework imports.6. Keep v1 scope to Codex and Claude Code unless an explicit ADR changes scope.7. Identify risks: observability gaps, token/context source confidence, redaction, global config mutation, hook latency, idempotency, and comparability.8. Only then outline implementation steps.## Planning Rules- Do not plan production code before defining the failing tests.- Do not introduce a dependency without naming why local patterns or standard APIs are insufficient.- Do not let Codex or Claude Code raw schemas leak into domain models.- Do not create broad refactors during feature work unless required by the acceptance criteria.- Do not promise native token/context data unless the source proves it.- Prefer fake harnesses and local fixtures over real Codex/Claude execution in tests.## Required OutputEvery plan must include:- relevant specs/ADRs consulted;- acceptance tests to add or update;- affected ports/use cases/adapters;- data/source confidence implications;- implementation sequence;- verification commands.

Frequently asked questions