@bastani/atomic 0.5.11 → 0.5.12-1

package/.agents/skills/prompt-engineer/references/quality_improvement.md

@@ -0,0 +1,193 @@
+# Quality Improvement Techniques
+
+This document covers techniques for improving specific aspects of language model output quality: consistency, factual accuracy, and security.
+
+## Reducing Hallucinations
+
+### Core Definition
+
+Language models can generate factually incorrect or contextually inconsistent text, a problem termed "hallucination." This guide provides strategies to minimize such issues.
+
+### Basic Strategies
+
+**1. Permission to Admit Uncertainty**
+Allow the model to say "I don't know" by explicitly granting permission to acknowledge uncertainty. This straightforward approach substantially reduces false information generation.
+
+Example:
+
+```
+If you don't know the answer or are uncertain, please say so rather than guessing.
+```
+
+**2. Direct Quotation Grounding**
+For very lengthy documents (100K+ tokens) or when working with multiple large documents, request that the model extract verbatim passages before proceeding with analysis. This anchors responses to actual source material rather than inferred content.
+
+Example:
+
+```
+First, find and quote the relevant passages from the document.
+Then, based only on those quotes, provide your analysis.
+```
+
+**3. Citation Verification**
+Make outputs traceable by requiring the model to cite supporting quotes for each claim. The model should then verify claims by locating corroborating evidence; unsupported statements must be removed.
+
+Example:
+
+```
+For each claim you make, provide a direct quote from the source material.
+After drafting your response, verify that each claim has supporting evidence.
+Remove any claims that cannot be substantiated with quotes.
+```
+
+### Advanced Approaches
+
+**Step-by-step reasoning**
+Request the model explain its logic before providing final answers, exposing potentially flawed assumptions
+
+**Multiple-run comparison**
+Execute identical prompts several times and analyze outputs for inconsistencies suggesting hallucinations
+
+**Progressive validation**
+Use prior responses as foundation for follow-up queries asking for verification or expansion of statements
+
+**Information source limitation**
+Explicitly restrict the model to provided materials, excluding general knowledge access
+
+Example:
+
+```
+Use ONLY the information provided in the attached documents.
+Do not use any external knowledge or general information.
+If the documents don't contain the information needed to answer, say so.
+```
+
+### Important Caveat
+
+While these techniques significantly reduce hallucinations, they don't eliminate them entirely. Always validate critical information, especially for high-stakes decisions.
+
+---
+
+## Increasing Consistency
+
+### Core Techniques
+
+**1. Format Specification**
+Define desired output structures using JSON, XML, or custom templates. This approach ensures the model understands all formatting requirements before generating responses.
+
+Example JSON:
+
+```json
+{
+    "sentiment": "positive|negative|neutral",
+    "confidence": "high|medium|low",
+    "key_themes": ["theme1", "theme2"],
+    "summary": "Brief summary here"
+}
+```
+
+Example XML:
+
+```xml
+<analysis>
+  <sentiment>positive|negative|neutral</sentiment>
+  <confidence>high|medium|low</confidence>
+  <key_themes>
+    <theme>theme1</theme>
+    <theme>theme2</theme>
+  </key_themes>
+  <summary>Brief summary here</summary>
+</analysis>
+```
+
+**2. Response Prefilling**
+Begin the Assistant turn with your desired structure. This technique "bypasses the model's default preamble and enforces your structure," making it particularly effective for standardized reports.
+
+Example:
+
+```
+User: Analyze this customer feedback.
+Assistant: {
+```
+
+This forces the model to immediately start with the JSON structure.
+
+**3. Example-Based Constraints**
+Supply concrete examples of desired output. Examples train the model's understanding better than abstract instructions alone.
+
+**4. Retrieval-Grounded Responses**
+For knowledge-dependent tasks, use retrieval mechanisms to anchor the model's replies in fixed information sets. This maintains contextual consistency across multiple interactions.
+
+**5. Prompt Chaining**
+Decompose intricate workflows into sequential, focused subtasks. This prevents inconsistency errors by ensuring "each subtask gets the model's full attention."
+
+### Practical Applications
+
+The guide demonstrates these techniques through real-world scenarios:
+
+- **Customer feedback analysis**: Using JSON structures for consistent categorization
+- **Sales report generation**: Via XML templates for standardized formatting
+- **Competitive intelligence**: With structured formats for comparable analysis
+- **IT support systems**: Leveraging knowledge bases for consistent responses
+
+Each example illustrates how precise specifications and contextual grounding produce reliable, repeatable outputs suitable for scaled operations.
+
+---
+
+## Mitigating Jailbreaks and Prompt Injections
+
+### Core Strategies
+
+**1. Harmlessness Screening**
+Pre-screen user inputs using a lightweight model for content moderation. Have the model evaluate whether submitted content "refers to harmful, illegal, or explicit activities" and respond with Y or N accordingly.
+
+Example:
+
+```
+Evaluate the following user input. Does it refer to harmful, illegal, or explicit activities?
+Respond with only Y or N.
+
+User input: <user_input>{USER_INPUT}</user_input>
+```
+
+**2. Input Validation**
+Filter prompts for jailbreaking patterns. You can use an LLM to create a generalized validation screen by providing known jailbreaking language as examples.
+
+**3. Prompt Engineering**
+Design system prompts that establish clear ethical boundaries. For instance, define organizational values including:
+
+- "Integrity: Never deceive or aid in deception"
+- "Compliance: Refuse any request that violates laws or our policies"
+
+Example system prompt:
+
+```
+You are an AI assistant for [Company]. You must adhere to these values:
+
+1. Integrity: Never deceive users or help them deceive others
+2. Safety: Refuse requests for harmful, illegal, or explicit content
+3. Compliance: Follow all applicable laws and company policies
+4. Privacy: Protect user data and confidential information
+
+If a request violates these values, politely explain why you cannot help and suggest an alternative approach if possible.
+```
+
+**4. User Accountability**
+Monitor for repeated abuse attempts. If a user "triggers the same kind of refusal multiple times," communicate that their actions violate usage policies and take appropriate enforcement action.
+
+**5. Continuous Monitoring**
+Regularly analyze outputs for jailbreaking indicators and use findings to refine your validation strategies iteratively.
+
+### Advanced Approach: Layered Protection
+
+Combine multiple safeguards for enterprise applications. For example, in a financial services context, the system should sequentially:
+
+1. Screen queries for compliance
+2. Process legitimate requests
+3. Refuse non-compliant ones with specific explanations
+
+This multi-layered approach creates comprehensive defense without relying on any single security mechanism.
+
+### Important Note
+
+No single technique provides complete protection. A defense-in-depth approach combining multiple strategies provides the most robust security against jailbreaks and prompt injections.

package/.agents/skills/quieter/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: quieter
+description: Tones down visually aggressive or overstimulating designs, reducing intensity while preserving quality. Use when the user mentions too bold, too loud, overwhelming, aggressive, garish, or wants a calmer, more refined aesthetic.
+version: 2.1.1
+user-invocable: true
+argument-hint: "[target]"
+---
+
+Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
+
+## MANDATORY PREPARATION
+
+Invoke /impeccable — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /impeccable teach first.
+
+---
+
+## Assess Current State
+
+Analyze what makes the design feel too intense:
+
+1. **Identify intensity sources**:
+   - **Color saturation**: Overly bright or saturated colors
+   - **Contrast extremes**: Too much high-contrast juxtaposition
+   - **Visual weight**: Too many bold, heavy elements competing
+   - **Animation excess**: Too much motion or overly dramatic effects
+   - **Complexity**: Too many visual elements, patterns, or decorations
+   - **Scale**: Everything is large and loud with no hierarchy
+
+2. **Understand the context**:
+   - What's the purpose? (Marketing vs tool vs reading experience)
+   - Who's the audience? (Some contexts need energy)
+   - What's working? (Don't throw away good ideas)
+   - What's the core message? (Preserve what matters)
+
+If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
+
+**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
+
+## Plan Refinement
+
+Create a strategy to reduce intensity while maintaining impact:
+
+- **Color approach**: Desaturate or shift to more sophisticated tones?
+- **Hierarchy approach**: Which elements should stay bold (very few), which should recede?
+- **Simplification approach**: What can be removed entirely?
+- **Sophistication approach**: How can we signal quality through restraint?
+
+**IMPORTANT**: Great quiet design is harder than great bold design. Subtlety requires precision.
+
+## Refine the Design
+
+Systematically reduce intensity across these dimensions:
+
+### Color Refinement
+- **Reduce saturation**: Shift from fully saturated to 70-85% saturation
+- **Soften palette**: Replace bright colors with muted, sophisticated tones
+- **Reduce color variety**: Use fewer colors more thoughtfully
+- **Neutral dominance**: Let neutrals do more work, use color as accent (10% rule)
+- **Gentler contrasts**: High contrast only where it matters most
+- **Tinted grays**: Use warm or cool tinted grays instead of pure gray—adds sophistication without loudness
+- **Never gray on color**: If you have gray text on a colored background, use a darker shade of that color or transparency instead
+
+### Visual Weight Reduction
+- **Typography**: Reduce font weights (900 → 600, 700 → 500), decrease sizes where appropriate
+- **Hierarchy through subtlety**: Use weight, size, and space instead of color and boldness
+- **White space**: Increase breathing room, reduce density
+- **Borders & lines**: Reduce thickness, decrease opacity, or remove entirely
+
+### Simplification
+- **Remove decorative elements**: Gradients, shadows, patterns, textures that don't serve purpose
+- **Simplify shapes**: Reduce border radius extremes, simplify custom shapes
+- **Reduce layering**: Flatten visual hierarchy where possible
+- **Clean up effects**: Reduce or remove blur effects, glows, multiple shadows
+
+### Motion Reduction
+- **Reduce animation intensity**: Shorter distances (10-20px instead of 40px), gentler easing
+- **Remove decorative animations**: Keep functional motion, remove flourishes
+- **Subtle micro-interactions**: Replace dramatic effects with gentle feedback
+- **Refined easing**: Use ease-out-quart for smooth, understated motion—never bounce or elastic
+- **Remove animations entirely** if they're not serving a clear purpose
+
+### Composition Refinement
+- **Reduce scale jumps**: Smaller contrast between sizes creates calmer feeling
+- **Align to grid**: Bring rogue elements back into systematic alignment
+- **Even out spacing**: Replace extreme spacing variations with consistent rhythm
+
+**NEVER**:
+- Make everything the same size/weight (hierarchy still matters)
+- Remove all color (quiet ≠ grayscale)
+- Eliminate all personality (maintain character through refinement)
+- Sacrifice usability for aesthetics (functional elements still need clear affordances)
+- Make everything small and light (some anchors needed)
+
+## Verify Quality
+
+Ensure refinement maintains quality:
+
+- **Still functional**: Can users still accomplish tasks easily?
+- **Still distinctive**: Does it have character, or is it generic now?
+- **Better reading**: Is text easier to read for extended periods?
+- **Sophistication**: Does it feel more refined and premium?
+
+Remember: Quiet design is confident design. It doesn't need to shout. Less is more, but less is also harder. Refine with precision and maintain intentionality.

package/.agents/skills/research-codebase/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: research-codebase
+description: Document codebase as-is with research directory for historical context
+argument-hint: "<research-question>"
+---
+
+# Research Codebase
+
+You are tasked with conducting comprehensive research across the codebase to answer user questions by spawning parallel sub-agents and synthesizing their findings.
+
+The user's research question/request is: **$ARGUMENTS**
+
+## Steps to follow after receiving the research query:
+
+<EXTREMELY_IMPORTANT>
+
+- OPTIMIZE the research question using your prompt-engineer skill to refine phrasing and structure for maximum clarity and precision.
+- After research is complete and the research artifact(s) are generated, provide an executive summary of the research and path to the research document(s) to the user, and ask if they have any follow-up questions or need clarification.
+
+</EXTREMELY_IMPORTANT>
+
+1. **Read any directly mentioned files first:**
+    - If the user mentions specific files (tickets, docs, or other notes), read them FULLY first
+    - **IMPORTANT**: Use the `readFile` tool WITHOUT limit/offset parameters to read entire files
+    - **CRITICAL**: Read these files yourself in the main context before spawning any sub-tasks
+    - This ensures you have full context before decomposing the research
+
+2. **Analyze and decompose the research question:**
+    - Break the research question down into composable research areas
+    - Take time to ultrathink about the underlying patterns, connections, and architectural implications the user might be seeking
+    - Identify specific components, patterns, or concepts to investigate
+    - Create a research plan using TodoWrite to track all subtasks
+    - Consider which directories, files, or architectural patterns are relevant
+
+3. **Spawn parallel sub-agent tasks:**
+    - Create multiple Task agents to research different aspects concurrently
+    - We now have specialized agents that know how to do specific research tasks:
+
+    **For codebase research:**
+    - Use the **codebase-locator** agent to find WHERE files and components live
+    - Use the **codebase-analyzer** agent to understand HOW specific code works (without critiquing it)
+    - Use the **codebase-pattern-finder** agent to find examples of existing patterns (without evaluating them)
+    - Output directory: `research/docs/`
+    - Examples:
+        - The database logic is found and can be documented in `research/docs/2024-01-10-database-implementation.md`
+        - The authentication flow is found and can be documented in `research/docs/2024-01-11-authentication-flow.md`
+
+    **IMPORTANT**: All agents are documentarians, not critics. They will describe what exists without suggesting improvements or identifying issues.
+
+    **For research directory:**
+    - Use the **codebase-research-locator** agent to discover what documents exist about the topic
+    - Use the **codebase-research-analyzer** agent to extract key insights from specific documents (only the most relevant ones)
+
+    **For online search:**
+    - VERY IMPORTANT: In case you discover external libraries as dependencies, use the **codebase-online-researcher** agent for external documentation and resources
+        - The agent fetches live web content using the **playwright-cli** skill (or `bunx @playwright/cli` / `curl`). Instruct it to apply the token-efficient fetch order: (1) try `curl https://<site>/llms.txt` for an AI-friendly index (see [llmstxt.org](https://llmstxt.org/llms.txt)), (2) try `curl <url> -H "Accept: text/markdown"` to get pre-converted Markdown (supported on Cloudflare-hosted docs via [Markdown for Agents](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/)), (3) fall back to HTML parsing via `playwright-cli`
+        - Instruct the agent to return LINKS with their findings and INCLUDE those links in the research document
+        - The agent should persist reusable source documents under `research/web/<YYYY-MM-DD>-<kebab-case-topic>.md` (with frontmatter noting `source_url`, `fetched_at`, and `fetch_method`) so future research can reuse them without re-fetching
+        - Output directory for the synthesized research artifact: `research/docs/`
+        - Examples:
+            - If researching `Redis` locks usage, the agent might find relevant usage and create a document `research/docs/2024-01-15-redis-locks-usage.md` with internal links to Redis docs and code references (and cache the fetched Redis docs under `research/web/`)
+            - If researching `OAuth` flows, the agent might find relevant external articles and create a document `research/docs/2024-01-16-oauth-flows.md` with links to those articles
+
+    The key is to use these agents intelligently:
+    - Start with locator agents to find what exists
+    - Then use analyzer agents on the most promising findings to document how they work
+    - Run multiple agents in parallel when they're searching for different things
+    - Each agent knows its job - just tell it what you're looking for
+    - Don't write detailed prompts about HOW to search - the agents already know
+    - Remind agents they are documenting, not evaluating or improving
+
+4. **Wait for all sub-agents to complete and synthesize:**
+    - IMPORTANT: Wait for ALL sub-agent tasks to complete before proceeding
+    - Compile all sub-agent results (both codebase and research findings)
+    - Prioritize live codebase findings as primary source of truth
+    - Use research findings as supplementary historical context
+    - Connect findings across different components
+    - Include specific file paths and line numbers for reference
+    - Highlight patterns, connections, and architectural decisions
+    - Answer the user's research question with concrete evidence
+    - **If findings reveal the original question was misframed** (e.g., the system works differently than assumed, or the components don't exist where expected), flag this to the user before finalizing the document. This is valuable signal — don't bury it.
+
+5. **Generate research document:**
+    - Follow the directory structure for research documents:
+
+```
+research/
+├── tickets/
+│   ├── YYYY-MM-DD-XXXX-description.md
+├── docs/
+│   ├── YYYY-MM-DD-topic.md
+├── notes/
+│   ├── YYYY-MM-DD-meeting.md
+├── ...
+└──
+```
+
+- Naming conventions:
+    - YYYY-MM-DD is today's date
+    - topic is a brief kebab-case description of the research topic
+    - meeting is a brief kebab-case description of the meeting topic
+    - XXXX is the ticket number (omit if no ticket)
+    - description is a brief kebab-case description of the research topic
+    - Examples:
+        - With ticket: `2025-01-08-1478-parent-child-tracking.md`
+        - Without ticket: `2025-01-08-authentication-flow.md`
+- Structure the document with YAML frontmatter followed by content:
+
+    ```markdown
+    ---
+    date: !`date '+%Y-%m-%d %H:%M:%S %Z'`
+    researcher: [Researcher name from thoughts status]
+    git_commit: !`git rev-parse --verify HEAD 2>/dev/null || echo "no-commits"`
+    branch: !`git branch --show-current 2>/dev/null || git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "unborn"`
+    repository: !`basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown-repo"`
+    topic: "[User's Question/Topic]"
+    tags: [research, codebase, relevant-component-names]
+    status: complete
+    last_updated: !`date '+%Y-%m-%d'`
+    last_updated_by: [Researcher name]
+    ---
+
+    # Research
+
+    ## Research Question
+
+    [Original user query]
+
+    ## Summary
+
+    [High-level documentation of what was found, answering the user's question by describing what exists]
+
+    ## Detailed Findings
+
+    ### [Component/Area 1]
+
+    - Description of what exists ([file.ext:line](link))
+    - How it connects to other components
+    - Current implementation details (without evaluation)
+
+    ### [Component/Area 2]
+
+    ...
+
+    ## Code References
+
+    - `path/to/file.py:123` - Description of what's there
+    - `another/file.ts:45-67` - Description of the code block
+
+    ## Architecture Documentation
+
+    [Current patterns, conventions, and design implementations found in the codebase]
+
+    ## Historical Context (from research/)
+
+    [Relevant insights from research/ directory with references]
+
+    - `research/docs/YYYY-MM-DD-topic.md` - Information about module X
+    - `research/notes/YYYY-MM-DD-meeting.md` - Past notes from internal engineering, customer, etc. discussions
+    - ...
+
+    ## Related Research
+
+    [Links to other research documents in research/]
+
+    ## Open Questions
+
+    [Any areas that need further investigation]
+    ```
+
+1. **Add GitHub permalinks (if applicable):**
+    - Check if on main branch or if commit is pushed: `git branch --show-current` and `git status`
+    - If on main/master or pushed, generate GitHub permalinks:
+        - Get repo info: `gh repo view --json owner,name`
+        - Create permalinks: `https://github.com/{owner}/{repo}/blob/{commit}/{file}#L{line}`
+    - Replace local file references with permalinks in the document
+
+2. **Present findings:**
+    - Present a concise summary of findings to the user
+    - Include key file references for easy navigation
+    - Ask if they have follow-up questions or need clarification
+
+3. **Handle follow-up questions:**
+
+- If the user has follow-up questions, append to the same research document
+- Update the frontmatter fields `last_updated` and `last_updated_by` to reflect the update
+- Add `last_updated_note: "Added follow-up research for [brief description]"` to frontmatter
+- Add a new section: `## Follow-up Research [timestamp]`
+- Spawn new sub-agents as needed for additional investigation
+- Continue updating the document and syncing
+
+## Important notes:
+
+- Please DO NOT implement anything in this stage, just create the comprehensive research document
+- Always use parallel Task agents to maximize efficiency and minimize context usage
+- Always run fresh codebase research - never rely solely on existing research documents
+- The `research/` directory provides historical context to supplement live findings
+- Focus on finding concrete file paths and line numbers for developer reference
+- Research documents should be self-contained with all necessary context
+- Each sub-agent prompt should be specific and focused on read-only documentation operations
+- Document cross-component connections and how systems interact
+- Include temporal context (when the research was conducted)
+- Link to GitHub when possible for permanent references
+- Keep the main agent focused on synthesis, not deep file reading
+- Have sub-agents document examples and usage patterns as they exist
+- Explore all of research/ directory, not just research subdirectory
+- **CRITICAL**: You and all sub-agents are documentarians, not evaluators
+- **REMEMBER**: Document what IS, not what SHOULD BE
+- **NO RECOMMENDATIONS**: Only describe the current state of the codebase
+- **File reading**: Always read mentioned files FULLY (no limit/offset) before spawning sub-tasks
+- **Critical ordering**: Follow the numbered steps exactly
+    - ALWAYS read mentioned files first before spawning sub-tasks (step 1)
+    - ALWAYS wait for all sub-agents to complete before synthesizing (step 4)
+    - ALWAYS gather metadata before writing the document (step 5 before step 6)
+    - NEVER write the research document with placeholder values
+
+- **Frontmatter consistency**:
+    - Always include frontmatter at the beginning of research documents
+    - Keep frontmatter fields consistent across all research documents
+    - Update frontmatter when adding follow-up research
+    - Use snake_case for multi-word field names (e.g., `last_updated`, `git_commit`)
+    - Tags should be relevant to the research topic and components studied
+
+## Final Output
+
+- A collection of research files with comprehensive research findings, properly formatted and linked, ready for consumption to create detailed specifications or design documents.
+- IMPORTANT: DO NOT generate any other artifacts or files OUTSIDE of the `research/` directory.

package/.agents/skills/shape/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: shape
+description: Plan the UX and UI for a feature before writing code. Runs a structured discovery interview, then produces a design brief that guides implementation. Use during the planning phase to establish design direction, constraints, and strategy before any code is written.
+version: 2.1.1
+user-invocable: true
+argument-hint: "[feature to shape]"
+---
+
+## MANDATORY PREPARATION
+
+Invoke /impeccable, which contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding. If no design context exists yet, you MUST run /impeccable teach first.
+
+---
+
+Shape the UX and UI for a feature before any code is written. This skill produces a **design brief**: a structured artifact that guides implementation through discovery, not guesswork.
+
+**Scope**: Design planning only. This skill does NOT write code. It produces the thinking that makes code good.
+
+**Output**: A design brief that can be handed off to /impeccable craft, /impeccable, or any other implementation skill.
+
+## Philosophy
+
+Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply first, so implementation is precise.
+
+## Phase 1: Discovery Interview
+
+**Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later.
+
+Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer.
+
+### Purpose & Context
+- What is this feature for? What problem does it solve?
+- Who specifically will use it? (Not "users"; be specific: role, context, frequency)
+- What does success look like? How will you know this feature is working?
+- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
+
+### Content & Data
+- What content or data does this feature display or collect?
+- What are the realistic ranges? (Minimum, typical, maximum, e.g., 0 items, 5 items, 500 items)
+- What are the edge cases? (Empty state, error state, first-time use, power user)
+- Is any content dynamic? What changes and how often?
+
+### Design Goals
+- What's the single most important thing a user should do or understand here?
+- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
+- Are there existing patterns in the product this should be consistent with?
+- Are there specific examples (inside or outside the product) that capture what you're going for?
+
+### Constraints
+- Are there technical constraints? (Framework, performance budget, browser support)
+- Are there content constraints? (Localization, dynamic text length, user-generated content)
+- Mobile/responsive requirements?
+- Accessibility requirements beyond WCAG AA?
+
+### Anti-Goals
+- What should this NOT be? What would be a wrong direction?
+- What's the biggest risk of getting this wrong?
+
+## Phase 2: Design Brief
+
+After the interview, synthesize everything into a structured design brief. Present it to the user for confirmation before considering this skill complete.
+
+### Brief Structure
+
+**1. Feature Summary** (2-3 sentences)
+What this is, who it's for, what it needs to accomplish.
+
+**2. Primary User Action**
+The single most important thing a user should do or understand here.
+
+**3. Design Direction**
+How this should feel. What aesthetic approach fits. Reference the project's design context from `.impeccable.md` and explain how this feature should express it.
+
+**4. Layout Strategy**
+High-level spatial approach: what gets emphasis, what's secondary, how information flows. Describe the visual hierarchy and rhythm, not specific CSS.
+
+**5. Key States**
+List every state the feature needs: default, empty, loading, error, success, edge cases. For each, note what the user needs to see and feel.
+
+**6. Interaction Model**
+How users interact with this feature. What happens on click, hover, scroll? What feedback do they get? What's the flow from entry to completion?
+
+**7. Content Requirements**
+What copy, labels, empty state messages, error messages, and microcopy are needed. Note any dynamic content and its realistic ranges.
+
+**8. Recommended References**
+Based on the brief, list which impeccable reference files would be most valuable during implementation (e.g., spatial-design.md for complex layouts, motion-design.md for animated features, interaction-design.md for form-heavy features).
+
+**9. Open Questions**
+Anything unresolved that the implementer should resolve during build.
+
+---
+
+ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
+
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)