@andespindola/crow-skills 0.1.0

package/skills/crow-interface/reference/degraded/asset-producer.md

@@ -0,0 +1,5 @@
+<!-- Modified for Crow, 2026-10-20: portable paths and capability-specific corrections. Shared flow: workflow.md. Derived from Impeccable, Copyright 2025 Paul Bakaus, Apache-2.0. -->
+
+# Inline role fallback
+
+Use the canonical [asset-producer](../roles/asset-producer.md) role. Adopt its output contract, then return to the parent workflow. Disclose that no independent agent performed this pass; the calling thread performs both roles. This does not authorize additional edits or tools.

package/skills/crow-interface/reference/degraded/documenter.md

@@ -0,0 +1,5 @@
+<!-- Modified for Crow, 2026-10-20: portable paths and capability-specific corrections. Shared flow: workflow.md. Derived from Impeccable, Copyright 2025 Paul Bakaus, Apache-2.0. -->
+
+# Inline role fallback
+
+Use the canonical [documenter](../roles/documenter.md) role. Adopt its output contract, then return to the parent workflow. Disclose that no independent agent performed this pass; the calling thread performs both roles. This does not authorize additional edits or tools.

package/skills/crow-interface/reference/degraded/finish-reviewer.md

@@ -0,0 +1,5 @@
+<!-- Modified for Crow, 2026-10-20: portable paths and capability-specific corrections. Shared flow: workflow.md. Derived from Impeccable, Copyright 2025 Paul Bakaus, Apache-2.0. -->
+
+# Inline role fallback
+
+Use the canonical [finish-reviewer](../roles/finish-reviewer.md) role. Adopt its output contract, then return to the parent workflow. Disclose that no independent agent performed this pass; the calling thread performs both roles. This does not authorize additional edits or tools.

package/skills/crow-interface/reference/degraded/manual-edit-applier.md

@@ -0,0 +1,5 @@
+<!-- Modified for Crow, 2026-10-20: portable paths and capability-specific corrections. Shared flow: workflow.md. Derived from Impeccable, Copyright 2025 Paul Bakaus, Apache-2.0. -->
+
+# Inline role fallback
+
+Use the canonical [manual-edit-applier](../roles/manual-edit-applier.md) role. Adopt its output contract, then return to the parent workflow. Disclose that no independent agent performed this pass; the calling thread performs both roles. This does not authorize additional edits or tools.

package/skills/crow-interface/reference/delight.md

@@ -0,0 +1,72 @@
+<!-- Modified for Crow, 2026-10-20: portable paths and capability-specific corrections. Shared flow: workflow.md. Derived from Impeccable, Copyright 2025 Paul Bakaus, Apache-2.0. -->
+
+> **Additional context needed**: the brand's emotional range.
+
+Make the experience memorable at moments that earn it. Delight is not a layer of generic whimsy; it is product character revealed through a useful interaction, a humane response, or an unexpectedly considered detail.
+
+---
+
+## Visitor mode
+
+- **Persuade + Experience:** personality may run through voice, composition, motion, and discovery, provided the artifact remains the focus.
+- **Operate + Read:** concentrate delight at meaningful moments such as first use, completion, recovery, or mastery. Reliability carries everything else.
+
+## Find the opportunity
+
+Inspect the target, DESIGN.md, product voice, repeated-use frequency, and emotional context. Look for:
+
+- effort worth acknowledging;
+- waiting that can become informative;
+- an empty or first-use state that can orient;
+- an error or recovery moment that needs empathy;
+- an interaction whose physical or verbal response could express the brand;
+- a useful capability people might enjoy discovering.
+
+Do not manufacture a celebration for an ordinary click. Ask only when the brand's emotional range or the stakes cannot be inferred.
+
+## Define one delight thesis
+
+State in one sentence what the user should feel and why that feeling belongs to this product. Then choose the smallest system that can deliver it:
+
+- a distinctive response to a meaningful action;
+- product-specific language that clarifies while carrying voice;
+- an interaction or transition with a recognizable material behavior;
+- an illustration, sound, haptic, or environmental detail grounded in the product world;
+- a discovery reward that reveals real utility.
+
+Derive the treatment from product mechanism and visual world, not a stock catalog.
+
+## Build for the emotional moment
+
+- **Success:** match the response to the effort and consequence. Major milestones can expand; routine saves should simply feel certain.
+- **Waiting:** show truthful progress, useful context, or product-specific activity. Never fake work or delay completion to stage a flourish.
+- **Empty and first use:** make the next action clear before adding personality.
+- **Error and recovery:** lead with the problem and recovery. Warmth may reduce stress; jokes must not trivialize loss, money, privacy, or blocked work.
+- **Repeated interaction:** keep the response satisfying after the hundredth use. Variation is useful only when it remains coherent and predictable enough to trust.
+- **Discovery:** reward curiosity without hiding required functionality.
+
+Copy must use the product's language. Generic whimsy is worse than neutral clarity.
+
+## Protect the experience
+
+Delight must not:
+
+- delay, block, or obscure the primary task;
+- override platform conventions or accessibility;
+- add unrequested factual claims;
+- play sound without consent or ignore mute settings;
+- become mandatory, unskippable, or exhausting on repeat;
+- add a dependency or asset cost disproportionate to the moment.
+
+For authored motion, load [animate.md](animate.md). Respect screen readers, keyboard use, touch, localization, and cultural context. Nonessential loops stop when hidden. Make celebration intensity proportional to frequency and consequence.
+
+## Verify
+
+- The moment is specific enough that a neighboring product could not use it unchanged.
+- It improves comprehension, confidence, motivation, or emotional recovery.
+- The interface remains fast and obvious without the flourish.
+- Repetition does not turn charm into friction.
+- Muted, keyboard, touch, and localized paths work.
+- The result feels like the selected world, not a generic “delight” treatment.
+
+When the personality feels earned, hand off to `$crow-interface polish` for the final pass.

package/skills/crow-interface/reference/distill.md

@@ -0,0 +1,113 @@
+<!-- Modified for Crow, 2026-10-20: portable paths and capability-specific corrections. Shared flow: workflow.md. Derived from Impeccable, Copyright 2025 Paul Bakaus, Apache-2.0. -->
+
+Strip a design to its essence. Remove anything that doesn't earn its place: redundant elements, repeated information, decorative noise, cosmetic complexity.
+
+
+---
+
+## Assess Current State
+
+Analyze what makes the design feel complex or cluttered:
+
+1. **Identify complexity sources**:
+   - **Too many elements**: Competing buttons, redundant information, visual clutter
+   - **Excessive variation**: Too many colors, fonts, sizes, styles without purpose
+   - **Information overload**: Everything visible at once, no progressive disclosure
+   - **Visual noise**: Unnecessary borders, shadows, backgrounds, decorations
+   - **Confusing hierarchy**: Unclear what matters most
+   - **Feature creep**: Too many options, actions, or paths forward
+
+2. **Find the essence**:
+   - What's the primary user goal? (There should be ONE)
+   - What's actually necessary vs nice-to-have?
+   - What can be removed, hidden, or combined?
+   - What's the 20% that delivers 80% of value?
+
+If any of these are unclear from the codebase, do not guess. STOP and use Codex's structured user-input/question tool when available; if unavailable, ask directly in chat to clarify what you cannot infer.
+
+**CRITICAL**: Simplicity is not about removing features. It's about removing obstacles between users and their goals. Every element should justify its existence.
+
+## Plan Simplification
+
+Create a ruthless editing strategy:
+
+- **Core purpose**: What's the ONE thing this should accomplish?
+- **Essential elements**: What's truly necessary to achieve that purpose?
+- **Progressive disclosure**: What can be hidden until needed?
+- **Consolidation opportunities**: What can be combined or integrated?
+
+**IMPORTANT**: Simplification is hard. It requires saying no to good ideas to make room for great execution. Be ruthless.
+
+## Simplify the Design
+
+Systematically remove complexity across these dimensions:
+
+### Information Architecture
+- **Reduce scope**: Remove secondary actions, optional features, redundant information
+- **Progressive disclosure**: Hide complexity behind clear entry points (accordions, modals, step-through flows)
+- **Combine related actions**: Merge similar buttons, consolidate forms, group related content
+- **Clear hierarchy**: ONE primary action, few secondary actions, everything else tertiary or hidden
+- **Remove redundancy**: If it's said elsewhere, don't repeat it here
+
+### Visual Simplification
+- **Reduce color palette**: Use 1-2 colors plus neutrals, not 5-7 colors
+- **Limit typography**: One font family, 3-4 sizes maximum, 2-3 weights
+- **Remove decorations**: Eliminate borders, shadows, backgrounds that don't serve hierarchy or function
+- **Flatten structure**: Reduce nesting, remove unnecessary containers; never nest cards inside cards
+- **Remove unnecessary cards**: Cards aren't needed for basic layout; use spacing and alignment instead
+- **Consistent spacing**: Use one spacing scale, remove arbitrary gaps
+
+### Layout Simplification
+- **Linear flow**: Replace complex grids with simple vertical flow where possible
+- **Remove sidebars**: Move secondary content inline or hide it
+- **Full-width**: Use available space generously instead of complex multi-column layouts
+- **Consistent alignment**: Pick left or center, stick with it
+- **Generous white space**: Let content breathe, don't pack everything tight
+
+### Interaction Simplification
+- **Reduce choices**: Fewer buttons, fewer options, clearer path forward (paradox of choice is real)
+- **Smart defaults**: Make common choices automatic, only ask when necessary
+- **Inline actions**: Replace modal flows with inline editing where possible
+- **Remove steps**: Can the flow lose a step?
+- **Clear next action**: ONE obvious next action, not five competing ones
+
+### Content Simplification
+- **Shorter copy**: Cut every sentence in half, then do it again
+- **Active voice**: "Save changes" not "Changes will be saved"
+- **Remove jargon**: Plain language always wins
+- **Scannable structure**: Short paragraphs, bullet points, clear headings
+- **Essential information only**: Remove marketing fluff, legalese, hedging
+- **Remove redundant copy**: No headers restating intros, no repeated explanations, say it once
+
+### Code Simplification
+- **Remove unused code**: Dead CSS, unused components, orphaned files
+- **Flatten component trees**: Reduce nesting depth
+- **Consolidate styles**: Merge similar styles, use utilities consistently
+- **Reduce variants**: Does that component need 12 variations, or can 3 cover 90% of cases?
+
+**NEVER**:
+- Remove necessary functionality (simplicity ≠ feature-less)
+- Sacrifice accessibility for simplicity (clear labels and ARIA still required)
+- Make things so simple they're unclear (mystery ≠ minimalism)
+- Remove information users need to make decisions
+- Eliminate hierarchy completely (some things should stand out)
+- Oversimplify complex domains (match complexity to actual task complexity)
+
+## Verify Simplification
+
+Ensure simplification improves usability:
+
+- **Faster task completion**: Can users accomplish goals more quickly?
+- **Reduced cognitive load**: Is it easier to understand what to do?
+- **Still complete**: Are all necessary features still accessible?
+- **Clearer hierarchy**: Is it obvious what matters most?
+- **Better performance**: Does simpler design load faster?
+
+## Document Removed Complexity
+
+If you removed features or options:
+- Document why they were removed
+- Consider if they need alternative access points
+- Note any user feedback to monitor
+
+When the cuts feel right, hand off to `$crow-interface polish` for the final pass. As Antoine de Saint-Exupéry put it: "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."

package/skills/crow-interface/reference/doctor.md

@@ -0,0 +1,56 @@
+<!-- Modified for Crow, 2026-10-20: portable paths and capability-specific corrections. Shared flow: workflow.md. Derived from Impeccable, Copyright 2025 Paul Bakaus, Apache-2.0. -->
+
+Report and repair drift between this project's Impeccable artifacts and what the installed version reads: PRODUCT.md, DESIGN.md and its `.impeccable/design.json` sidecar, `.impeccable/config.json`, persisted surface briefs, and the design hook.
+
+This is maintenance, not design. Do not redesign anything, do not open files outside the ones the report names, and do not run any other command as a side effect.
+
+## What this owns, and what it does not
+
+Three kinds of drift travel under "out of date". Keep them apart:
+
+- **Tool version.** The installed skill is older than the published one. `impeccable context` reports that at boot as `UPDATE_AVAILABLE` and `npx impeccable update` fixes it. Not this command's job.
+- **Schema drift.** An artifact was written by an older Impeccable: fields nothing reads, fields now expected, files in retired locations. Mechanical, and this command repairs most of it.
+- **Truth drift.** The code moved on and the document no longer describes it. No file comparison settles this. `document` owns DESIGN.md, `init` owns PRODUCT.md, and this command's job is to hand them a specific gap rather than a vague suspicion.
+
+## Step 1: Run the pass
+
+```
+<skill-base-dir>/scripts/impeccable doctor --json
+```
+
+Add `--target <path>` when the user named a workspace, file, or route in a monorepo. Without it the report describes the repo root, and in a monorepo that is often the wrong project.
+
+The output carries `findings` (each with `id`, `artifact`, `path`, `severity`, `summary`, `fix`) and, in a monorepo, `workspaces` with each app's product and design resolution. `ruleRegistryAvailable: false` means ignored rule ids could not be validated; say so rather than implying that list is clean.
+
+An empty `findings` array is the good outcome. Say so in one line and stop.
+
+## Step 2: Act by severity
+
+The severity says what should happen, not how bad it is.
+
+- **`auto`** carries no decision. Run `<skill-base-dir>/scripts/impeccable doctor --fix` once to apply these, then report what it moved in one line. Do not ask permission first, and do not ask about them afterward.
+- **`mention`** needs the user to know but not to decide anything now. State each one in a sentence with its offered fix.
+- **`route`** needs a specific command. Name the command and the gap it would close. Run it only if the user asks in this turn; `init` and `document` are conversations, not repairs you perform unattended.
+
+Report all three groups in one pass. Findings are not errors and the command does not fail on them.
+
+## Step 3: Deprecated fields are binding
+
+A finding that reports a deprecated field (`## Register` is the current one) is not a style note. Treat that field as absent for every decision from here on, whatever value it holds, and offer to delete the section. Preserving it "just in case" is how a retired axis keeps steering current output.
+
+## Step 4: Do not overclaim on truth drift
+
+`design-md-drift` counts commits to the visual source directories since DESIGN.md was last edited. A commit count is not a contradiction. Report the number, say what it measures, and if the user wants to know whether the document is actually wrong, read DESIGN.md against the current tokens and components and answer from that. Never assert that DESIGN.md is stale because the number is large.
+
+The same restraint applies to `workspace-context-inherited`. Inheritance is a designed behavior. Whether one product record truthfully describes several apps is a question for the user, not a defect to fix.
+
+## Monorepo notes
+
+- `workspace-platform-native-evidence` is the finding that matters most here: a workspace carrying native build files while inheriting a root record that resolves to web gets web guidance for its whole life and never loads [ios.md](ios.md) or [android.md](android.md). The repair is a child PRODUCT.md in that workspace, because one inherited record cannot hold two platforms.
+- `config-project-roots-match-nothing` means every `projectRoots` glob missed, so the repo root is silently standing in as the active project. A renamed workspace directory is the usual cause. Report the patterns and ask which directories they should name.
+- `config-invalid-build-path` and `config-build-path-unset` both concern one key, `buildPath` in `.impeccable/config.json` (or the gitignored `.impeccable/config.local.json`, which wins for that developer). It holds `comp` or `code` and sets whether new surfaces are built from a generated comp or straight in code. An unread value does not fall back to the opposite path, so a project meaning `code` has been building comp-led; report the exact value. The unset finding fires only where a project has done direction work and never recorded a preference, and the offer belongs in it only when image generation exists in your tool surface. Without image generation there is nothing to choose and nothing to say.
+- Use the `workspaces` table to show the user which apps carry their own context, which inherit, and which have none, before proposing any change.
+
+## Opting out of the boot check
+
+`impeccable context` reports the cheap subset of these findings at session start, throttled to once a week per project. Set `"stalenessCheck": false` in `.impeccable/config.json` to silence that, or `IMPECCABLE_NO_STALENESS_CHECK=1` for one session. This command still works with the check disabled, and that is the combination to suggest for a user who wants the report only when they ask for it.