@xgent-ai/skills 0.1.0 → 0.3.0

package/vendor/impeccable/bundle/blobs/edddeb3fad88adec9a055b1bf9d5c75418cbe97a13b1a7f6765e73249e482563

@@ -0,0 +1,144 @@
+/**
+ * Browser-side durable session helpers for Impeccable live mode.
+ *
+ * Kept separate from live-browser.js so recovery state can be tested without
+ * booting the full overlay UI. Served before live-browser.js and attached to
+ * window.__IMPECCABLE_LIVE_SESSION__.
+ */
+(function (root) {
+  'use strict';
+
+  function createLiveBrowserSessionState({ prefix, storage, idFactory }) {
+    if (!prefix) throw new Error('prefix required');
+    const store = storage || root.localStorage;
+    const makeId = idFactory || function () { return Math.random().toString(16).slice(2, 10); };
+    const sessionKey = prefix + '-session';
+    const handledKey = sessionKey + '-handled';
+    const scrollKey = sessionKey + '-scroll';
+    let checkpointRevision = 0;
+    const owner = makeId();
+
+    function safeRead(key) {
+      try { return store.getItem(key); } catch { return null; }
+    }
+
+    function safeWrite(key, value) {
+      try { store.setItem(key, value); } catch { /* quota exceeded or private mode */ }
+    }
+
+    function safeRemove(key) {
+      try { store.removeItem(key); } catch { /* unavailable storage */ }
+    }
+
+    function loadSession() {
+      try {
+        const raw = safeRead(sessionKey);
+        if (!raw) return null;
+        const parsed = JSON.parse(raw);
+        if (Number.isInteger(parsed.checkpointRevision)) {
+          checkpointRevision = Math.max(checkpointRevision, parsed.checkpointRevision);
+        }
+        return parsed;
+      } catch { return null; }
+    }
+
+    function saveSession(session) {
+      if (!session || !session.id) return;
+      const payload = {
+        ...session,
+        checkpointRevision,
+      };
+      safeWrite(sessionKey, JSON.stringify(payload));
+    }
+
+    function clearSession() {
+      safeRemove(sessionKey);
+    }
+
+    function nextCheckpointRevision() {
+      checkpointRevision += 1;
+      const existing = loadSession();
+      if (existing?.id) saveSession(existing);
+      return checkpointRevision;
+    }
+
+    function seedCheckpointRevision(value) {
+      if (Number.isInteger(value)) checkpointRevision = Math.max(checkpointRevision, value);
+      return checkpointRevision;
+    }
+
+    function currentCheckpointRevision() {
+      return checkpointRevision;
+    }
+
+    function readHandledIds() {
+      const raw = safeRead(handledKey);
+      if (!raw) return [];
+      try {
+        const parsed = JSON.parse(raw);
+        if (Array.isArray(parsed)) {
+          return parsed.filter(id => typeof id === 'string' && id);
+        }
+        if (typeof parsed === 'string' && parsed) return [parsed];
+      } catch { /* legacy values were stored as a plain session id */ }
+      return [raw];
+    }
+
+    function markHandled(id) {
+      if (!id) return;
+      const ids = readHandledIds().filter(existing => existing !== id);
+      ids.push(id);
+      safeWrite(handledKey, JSON.stringify(ids.slice(-8)));
+    }
+
+    function isHandled(id) {
+      return !!id && readHandledIds().includes(id);
+    }
+
+    function clearHandled(id) {
+      if (!id) {
+        safeRemove(handledKey);
+        return;
+      }
+      const remaining = readHandledIds().filter(existing => existing !== id);
+      if (remaining.length > 0) safeWrite(handledKey, JSON.stringify(remaining));
+      else safeRemove(handledKey);
+    }
+
+    function writeScrollY(y) {
+      safeWrite(scrollKey, String(y));
+    }
+
+    function readScrollY() {
+      const raw = safeRead(scrollKey);
+      if (raw == null) return null;
+      const n = parseFloat(raw);
+      return isFinite(n) ? n : null;
+    }
+
+    function clearScrollY() {
+      safeRemove(scrollKey);
+    }
+
+    return {
+      owner,
+      sessionKey,
+      handledKey,
+      scrollKey,
+      saveSession,
+      loadSession,
+      clearSession,
+      nextCheckpointRevision,
+      seedCheckpointRevision,
+      currentCheckpointRevision,
+      markHandled,
+      isHandled,
+      clearHandled,
+      writeScrollY,
+      readScrollY,
+      clearScrollY,
+    };
+  }
+
+  root.__IMPECCABLE_LIVE_SESSION__ = { createLiveBrowserSessionState };
+})(typeof window !== 'undefined' ? window : globalThis);

package/vendor/impeccable/bundle/blobs/ee0a15fcfc244b76b896a2650a17b35e444d4311166b69a3cfa32d11f8f44851

@@ -0,0 +1,30 @@
+{
+  "description": "Impeccable design detector: immediate-tier checks after Edit/Write on UI files, full-rule deep pass on Stop.",
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "[ ! -f \"${CLAUDE_PROJECT_DIR}/.claude/skills/impeccable/scripts/impeccable\" ] || \"${CLAUDE_PROJECT_DIR}/.claude/skills/impeccable/scripts/impeccable\" hook",
+            "timeout": 5,
+            "statusMessage": "Checking UI changes"
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "[ ! -f \"${CLAUDE_PROJECT_DIR}/.claude/skills/impeccable/scripts/impeccable\" ] || \"${CLAUDE_PROJECT_DIR}/.claude/skills/impeccable/scripts/impeccable\" hook",
+            "timeout": 30,
+            "statusMessage": "Design deep pass"
+          }
+        ]
+      }
+    ]
+  }
+}

package/vendor/impeccable/bundle/blobs/ee6d6d127c1c2ab3526d529a8e3698be2185b5e346ac617f37501de2c0698b97

@@ -0,0 +1,99 @@
+Quiet design is harder than bold design. Subtlety needs precision. Reduce visual intensity in designs that are too loud, aggressive, or overstimulating without losing personality or making the result generic.
+
+---
+
+## Visitor mode
+
+Persuade + Experience: "quieter" means more restrained palette, more whitespace, more typographic air. Drama is reduced, not eliminated; the POV stays intact.
+
+Operate + Read: "quieter" means reducing visual noise. Fewer background accents, flatter cards, less color, less motion. The tool should disappear more completely into the task.
+
+---
+
+## 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, do not guess. STOP and call the AskUserQuestion tool to clarify.
+
+**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined 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 restrained 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**: Subtlety requires precision. Quiet without intent collapses to generic.
+
+## 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 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 depth 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?
+- **Restrained, not absent**: Does the POV survive the cuts?
+
+When the result feels right, hand off to `/impeccable polish` for the final pass.

package/vendor/impeccable/bundle/blobs/ef0b8eca20e1321cf7216fd0bda41ce54b0cca197cfd1b075eb51f3436f59059

@@ -0,0 +1,24 @@
+# Command guidance
+
+## Workflow questions
+
+Give advice without executing commands; the menu below is only for bare invocations. Consult relevant command references as needed for prerequisites and scope. Link to the [docs](https://impeccable.style/docs/) for the broader workflow guide. If the user also requests execution, follow that request.
+
+## No-argument routing: the context-aware menu
+
+Read this when the user invokes `$impeccable` with no argument. They are asking "what should I do?" Make the menu context-aware instead of static.
+
+Setup has already run `impeccable context`. If that reported `NO_PRODUCT_MD`, the project has no captured context yet: lead the menu with `$impeccable init` as the top recommendation (one line on why) and still show the rest below; don't silently jump into init. Otherwise run `.agents/skills/impeccable/scripts/impeccable signals` once and read its JSON, then lead with the **2-3 highest-value next commands**, each with a one-line reason pulled from the signals, followed by the full menu (the Commands table in SKILL.md, grouped by category). **Never auto-run a command; the recommendation is a suggestion the user confirms.**
+
+Reason over the signals; there is no score to obey:
+
+- `setup.hasDesign` false while `setup.hasCode` true → `document` (capture the visual system).
+- `critique.latest` is `null` → the project has never been critiqued; for a set-up project with a real surface, offering `$impeccable critique <surface>` is a strong default.
+- `critique.latest` with a low `score` or non-zero `p0` / `p1` → `polish` (it reads that snapshot as its backlog and closes it when stale or cleared).
+- `git.changedFiles` pointing at one surface → scope `audit` or `polish` to those files specifically, naming them.
+- `devServer.running` true → `live` is available for in-browser iteration; if false, don't lead with `live`. **`live` and the bundled `impeccable detect` are web-only.** If `setup.platform` is `ios`, `android`, or `adaptive`, don't lead with either; the browser overlay and the HTML rule engine don't apply to native app code.
+- Otherwise group by intent (build new / improve what's there / iterate visually), tailored to the current surface and `setup.platform`.
+
+**If `scan.targets` is non-empty and `setup.platform` is not `ios`/`android`/`adaptive`, run `.agents/skills/impeccable/scripts/impeccable detect --json <scan.targets joined by spaces>` once** (the bundled detector over local files: no network, no npx; it reads HTML/CSS, so skip it for native projects). `scan.via` tells you what they are: `git-changes` (the markup/style files in your dirty tree, the most relevant set), `source-dir` (e.g. `src`, `app`), `html`, or `root`. Fold the hits into your picks: many quality / contrast hits → `audit` or `polish`; a specific slop family → the matching command (gradient text or eyebrows → `quieter` / `typeset`, flat or gray palette → `colorize`, and so on). It's a real, current signal that beats guessing. If detect errors or the tree is large and slow, skip it and recommend the user run `audit` themselves; never block the suggestion on it.
+
+Keep it to 2-3 pointed picks with the exact command to type. The menu stays the fallback; the recommendation is the lede.

package/vendor/impeccable/bundle/blobs/ef2dde00030580ed2765cbf7be9b2ea4a6f64cb915b804fd6f6abcf38051c7b9

@@ -0,0 +1,234 @@
+> **Additional context needed**: the "aha moment" you want users to reach, and users' experience level.
+
+Get users to first value as fast as possible. Onboarding's job is not to teach the product. Its job is to get people to the moment that proves the product is worth their time.
+
+## Assess Onboarding Needs
+
+Understand what users need to learn and why:
+
+1. **Identify the challenge**:
+   - What are users trying to accomplish?
+   - What's confusing or unclear about current experience?
+   - Where do users get stuck or drop off?
+   - What's the "aha moment" we want users to reach?
+
+2. **Understand the users**:
+   - What's their experience level? (Beginners, power users, mixed?)
+   - What's their motivation? (Excited and exploring? Required by work?)
+   - What's their time commitment? (5 minutes? 30 minutes?)
+   - What alternatives do they know? (Coming from competitor? New to category?)
+
+3. **Define success**:
+   - What's the minimum users need to learn to be successful?
+   - What's the key action we want them to take? (First project? First invite?)
+   - How do we know onboarding worked? (Completion rate? Time to value?)
+
+**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
+
+## Onboarding Principles
+
+Follow these core principles:
+
+### Show, Don't Tell
+- Demonstrate with working examples, not just descriptions
+- Provide real functionality in onboarding, not separate tutorial mode
+- Use progressive disclosure, teach one thing at a time
+
+### Make It Optional (When Possible)
+- Let experienced users skip onboarding
+- Don't block access to product
+- Provide "Skip" or "I'll explore on my own" options
+
+### Time to Value
+- Get users to their "aha moment" ASAP
+- Front-load most important concepts
+- Teach 20% that delivers 80% of value
+- Save advanced features for contextual discovery
+
+### Context Over Ceremony
+- Teach features when users need them, not upfront
+- Empty states are onboarding opportunities
+- Tooltips and hints at point of use
+
+### Respect User Intelligence
+- Don't patronize or over-explain
+- Be concise and clear
+- Assume users can figure out standard patterns
+
+## Design Onboarding Experiences
+
+Create appropriate onboarding for the context:
+
+### Initial Product Onboarding
+
+**Welcome Screen**:
+- Clear value proposition (what is this product?)
+- What users will learn/accomplish
+- Time estimate (honest about commitment)
+- Option to skip (for experienced users)
+
+**Account Setup**:
+- Minimal required information (collect more later)
+- Explain why you're asking for each piece of information
+- Smart defaults where possible
+- Social login when appropriate
+
+**Core Concept Introduction**:
+- Introduce 1-3 core concepts (not everything)
+- Use simple language and examples
+- Interactive when possible (do, don't just read)
+- Progress indication (step 1 of 3)
+
+**First Success**:
+- Guide users to accomplish something real
+- Pre-populated examples or templates
+- Celebrate completion (but don't overdo it)
+- Clear next steps
+
+### Feature Discovery & Adoption
+
+**Empty States**:
+Instead of blank space, show:
+- What will appear here (description + screenshot/illustration)
+- Why it's valuable
+- Clear CTA to create first item
+- Example or template option
+
+Example:
+```
+No projects yet
+Projects help you organize your work and collaborate with your team.
+[Create your first project] or [Start from template]
+```
+
+**Contextual Tooltips**:
+- Appear at relevant moment (first time user sees feature)
+- Point directly at relevant UI element
+- Brief explanation + benefit
+- Dismissable (with "Don't show again" option)
+- Optional "Learn more" link
+
+**Feature Announcements**:
+- Highlight new features when they're released
+- Show what's new and why it matters
+- Let users try immediately
+- Dismissable
+
+**Progressive Onboarding**:
+- Teach features when users encounter them
+- Badges or indicators on new/unused features
+- Unlock complexity gradually (don't show all options immediately)
+
+### Guided Tours & Walkthroughs
+
+**When to use**:
+- Complex interfaces with many features
+- Significant changes to existing product
+- Industry-specific tools needing domain knowledge
+
+**How to design**:
+- Spotlight specific UI elements (dim rest of page)
+- Keep steps short (3-7 steps max per tour)
+- Allow users to click through tour freely
+- Include "Skip tour" option
+- Make replayable (help menu)
+
+**Best practices**:
+- Interactive over passive (let users click real buttons)
+- Focus on workflow, not features ("Create a project" not "This is the project button")
+- Provide sample data so actions work
+
+### Interactive Tutorials
+
+**When to use**:
+- Users need hands-on practice
+- Concepts are complex or unfamiliar
+- High stakes (better to practice in safe environment)
+
+**How to design**:
+- Sandbox environment with sample data
+- Clear objectives ("Create a chart showing sales by region")
+- Step-by-step guidance
+- Validation (confirm they did it right)
+- Graduation moment (you're ready!)
+
+### Documentation & Help
+
+**In-product help**:
+- Contextual help links throughout interface
+- Keyboard shortcut reference
+- Search-able help center
+- Video tutorials for complex workflows
+
+**Help patterns**:
+- `?` icon near complex features
+- "Learn more" links in tooltips
+- Keyboard shortcut hints (`⌘K` shown on search box)
+
+## Empty State Design
+
+Every empty state needs:
+
+### What Will Be Here
+"Your recent projects will appear here"
+
+### Why It Matters
+"Projects help you organize your work and collaborate with your team"
+
+### How to Get Started
+[Create project] or [Import from template]
+
+### Visual Interest
+Illustration or icon (not just text on blank page)
+
+### Contextual Help
+"Need help getting started? [Watch 2-min tutorial]"
+
+**Empty state types**:
+- **First use**: Never used this feature (emphasize value, provide template)
+- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
+- **No results**: Search or filter returned nothing (suggest different query, clear filters)
+- **No permissions**: Can't access (explain why, how to get access)
+- **Error state**: Failed to load (explain what happened, retry option)
+
+## Implementation Patterns
+
+### Technical approaches:
+
+**Tooltip libraries**: Tippy.js, Popper.js
+**Tour libraries**: Intro.js, Shepherd.js, React Joyride
+**Modal patterns**: Focus trap, backdrop, ESC to close
+**Progress tracking**: LocalStorage for "seen" states
+**Analytics**: Track completion, drop-off points
+
+**Storage patterns**:
+```javascript
+// Track which onboarding steps user has seen
+localStorage.setItem('onboarding-completed', 'true');
+localStorage.setItem('feature-tooltip-seen-reports', 'true');
+```
+
+**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
+
+**NEVER**:
+- Force users through long onboarding before they can use product
+- Patronize users with obvious explanations
+- Show same tooltip repeatedly (respect dismissals)
+- Block all UI during tour (let users explore)
+- Create separate tutorial mode disconnected from real product
+- Overwhelm with information upfront (progressive disclosure!)
+- Hide "Skip" or make it hard to find
+- Forget about returning users (don't show initial onboarding again)
+
+## Verify Onboarding Quality
+
+Test with real users:
+
+- **Time to completion**: Can users complete onboarding quickly?
+- **Comprehension**: Do users understand after completing?
+- **Action**: Do users take desired next step?
+- **Skip rate**: Are too many users skipping? (Maybe it's too long or not valuable)
+- **Completion rate**: Are users completing? (If low, simplify)
+- **Time to value**: How long until users get first value?
+
+When users hit the aha moment fast and don't drop off, hand off to `$impeccable polish` for the final pass.

package/vendor/impeccable/bundle/blobs/f0c4d0615c7d520dfc2536c01cc7f1f3aab9b60ddc399ba01289fe62edb12370

@@ -0,0 +1,24 @@
+# Command guidance
+
+## Workflow questions
+
+Give advice without executing commands; the menu below is only for bare invocations. Consult relevant command references as needed for prerequisites and scope. Link to the [docs](https://impeccable.style/docs/) for the broader workflow guide. If the user also requests execution, follow that request.
+
+## No-argument routing: the context-aware menu
+
+Read this when the user invokes `/impeccable` with no argument. They are asking "what should I do?" Make the menu context-aware instead of static.
+
+Setup has already run `impeccable context`. If that reported `NO_PRODUCT_MD`, the project has no captured context yet: lead the menu with `/impeccable init` as the top recommendation (one line on why) and still show the rest below; don't silently jump into init. Otherwise run `.opencode/skills/impeccable/scripts/impeccable signals` once and read its JSON, then lead with the **2-3 highest-value next commands**, each with a one-line reason pulled from the signals, followed by the full menu (the Commands table in SKILL.md, grouped by category). **Never auto-run a command; the recommendation is a suggestion the user confirms.**
+
+Reason over the signals; there is no score to obey:
+
+- `setup.hasDesign` false while `setup.hasCode` true → `document` (capture the visual system).
+- `critique.latest` is `null` → the project has never been critiqued; for a set-up project with a real surface, offering `/impeccable critique <surface>` is a strong default.
+- `critique.latest` with a low `score` or non-zero `p0` / `p1` → `polish` (it reads that snapshot as its backlog and closes it when stale or cleared).
+- `git.changedFiles` pointing at one surface → scope `audit` or `polish` to those files specifically, naming them.
+- `devServer.running` true → `live` is available for in-browser iteration; if false, don't lead with `live`. **`live` and the bundled `impeccable detect` are web-only.** If `setup.platform` is `ios`, `android`, or `adaptive`, don't lead with either; the browser overlay and the HTML rule engine don't apply to native app code.
+- Otherwise group by intent (build new / improve what's there / iterate visually), tailored to the current surface and `setup.platform`.
+
+**If `scan.targets` is non-empty and `setup.platform` is not `ios`/`android`/`adaptive`, run `.opencode/skills/impeccable/scripts/impeccable detect --json <scan.targets joined by spaces>` once** (the bundled detector over local files: no network, no npx; it reads HTML/CSS, so skip it for native projects). `scan.via` tells you what they are: `git-changes` (the markup/style files in your dirty tree, the most relevant set), `source-dir` (e.g. `src`, `app`), `html`, or `root`. Fold the hits into your picks: many quality / contrast hits → `audit` or `polish`; a specific slop family → the matching command (gradient text or eyebrows → `quieter` / `typeset`, flat or gray palette → `colorize`, and so on). It's a real, current signal that beats guessing. If detect errors or the tree is large and slow, skip it and recommend the user run `audit` themselves; never block the suggestion on it.
+
+Keep it to 2-3 pointed picks with the exact command to type. The menu stays the fallback; the recommendation is the lede.