ai-design-context 0.4.0

package/skills/reference-driven-design/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: reference-driven-design
+description: Build an evidence-backed visual reference brief before UI concept or polish work. Use when a product needs a modern visual direction, category-aware references, comparative design analysis, or protection from generic AI-generated styling without copying a specific brand.
+---
+
+# Reference-Driven Design Skill
+
+## Role
+
+Translate current product and platform references into an abstract, traceable visual direction.
+
+## Mission
+
+Improve visual judgment without turning taste, trends, or one admired product into unsupported design rules.
+
+## When To Use
+
+- A user asks for a more modern, polished, premium, expressive, or product-specific interface.
+- A new surface needs a visual direction before implementation.
+- Existing UI feels generic but the workflow and object model are already clear.
+- A prompt needs reference categories and explicit anti-copy constraints.
+
+## When Not To Use
+
+- Product direction, user goal, or object model is unresolved.
+- The task is a narrow visual bug with an existing token and component answer.
+- No source, screenshot, product behavior, or graph context is available; record a research gap first.
+
+## Inputs
+
+- Product goal, primary action, audience, and platform.
+- Current UI or implementation.
+- Existing components, tokens, and product design direction.
+- Focused graph context from `npm run context`.
+- Supplied references or traceable current product and platform evidence.
+
+## Process
+
+1. Resolve graph context for the target task.
+2. Classify the surface by product type, workflow density, platform, and emotional tone.
+3. Select two or three relevant reference families, not a single brand to imitate.
+4. For each source, separate observed behavior from interpretation.
+5. Extract reusable abstractions:
+   - content and functional layers;
+   - hierarchy and density;
+   - typography and shape roles;
+   - material and color meaning;
+   - state and motion behavior;
+   - responsive and input adaptation.
+6. Map recommendations to existing research, rules, patterns, and tokens.
+7. Mark unsupported ideas as observations or research needs instead of instructions.
+8. Define what must not be copied: branding, proprietary assets, distinctive composition, or platform-inappropriate effects.
+9. Hand the brief to `visual-designer`, `motion-designer`, or `prompt-architect`.
+
+## Output Format
+
+```md
+## Reference Brief
+- Product category:
+- User goal:
+- Platform and density:
+- Evidence date:
+
+## Reference Matrix
+| Source | Observed behavior | Reusable abstraction | Limit |
+| --- | --- | --- | --- |
+
+## Visual Direction
+- Content layer:
+- Functional layer:
+- Focal emphasis:
+- Typography and shape:
+- State and motion:
+- Responsive adaptation:
+
+## Graph Traceability
+- Research:
+- Rules:
+- Patterns:
+- Missing evidence:
+
+## Anti-Copy Boundary
+- Do not copy:
+- Platform constraints:
+
+## Handoff
+- Next skill:
+- Reason:
+```
+
+## Quality Checklist
+
+- Recommendations come from observable source behavior.
+- At least two reference families are compared when the task is exploratory.
+- Product purpose determines expression level and density.
+- Content and primary action remain dominant.
+- Platform-specific materials have fallbacks.
+- The brief names unsupported ideas as gaps.
+- No specific brand composition or proprietary asset is copied.
+
+## Related Research
+
+- `RESEARCH-00009` Expressive System UI In 2026
+- `RESEARCH-00010` Motion As State Continuity
+- `RESEARCH-00011` Contextual And Observable Agentic Interfaces
+
+## Related Rules
+
+- `RULE-00008` / `VIS-001` Semantic Tokens Only
+- `RULE-00014` / `VIS-002` Keep Expression Subordinate To Content
+- `RULE-00015` / `UX-004` Use Motion To Explain State Continuity
+
+## Handoff To Other Skills
+
+- Use `product-designer` if product direction or the primary action is unclear.
+- Use `design-evidence-researcher` when current evidence is missing.
+- Use `visual-designer` to convert the brief into hierarchy and token decisions.
+- Use `motion-designer` when continuity or interaction feedback needs movement.
+- Use `prompt-architect` to encode the direction into a graph-backed prompt.

package/skills/ux-reviewer/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: ux-reviewer
+description: Review product journeys for usability and friction. Use for task clarity, user flow, state coverage, form recovery, empty/loading/error behavior, or interaction issues before implementation or release.
+---
+
+# UX Reviewer Skill
+
+## Role
+
+Review user journeys, usability, flow clarity, and state behavior.
+
+## Mission
+
+Find where a product workflow makes users think, wait, repeat work, lose context, or miss the next action.
+
+## When To Use
+
+- A feature flow needs usability review.
+- Empty, loading, error, or success states are unclear.
+- A design may be too dashboard-like for a consumer workflow.
+- Pattern selection needs UX validation.
+
+## When Not To Use
+
+- The product goal is not defined.
+- The task is only visual token cleanup.
+- The request is purely schema or registry architecture.
+
+## Inputs
+
+- User goal, workflow, screen sequence, or prototype.
+- Claimed rules and patterns.
+- State requirements and constraints.
+- Generated rule and pattern indexes.
+
+## Process
+
+1. Identify the user goal and expected next action.
+2. Trace the default path from entry to completion.
+3. Check whether capture, inspection, and completion preserve context.
+4. Review empty, loading, error, disabled, and success states.
+5. Flag friction, ambiguity, unnecessary metadata, and mode confusion.
+6. Tie each issue to an existing rule, pattern, or missing knowledge layer.
+7. Hand off visual, mobile, accessibility, or interaction issues as needed.
+
+## Output Format
+
+```md
+## UX Review
+- User goal:
+- Flow reviewed:
+- Verdict:
+
+## Findings
+- Issue:
+- Impact:
+- Rule or pattern:
+- Suggested fix:
+
+## State Coverage
+- Empty:
+- Loading:
+- Error:
+- Success:
+
+## Handoff
+- Next skill:
+- Reason:
+```
+
+## Quality Checklist
+
+- The main user path is understandable.
+- The next action is visible.
+- Optional metadata does not block capture.
+- Detail views preserve context.
+- States are designed, not left implicit.
+- Findings are grounded in rules and patterns.
+
+## Related Rules
+
+- `RULE-00001` / `PRD-001` Daily Actions First
+- `RULE-00002` / `PRD-002` Low-Friction Capture Before Organization
+- `RULE-00006` / `UX-002` Progressively Disclose Power
+- `RULE-00007` / `UX-003` Preserve Context During Inspection
+
+## Related Patterns
+
+- `PAT-00001` / `PAT-001` Daily Home Surface
+- `PAT-00002` / `PAT-002` Quick Capture
+- `PAT-00004` / `PAT-004` Progressive Detail
+- `PAT-00005` / `PAT-005` Context-Preserving Preview
+
+## Handoff To Other Skills
+
+- Use `product-designer` when the user goal or primary action is unclear.
+- Use `interaction-designer` for detailed flow mechanics.
+- Use `mobile-ux-expert` for touch-first layout issues.
+- Use `design-reviewer` for final quality gate.

package/skills/visual-designer/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: visual-designer
+description: Review or refine visual hierarchy in product UI. Use for layout, spacing, typography, color meaning, contrast-sensitive choices, visual polish, and consistency with existing design tokens.
+---
+
+# Visual Designer Skill
+
+## Role
+
+Review visual hierarchy, typography, spacing, color meaning, and product polish.
+
+## Mission
+
+Make the interface feel modern, legible, and product-specific while preserving rule and pattern intent.
+
+## When To Use
+
+- A screen is structurally correct but visually unclear or generic.
+- Hierarchy, spacing, contrast, density, or status styling needs review.
+- A product surface needs polish without redesigning the workflow.
+- Semantic token use needs visual validation.
+
+## When Not To Use
+
+- Product direction or IA is unresolved.
+- The task asks for a new design system or component library.
+- The issue is primarily accessibility, motion, or performance.
+
+## Inputs
+
+- Current screen or implementation.
+- Product goal and selected patterns.
+- Evidence-backed reference brief when visual direction or polish is requested.
+- Existing tokens, theme values, and component styles.
+- Accessibility constraints and viewport requirements.
+
+## Process
+
+1. Identify the primary content and action.
+2. Identify the content layer, functional layer, focal emphasis, and quiet supporting surfaces.
+3. Check typography scale, spacing, density, and hierarchy.
+4. Check whether color, shape, material, depth, and status styling use semantic meaning.
+5. Keep expressive treatment subordinate to content and primary action.
+6. Ensure repeated items scan cleanly.
+7. Preserve platform, mobile, and accessibility constraints.
+8. Hand off reference, token, accessibility, or final review concerns.
+
+## Output Format
+
+```md
+## Visual Review
+- Primary visual issue:
+- Product impact:
+- Recommended change:
+- Evidence or reference:
+
+## Hierarchy
+- Primary:
+- Secondary:
+- Supporting:
+
+## Surface Roles
+- Content layer:
+- Functional layer:
+- Focal emphasis:
+- Quiet surfaces:
+
+## Token And Pattern Links
+- Rule:
+- Pattern:
+
+## Handoff
+- Next skill:
+- Reason:
+```
+
+## Quality Checklist
+
+- Primary action and content are visually dominant.
+- Typography fits the surface.
+- Spacing supports scanning.
+- Color communicates meaning, not decoration alone.
+- Expressive materials preserve content priority and platform behavior.
+- Visual polish does not change product logic.
+- The recommendation uses existing rules and patterns.
+
+## Related Rules
+
+- `RULE-00001` / `PRD-001` Daily Actions First
+- `RULE-00003` / `IA-001` One Stable Home Surface
+- `RULE-00008` / `VIS-001` Semantic Tokens Only
+- `RULE-00009` / `A11Y-001` 44x44 Touch Targets
+- `RULE-00014` / `VIS-002` Keep Expression Subordinate To Content
+
+## Related Patterns
+
+- `PAT-00001` / `PAT-001` Daily Home Surface
+- `PAT-00004` / `PAT-004` Progressive Detail
+- `PAT-00006` / `PAT-006` Object Status List
+
+## Handoff To Other Skills
+
+- Use `design-system-architect` when token or reusable state naming is needed.
+- Use `reference-driven-design` when the visual direction lacks traceable references.
+- Use `accessibility-reviewer` for contrast, focus, and target checks.
+- Use `mobile-ux-expert` when visual density breaks on narrow screens.
+- Use `design-reviewer` for final signoff.

package/starter-kit/AGENTS.md

@@ -0,0 +1,37 @@
+# Project AGENTS
+
+This repository follows AI Design Context.
+
+## Agent Workflow
+
+For every feature:
+
+1. Read `docs/PRD.md`.
+2. Read `docs/PERSONAS.md`.
+3. Read `docs/USER_FLOWS.md`.
+4. Read `docs/INFORMATION_ARCHITECTURE.md`.
+5. Select applicable rules from AI Design Context.
+6. Select applicable patterns from AI Design Context.
+7. Explain the design reasoning before implementation.
+8. Prototype or implement the smallest useful change.
+9. Review with `reviews/DESIGN_REVIEW.md`.
+10. Benchmark meaningful product changes.
+
+## Do Not
+
+- Do not jump directly from a feature request to code.
+- Do not invent new design rules inside the product repo.
+- Do not add UI complexity without a user goal.
+- Do not skip empty, loading, error, disabled, and success states.
+- Do not claim benchmark improvement without stored evidence.
+
+## Output
+
+When completing UI or product work, report:
+
+- rules used;
+- patterns used;
+- states covered;
+- mobile assumptions;
+- accessibility checks;
+- validation result.

package/starter-kit/BOOTSTRAP.md

@@ -0,0 +1,13 @@
+# Bootstrap Checklist
+
+- [ ] Create `docs/PRD.md`.
+- [ ] Define personas and jobs in `docs/PERSONAS.md`.
+- [ ] Map primary user flows in `docs/USER_FLOWS.md`.
+- [ ] Define screens, navigation, and object model in `docs/INFORMATION_ARCHITECTURE.md`.
+- [ ] Record product and UX decisions in `docs/DESIGN_DECISIONS.md`.
+- [ ] Select applicable AI Design Context.
+- [ ] Select applicable patterns.
+- [ ] Prototype or implement the smallest useful version.
+- [ ] Run `reviews/DESIGN_REVIEW.md`.
+- [ ] Benchmark meaningful product changes.
+- [ ] Store evidence before claiming improvement.

package/starter-kit/INSTALL_WITH_AGENT.md

@@ -0,0 +1,133 @@
+# Install with a Coding Agent
+
+Use this guide to connect AI Design Context to an existing product repository without replacing its application code, UI library, or current agent instructions.
+
+After setup, the product repository has:
+
+- a pinned AI Design Context knowledge source;
+- project-local agent instructions;
+- product context and review templates where they are missing;
+- a repeatable command for retrieving task-specific graph context.
+
+## Choose a Connection
+
+| Connection | Use when | Trade-off |
+| --- | --- | --- |
+| npm dev dependency `ai-design-context` | A Node.js project wants CLI access and lockfile-pinned guidance. | Requires Node.js 20+; upgrades are explicit dependency updates. |
+| Git submodule at `.ai-design-rules/` | A team needs a reviewable, reproducible version. | The parent repository must update the pinned commit deliberately. |
+| Sibling checkout | One developer wants to evaluate the workflow locally. | The path is machine-specific and is not shared with the team. |
+| Starter kit only | The project needs the workflow and templates but not live graph retrieval. | The agent cannot resolve current research, rules, or patterns automatically. |
+
+## npm Installation
+
+The package is implemented in this checkout; registry installation requires its first npm publication. After publication, run these commands from the product repository:
+
+```bash
+npm install --save-dev --save-exact ai-design-context
+npx ai-design-context init
+npx ai-design-context context --task quick-capture --platform mobile --intent implement
+```
+
+Before publication, run `npm pack` in the knowledge-source checkout, then install that generated `.tgz` with `npm install --save-dev /path/to/ai-design-context-0.4.0.tgz` in the product repository. The same `init` and `context` commands work with the local tarball.
+
+`init` appends an optional, marked section to the existing `AGENTS.md` and creates only missing files under `docs/`, `templates/`, `reviews/`, and `benchmarks/`. It preserves existing project-specific instructions, populated documents, and edited integration blocks. Repeat it safely to create newly missing templates; it does not refresh an existing block. Review any newly created placeholders and fill them with actual product context. There are no install hooks and no runtime dependencies.
+
+Ask the agent to use the returned absolute reading paths, read research and rules, and preserve evidence limits. JSON output includes `knowledgeRoot`, relative `path`, and `absolutePath`. `--review` matches graph identifiers or phrases rather than analyzing arbitrary product files.
+
+Commit the package manifest and lockfile. Adopt future guidance deliberately with `npm install --save-dev --save-exact ai-design-context@<version>` after reviewing its changes.
+
+The GitHub URL remains `https://github.com/dev-ik/ai-design-rules`. The instructions below describe the Git submodule alternative; its existing `.ai-design-rules/` path remains valid.
+
+## Give the Agent This Task
+
+Run the agent from the root of the product repository and give it this prompt:
+
+```text
+Connect AI Design Context to this repository.
+
+Knowledge source:
+https://github.com/dev-ik/ai-design-rules.git
+
+Use the repository's existing conventions and make only integration changes.
+
+1. Inspect the repository instructions, documentation structure, package manager,
+   and current git status before changing files.
+2. If `.ai-design-rules` is absent, add the knowledge source there as a Git
+   submodule. If that path already exists, inspect and reuse it; do not replace it.
+3. Read `.ai-design-rules/starter-kit/README.md`,
+   `.ai-design-rules/starter-kit/PROJECT_INTEGRATION.md`, and
+   `.ai-design-rules/starter-kit/AGENTS.md`.
+4. Merge the relevant starter-kit instructions into the repository's existing
+   `AGENTS.md`. Preserve all existing project-specific and higher-priority rules.
+   If the repository uses another instruction file, adapt the integration to it
+   and explain the choice.
+5. Reuse existing product documentation. Create only missing PRD, persona,
+   user-flow, information-architecture, design-decision, feature-template,
+   design-review, and benchmark files. Never overwrite populated files with
+   starter-kit placeholders.
+6. Add these commands to the project instructions for user-facing product, UX,
+   UI, accessibility, motion, and design-prompt work:
+
+   npm --prefix .ai-design-rules run context -- --task "<task phrase>" --intent implement
+   npm --prefix .ai-design-rules run context -- --task "<task phrase>" --platform mobile --intent implement
+   npm --prefix .ai-design-rules run context -- --review "<path>" --intent qa
+
+   Tell agents to read the returned research and rules before making product
+   decisions. If no context resolves, they must record a knowledge gap instead of
+   inventing a rule. Skip graph retrieval for backend-only, infrastructure-only,
+   or unrelated maintenance work.
+7. Verify the knowledge source and run:
+
+   npm --prefix .ai-design-rules run check
+   npm --prefix .ai-design-rules run context -- --task quick-capture --platform mobile --intent implement
+
+8. Report the files created or merged, checks run, unresolved conflicts, and the
+   pinned AI Design Context commit.
+
+Do not change application behavior, dependencies, or product code as part of this
+integration.
+```
+
+The prompt intentionally tells the agent to merge rather than copy. Existing product context is more authoritative than starter-kit placeholders.
+
+## Verify the Connection
+
+From the product repository root, run:
+
+```bash
+git submodule status .ai-design-rules
+npm --prefix .ai-design-rules run check
+npm --prefix .ai-design-rules run context -- --task quick-capture --platform mobile --intent implement
+git status --short
+```
+
+The context command should return matched anchors, research, rules, and a recommended reading order. Review `git status` before committing: the integration should change only `.gitmodules`, the pinned submodule, agent instructions, and explicitly selected project documentation.
+
+## Use It on Product Work
+
+Before implementing a user-facing task:
+
+```bash
+npm --prefix .ai-design-rules run context -- --task "describe the task" --intent implement
+```
+
+Add `--platform mobile` when narrow-screen or touch behavior matters.
+
+Before reviewing an implementation or reference fixture:
+
+```bash
+npm --prefix .ai-design-rules run context -- --review "path/to/implementation" --intent qa
+```
+
+The agent should use the returned objects as bounded evidence, preserve the product's existing logic and design system, and report which rules and patterns influenced the result.
+
+## Update the Pinned Knowledge Source
+
+Update intentionally, then validate before committing the new submodule pointer:
+
+```bash
+git submodule update --remote .ai-design-rules
+npm --prefix .ai-design-rules run check
+```
+
+Review upstream changes before adopting them. A knowledge-source update can change the guidance an agent retrieves even when product code is unchanged.

package/starter-kit/PROJECT_INTEGRATION.md

@@ -0,0 +1,60 @@
+# Project Integration
+
+Integrate AI Design Context before implementation.
+
+## Workflow
+
+1. Understand the product problem.
+2. Capture relevant research or product context.
+3. Select applicable rules.
+4. Select applicable patterns.
+5. Explain design decisions.
+6. Prototype the smallest useful solution.
+7. Review UX, IA, accessibility, mobile behavior, states, and consistency.
+8. Implement after review.
+9. Benchmark meaningful product changes.
+10. Feed learnings back into project docs.
+
+## Design Options Checkpoint
+
+Before broad visual design, new screen direction, visual exploration, or product polish, ask whether the user wants:
+
+- multiple design options for comparison; or
+- one conservative implementation path that fits the existing product system.
+
+Skip this checkpoint for narrow bug fixes, already approved designs, small accessibility fixes, copy-only changes, or tasks where the user explicitly asked for immediate implementation.
+
+## Integration Modes
+
+Choose the lightest integration mode that gives agents enough context without weakening local project rules.
+
+- npm package: install `ai-design-context` as a dev dependency, run `npx ai-design-context init`, and use `npx ai-design-context context` for lockfile-pinned graph retrieval. See `INSTALL_WITH_AGENT.md` for publication status and local tarball installation.
+- Direct graph: use this repository directly when the product repo is the same workspace or can run the local context CLI.
+- Pinned snapshot: copy a reviewed snapshot into the product repo when agents need reproducible offline guidance.
+- Bridge skill: create a small local skill that points agents at the snapshot, local design docs, and applicable AI Design Context skills.
+- Optional reasoning layer: reference AI Design Context only for UI, UX, accessibility, responsive behavior, design review, or visual polish while keeping local architecture, API, security, routing, and test rules higher priority.
+
+Do not copy the starter kit wholesale into mature product repositories. Adapt only the parts that improve design reasoning and keep local product constraints authoritative.
+
+## Required Project Files
+
+For broad product work, prefer:
+
+- `docs/PRD.md`
+- `docs/PERSONAS.md`
+- `docs/USER_FLOWS.md`
+- `docs/INFORMATION_ARCHITECTURE.md`
+- `docs/DESIGN_DECISIONS.md`
+
+For narrow UI fixes, do not require a full document set. Capture the user goal, affected state, applicable rule or pattern, responsive assumption, accessibility check, and visual QA result in the task or review.
+
+## Contributor Expectation
+
+Every UI or UX change should state:
+
+- user goal;
+- applicable AI Design Context;
+- applicable patterns;
+- states handled;
+- review result;
+- validation or benchmark evidence when relevant.

package/starter-kit/README.md

@@ -0,0 +1,41 @@
+# AI Design Context Starter Kit
+
+This starter kit bootstraps a product repository that wants to use AI Design Context.
+
+Use the npm CLI's `init` command to append agent instructions and create only missing templates, or selectively copy these files into a target project. Adapt placeholders to that product. See `INSTALL_WITH_AGENT.md` for registry and local tarball installation.
+
+It does not include a UI kit, components, or generated rules. It gives agents a working structure for applying research, rules, patterns, prompts, reviews, benchmarks, and evidence.
+
+## Included
+
+- `INSTALL_WITH_AGENT.md` - safe, agent-driven installation for an existing repository.
+- `PROJECT_INTEGRATION.md` - how the project should adopt AI Design Context.
+- `AGENTS.md` - local agent instructions for feature work.
+- `BOOTSTRAP.md` - first setup checklist.
+- `docs/` - product context documents.
+- `templates/` - feature and task templates.
+- `reviews/` - design review checklist.
+- `benchmarks/` - benchmark checklist.
+
+## Recommended Workflow
+
+```text
+research -> rules -> patterns -> prompts -> prototype -> review -> code -> benchmark -> evidence
+```
+
+## How To Use
+
+For an existing repository, start with `INSTALL_WITH_AGENT.md`. It tells an agent how to preserve current instructions and populated project documents.
+
+1. Fill `docs/PRD.md`.
+2. Define users in `docs/PERSONAS.md`.
+3. Map the core journey in `docs/USER_FLOWS.md`.
+4. Define objects, screens, and navigation in `docs/INFORMATION_ARCHITECTURE.md`.
+5. Record key decisions in `docs/DESIGN_DECISIONS.md`.
+6. Use `templates/FEATURE_TEMPLATE.md` before implementing a feature.
+7. Run `reviews/DESIGN_REVIEW.md` before merging UI work.
+8. Store benchmark evidence for meaningful product changes.
+
+## Agent Rule
+
+Agents should not jump from a feature request directly to code. They should identify the user goal, select applicable AI Design Context, compose patterns, review states, and validate the result.

package/starter-kit/benchmarks/BENCHMARK_CHECKLIST.md

@@ -0,0 +1,10 @@
+# Benchmark Checklist
+
+- [ ] Product brief is fixed.
+- [ ] Same model/tooling is used for both runs.
+- [ ] Baseline output is stored.
+- [ ] AI Design Context output is stored.
+- [ ] Evaluation rubric is applied.
+- [ ] Scores include written evidence.
+- [ ] Difference is described without overclaiming.
+- [ ] Evidence is stored in the project.

package/starter-kit/docs/DESIGN_DECISIONS.md

@@ -0,0 +1,22 @@
+# Design Decisions
+
+Record important UX and product decisions.
+
+## Decision Template
+
+### Decision
+
+What was decided?
+
+### Why
+
+What user goal, rule, pattern, research, or constraint supports it?
+
+### Alternatives Considered
+
+- Alternative:
+- Reason rejected:
+
+### Evidence
+
+- Link to benchmark, review, issue, or product note:

package/starter-kit/docs/INFORMATION_ARCHITECTURE.md

@@ -0,0 +1,25 @@
+# Information Architecture
+
+Define screens, navigation and object model.
+
+## Objects
+
+- Object:
+- Key fields:
+- Status values:
+
+## Screens
+
+- Screen:
+- Purpose:
+- Primary action:
+
+## Navigation
+
+- Home surface:
+- Primary navigation:
+- Secondary navigation:
+
+## Relationships
+
+- Object A relates to Object B because...

package/starter-kit/docs/PERSONAS.md

@@ -0,0 +1,14 @@
+# Personas
+
+## Primary User
+
+- Context:
+- Motivation:
+- Constraints:
+- Repeated action:
+
+## Jobs To Be Done
+
+- When...
+- I want...
+- So I can...