to-spec

$npx mdskill add e2b-dev/herdr-e2b-sandbox/to-spec

Synthesize the current conversation into a spec and publish it to the issue tracker.

  • Turns existing conversation context into a spec without interviewing the user.
  • Depends on the project issue tracker and triage label vocabulary from setup.
  • Explores the repo, respects ADRs, and proposes test seams at the highest level.
  • Publishes the spec to the issue tracker with the ready-for-agent label.

SKILL.md

.github/skills/to-specView on GitHub ↗
---
name: to-spec
description: Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
disable-model-invocation: true
---

This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user — just synthesize what you already know.

The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.

## Process

1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.

2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.

Check with the user that these seams match their expectations.

3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.

<spec-template>

## Problem Statement

The problem that the user is facing, from the user's perspective.

## Solution

The solution to the problem, from the user's perspective.

## User Stories

A LONG, numbered list of user stories. Each user story should be in the format of:

1. As an <actor>, I want a <feature>, so that <benefit>

<user-story-example>
1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
</user-story-example>

This list of user stories should be extremely extensive and cover all aspects of the feature.

## Implementation Decisions

A list of implementation decisions that were made. This can include:

- The modules that will be built/modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions

Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.

Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.

## Testing Decisions

A list of testing decisions that were made. Include:

- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)

## Out of Scope

A description of the things that are out of scope for this spec.

## Further Notes

Any further notes about the feature.

</spec-template>

More from e2b-dev/herdr-e2b-sandbox

SkillDescription
ask-mattAsk which skill or flow fits your situation. A router over the skills in this repo.
e2b-boxDrive the herdr-e2b plugin — e2b-box, e2b-fleet, e2b-bench, e2b-dash — from the CLI, the way an agent orchestrator (or a human without the keybindings) uses it. Two workflows it maps: (1) you already have a worktree and want its work mirrored into an E2B cloud sandbox (e2b-box open/sync/pull, one box per worktree), and (2) you want ONE task fanned out from the current checkout to several coding agents at once — claude, codex, opencode, amp, grok, droid, prime, muse — each in its own auto-created worktree + sandbox (e2b-fleet), then monitored, graded with a held-out check (e2b-bench), and the best result pulled back (best-of-n). Use whenever the user mentions e2b-box, e2b-fleet, e2b-bench, fleets, "run the same task on claude and codex", "fan this out to N agents", "send this worktree to a sandbox", "move my work to the cloud box", "grade the fleet", "best of n agents", "pull the winner", or presses/asks about prefix+shift+E / prefix+shift+F / prefix+shift+D in herdr. Also use when orchestrating these commands yourself as the agent instead of the human.
herdr-e2b-benchBuild and run a coding-agent shootout in this repo — one task, N agents (claude, codex, opencode, amp, grok, droid, prime, muse), each in its own E2B sandbox, graded by a held-out test and compared on tokens, cost, wall clock and diff size. Takes one argument. `create` authors a new benchmark task: the brief (bench/BENCH.md), the held-out grader (bench/grade.sh), and the reusable measurement scripts (bench/usage.sh, bench/judge.sh, bench/README.md), then calibrates the grader by measuring its floor and its ceiling. `execute` drives an existing benchmark: fan out with e2b-box fleet, grade with e2b-bench, table with usage.sh, blind-judge with judge.sh, tear down. `quick` is `execute` on the fast task pair (bench/BENCH-quick.md + bench/grade-quick.sh) — ~5 minutes of agent time and a ~1s grader, for when you are testing the harness rather than the agents. Use this skill whenever the user mentions a bench, benchmark, shootout, race, "which agent is better", harness-bench, bench/BENCH.md, bench/grade.sh, held-out test, grading a fleet, best-of-n, or wants to compare coding agents on the same task, or says quick bench, fast bench, short bench, smoke bench, quick lap, or asks for a bench that does not take an hour — and also whenever they ask to add, change, calibrate, or score a benchmark task in this repo, or to run one for a demo recording. Prefer this over improvising e2b-fleet and e2b-bench calls by hand, because the held-out mechanics and the grader calibration are easy to get subtly wrong.
resolving-merge-conflictsUse when you need to resolve an in-progress git merge/rebase conflict.
to-questionnaireTurn a decision you can't fully answer into a questionnaire for someone else to fill in.
wait-whatStop. That last message did not land — re-pitch it.
wayfinderPlan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
wizardGenerate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.
writing-for-agentsWriting documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.