---
name: Use Cases
slug: use-cases-2
category: Writing
description: Use Cases guides an iterative discovery conversation to define or refine an approved non-technical specification for a feature, change, refactor, or user journey. It is used before technical design to capture goals, flows, rules, boundaries, and acceptance criteria.
github: "https://github.com/enmanuelmag/agent-harness-kit/tree/main/src/core/materializer/skills/ahk-use-cases"
language: TypeScript
stars: 180
forks: 9
install: "npx degit https://github.com/enmanuelmag/agent-harness-kit/tree/main/src/core/materializer/skills/ahk-use-cases ~/.claude/skills/ahk-use-cases"
installs_to: ~/.claude/skills/ahk-use-cases
source_path: src/core/materializer/skills/ahk-use-cases/SKILL.md
collection_size: 14
category_size: 1328
collection_url: "https://dirskills.com/collections/enmanuelmag/agent-harness-kit"
added: 2026-09-07T05:20:29.108Z
last_synced: 2026-09-07T05:20:29.108Z
canonical_url: "https://dirskills.com/skills/use-cases-2"
---

# Use Cases

Use Cases guides an iterative discovery conversation to define or refine an approved non-technical specification for a feature, change, refactor, or user journey. It is used before technical design to capture goals, flows, rules, boundaries, and acceptance criteria.

**Install:**

```bash
npx degit https://github.com/enmanuelmag/agent-harness-kit/tree/main/src/core/materializer/skills/ahk-use-cases ~/.claude/skills/ahk-use-cases
```

## README

## Purpose

Guide a lightweight, iterative product-discovery conversation. Do not choose a stack, library, API, architecture, or implementation plan.

Read [the discovery workflow](resources/discovery-workflow.md) before the conversation and [the use-case template](resources/use-case-template.md) before saving.

## Discovery

Ask one follow-up question at a time. Establish the user and their goal, current and desired flow, trigger, happy path, variants and failures, business rules, boundaries, exclusions, assumptions, risks, dependencies, priority, success signal, and observable acceptance criteria. Separate confirmed decisions from open questions and do not invent either.

## Save and iterate

When the user explicitly asks to save the agreed result, use the specification MCP tools. Create or update `docs/specs/<slug>.md` through structured tools only. Use `specs.list` before creating, `specs.get` for the selected specification, and `specs.validate` after every write. A use-case becomes `approved` only after the user explicitly approves it.

If the user changes an approved use-case, explain the affected technical specifications, update the use-case, and let the MCP transition linked technical specs to `needs-reconciliation`. Keep the conversation iterative; later messages refine the same specification unless the user clearly starts another initiative.

## Handoff

Offer `ahk-use-case-tech` only when the use case is approved and the user asks for technical design. The saved body follows the template and covers problem and value, actors, scope and exclusions, current and desired flows, cases and edge cases, rules, dependencies and risks, assumptions/open decisions, acceptance criteria, and change log.