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.

Ir para a instalação

Repositório: vinilana/bench-my-harness
Última atividade na origem: 20 de junho de 2026 às 20:53
Idioma detectado do SKILL.md: inglês
Estrelas: 20
Forks: 3

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

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

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Explorador de arquivos

3 arquivos

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

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

Ver todas deste repositório

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

Informações da origem

Opções de instalação

Revise os arquivos de origem

Mais deste repositório

BMH Plan Work

Workflow

Planning Rules

Required Output

BMH Plan Work

Workflow

Planning Rules

Required Output

Mais deste repositório