# Tesslio Spec Driven Development Tile Spec Driven Development Tile

> Requirement Gathering

- Skill: `tomevault-io/tesslio-spec-driven-development-tile-spec-driven-development` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/tesslio-spec-driven-development-tile-spec-driven-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/tesslio-spec-driven-development-tile-spec-driven-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/tesslio-spec-driven-development-tile-spec-driven-development

---


# Requirement Gathering

Structured interview process that turns vague requests into clear, actionable requirements.

## When to use

- A new task arrives from a stakeholder (feature, bugfix, refactor)
- The request has ambiguous or missing acceptance criteria
- Existing specs don't cover the requested change
- Before running `spec-writer` to create or update specs

## Rules

- Ask ONE question at a time (see `one-question-at-a-time` rule)
- Never begin implementation until requirements are confirmed
- Base questions on gaps found in existing specs, not assumptions

## Inputs

- The stakeholder's initial request
- Existing specs in the project's `specs/` folder (if any)

## Steps

1. **Review existing specs.** Scan the `specs/` directory for any specs related to the request. Note what's already documented and what's missing.

2. **Identify gaps.** List the ambiguous or underspecified areas:
   - Unclear scope boundaries (what's in vs. out)
   - Missing edge cases or error handling expectations
   - Unspecified behavior for boundary conditions
   - Unclear integration points with existing functionality
   - Missing non-functional requirements (performance, security)

3. **Interview the stakeholder.** Ask ONE question at a time. Wait for the answer before asking the next question. Prioritize questions by impact — ask about scope and core behavior first, edge cases second.

   Good questions are specific and bounded:
   - "Should the API return a 404 or an empty list when no results match?"
   - "Is this endpoint authenticated, and if so, which roles have access?"

   Bad questions are open-ended or bundled:
   - "What should the API do?" (too vague)
   - "What about errors, pagination, auth, and rate limits?" (too many at once)

4. **Summarize requirements.** After all questions are answered, present a concise summary of the clarified requirements back to the stakeholder for confirmation.

5. **Get explicit approval.** Do not proceed until the stakeholder confirms the summary is accurate. If they correct anything, update the summary and re-confirm.

## Output

A confirmed requirements summary ready to be turned into specs by `spec-writer`. The summary should include:
- Scope: what's included and excluded
- Core behavior: the happy path
- Edge cases: boundary conditions and error handling
- Constraints: performance, security, compatibility requirements

## Success criteria

- Zero ambiguous requirements remain after the interview
- Stakeholder explicitly confirmed the summary
- No implementation work began before confirmation

---
> Source: [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-21 -->