@heyai-rules/pilo-masterkit 2.1.0 → 3.1.0

package/.agent/skills/brand-voice/SKILL.md

@@ -1,97 +1,97 @@
----
-name: brand-voice
-description: Build a source-derived writing style profile from real posts, essays, launch notes, docs, or site copy, then reuse that profile across content, outreach, and social workflows. Use when the user wants voice consistency without generic AI writing tropes.
-origin: ECC
----
-
-# Brand Voice
-
-Build a durable voice profile from real source material, then use that profile everywhere instead of re-deriving style from scratch or defaulting to generic AI copy.
-
-## When to Activate
-
-- the user wants content or outreach in a specific voice
-- writing for X, LinkedIn, email, launch posts, threads, or product updates
-- adapting a known author's tone across channels
-- the existing content lane needs a reusable style system instead of one-off mimicry
-
-## Source Priority
-
-Use the strongest real source set available, in this order:
-
-1. recent original X posts and threads
-2. articles, essays, memos, launch notes, or newsletters
-3. real outbound emails or DMs that worked
-4. product docs, changelogs, README framing, and site copy
-
-Do not use generic platform exemplars as source material.
-
-## Collection Workflow
-
-1. Gather 5 to 20 representative samples when available.
-2. Prefer recent material over old material unless the user says the older writing is more canonical.
-3. Separate "public launch voice" from "private working voice" if the source set clearly splits.
-4. If live X access is available, use `x-api` to pull recent original posts before drafting.
-5. If site copy matters, include the current ECC landing page and repo/plugin framing.
-
-## What to Extract
-
-- rhythm and sentence length
-- compression vs explanation
-- capitalization norms
-- parenthetical use
-- question frequency and purpose
-- how sharply claims are made
-- how often numbers, mechanisms, or receipts show up
-- how transitions work
-- what the author never does
-
-## Output Contract
-
-Produce a reusable `VOICE PROFILE` block that downstream skills can consume directly. Use the schema in [references/voice-profile-schema.md](references/voice-profile-schema.md).
-
-Keep the profile structured and short enough to reuse in session context. The point is not literary criticism. The point is operational reuse.
-
-## Affaan / ECC Defaults
-
-If the user wants Affaan / ECC voice and live sources are thin, start here unless newer source material overrides it:
-
-- direct, compressed, concrete
-- specifics, mechanisms, receipts, and numbers beat adjectives
-- parentheticals are for qualification, narrowing, or over-clarification
-- capitalization is conventional unless there is a real reason to break it
-- questions are rare and should not be used as bait
-- tone can be sharp, blunt, skeptical, or dry
-- transitions should feel earned, not smoothed over
-
-## Hard Bans
-
-Delete and rewrite any of these:
-
-- fake curiosity hooks
-- "not X, just Y"
-- "no fluff"
-- forced lowercase
-- LinkedIn thought-leader cadence
-- bait questions
-- "Excited to share"
-- generic founder-journey filler
-- corny parentheticals
-
-## Persistence Rules
-
-- Reuse the latest confirmed `VOICE PROFILE` across related tasks in the same session.
-- If the user asks for a durable artifact, save the profile in the requested workspace location or memory surface.
-- Do not create repo-tracked files that store personal voice fingerprints unless the user explicitly asks for that.
-
-## Downstream Use
-
-Use this skill before or inside:
-
-- `content-engine`
-- `crosspost`
-- `lead-intelligence`
-- article or launch writing
-- cold or warm outbound across X, LinkedIn, and email
-
-If another skill already has a partial voice capture section, this skill is the canonical source of truth.
+---
+name: brand-voice
+description: Build a source-derived writing style profile from real posts, essays, launch notes, docs, or site copy, then reuse that profile across content, outreach, and social workflows. Use when the user wants voice consistency without generic AI writing tropes.
+origin: ECC
+---
+
+# Brand Voice
+
+Build a durable voice profile from real source material, then use that profile everywhere instead of re-deriving style from scratch or defaulting to generic AI copy.
+
+## When to Activate
+
+- the user wants content or outreach in a specific voice
+- writing for X, LinkedIn, email, launch posts, threads, or product updates
+- adapting a known author's tone across channels
+- the existing content lane needs a reusable style system instead of one-off mimicry
+
+## Source Priority
+
+Use the strongest real source set available, in this order:
+
+1. recent original X posts and threads
+2. articles, essays, memos, launch notes, or newsletters
+3. real outbound emails or DMs that worked
+4. product docs, changelogs, README framing, and site copy
+
+Do not use generic platform exemplars as source material.
+
+## Collection Workflow
+
+1. Gather 5 to 20 representative samples when available.
+2. Prefer recent material over old material unless the user says the older writing is more canonical.
+3. Separate "public launch voice" from "private working voice" if the source set clearly splits.
+4. If live X access is available, use `x-api` to pull recent original posts before drafting.
+5. If site copy matters, include the current ECC landing page and repo/plugin framing.
+
+## What to Extract
+
+- rhythm and sentence length
+- compression vs explanation
+- capitalization norms
+- parenthetical use
+- question frequency and purpose
+- how sharply claims are made
+- how often numbers, mechanisms, or receipts show up
+- how transitions work
+- what the author never does
+
+## Output Contract
+
+Produce a reusable `VOICE PROFILE` block that downstream skills can consume directly. Use the schema in [references/voice-profile-schema.md](references/voice-profile-schema.md).
+
+Keep the profile structured and short enough to reuse in session context. The point is not literary criticism. The point is operational reuse.
+
+## Affaan / ECC Defaults
+
+If the user wants Affaan / ECC voice and live sources are thin, start here unless newer source material overrides it:
+
+- direct, compressed, concrete
+- specifics, mechanisms, receipts, and numbers beat adjectives
+- parentheticals are for qualification, narrowing, or over-clarification
+- capitalization is conventional unless there is a real reason to break it
+- questions are rare and should not be used as bait
+- tone can be sharp, blunt, skeptical, or dry
+- transitions should feel earned, not smoothed over
+
+## Hard Bans
+
+Delete and rewrite any of these:
+
+- fake curiosity hooks
+- "not X, just Y"
+- "no fluff"
+- forced lowercase
+- LinkedIn thought-leader cadence
+- bait questions
+- "Excited to share"
+- generic founder-journey filler
+- corny parentheticals
+
+## Persistence Rules
+
+- Reuse the latest confirmed `VOICE PROFILE` across related tasks in the same session.
+- If the user asks for a durable artifact, save the profile in the requested workspace location or memory surface.
+- Do not create repo-tracked files that store personal voice fingerprints unless the user explicitly asks for that.
+
+## Downstream Use
+
+Use this skill before or inside:
+
+- `content-engine`
+- `crosspost`
+- `lead-intelligence`
+- article or launch writing
+- cold or warm outbound across X, LinkedIn, and email
+
+If another skill already has a partial voice capture section, this skill is the canonical source of truth.

package/.agent/skills/brand-voice/references/voice-profile-schema.md

@@ -1,55 +1,55 @@
-# Voice Profile Schema
-
-Use this exact structure when building a reusable voice profile:
-
-```text
-VOICE PROFILE
-=============
-Author:
-Goal:
-Confidence:
-
-Source Set
-- source 1
-- source 2
-- source 3
-
-Rhythm
-- short note on sentence length, pacing, and fragmentation
-
-Compression
-- how dense or explanatory the writing is
-
-Capitalization
-- conventional, mixed, or situational
-
-Parentheticals
-- how they are used and how they are not used
-
-Question Use
-- rare, frequent, rhetorical, direct, or mostly absent
-
-Claim Style
-- how claims are framed, supported, and sharpened
-
-Preferred Moves
-- concrete moves the author does use
-
-Banned Moves
-- specific patterns the author does not use
-
-CTA Rules
-- how, when, or whether to close with asks
-
-Channel Notes
-- X:
-- LinkedIn:
-- Email:
-```
-
-Guidelines:
-
-- Keep the profile concrete and source-backed.
-- Use short bullets, not essay paragraphs.
-- Every banned move should be observable in the source set or explicitly requested by the user.
-- If the source set conflicts, call out the split instead of averaging it into mush.
+# Voice Profile Schema
+
+Use this exact structure when building a reusable voice profile:
+
+```text
+VOICE PROFILE
+=============
+Author:
+Goal:
+Confidence:
+
+Source Set
+- source 1
+- source 2
+- source 3
+
+Rhythm
+- short note on sentence length, pacing, and fragmentation
+
+Compression
+- how dense or explanatory the writing is
+
+Capitalization
+- conventional, mixed, or situational
+
+Parentheticals
+- how they are used and how they are not used
+
+Question Use
+- rare, frequent, rhetorical, direct, or mostly absent
+
+Claim Style
+- how claims are framed, supported, and sharpened
+
+Preferred Moves
+- concrete moves the author does use
+
+Banned Moves
+- specific patterns the author does not use
+
+CTA Rules
+- how, when, or whether to close with asks
+
+Channel Notes
+- X:
+- LinkedIn:
+- Email:
+```
+
+Guidelines:
+
+- Keep the profile concrete and source-backed.
+- Use short bullets, not essay paragraphs.
+- Every banned move should be observable in the source set or explicitly requested by the user.
+- If the source set conflicts, call out the split instead of averaging it into mush.

package/.agent/skills/browser-qa/SKILL.md

@@ -1,87 +1,87 @@
----
-name: browser-qa
-description: Use this skill to automate visual testing and UI interaction verification using browser automation after deploying features.
-origin: ECC
----
-
-# Browser QA — Automated Visual Testing & Interaction
-
-## When to Use
-
-- After deploying a feature to staging/preview
-- When you need to verify UI behavior across pages
-- Before shipping — confirm layouts, forms, interactions actually work
-- When reviewing PRs that touch frontend code
-- Accessibility audits and responsive testing
-
-## How It Works
-
-Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user.
-
-### Phase 1: Smoke Test
-```
-1. Navigate to target URL
-2. Check for console errors (filter noise: analytics, third-party)
-3. Verify no 4xx/5xx in network requests
-4. Screenshot above-the-fold on desktop + mobile viewport
-5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
-```
-
-### Phase 2: Interaction Test
-```
-1. Click every nav link — verify no dead links
-2. Submit forms with valid data — verify success state
-3. Submit forms with invalid data — verify error state
-4. Test auth flow: login → protected page → logout
-5. Test critical user journeys (checkout, onboarding, search)
-```
-
-### Phase 3: Visual Regression
-```
-1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
-2. Compare against baseline screenshots (if stored)
-3. Flag layout shifts > 5px, missing elements, overflow
-4. Check dark mode if applicable
-```
-
-### Phase 4: Accessibility
-```
-1. Run axe-core or equivalent on each page
-2. Flag WCAG AA violations (contrast, labels, focus order)
-3. Verify keyboard navigation works end-to-end
-4. Check screen reader landmarks
-```
-
-## Output Format
-
-```markdown
-## QA Report — [URL] — [timestamp]
-
-### Smoke Test
-- Console errors: 0 critical, 2 warnings (analytics noise)
-- Network: all 200/304, no failures
-- Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓
-
-### Interactions
-- [✓] Nav links: 12/12 working
-- [✗] Contact form: missing error state for invalid email
-- [✓] Auth flow: login/logout working
-
-### Visual
-- [✗] Hero section overflows on 375px viewport
-- [✓] Dark mode: all pages consistent
-
-### Accessibility
-- 2 AA violations: missing alt text on hero image, low contrast on footer links
-
-### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
-```
-
-## Integration
-
-Works with any browser MCP:
-- `mChild__claude-in-chrome__*` tools (preferred — uses your actual Chrome)
-- Playwright via `mcp__browserbase__*`
-- Direct Puppeteer scripts
-
-Pair with `/canary-watch` for post-deploy monitoring.
+---
+name: browser-qa
+description: Use this skill to automate visual testing and UI interaction verification using browser automation after deploying features.
+origin: ECC
+---
+
+# Browser QA — Automated Visual Testing & Interaction
+
+## When to Use
+
+- After deploying a feature to staging/preview
+- When you need to verify UI behavior across pages
+- Before shipping — confirm layouts, forms, interactions actually work
+- When reviewing PRs that touch frontend code
+- Accessibility audits and responsive testing
+
+## How It Works
+
+Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user.
+
+### Phase 1: Smoke Test
+```
+1. Navigate to target URL
+2. Check for console errors (filter noise: analytics, third-party)
+3. Verify no 4xx/5xx in network requests
+4. Screenshot above-the-fold on desktop + mobile viewport
+5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
+```
+
+### Phase 2: Interaction Test
+```
+1. Click every nav link — verify no dead links
+2. Submit forms with valid data — verify success state
+3. Submit forms with invalid data — verify error state
+4. Test auth flow: login → protected page → logout
+5. Test critical user journeys (checkout, onboarding, search)
+```
+
+### Phase 3: Visual Regression
+```
+1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
+2. Compare against baseline screenshots (if stored)
+3. Flag layout shifts > 5px, missing elements, overflow
+4. Check dark mode if applicable
+```
+
+### Phase 4: Accessibility
+```
+1. Run axe-core or equivalent on each page
+2. Flag WCAG AA violations (contrast, labels, focus order)
+3. Verify keyboard navigation works end-to-end
+4. Check screen reader landmarks
+```
+
+## Output Format
+
+```markdown
+## QA Report — [URL] — [timestamp]
+
+### Smoke Test
+- Console errors: 0 critical, 2 warnings (analytics noise)
+- Network: all 200/304, no failures
+- Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓
+
+### Interactions
+- [✓] Nav links: 12/12 working
+- [✗] Contact form: missing error state for invalid email
+- [✓] Auth flow: login/logout working
+
+### Visual
+- [✗] Hero section overflows on 375px viewport
+- [✓] Dark mode: all pages consistent
+
+### Accessibility
+- 2 AA violations: missing alt text on hero image, low contrast on footer links
+
+### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
+```
+
+## Integration
+
+Works with any browser MCP:
+- `mChild__claude-in-chrome__*` tools (preferred — uses your actual Chrome)
+- Playwright via `mcp__browserbase__*`
+- Direct Puppeteer scripts
+
+Pair with `/canary-watch` for post-deploy monitoring.

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

@@ -1,84 +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.
+---
+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.