Think Discover Define
- 1 repo stars
- Updated April 27, 2026
- benedekvarga/bens-claude-code-toolkit
think-discover-define runs a three-phase SPEC, PLAN and TEST pipeline that turns guided discovery into EARS requirements, a traceable implementation plan and a linked test strategy.
About
think-discover-define runs a three-phase spec pipeline (01-SPEC, 02-PLAN, 03-TEST) before any code is written: decision-tree discovery where every question ships with a recommended answer drawn from codebase analysis, a spec in EARS requirements notation with pre/post contracts and state invariants, then an implementation plan and test strategy whose every item traces back to a requirement. The codebase stays read-only for the whole run; the only outputs are three markdown artifacts saved under specs/, each gated on explicit developer approval.
- Decision-tree discovery where every question carries a recommended answer based on codebase analysis
- EARS requirements plus pre/post contracts and state invariants, without mathematical notation or proof tooling
- Requirement-to-task-to-test traceability: every R# and INV-# must appear in both PLAN.md and TEST.md
- Hard checkpoints: never auto-advances a phase without developer approval
- Read-only rule: writes only the three spec artifacts, never source code, tests, or configs
Think Discover Define by the numbers
- Data as of Jul 15, 2026 (Skillselion catalog sync)
/plugin marketplace add benedekvarga/bens-claude-code-toolkit/plugin install think-discover-define@bens-claude-code-toolkitAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| repo stars | ★ 1 |
|---|---|
| Last updated | April 27, 2026 |
| Repository | benedekvarga/bens-claude-code-toolkit ↗ |
What it does
Run /think-discover-define at the start of a feature, complex behavior change, or bug-fix scoping session to produce an approved SPEC, PLAN, and TEST artifact set before implementation begins.
Who is it for?
Developers who want requirements pinned down as a written, traceable contract before a coding session starts, especially for features with state transitions, error cases, or async behavior.
Skip if: Trivial changes: typos, renames, single-line config tweaks. Also not an implementation tool: during all phases the codebase is read-only and it never modifies source code.
When should I use this skill?
Invoke manually with /think-discover-define when starting a new feature, modifying complex behavior, scoping a bug fix, or planning an implementation.
What you get
Creates three approved files under specs/: an EARS-based specification, an implementation plan mapped to requirement numbers and a test strategy with validation for every requirement.
- SPEC.md with project context, discovery summary, EARS requirements, state model, and pre/post contracts
- PLAN.md with a component breakdown and task checklist traced to R# and INV-# references
- TEST.md with validation items derived from every requirement and invariant, no orphan validation
By the numbers
- 3 phases producing 3 artifacts (SPEC, PLAN, TEST), one approval checkpoint per phase
- 7 bundled reference files: 3 phase guides, a spec template, and 3 worked examples
- 5-item traceability checklist run before approving each artifact
README.md
/think-discover-define
A Claude Code skill for spec-driven feature development. Front-loads thinking before code — guided discovery, formal-methods-flavored contracts, and a fully traceable pipeline from requirement to test.
Installation
Via Plugin Marketplace (Recommended)
Install directly from Claude Code in two commands:
/plugin marketplace add https://github.com/benedekvarga/bens-claude-code-toolkit
/plugin install think-discover-define@bens-claude-code-toolkit
Then use it by typing /think-discover-define in Claude Code.
Usage
Start a new feature
/think-discover-define
"I want to add rate limiting to the API"
The skill will:
- Scan the codebase for existing docs, architecture decisions, and relevant context before asking anything
- Run interactive discovery — questions with recommended answers based on codebase analysis
- Generate a formal spec (01-SPEC) with EARS requirements and pre/post contracts
- Derive an implementation plan (02-PLAN) with tasks mapped to requirements
- Produce a validation strategy (03-TEST) with test cases derived directly from the spec
Each phase ends at a checkpoint — the skill stops and waits for your approval before continuing.
Pipeline
01-SPEC ──► 02-PLAN ──► 03-TEST
Each phase produces a persistent file in specs/<feature-slug>/. Each phase ends at a checkpoint — the skill stops and waits for approval before continuing.
| Phase | Output | What it produces |
|---|---|---|
| 1 · Spec | 01-SPEC.md |
Discovery Q&A, EARS requirements, state model, pre/post contracts |
| 2 · Plan | 02-PLAN.md |
Task checklist with exact file paths, mapped to R-numbers |
| 3 · Test | 03-TEST.md |
Test cases derived directly from requirements |
Every requirement (R-number) traces to a task (T-number) and a test case (TC-number). If a requirement changes, the chain breaks visibly.
Formal methods connections
The skill borrows structure from formal specification without mathematical notation or tooling.
| Skill construct | Origin |
|---|---|
| Pre/post condition contracts | Design-by-contract (Dafny, VDM, Eiffel) |
| State invariants + impossible transitions | TLA+, Alloy |
| EARS requirements | Semi-formal requirements engineering (Rolls-Royce airworthiness) |
| R → T → TC traceability | Refinement (B-Method, Event-B) |
| Test derivation from spec | Specification-based testing |
EARS sits at the formal/informal boundary: each pattern (When / While / If-Then) maps to a logical form and is directly translatable into a test — the same property formal specs are designed to have. What the skill omits: mathematical notation, model checking, temporal logic, and proof tooling. The formal influence is in the structure of thinking, not the machinery.
When to skip it
Only trivial changes: typos, renames, single-line config tweaks. For everything else, run the full pipeline.
Related skills
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493kHow it compares
Unlike generic planning prompts, it enforces traceability and approval gates. It borrows contracts, invariants and refinement ideas from formal methods without becoming a proof tool.
FAQ
Does think-discover-define write any code?
No. During all phases the codebase is read-only; the skill only creates the three spec artifacts in the specs/ folder, and after the TEST phase it outputs a mandatory context-break handoff prompt so implementation starts in a fresh session.
What is EARS notation and why does this skill use it?
EARS is a semi-formal requirements syntax where each pattern (When / While / If-Then) maps to a logical form directly translatable into a test. The skill uses it to keep every requirement testable without formal-methods tooling.
What happens when implementation contradicts the spec?
The skill defines explicit drift handling: flag the contradiction against the specific requirement, ask whether to update the spec or treat it as a one-off exception, then cascade any edit into PLAN.md and TEST.md. It never silently deviates from the spec.