aw-ecc 1.4.21

package/.cursor/skills/article-writing/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: article-writing
+description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
+origin: ECC
+---
+
+# Article Writing
+
+Write long-form content that sounds like a real person or brand, not generic AI output.
+
+## When to Activate
+
+- drafting blog posts, essays, launch posts, guides, tutorials, or newsletter issues
+- turning notes, transcripts, or research into polished articles
+- matching an existing founder, operator, or brand voice from examples
+- tightening structure, pacing, and evidence in already-written long-form copy
+
+## Core Rules
+
+1. Lead with the concrete thing: example, output, anecdote, number, screenshot description, or code block.
+2. Explain after the example, not before.
+3. Prefer short, direct sentences over padded ones.
+4. Use specific numbers when available and sourced.
+5. Never invent biographical facts, company metrics, or customer evidence.
+
+## Voice Capture Workflow
+
+If the user wants a specific voice, collect one or more of:
+- published articles
+- newsletters
+- X / LinkedIn posts
+- docs or memos
+- a short style guide
+
+Then extract:
+- sentence length and rhythm
+- whether the voice is formal, conversational, or sharp
+- favored rhetorical devices such as parentheses, lists, fragments, or questions
+- tolerance for humor, opinion, and contrarian framing
+- formatting habits such as headers, bullets, code blocks, and pull quotes
+
+If no voice references are given, default to a direct, operator-style voice: concrete, practical, and low on hype.
+
+## Banned Patterns
+
+Delete and rewrite any of these:
+- generic openings like "In today's rapidly evolving landscape"
+- filler transitions such as "Moreover" and "Furthermore"
+- hype phrases like "game-changer", "cutting-edge", or "revolutionary"
+- vague claims without evidence
+- biography or credibility claims not backed by provided context
+
+## Writing Process
+
+1. Clarify the audience and purpose.
+2. Build a skeletal outline with one purpose per section.
+3. Start each section with evidence, example, or scene.
+4. Expand only where the next sentence earns its place.
+5. Remove anything that sounds templated or self-congratulatory.
+
+## Structure Guidance
+
+### Technical Guides
+- open with what the reader gets
+- use code or terminal examples in every major section
+- end with concrete takeaways, not a soft summary
+
+### Essays / Opinion Pieces
+- start with tension, contradiction, or a sharp observation
+- keep one argument thread per section
+- use examples that earn the opinion
+
+### Newsletters
+- keep the first screen strong
+- mix insight with updates, not diary filler
+- use clear section labels and easy skim structure
+
+## Quality Gate
+
+Before delivering:
+- verify factual claims against provided sources
+- remove filler and corporate language
+- confirm the voice matches the supplied examples
+- ensure every section adds new information
+- check formatting for the intended platform

package/.cursor/skills/bun-runtime/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: bun-runtime
+description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
+origin: ECC
+---
+
+# Bun Runtime
+
+Bun is a fast all-in-one JavaScript runtime and toolkit: runtime, package manager, bundler, and test runner.
+
+## When to Use
+
+- **Prefer Bun** for: new JS/TS projects, scripts where install/run speed matters, Vercel deployments with Bun runtime, and when you want a single toolchain (run + install + test + build).
+- **Prefer Node** for: maximum ecosystem compatibility, legacy tooling that assumes Node, or when a dependency has known Bun issues.
+
+Use when: adopting Bun, migrating from Node, writing or debugging Bun scripts/tests, or configuring Bun on Vercel or other platforms.
+
+## How It Works
+
+- **Runtime**: Drop-in Node-compatible runtime (built on JavaScriptCore, implemented in Zig).
+- **Package manager**: `bun install` is significantly faster than npm/yarn. Lockfile is `bun.lock` (text) by default in current Bun; older versions used `bun.lockb` (binary).
+- **Bundler**: Built-in bundler and transpiler for apps and libraries.
+- **Test runner**: Built-in `bun test` with Jest-like API.
+
+**Migration from Node**: Replace `node script.js` with `bun run script.js` or `bun script.js`. Run `bun install` in place of `npm install`; most packages work. Use `bun run` for npm scripts; `bun x` for npx-style one-off runs. Node built-ins are supported; prefer Bun APIs where they exist for better performance.
+
+**Vercel**: Set runtime to Bun in project settings. Build: `bun run build` or `bun build ./src/index.ts --outdir=dist`. Install: `bun install --frozen-lockfile` for reproducible deploys.
+
+## Examples
+
+### Run and install
+
+```bash
+# Install dependencies (creates/updates bun.lock or bun.lockb)
+bun install
+
+# Run a script or file
+bun run dev
+bun run src/index.ts
+bun src/index.ts
+```
+
+### Scripts and env
+
+```bash
+bun run --env-file=.env dev
+FOO=bar bun run script.ts
+```
+
+### Testing
+
+```bash
+bun test
+bun test --watch
+```
+
+```typescript
+// test/example.test.ts
+import { expect, test } from "bun:test";
+
+test("add", () => {
+  expect(1 + 2).toBe(3);
+});
+```
+
+### Runtime API
+
+```typescript
+const file = Bun.file("package.json");
+const json = await file.json();
+
+Bun.serve({
+  port: 3000,
+  fetch(req) {
+    return new Response("Hello");
+  },
+});
+```
+
+## Best Practices
+
+- Commit the lockfile (`bun.lock` or `bun.lockb`) for reproducible installs.
+- Prefer `bun run` for scripts. For TypeScript, Bun runs `.ts` natively.
+- Keep dependencies up to date; Bun and the ecosystem evolve quickly.

package/.cursor/skills/content-engine/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: content-engine
+description: Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.
+origin: ECC
+---
+
+# Content Engine
+
+Turn one idea into strong, platform-native content instead of posting the same thing everywhere.
+
+## When to Activate
+
+- writing X posts or threads
+- drafting LinkedIn posts or launch updates
+- scripting short-form video or YouTube explainers
+- repurposing articles, podcasts, demos, or docs into social content
+- building a lightweight content plan around a launch, milestone, or theme
+
+## First Questions
+
+Clarify:
+- source asset: what are we adapting from
+- audience: builders, investors, customers, operators, or general audience
+- platform: X, LinkedIn, TikTok, YouTube, newsletter, or multi-platform
+- goal: awareness, conversion, recruiting, authority, launch support, or engagement
+
+## Core Rules
+
+1. Adapt for the platform. Do not cross-post the same copy.
+2. Hooks matter more than summaries.
+3. Every post should carry one clear idea.
+4. Use specifics over slogans.
+5. Keep the ask small and clear.
+
+## Platform Guidance
+
+### X
+- open fast
+- one idea per post or per tweet in a thread
+- keep links out of the main body unless necessary
+- avoid hashtag spam
+
+### LinkedIn
+- strong first line
+- short paragraphs
+- more explicit framing around lessons, results, and takeaways
+
+### TikTok / Short Video
+- first 3 seconds must interrupt attention
+- script around visuals, not just narration
+- one demo, one claim, one CTA
+
+### YouTube
+- show the result early
+- structure by chapter
+- refresh the visual every 20-30 seconds
+
+### Newsletter
+- deliver one clear lens, not a bundle of unrelated items
+- make section titles skimmable
+- keep the opening paragraph doing real work
+
+## Repurposing Flow
+
+Default cascade:
+1. anchor asset: article, video, demo, memo, or launch doc
+2. extract 3-7 atomic ideas
+3. write platform-native variants
+4. trim repetition across outputs
+5. align CTAs with platform intent
+
+## Deliverables
+
+When asked for a campaign, return:
+- the core angle
+- platform-specific drafts
+- optional posting order
+- optional CTA variants
+- any missing inputs needed before publishing
+
+## Quality Gate
+
+Before delivering:
+- each draft reads natively for its platform
+- hooks are strong and specific
+- no generic hype language
+- no duplicated copy across platforms unless requested
+- the CTA matches the content and audience

package/.cursor/skills/documentation-lookup/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: documentation-lookup
+description: Use up-to-date library and framework docs via Context7 MCP instead of training data. Activates for setup questions, API references, code examples, or when the user names a framework (e.g. React, Next.js, Prisma).
+origin: ECC
+---
+
+# Documentation Lookup (Context7)
+
+When the user asks about libraries, frameworks, or APIs, fetch current documentation via the Context7 MCP (tools `resolve-library-id` and `query-docs`) instead of relying on training data.
+
+## Core Concepts
+
+- **Context7**: MCP server that exposes live documentation; use it instead of training data for libraries and APIs.
+- **resolve-library-id**: Returns Context7-compatible library IDs (e.g. `/vercel/next.js`) from a library name and query.
+- **query-docs**: Fetches documentation and code snippets for a given library ID and question. Always call resolve-library-id first to get a valid library ID.
+
+## When to use
+
+Activate when the user:
+
+- Asks setup or configuration questions (e.g. "How do I configure Next.js middleware?")
+- Requests code that depends on a library ("Write a Prisma query for...")
+- Needs API or reference information ("What are the Supabase auth methods?")
+- Mentions specific frameworks or libraries (React, Vue, Svelte, Express, Tailwind, Prisma, Supabase, etc.)
+
+Use this skill whenever the request depends on accurate, up-to-date behavior of a library, framework, or API. Applies across harnesses that have the Context7 MCP configured (e.g. Claude Code, Cursor, Codex).
+
+## How it works
+
+### Step 1: Resolve the Library ID
+
+Call the **resolve-library-id** MCP tool with:
+
+- **libraryName**: The library or product name taken from the user's question (e.g. `Next.js`, `Prisma`, `Supabase`).
+- **query**: The user's full question. This improves relevance ranking of results.
+
+You must obtain a Context7-compatible library ID (format `/org/project` or `/org/project/version`) before querying docs. Do not call query-docs without a valid library ID from this step.
+
+### Step 2: Select the Best Match
+
+From the resolution results, choose one result using:
+
+- **Name match**: Prefer exact or closest match to what the user asked for.
+- **Benchmark score**: Higher scores indicate better documentation quality (100 is highest).
+- **Source reputation**: Prefer High or Medium reputation when available.
+- **Version**: If the user specified a version (e.g. "React 19", "Next.js 15"), prefer a version-specific library ID if listed (e.g. `/org/project/v1.2.0`).
+
+### Step 3: Fetch the Documentation
+
+Call the **query-docs** MCP tool with:
+
+- **libraryId**: The selected Context7 library ID from Step 2 (e.g. `/vercel/next.js`).
+- **query**: The user's specific question or task. Be specific to get relevant snippets.
+
+Limit: do not call query-docs (or resolve-library-id) more than 3 times per question. If the answer is unclear after 3 calls, state the uncertainty and use the best information you have rather than guessing.
+
+### Step 4: Use the Documentation
+
+- Answer the user's question using the fetched, current information.
+- Include relevant code examples from the docs when helpful.
+- Cite the library or version when it matters (e.g. "In Next.js 15...").
+
+## Examples
+
+### Example: Next.js middleware
+
+1. Call **resolve-library-id** with `libraryName: "Next.js"`, `query: "How do I set up Next.js middleware?"`.
+2. From results, pick the best match (e.g. `/vercel/next.js`) by name and benchmark score.
+3. Call **query-docs** with `libraryId: "/vercel/next.js"`, `query: "How do I set up Next.js middleware?"`.
+4. Use the returned snippets and text to answer; include a minimal `middleware.ts` example from the docs if relevant.
+
+### Example: Prisma query
+
+1. Call **resolve-library-id** with `libraryName: "Prisma"`, `query: "How do I query with relations?"`.
+2. Select the official Prisma library ID (e.g. `/prisma/prisma`).
+3. Call **query-docs** with that `libraryId` and the query.
+4. Return the Prisma Client pattern (e.g. `include` or `select`) with a short code snippet from the docs.
+
+### Example: Supabase auth methods
+
+1. Call **resolve-library-id** with `libraryName: "Supabase"`, `query: "What are the auth methods?"`.
+2. Pick the Supabase docs library ID.
+3. Call **query-docs**; summarize the auth methods and show minimal examples from the fetched docs.
+
+## Best Practices
+
+- **Be specific**: Use the user's full question as the query where possible for better relevance.
+- **Version awareness**: When users mention versions, use version-specific library IDs from the resolve step when available.
+- **Prefer official sources**: When multiple matches exist, prefer official or primary packages over community forks.
+- **No sensitive data**: Redact API keys, passwords, tokens, and other secrets from any query sent to Context7. Treat the user's question as potentially containing secrets before passing it to resolve-library-id or query-docs.

package/.cursor/skills/frontend-slides/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: frontend-slides
+description: Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.
+origin: ECC
+---
+
+# Frontend Slides
+
+Create zero-dependency, animation-rich HTML presentations that run entirely in the browser.
+
+Inspired by the visual exploration approach showcased in work by [zarazhangrui](https://github.com/zarazhangrui).
+
+## When to Activate
+
+- Creating a talk deck, pitch deck, workshop deck, or internal presentation
+- Converting `.ppt` or `.pptx` slides into an HTML presentation
+- Improving an existing HTML presentation's layout, motion, or typography
+- Exploring presentation styles with a user who does not know their design preference yet
+
+## Non-Negotiables
+
+1. **Zero dependencies**: default to one self-contained HTML file with inline CSS and JS.
+2. **Viewport fit is mandatory**: every slide must fit inside one viewport with no internal scrolling.
+3. **Show, don't tell**: use visual previews instead of abstract style questionnaires.
+4. **Distinctive design**: avoid generic purple-gradient, Inter-on-white, template-looking decks.
+5. **Production quality**: keep code commented, accessible, responsive, and performant.
+
+Before generating, read `STYLE_PRESETS.md` for the viewport-safe CSS base, density limits, preset catalog, and CSS gotchas.
+
+## Workflow
+
+### 1. Detect Mode
+
+Choose one path:
+- **New presentation**: user has a topic, notes, or full draft
+- **PPT conversion**: user has `.ppt` or `.pptx`
+- **Enhancement**: user already has HTML slides and wants improvements
+
+### 2. Discover Content
+
+Ask only the minimum needed:
+- purpose: pitch, teaching, conference talk, internal update
+- length: short (5-10), medium (10-20), long (20+)
+- content state: finished copy, rough notes, topic only
+
+If the user has content, ask them to paste it before styling.
+
+### 3. Discover Style
+
+Default to visual exploration.
+
+If the user already knows the desired preset, skip previews and use it directly.
+
+Otherwise:
+1. Ask what feeling the deck should create: impressed, energized, focused, inspired.
+2. Generate **3 single-slide preview files** in `.ecc-design/slide-previews/`.
+3. Each preview must be self-contained, show typography/color/motion clearly, and stay under roughly 100 lines of slide content.
+4. Ask the user which preview to keep or what elements to mix.
+
+Use the preset guide in `STYLE_PRESETS.md` when mapping mood to style.
+
+### 4. Build the Presentation
+
+Output either:
+- `presentation.html`
+- `[presentation-name].html`
+
+Use an `assets/` folder only when the deck contains extracted or user-supplied images.
+
+Required structure:
+- semantic slide sections
+- a viewport-safe CSS base from `STYLE_PRESETS.md`
+- CSS custom properties for theme values
+- a presentation controller class for keyboard, wheel, and touch navigation
+- Intersection Observer for reveal animations
+- reduced-motion support
+
+### 5. Enforce Viewport Fit
+
+Treat this as a hard gate.
+
+Rules:
+- every `.slide` must use `height: 100vh; height: 100dvh; overflow: hidden;`
+- all type and spacing must scale with `clamp()`
+- when content does not fit, split into multiple slides
+- never solve overflow by shrinking text below readable sizes
+- never allow scrollbars inside a slide
+
+Use the density limits and mandatory CSS block in `STYLE_PRESETS.md`.
+
+### 6. Validate
+
+Check the finished deck at these sizes:
+- 1920x1080
+- 1280x720
+- 768x1024
+- 375x667
+- 667x375
+
+If browser automation is available, use it to verify no slide overflows and that keyboard navigation works.
+
+### 7. Deliver
+
+At handoff:
+- delete temporary preview files unless the user wants to keep them
+- open the deck with the platform-appropriate opener when useful
+- summarize file path, preset used, slide count, and easy theme customization points
+
+Use the correct opener for the current OS:
+- macOS: `open file.html`
+- Linux: `xdg-open file.html`
+- Windows: `start "" file.html`
+
+## PPT / PPTX Conversion
+
+For PowerPoint conversion:
+1. Prefer `python3` with `python-pptx` to extract text, images, and notes.
+2. If `python-pptx` is unavailable, ask whether to install it or fall back to a manual/export-based workflow.
+3. Preserve slide order, speaker notes, and extracted assets.
+4. After extraction, run the same style-selection workflow as a new presentation.
+
+Keep conversion cross-platform. Do not rely on macOS-only tools when Python can do the job.
+
+## Implementation Requirements
+
+### HTML / CSS
+
+- Use inline CSS and JS unless the user explicitly wants a multi-file project.
+- Fonts may come from Google Fonts or Fontshare.
+- Prefer atmospheric backgrounds, strong type hierarchy, and a clear visual direction.
+- Use abstract shapes, gradients, grids, noise, and geometry rather than illustrations.
+
+### JavaScript
+
+Include:
+- keyboard navigation
+- touch / swipe navigation
+- mouse wheel navigation
+- progress indicator or slide index
+- reveal-on-enter animation triggers
+
+### Accessibility
+
+- use semantic structure (`main`, `section`, `nav`)
+- keep contrast readable
+- support keyboard-only navigation
+- respect `prefers-reduced-motion`
+
+## Content Density Limits
+
+Use these maxima unless the user explicitly asks for denser slides and readability still holds:
+
+| Slide type | Limit |
+|------------|-------|
+| Title | 1 heading + 1 subtitle + optional tagline |
+| Content | 1 heading + 4-6 bullets or 2 short paragraphs |
+| Feature grid | 6 cards max |
+| Code | 8-10 lines max |
+| Quote | 1 quote + attribution |
+| Image | 1 image constrained by viewport |
+
+## Anti-Patterns
+
+- generic startup gradients with no visual identity
+- system-font decks unless intentionally editorial
+- long bullet walls
+- code blocks that need scrolling
+- fixed-height content boxes that break on short screens
+- invalid negated CSS functions like `-clamp(...)`
+
+## Related ECC Skills
+
+- `frontend-patterns` for component and interaction patterns around the deck
+- `liquid-glass-design` when a presentation intentionally borrows Apple glass aesthetics
+- `e2e-testing` if you need automated browser verification for the final deck
+
+## Deliverable Checklist
+
+- presentation runs from a local file in a browser
+- every slide fits the viewport without scrolling
+- style is distinctive and intentional
+- animation is meaningful, not noisy
+- reduced motion is respected
+- file paths and customization points are explained at handoff