Tag: ux

Categoria: Workflows/SDD

Tasks break a Plan into ordered, independently completable units. Only generate a tasks.md for Project scope (multi-day work). For Quick or Feature scope, the agent's todo list is enough.

Categoria: Workflows/SDD

The spec answers what and why — never how. No frameworks, libraries, file paths, function names, or implementation details. If a non-technical PM could write it, you're at the right level.

Categoria: Workflows/SDD

The boring-but-critical pass. Run before declaring a feature done. The difference between "compiles and runs" and "delightful in production" is in this list.

Categoria: Workflows/SDD

The plan answers how. Built only after the spec is signed off. Under 2 minutes to read — if longer, the feature is too big; split it.

Categoria: Workflows/SDD

How to ask the right questions, organized by request type. Pick 2–5 questions total — never run the full list. Questions are ordered most-to-least important; start at the top.

Categoria: Workflows/SDD

A worked example of how the Quick path looks in practice. Total interaction: one round of questions, an inline mini-spec, a thumbs-up, then build.

Categoria: Workflows/SDD

A worked example of Project scope: spec + plan + tasks as files in specs//. For multi-day work where the artifacts pay for themselves.

Categoria: Workflows/SDD

A worked example of a Feature-scope flow: full spec + plan, but no separate tasks file. Typical for 1–4 hours of work.

Categoria: Workflows/SDD

User requests for features are incomplete by design — the user gives you the top-of-mind 30%, not the full spec. Coding from that ships things that compile but miss the actual intent, skip the boring-but-critical states (loading, empty, error, edge), and feel unpolished.