mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-11 21:57:14 +03:00
Paul BakausandClaude Opus 5
0e5c6cbe17
The critique report and the AskUserQuestion call shipped in one assistant message, so the report stayed hidden until the user answered the picker and the command read as if it had never run. Reorder critique's persistence steps so the temp-file cleanup runs after the report and trend line are sent. That cleanup now ends the message carrying the report, leaving the questions to open a fresh one. Both critique.md and overdrive.md state the constraint and why it exists, so the ordering is not an unexplained sequence a model can optimize away. Overdrive additionally moves its direction descriptions inside the question options, where the user is actually reading them. Also fix the ask_instruction splices. The placeholder is a complete sentence, but five call sites spliced it mid-sentence and shipped text like "stop and STOP and call the AskUserQuestion tool to clarify. before expanding it". Every call site is now sentence-initial and the twelve lowercase provider values are capitalized to match, with a comment in utils.js pinning the contract. Record a workflow-contract baseline for the current model lineup. The two failures seen while validating this change are pre-existing: bolder refinement fails on deepseek-v4-flash identically with bolder.md reverted to HEAD, and redesign replaces DESIGN is flaky on assertions driven by new-work.md, which this change does not touch. Prepared with AI assistance (Claude Code). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.2 KiB
3.2 KiB
Extract Flow
Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
Step 1: Discover the Design System
Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
CRITICAL: If no design system exists, do not create one yet. {{ask_instruction}} Understand the preferred location and structure first.
Step 2: Identify Patterns
Look for extraction opportunities in the target area:
- Repeated components: Similar UI patterns used 3+ times (buttons, cards, inputs)
- Hard-coded values: Colors, spacing, typography, shadows that should be tokens
- Inconsistent variations: Multiple implementations of the same concept
- Composition patterns: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
- Type styles: Repeated font-size + weight + line-height combinations
- Animation patterns: Repeated easing, duration, or keyframe combinations
Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
Step 3: Plan Extraction
Create a systematic plan:
- Components to extract: Which UI elements become reusable components?
- Tokens to create: Which hard-coded values become design tokens?
- Variants to support: What variations does each component need?
- Naming conventions: Component names, token names, prop names that match existing patterns
- Migration path: How to refactor existing uses to consume the new shared versions
IMPORTANT: Design systems grow incrementally. Extract what is clearly reusable now, not everything that might someday be reusable.
Step 4: Extract & Enrich
Build improved, reusable versions:
- Components: Clear props API with sensible defaults, proper variants for different use cases, accessibility built in (ARIA, keyboard navigation, focus management), documentation and usage examples
- Design tokens: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
- Patterns: When to use this pattern, code examples, variations and combinations
Step 5: Migrate
Replace existing uses with the new shared versions:
- Find all instances: Search for the patterns you extracted
- Replace systematically: Update each use to consume the shared version
- Test thoroughly: Ensure visual and functional parity
- Delete dead code: Remove the old implementations
Step 6: Document
Update design system documentation:
- Add new components to the component library
- Document token usage and values
- Add examples and guidelines
- Update any Storybook or component catalog
NEVER:
- Extract one-off, context-specific implementations without generalization
- Create components so generic they are useless
- Extract without considering existing design system conventions
- Skip proper TypeScript types or prop documentation
- Create tokens for every single value (tokens should have semantic meaning)
- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)