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.

Jump to install

Repository: vinilana/bench-my-harness
Last source activity: June 20, 2026 at 20:53
Detected SKILL.md language: English
Stars: 20
Forks: 3

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/vinilana/bench-my-harness --skill bmh-plan-work

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer

3 files

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

bmh-review-work

Always use when reviewing, validating, auditing, or summarizing completed Bench My Harness work, including code changes, tests, docs, ADRs, schemas, adapters, CLI behavior, benchmark runner behavior, or pull-request style review. Enforces TDD acceptance criteria, hexagonal architecture, v1 Codex/Claude Code scope, redaction, source confidence, and quality gates before work is considered done.

2026-06-20

adr-architecture-writer

Write, review, or update Bench My Harness architecture decision records for hexagonal architecture, event schemas, benchmark protocol, adapter strategy, storage, security, comparability, metrics, or execution isolation.

2026-06-20

benchmark-spec-author

Create, review, or update Bench My Harness benchmark scenarios, suites, prompts, fixtures, expected outputs, validation commands, scoring rubrics, reproducibility metadata, and benchmark YAML or JSON contracts.

2026-06-20

View all from this repository

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-work
description	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

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.

bmh-plan-work

Source facts

Install options

Review the source files

More from this repository

BMH Plan Work

Workflow

Planning Rules

Required Output

BMH Plan Work

Workflow

Planning Rules

Required Output

More from this repository