quiver-cli 1.3.1 → 2.0.0

package/template/.agents/skills/design/impeccable/reference/audit.native.md

@@ -1,139 +0,0 @@
-Run systematic **technical** quality checks on a native app (`ios` / `android` / `adaptive`) and generate a comprehensive report. Don't fix issues; document them for other commands to address.
-
-This is a code-level audit, not a design critique. Audit from source (SwiftUI / UIKit / Compose / React Native / Flutter); no browser tooling or `detect.mjs` applies. Score against the platform reference(s): [ios.md](ios.md) / [android.md](android.md), both for `adaptive`. Read them before scoring if Setup hasn't already. The report skeleton mirrors [audit.md](audit.md); keep the two in sync when changing it.
-
-## Diagnostic Scan
-
-Run comprehensive checks across 5 dimensions. Score each dimension 0-4 using the criteria below.
-
-### 1. Accessibility (VoiceOver / TalkBack)
-
-**Check for**:
-- **Missing labels**: interactive elements without accessibility labels, traits/roles, or state announcements
-- **Reading and focus order**: illogical traversal, unreachable controls, focus lost on navigation
-- **Text scaling**: fixed point sizes defeating Dynamic Type (iOS) or px instead of sp (Android); layouts that clip or overlap at large sizes
-- **Touch targets**: below 44 pt (iOS) / 48 dp (Android), or crammed without spacing
-- **Reduce Motion ignored**: parallax and large slides with no crossfade alternative
-- **Contrast**: text failing contrast in either appearance, light or dark
-
-**Score 0-4**: 0=Screen reader unusable, 1=Major gaps (unlabeled controls, no scaling), 2=Partial (labels exist, order or scaling breaks), 3=Good (minor gaps), 4=Excellent (labeled, ordered, scales cleanly, Reduce Motion honored)
-
-### 2. Performance
-
-**Check for**:
-- **Slow startup**: heavy work on launch before first frame
-- **Unvirtualized lists**: long content without FlatList / LazyColumn / List recycling
-- **Main-thread jank**: synchronous work in scroll or gesture paths, dropped frames on 60/120 Hz
-- **Wasted rendering**: unnecessary re-renders (React Native) or recompositions (Compose); missing memoization/keys
-- **Image handling**: full-size images decoded for thumbnails, no caching
-- **App weight**: bloated JS bundle or binary, unused dependencies
-
-**Score 0-4**: 0=Janky everywhere, 1=Major problems (unvirtualized lists, slow launch), 2=Partial, 3=Good (minor improvements possible), 4=Excellent (fast launch, smooth scroll, lean)
-
-### 3. Appearance & Theming
-
-**Check for**:
-- **Hard-coded colors**: raw hex instead of semantic system colors (iOS) / Material color roles (Android) / design tokens
-- **Broken dark appearance**: missing dark variants, poor contrast in dark, quick inverts
-- **Dynamic Color** (Android 12+): no static fallback scheme, or ignored where it fits
-- **Off-platform materials**: hand-rolled visual materials where system materials or tonal elevation are expected
-
-**Score 0-4**: 0=Hard-coded everything, 1=Minimal tokens, 2=Partial (tokens exist, inconsistently used), 3=Good (minor hard-coded values), 4=Excellent (semantic throughout, both appearances first-class)
-
-### 4. Platform Conformance (CRITICAL)
-
-Score against the loaded platform reference(s), including their slop tests. **Check for**:
-- **Broken system gestures**: edge-swipe back disabled (iOS), predictive Back hijacked (Android)
-- **Inset violations**: content under the notch, Dynamic Island, home indicator, status bar, or keyboard
-- **Off-platform navigation**: custom global nav, overloaded tab bars, iOS patterns on Android or vice versa
-- **Web-shaped controls**: HTML-style buttons, custom toggles, hover-dependent affordances
-- **Icon drift**: mixed icon sets instead of SF Symbols / Material Symbols
-- **System drift**: repeated shortcuts or decorative patterns that conflict with the product, platform, or established design system
-
-**Score 0-4**: 0=Web port (nothing native), 1=Heavy violations (3-4 kinds), 2=Some (1-2 noticeable), 3=Mostly conformant (subtle issues), 4=Fully native (a fluent user trusts every screen)
-
-### 5. Adaptivity
-
-**Check for**:
-- **Stretched phone layouts**: tablet/iPad rendering a scaled-up phone UI instead of using size classes / window size classes
-- **Orientation breakage**: landscape clipping, ignored, or locked without reason
-- **Keyboard/IME handling**: inputs hidden behind the keyboard, no inset adjustment
-- **Multitasking**: iPad Split View / Android multi-window breaking layout
-- **Foldables**: hinge-unaware layouts on posture change (Android)
-
-**Score 0-4**: 0=One screen size only, 1=Major breakage (landscape or tablet broken), 2=Partial, 3=Good (minor edge cases), 4=Excellent (adapts across sizes, orientations, and windowing)
-
-## Generate Report
-
-### Audit Health Score
-
-| # | Dimension | Score | Key Finding |
-|---|-----------|-------|-------------|
-| 1 | Accessibility | ? | [most critical issue or "--"] |
-| 2 | Performance | ? | |
-| 3 | Appearance & Theming | ? | |
-| 4 | Platform Conformance | ? | |
-| 5 | Adaptivity | ? | |
-| **Total** | | **??/20** | **[Rating band]** |
-
-**Rating bands**: 18-20 Excellent (minor polish), 14-17 Good (address weak dimensions), 10-13 Acceptable (significant work needed), 6-9 Poor (major overhaul), 0-5 Critical (fundamental issues)
-
-### Platform Conformance Verdict
-**Start here.** Pass/fail: does this read as a native app or a ported website? List specific violations. Be brutally honest.
-
-### Executive Summary
-- Audit Health Score: **??/20** ([rating band])
-- Total issues found (count by severity: P0/P1/P2/P3)
-- Top 3-5 critical issues
-- Recommended next steps
-
-### Detailed Findings by Severity
-
-Tag every issue with **P0-P3 severity**:
-- **P0 Blocking**: Prevents task completion. Fix immediately
-- **P1 Major**: Significant difficulty or platform-guideline violation. Fix before release
-- **P2 Minor**: Annoyance, workaround exists. Fix in next pass
-- **P3 Polish**: Nice-to-fix, no real user impact. Fix if time permits
-
-For each issue, document:
-- **[P?] Issue name**
-- **Location**: Screen, file, line
-- **Category**: Accessibility / Performance / Theming / Conformance / Adaptivity
-- **Impact**: How it affects users
-- **Guideline**: The HIG / Material rule it violates (if applicable)
-- **Recommendation**: How to fix it
-- **Suggested command**: Which command to use (prefer: /impeccable adapt, /impeccable animate, /impeccable audit, /impeccable bolder, /impeccable clarify, /impeccable colorize, /impeccable critique, /impeccable delight, /impeccable distill, /impeccable document, /impeccable harden, /impeccable layout, /impeccable onboard, /impeccable optimize, /impeccable overdrive, /impeccable polish, /impeccable quieter, /impeccable shape, /impeccable typeset)
-
-### Patterns & Systemic Issues
-
-Identify recurring problems that indicate systemic gaps rather than one-off mistakes:
-- "Hard-coded colors appear in 15+ screens, should use semantic colors"
-- "Touch targets consistently below 44 pt throughout the tab bar and list rows"
-
-### Positive Findings
-
-Note what's working well: good practices to maintain and replicate.
-
-## Recommended Actions
-
-List recommended commands in priority order (P0 first, then P1, then P2):
-
-1. **[P?] `/command-name`**: Brief description (specific context from audit findings)
-2. **[P?] `/command-name`**: Brief description (specific context)
-
-**Rules**: Only recommend commands from: /impeccable adapt, /impeccable animate, /impeccable audit, /impeccable bolder, /impeccable clarify, /impeccable colorize, /impeccable critique, /impeccable delight, /impeccable distill, /impeccable document, /impeccable harden, /impeccable layout, /impeccable onboard, /impeccable optimize, /impeccable overdrive, /impeccable polish, /impeccable quieter, /impeccable shape, /impeccable typeset. Map findings to the most appropriate command. End with `/impeccable polish` as the final step if any fixes were recommended.
-
-After presenting the summary, tell the user:
-
-> You can ask me to run these one at a time, all at once, or in any order you prefer.
->
-> Re-run `/impeccable audit` after fixes to see your score improve.
-
-**IMPORTANT**: Be thorough but actionable. Too many P3 issues creates noise. Focus on what actually matters.
-
-**NEVER**:
-- Report issues without explaining impact (why does this matter?)
-- Provide generic recommendations (be specific and actionable)
-- Skip positive findings (celebrate what works)
-- Forget to prioritize (everything can't be P0)
-- Report false positives without verification

package/template/.agents/skills/design/impeccable/reference/bolder.md

@@ -1,33 +0,0 @@
-> **Additional context needed**: which section is the target, and what must stay untouched.
-
-An open direction round owns the word first: "bolder" said while a direction decision is on the table is the Bolder hand register steer, a fresh deal of foreign forms (see new-work.md), not this command. This command refines a surface whose world already shipped.
-
-"Bolder" is an amplification request, and almost always it is scoped to something that already exists. The surrounding page, its system, and its conventions are the given. Your job is to raise one part to the conviction the rest already implies, without rebuilding anything the brief did not name. The reflex answer, reaching for more effects, is the opposite of bold; reject it first.
-
-## Scope is sovereign
-
-"Everything else stays" is a literal instruction. Touch only the named target. Do not restyle its neighbors, do not migrate the page to a new idea, do not add colors, fonts, radii, shadows, or system primitives the surface does not already own. If the existing system genuinely cannot express the direction, do not expand it on your own. Ask the user directly to clarify what you cannot infer. Name the exact addition and the job it would do.
-
-## Why it reads flat
-
-A section usually reads flat for reasons its neighbors have already solved. Look at what the rest of the page does that this section does not: the display type at full strength, the structural devices that carry meaning, the signature motif, the density and pacing. A flat section is typically one that quietly opts out of the system's own strongest moves. The most reliable bolder pass brings the target up to the expressive level its neighbors already reach, in the system's own vocabulary rather than a new one.
-
-## The amplification
-
-- **Amplify what the system already owns.** Reuse its motif and its type scale at full strength, turned up for this section rather than invented for it. The bolder version should look more like the same brand, not less.
-- **Keep content true.** Existing claims are part of the scope: preserve them unless the user supplies replacements. If real evidence is essential to the direction but absent, ask for it.
-- **Commit, then clarify.** Half-measures read as noise. Make the one decisive move completely, then quiet everything around it so the move is legible. If every element got louder, the section got flatter.
-- **Give it its own rhythm.** The target should read as a peak in the scroll, a shift in density or pace from what surrounds it, not simply more of the same.
-
-## The skeleton test
-
-Strip the copy out of your planned section and study the bare structure. Does the skeleton still say what this section is and why it matters, through hierarchy and the system's devices alone? If it only works once the words return, the boldness is in the text size, not the design. A placeholder for an image or artifact names a job, an anchor and a piece of evidence, not a cue to drop in a decorative photo; fill that job with whatever the subject actually has.
-
-## Before you finish
-
-- Everything outside the named target is unchanged.
-- No new color, font, or system primitive appeared without being asked for.
-- The conventions the section carried, including anything that drives an action, still work the same way.
-- The section is unmistakably the same brand, only more sure of itself.
-
-When the target holds its own without pulling the page apart, hand off to `/impeccable polish` for the final pass.

package/template/.agents/skills/design/impeccable/reference/clarify.md

@@ -1,94 +0,0 @@
-> **Additional context needed**: audience knowledge and emotional state.
-
-Rewrite unclear interface text so users understand what happened, what matters, and what to do next. Preserve factual meaning, product terminology, and brand voice.
-
-## Audit the language
-
-Read the entire interaction path, not isolated strings. Identify:
-
-- ambiguous nouns, verbs, and actions;
-- internal jargon or assumed knowledge;
-- vague labels, outcomes, and system states;
-- missing consequences, recovery, or timing;
-- inconsistent terminology and capitalization;
-- redundant headings, intros, helper text, and confirmations;
-- text that breaks at realistic widths or in translation;
-- tone that ignores stress, risk, success, or urgency.
-
-Infer audience and task from product context and surrounding UI. Ask before changing factual claims, legal meaning, or a term that may be domain-specific.
-
-## Set the message hierarchy
-
-For each state, decide:
-
-1. the one fact the user needs now;
-2. the action available next;
-3. supporting context that changes the decision;
-4. the appropriate tone for this moment.
-
-Say each idea once. If the heading already explains the state, the introduction should add new information or disappear.
-
-## Rewrite by function
-
-### Actions and navigation
-
-Use a specific verb and object when the outcome is not already obvious. Labels should describe what will happen, not the gesture used to trigger it. Keep the same noun and verb for the same concept throughout the product.
-
-For destructive actions, name the object and consequence. Prefer undo over confirmation when recovery is safe. When confirmation is necessary, name the action on both the message and button instead of using `Yes`, `No`, `OK`, or `Submit`.
-
-### Forms
-
-Use persistent labels; placeholders are examples, not labels. Put format and eligibility requirements before submission. Explain why information is requested only when it is not obvious. Required and optional treatment should be consistent.
-
-Validation says what needs attention and how to correct it without blaming the user. Keep related instructions near the field and announce errors accessibly.
-
-### Errors and permissions
-
-An actionable error answers:
-
-1. what failed;
-2. why, when known and useful;
-3. how to recover or what alternative remains.
-
-Do not expose internal codes as the primary message. Do not promise a cause or resolution the system cannot know. Treat privacy, payment, deletion, access loss, and blocked work seriously; warmth is welcome, jokes are not.
-
-### Loading, empty, and success states
-
-Loading text names the real operation and sets an honest expectation when the wait is meaningful. Show determinate progress when available; never invent progress.
-
-An empty state distinguishes first use, no results, filters, permissions, and failure. Explain the state and provide the next useful action.
-
-Success confirms the completed outcome and mentions the next consequence only when it changes what the user should do. Routine success should be brief.
-
-### Help and instructional text
-
-Helper text answers an implicit question instead of restating the control. Use progressive disclosure for uncommon detail. Link text must make sense out of context; icon-only controls need accessible names.
-
-## Voice, accessibility, and localization
-
-Voice stays consistent; tone adapts to the moment. Use plain language without flattening terminology the audience genuinely knows.
-
-- Write complete translatable messages rather than concatenated fragments.
-- Keep variables and numbers structured so translators can reorder them.
-- Allow expansion instead of abbreviating prematurely.
-- Make alt text convey the image's information; use empty alt for decoration.
-- Keep screen-reader names aligned with visible labels and outcomes.
-- Do not rely on punctuation, color, or iconography to carry the message alone.
-
-Maintain a short terminology glossary when inconsistency spans the product. Do not vary words for literary effect in an interface.
-
-## Verify
-
-Read the flow in context and test:
-
-- comprehension without hidden product knowledge;
-- actionability at errors, empty states, and decision points;
-- factual accuracy and consistent terminology;
-- scanability at target widths and 200% zoom;
-- long names, localization expansion, pluralization, and dynamic values;
-- accessible names and announced state changes;
-- tone appropriate to consequence and emotional context.
-
-The final copy is as short as it can be without removing meaning or recovery.
-
-When the language reads cleanly, hand off to `/impeccable polish` for the final pass.

package/template/.agents/skills/design/impeccable/reference/colorize.md

@@ -1,86 +0,0 @@
-> **Additional context needed**: existing brand colors.
-
-Introduce color as hierarchy, meaning, and atmosphere. Preserve confirmed brand and semantic conventions; do not replace a visual world under the guise of colorizing it.
-
----
-
-## Visitor mode
-
-- **Persuade + Experience:** color may carry the voice and own large regions when the selected world calls for it.
-- **Operate + Read:** color primarily encodes action, selection, status, wayfinding, and reading hierarchy. Rarity gives an accent force.
-
-## Audit before choosing
-
-Read DESIGN.md, tokens, assets, current themes, and representative states. Identify:
-
-- which colors are confirmed brand commitments;
-- current surface, text, action, and semantic roles;
-- places where grayscale obscures hierarchy or state;
-- contrast failures and color-only communication;
-- light/dark or data-visualization requirements;
-- whether the task asks for more color or a new identity.
-
-If a new identity is required, use [new-work.md](new-work.md). Ask only when a binding brand decision cannot be inferred.
-
-## Choose a strategy
-
-Name the intended emotional temperature, dominant relationship, contrast range, and color dosage before editing. The strategy may be restrained or immersive; it must follow the brief and selected world rather than a fixed percentage rule.
-
-Build roles, not a bag of swatches:
-
-- canvas and elevated surfaces;
-- primary and secondary text;
-- action, focus, and selection;
-- borders and separators;
-- success, warning, error, and information;
-- data categories or scales when needed.
-
-Use the project's existing color space. For a new web palette, prefer OKLCH because lightness and chroma can be adjusted predictably. Choose hue from product meaning and visual direction, never from a default category association.
-
-## Apply at system scale
-
-- Let the strongest color own a deliberate region or role instead of scattering tiny accents.
-- Keep the primary action easy to find; do not spend its color on decoration.
-- Tint neutrals only when the brand hue genuinely creates cohesion. Neutral gray is valid when it serves the world.
-- On colored surfaces, derive secondary text from the foreground or surface hue rather than using washed-out generic gray.
-- Keep semantic meanings consistent, but respect platform and domain conventions instead of assuming fixed hues.
-- For data, use distinct lightness, chroma, shape, label, or pattern so color is not the only code.
-- In dark mode, design surface elevation and contrast explicitly; do not invert the light theme mechanically.
-- Define primitive values and semantic tokens when the project has a token system. Theme changes should normally remap semantic roles.
-
-Decoration without a relationship to hierarchy, state, content, or the visual world is not a color strategy.
-
-## Contrast and perception
-
-Verify computed foreground/background pairs:
-
-| Content | WCAG AA minimum |
-|---|---|
-| body text | 4.5:1 |
-| large text | 3:1 |
-| controls, icons, focus indicators | 3:1 |
-
-Do not rely on eyesight alone. Check interactive states, overlays, text on images, disabled content, and both themes. Simulate common vision deficiencies. Information conveyed by color also needs text, shape, iconography, or position.
-
-When deriving OKLCH ramps, vary lightness and reduce chroma near white and black. Do not keep high chroma at extreme lightness merely to make the math uniform. Prefer explicit colors over chains of translucent overlays when alpha would make contrast context-dependent.
-
-## Verify
-
-- Every color has a stable role or a world-specific atmospheric purpose.
-- Attention lands on the intended action, content, or state.
-- The palette works across quiet, dense, interactive, error, and empty states.
-- Light and dark themes are each composed, not mechanically inverted.
-- Contrast and non-color cues pass in all relevant states.
-- The result is recognizably this product, not a generic “colorful” treatment.
-
-When the palette earns its place, hand off to `/impeccable polish` for the final pass.
-
-## Live-mode signature params
-
-When invoked from live mode, every variant declares a `color-amount` parameter. Author CSS against `var(--p-color-amount, 0.5)` so the user can move from neutral to the variant's full color strategy without regeneration.
-
-```json
-{"id":"color-amount","kind":"range","min":0,"max":1,"step":0.05,"default":0.5,"label":"Color amount"}
-```
-
-Add at most two variant-specific parameters, such as palette, temperature, or tint behavior. Follow [live.md](live.md)'s parameter contract.

package/template/.agents/skills/design/impeccable/reference/craft-floor.md

@@ -1,44 +0,0 @@
-# Craft floor
-
-Load this after the direction is settled, and build without announcing the checklist. A pinned brief or the committed visual world overrides anything here; your own habit does not. When the design hook is active it already enforces the mechanical checks below as you edit: act on its findings instead of re-auditing each rule.
-
-## Verify
-
-Each of these is a check on the built result, not an intention. Run them together in the batched inspection rounds, not as separate screenshot trips; the checks share one render.
-
-- **Contrast:** body and placeholder text ≥4.5:1, large text ≥3:1. On colored surfaces tint secondary text from that hue or the foreground; never gray.
-- **Depth:** shadows carry an offset and a soft blur. A zero-offset colored halo is decoration.
-- **Spacing:** tight groups, generous separation, more space above a heading than below it. Read the computed values.
-- **Type:** body measure 65–75ch, display max 6rem, tracking floor -0.04em, balanced headings, obvious scale and weight steps. Run the real copy at every breakpoint and fix what overflows.
-- **Motion:** one authored moment, not scattered effects and not one identical entrance on every section. Exponential ease-out from an already-visible default. Reach past transform and opacity: blur, backdrop-filter, clip-path, mask, and shadow belong to the palette when they stay smooth.
-- **States:** hover, disabled, loading, error, empty. Plus real content, working controls, responsive composition, keyboard focus.
-- **Browser surfaces:** the parts you did not draw still carry the design. Text selection, the caret, custom scrollbars, focus rings, underline offset, and the numerals in tabular data all ship with browser defaults that belong to no design system. Theme them from the palette. This is the cheapest signal that a page was built rather than assembled, and the one models skip most reliably.
-- **Copy:** the product's own language. Controls name their action; errors name the problem and the recovery.
-- **Coverage:** every brief requirement present and findable within seconds.
-
-## Refuse
-
-These are the category's defaults, not bans: the brief's own words can earn any of them. Reaching for one when the axis is free means you were not deciding; recognizing that means rewriting the element, not softening it.
-
-Page scaffolds:
-
-- Same-size cards of icon plus heading plus text as the page structure. Cards are the lazy container; nested cards are always wrong.
-- The hero-metric template: big number, small label, supporting stats, accent.
-- A kicker or eyebrow above a heading. This one is a ban, not a default: no brief earns it back. The heading carries its own weight; delete the label and let the heading speak.
-- Section numbers (01 / 02 / 03) unless the sequence itself carries information the reader needs.
-- A modal for a task that needs neither interruption nor protected focus.
-
-Surface habits:
-
-- Gradient text. Emphasis comes from weight or size.
-- Glass and blur as decoration rather than as a specific effect.
-- A colored `border-left` or `border-right` above 1px on cards, list items, callouts, or alerts.
-- Hard offset shadows (`box-shadow: 4px 4px 0`) outside a world that is actually neobrutalist. The zero-blur block shadow is a costume, not a depth system; a world that did not choose it never earns it as a default.
-- Sparklines, progress rings, and soft-shadowed rounded rectangles standing in for content.
-- Monospace as a costume for "technical" rather than for code, data, or measurement.
-- A system display face (Impact, Arial Black, the platform sans) as the display voice of an own-world page. Source and self-host a face whose character matches the approved lettering; the closest installed font is a failure, not a fallback.
-- Unicode glyphs or emoji standing in for an icon system. Icons are drawn, from a real library or authored SVG, in one consistent stroke and weight.
-- Geometric masks standing in for organic contours. A circle, polygon, or radial-gradient cutout approximating a photographic subject's edge is the cheap version of the effect and reads worse than omitting it. Derive an alpha matte from the actual image, or produce a cut-out asset.
-- Light or dark picked by category. Pick it from the use scene: who, where, under what ambient light.
-
-The floor holds the mechanics; it never picks the direction. With every check green, spend the page on the committed world, and when torn between refined and committed, commit.

package/template/.agents/skills/design/impeccable/reference/craft.md

@@ -1,5 +0,0 @@
-# Craft (deprecated alias)
-
-`craft` is a deprecated alias for an ordinary request to make new visual work. It adds no setup, interview, checkpoint, tool, or quality behavior. Apply SKILL.md's normal routing: create missing PRODUCT.md through [init.md](init.md), then follow [new-work.md](new-work.md) for visual authority, world and surface decisions, implementation, and finish.
-
-Do not tell users they need to invoke `craft`. Natural requests such as “build this feature,” “make a landing page,” or “redesign this screen” use the same flow.