@olegkoval/agent-skills 1.19.1 → 1.20.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-agent-skills",
   "description": "Agent-agnostic skill catalog for Codex, Claude, Cursor, Grok, Copilot, Windsurf, Kiro, and other skill-aware tools.",
-  "version": "1.19.0",
+  "version": "1.19.1",
   "author": {
     "name": "Oleg Koval"
   },
@@ -32,6 +32,7 @@
     "./packages/software-development/macos-menubar-app",
     "./packages/software-development/skill-budget-audit",
     "./packages/software-development/crash-course",
-    "./packages/software-development/qodoloop"
+    "./packages/software-development/qodoloop",
+    "./packages/wearables/garmin-watchface"
   ]
 }

package/.cursor-plugin/index.json

@@ -110,6 +110,11 @@
       "name": "olko:qodoloop",
       "source": "./packages/software-development/qodoloop/adapters/cursor",
       "description": "Iteratively drives a GitHub PR to zero unresolved Qodo findings — reads each finding's own Agent Prompt, applies the fix, replies to the thread, resolves it, pushes, and waits for Qodo's next pass."
+    },
+    {
+      "name": "olko:garmin-watchface",
+      "source": "./packages/wearables/garmin-watchface/adapters/cursor",
+      "description": "Build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C."
     }
   ]
 }

package/.grok-plugin/index.json

@@ -120,6 +120,11 @@
       "name": "olko:qodoloop",
       "source": "./packages/software-development/qodoloop/adapters/grok",
       "description": "Iteratively drives a GitHub PR to zero unresolved Qodo findings — reads each finding's own Agent Prompt, applies the fix, replies to the thread, resolves it, pushes, and waits for Qodo's next pass."
+    },
+    {
+      "name": "olko:garmin-watchface",
+      "source": "./packages/wearables/garmin-watchface/adapters/grok",
+      "description": "Build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C."
     }
   ]
 }

package/.kiro/steering/garmin-watchface.md

@@ -0,0 +1,201 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+inclusion: manual
+description: "Build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C."
+---
+
+# Garmin Connect IQ watch faces
+
+Monkey C gives you almost no safety net. The compiler is happy to build a face
+that draws off the bottom of the screen, a test suite that contains no tests, and
+a colour that is not the colour you get. Everything below is a failure mode that
+looked like success first.
+
+**Read `references/` files as needed — do not read them all up front.**
+
+| File | When |
+| --- | --- |
+| `references/display.md` | Choosing colours, anything about brightness or legibility |
+| `references/layout.md` | Positioning anything; content clipped, overlapping, or off-screen |
+| `references/testing.md` | Writing tests; a suspiciously clean test run |
+| `references/simulator.md` | Screenshots, settings not applying, monkeydo hanging |
+| `references/devices.md` | Adding device support, launcher icons, API levels |
+| `references/store.md` | Publishing, listing copy, IP questions |
+
+## Tools
+
+Run these rather than reinventing them. All are standalone.
+
+```bash
+<skill-dir>/scripts/ciq-doctor                    # toolchain check: SDK, JDK, key, devices
+<skill-dir>/scripts/ciq-devices                   # survey installed devices by resolution
+<skill-dir>/scripts/ciq-devices --same-as fenix6pro   # products you can add with no code change
+<skill-dir>/scripts/ciq-capture out.png           # calibrated simulator screenshot
+<skill-dir>/scripts/ciq-capture out.png --face --size 260   # cropped + masked to the round display
+<skill-dir>/scripts/ciq-calibrate                 # re-derive the display rect if capture looks wrong
+```
+
+`<skill-dir>/scripts/ciq-capture` exists because `screencapture -R` grabs a screen *region*, not
+a window: without a frontmost check it silently photographs whatever is on top,
+and the window moves between simulator restarts. Both failure modes produce a
+plausible PNG of the wrong thing.
+
+## The five things that will bite you
+
+### 1. `make test` can compile zero tests and report success
+
+If `monkey.jungle` sets `base.excludeAnnotations = test`, every `(:test)`
+function is stripped from **every** target, including the unit-test build. You
+get `BUILD SUCCESSFUL` and a green run with nothing compiled — even when the test
+files reference symbols that no longer exist.
+
+Fix: a second jungle passed as an additional `-f`. See
+`<skill-dir>/templates/monkey.test.jungle` and the `test` target in `<skill-dir>/templates/Makefile`.
+
+**Prove it before you trust it.** Put a deliberately unresolvable symbol in one
+test and confirm the build fails:
+
+```monkeyc
+return ThisDoesNotExist.definitelyNotAFunction();
+```
+
+### 2. Never hardcode a Y coordinate or assume a font height
+
+`dc.getFontHeight()` is the only source of truth, and the numbers are larger than
+they look. Measured on fenix 6 Pro:
+
+| Font | Height |
+| --- | --- |
+| `FONT_XTINY` | 19 |
+| `FONT_TINY` | 29 |
+| `FONT_SMALL` | 32 |
+| `FONT_NUMBER_MEDIUM` | 74 |
+
+Content drawn past the screen height is simply invisible — no error, no warning,
+no clipping indicator. A two-line `FONT_NUMBER_MEDIUM` block is 148px of a 260px
+face.
+
+Derive every Y at draw time, and **clamp** so a bottom row cannot be pushed off:
+
+```monkeyc
+function clampRuleY(derived as Number, footerH as Number) as Number {
+    var reserved = (footerH * 2) + GAP_BELOW_RULE + GAP_BETWEEN_ROWS;
+    var maxRuleY = SCREEN - BOTTOM_MARGIN - reserved;
+    return derived > maxRuleY ? maxRuleY : derived;
+}
+```
+
+See `references/layout.md`.
+
+### 3. The screen is round; your layout is not
+
+Check content against the bezel curve, not the bounding square. A rectangle
+inscribed in a circle fails at its **corners** long before its sides.
+
+```monkeyc
+function halfWidthAt(y as Number) as Number {
+    var dy = y - CENTER;
+    var inside = (CENTER * CENTER) - (dy * dy);
+    return inside <= 0 ? 0 : Math.sqrt(inside).toNumber();
+}
+```
+
+### 4. Colours are quantised, and brightness is reflectance
+
+Many devices snap to a 4×4×4 lattice: `0x00 / 0x55 / 0xAA / 0xFF` per channel. A
+colour not already on it is not the colour that ships.
+
+More important: MIP screens are **transflective with no backlight**. A colour's
+brightness *is* how much ambient light it returns. Grey reflects about two-thirds
+of what white does. Choosing a photographically accurate grey for a large area
+makes the whole face read as dim on the wrist while looking fine in the
+simulator's backlit LCD.
+
+Corollary: a saturated colour on a glyph reflects only its own channel, making
+the thing you want to read the *dimmest* thing on screen.
+
+See `references/display.md`.
+
+### 5. The simulator lies about settings
+
+It persists app settings and **ignores changed defaults in `properties.xml`**
+until you do File → Reset All App Data. A property will keep reading its old
+value while the XML plainly says otherwise. This looks exactly like broken
+settings code.
+
+Reset also drops the loaded device, so relaunch and re-push afterwards.
+
+See `references/simulator.md`.
+
+## Workflow
+
+### Starting a face
+
+1. `<skill-dir>/scripts/ciq-doctor` — confirm SDK, JDK, developer key, target device installed.
+2. Copy `<skill-dir>/templates/Makefile`, `<skill-dir>/templates/monkey.jungle`, `<skill-dir>/templates/monkey.test.jungle`.
+3. Generate a fresh app id: `python3 -c "import uuid;print(uuid.uuid4().hex)"`.
+4. Split source by responsibility. This structure has held up well:
+
+| Module | Holds |
+| --- | --- |
+| `Palette.mc` | Colours only, all lattice-exact |
+| `Layout.mc` | Geometry, derivations, bezel maths — no drawing |
+| `<Widget>.mc` | Drawing primitives (rows, bars, segments) |
+| `Fields.mc` | Formatting and thresholds — pure, easy to test |
+| `Sensors.mc` | Sensor reads with null handling |
+| `<Name>View.mc` | Composition only |
+
+Keeping `Layout` free of `Dc` calls is what makes geometry unit-testable.
+
+### Every change
+
+```bash
+make build && make test && make lint
+```
+
+`make lint` is level 3 and catches real problems the level 2 build allows.
+
+### Before committing
+
+Capture and *look at it*. Layout bugs are invisible in a passing test run:
+
+```bash
+make build && make sim
+<skill-dir>/scripts/ciq-capture /tmp/face.png --face --size 260
+```
+
+Then Read the PNG. Every layout bug in this skill's history was found by looking,
+not by testing.
+
+## Monkey C gotchas
+
+- Module-level functions take **no** visibility modifier. `private` and `hidden`
+  are class-only; at module scope they are syntax errors.
+- `dc.fillPolygon` wants `Array<[Numeric, Numeric]>`. Cast the literal:
+  `[[x, y], ...] as Array<[Numeric, Numeric]>`.
+- `getInitialView()` returns
+  `[WatchUi.Views] or [WatchUi.Views, WatchUi.InputDelegates]`.
+- `Application.Properties.getValue()` **throws** when a key is absent, which
+  happens on a fresh install before settings have ever been written. Wrap every
+  read with a default.
+- Integer division everywhere. Centring an odd width leaves a 1px skew — write
+  tests that allow it rather than forcing constants to stay even.
+
+## Reference watches and homages
+
+If reproducing a real object, get these right before anything else, because they
+are what makes it recognisable:
+
+- **Display polarity.** A 1970s LCD is *positive*: dark segments on a pale panel,
+  the inverse of every modern face. Getting this backwards turns a crystal into a
+  screen.
+- **Proportion.** Bezels on vintage digitals are thick; the window is smaller
+  than memory suggests.
+- **Where the legends sit** — maker's name on the bezel, not the glass.
+
+No system font is a segment display. If you need one, draw it: see
+`references/layout.md` for a working seven-segment renderer, including the ghost
+(unlit) segments that are most of what sells the effect.
+
+**Do not print a real brand on the face.** See `references/store.md`.

package/.windsurf/rules/garmin-watchface.md

@@ -0,0 +1,200 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C."
+---
+
+# Garmin Connect IQ watch faces
+
+Monkey C gives you almost no safety net. The compiler is happy to build a face
+that draws off the bottom of the screen, a test suite that contains no tests, and
+a colour that is not the colour you get. Everything below is a failure mode that
+looked like success first.
+
+**Read `references/` files as needed — do not read them all up front.**
+
+| File | When |
+| --- | --- |
+| `references/display.md` | Choosing colours, anything about brightness or legibility |
+| `references/layout.md` | Positioning anything; content clipped, overlapping, or off-screen |
+| `references/testing.md` | Writing tests; a suspiciously clean test run |
+| `references/simulator.md` | Screenshots, settings not applying, monkeydo hanging |
+| `references/devices.md` | Adding device support, launcher icons, API levels |
+| `references/store.md` | Publishing, listing copy, IP questions |
+
+## Tools
+
+Run these rather than reinventing them. All are standalone.
+
+```bash
+<skill-dir>/scripts/ciq-doctor                    # toolchain check: SDK, JDK, key, devices
+<skill-dir>/scripts/ciq-devices                   # survey installed devices by resolution
+<skill-dir>/scripts/ciq-devices --same-as fenix6pro   # products you can add with no code change
+<skill-dir>/scripts/ciq-capture out.png           # calibrated simulator screenshot
+<skill-dir>/scripts/ciq-capture out.png --face --size 260   # cropped + masked to the round display
+<skill-dir>/scripts/ciq-calibrate                 # re-derive the display rect if capture looks wrong
+```
+
+`<skill-dir>/scripts/ciq-capture` exists because `screencapture -R` grabs a screen *region*, not
+a window: without a frontmost check it silently photographs whatever is on top,
+and the window moves between simulator restarts. Both failure modes produce a
+plausible PNG of the wrong thing.
+
+## The five things that will bite you
+
+### 1. `make test` can compile zero tests and report success
+
+If `monkey.jungle` sets `base.excludeAnnotations = test`, every `(:test)`
+function is stripped from **every** target, including the unit-test build. You
+get `BUILD SUCCESSFUL` and a green run with nothing compiled — even when the test
+files reference symbols that no longer exist.
+
+Fix: a second jungle passed as an additional `-f`. See
+`<skill-dir>/templates/monkey.test.jungle` and the `test` target in `<skill-dir>/templates/Makefile`.
+
+**Prove it before you trust it.** Put a deliberately unresolvable symbol in one
+test and confirm the build fails:
+
+```monkeyc
+return ThisDoesNotExist.definitelyNotAFunction();
+```
+
+### 2. Never hardcode a Y coordinate or assume a font height
+
+`dc.getFontHeight()` is the only source of truth, and the numbers are larger than
+they look. Measured on fenix 6 Pro:
+
+| Font | Height |
+| --- | --- |
+| `FONT_XTINY` | 19 |
+| `FONT_TINY` | 29 |
+| `FONT_SMALL` | 32 |
+| `FONT_NUMBER_MEDIUM` | 74 |
+
+Content drawn past the screen height is simply invisible — no error, no warning,
+no clipping indicator. A two-line `FONT_NUMBER_MEDIUM` block is 148px of a 260px
+face.
+
+Derive every Y at draw time, and **clamp** so a bottom row cannot be pushed off:
+
+```monkeyc
+function clampRuleY(derived as Number, footerH as Number) as Number {
+    var reserved = (footerH * 2) + GAP_BELOW_RULE + GAP_BETWEEN_ROWS;
+    var maxRuleY = SCREEN - BOTTOM_MARGIN - reserved;
+    return derived > maxRuleY ? maxRuleY : derived;
+}
+```
+
+See `references/layout.md`.
+
+### 3. The screen is round; your layout is not
+
+Check content against the bezel curve, not the bounding square. A rectangle
+inscribed in a circle fails at its **corners** long before its sides.
+
+```monkeyc
+function halfWidthAt(y as Number) as Number {
+    var dy = y - CENTER;
+    var inside = (CENTER * CENTER) - (dy * dy);
+    return inside <= 0 ? 0 : Math.sqrt(inside).toNumber();
+}
+```
+
+### 4. Colours are quantised, and brightness is reflectance
+
+Many devices snap to a 4×4×4 lattice: `0x00 / 0x55 / 0xAA / 0xFF` per channel. A
+colour not already on it is not the colour that ships.
+
+More important: MIP screens are **transflective with no backlight**. A colour's
+brightness *is* how much ambient light it returns. Grey reflects about two-thirds
+of what white does. Choosing a photographically accurate grey for a large area
+makes the whole face read as dim on the wrist while looking fine in the
+simulator's backlit LCD.
+
+Corollary: a saturated colour on a glyph reflects only its own channel, making
+the thing you want to read the *dimmest* thing on screen.
+
+See `references/display.md`.
+
+### 5. The simulator lies about settings
+
+It persists app settings and **ignores changed defaults in `properties.xml`**
+until you do File → Reset All App Data. A property will keep reading its old
+value while the XML plainly says otherwise. This looks exactly like broken
+settings code.
+
+Reset also drops the loaded device, so relaunch and re-push afterwards.
+
+See `references/simulator.md`.
+
+## Workflow
+
+### Starting a face
+
+1. `<skill-dir>/scripts/ciq-doctor` — confirm SDK, JDK, developer key, target device installed.
+2. Copy `<skill-dir>/templates/Makefile`, `<skill-dir>/templates/monkey.jungle`, `<skill-dir>/templates/monkey.test.jungle`.
+3. Generate a fresh app id: `python3 -c "import uuid;print(uuid.uuid4().hex)"`.
+4. Split source by responsibility. This structure has held up well:
+
+| Module | Holds |
+| --- | --- |
+| `Palette.mc` | Colours only, all lattice-exact |
+| `Layout.mc` | Geometry, derivations, bezel maths — no drawing |
+| `<Widget>.mc` | Drawing primitives (rows, bars, segments) |
+| `Fields.mc` | Formatting and thresholds — pure, easy to test |
+| `Sensors.mc` | Sensor reads with null handling |
+| `<Name>View.mc` | Composition only |
+
+Keeping `Layout` free of `Dc` calls is what makes geometry unit-testable.
+
+### Every change
+
+```bash
+make build && make test && make lint
+```
+
+`make lint` is level 3 and catches real problems the level 2 build allows.
+
+### Before committing
+
+Capture and *look at it*. Layout bugs are invisible in a passing test run:
+
+```bash
+make build && make sim
+<skill-dir>/scripts/ciq-capture /tmp/face.png --face --size 260
+```
+
+Then Read the PNG. Every layout bug in this skill's history was found by looking,
+not by testing.
+
+## Monkey C gotchas
+
+- Module-level functions take **no** visibility modifier. `private` and `hidden`
+  are class-only; at module scope they are syntax errors.
+- `dc.fillPolygon` wants `Array<[Numeric, Numeric]>`. Cast the literal:
+  `[[x, y], ...] as Array<[Numeric, Numeric]>`.
+- `getInitialView()` returns
+  `[WatchUi.Views] or [WatchUi.Views, WatchUi.InputDelegates]`.
+- `Application.Properties.getValue()` **throws** when a key is absent, which
+  happens on a fresh install before settings have ever been written. Wrap every
+  read with a default.
+- Integer division everywhere. Centring an odd width leaves a 1px skew — write
+  tests that allow it rather than forcing constants to stay even.
+
+## Reference watches and homages
+
+If reproducing a real object, get these right before anything else, because they
+are what makes it recognisable:
+
+- **Display polarity.** A 1970s LCD is *positive*: dark segments on a pale panel,
+  the inverse of every modern face. Getting this backwards turns a crystal into a
+  screen.
+- **Proportion.** Bezels on vintage digitals are thick; the window is smaller
+  than memory suggests.
+- **Where the legends sit** — maker's name on the bezel, not the glass.
+
+No system font is a segment display. If you need one, draw it: see
+`references/layout.md` for a working seven-segment renderer, including the ghost
+(unlit) segments that are most of what sells the effect.
+
+**Do not print a real brand on the face.** See `references/store.md`.

package/README.md

@@ -136,7 +136,7 @@ packages/{category}/{skill}/SKILL.md
 
 </details>
 
-## All 24 Skills
+## All 25 Skills
 
 Each entry links to its `SKILL.md`. Reference any skill by its `olko:*` lookup name in a new agent session.
 
@@ -185,6 +185,12 @@ Each entry links to its `SKILL.md`. Reference any skill by its `olko:*` lookup n
 |-------|-------------|----------|
 | [gallery](packages/photography/gallery/SKILL.md) | Creates photo galleries with AI-assisted layout curation and sequencing | Building a gallery from photos or planning photo layout, sequencing, and curation |
 
+### Wearables (1)
+
+| Skill | What it does | Use when |
+|-------|-------------|----------|
+| [garmin-watchface](packages/wearables/garmin-watchface/SKILL.md) | Builds, tests, screenshots, and publishes Garmin Connect IQ watch faces in Monkey C | Working on a Connect IQ watch face — layout that clips or overlaps, simulator screenshots, app settings, device support, or store submission |
+
 ## How to use skills
 
 Install the Codex symlinks, then mention a skill by its lookup name in a new agent session:

package/catalog/skills.json

@@ -399,7 +399,7 @@
       "lookupName": "olko:obsidian-pr-sync",
       "category": "software-development",
       "path": "packages/software-development/obsidian-pr-sync",
-      "description": "Fetch open GitHub PRs assigned to you or requesting your review, and write a grouped, age-sorted '## PRs to review' section into today's Obsidian daily note. Idempotent — re-running replaces the section.",
+      "description": "Fetch open GitHub PRs assigned to you or requesting your review, and write a grouped, age-sorted '## PRs to review' section into today's Obsidian daily note. Idempotent \u2014 re-running replaces the section.",
       "tags": [
         "github",
         "obsidian",
@@ -470,7 +470,7 @@
       "lookupName": "olko:macos-menubar-app",
       "category": "software-development",
       "path": "packages/software-development/macos-menubar-app",
-      "description": "Build a production-quality macOS menubar or notch app in SwiftUI — MenuBarExtra, sandbox entitlements, keyboard shortcuts, sound effects, accessibility permissions, and App Store preparation.",
+      "description": "Build a production-quality macOS menubar or notch app in SwiftUI \u2014 MenuBarExtra, sandbox entitlements, keyboard shortcuts, sound effects, accessibility permissions, and App Store preparation.",
       "tags": [
         "macos",
         "swiftui",
@@ -495,7 +495,7 @@
       "lookupName": "olko:skill-budget-audit",
       "category": "software-development",
       "path": "packages/software-development/skill-budget-audit",
-      "description": "Diagnose and fix Claude Code skill context budget overflow — identify heavy plugin bundles, remove domain-specific ones, and restore skill discoverability.",
+      "description": "Diagnose and fix Claude Code skill context budget overflow \u2014 identify heavy plugin bundles, remove domain-specific ones, and restore skill discoverability.",
       "tags": [
         "claude-code",
         "skills",
@@ -538,7 +538,7 @@
       "lookupName": "olko:qodoloop",
       "category": "software-development",
       "path": "packages/software-development/qodoloop",
-      "description": "Iteratively drives a GitHub PR to zero unresolved Qodo findings — reads each finding's own Agent Prompt, applies the fix, replies to the thread, resolves it, pushes, and waits for Qodo's next pass.",
+      "description": "Iteratively drives a GitHub PR to zero unresolved Qodo findings \u2014 reads each finding's own Agent Prompt, applies the fix, replies to the thread, resolves it, pushes, and waits for Qodo's next pass.",
       "tags": [
         "code-review",
         "qodo",
@@ -556,6 +556,30 @@
         "windsurf",
         "kiro"
       ]
+    },
+    {
+      "name": "garmin-watchface",
+      "lookupName": "olko:garmin-watchface",
+      "category": "wearables",
+      "path": "packages/wearables/garmin-watchface",
+      "description": "Build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C.",
+      "tags": [
+        "garmin",
+        "connect-iq",
+        "monkey-c",
+        "watch-face",
+        "wearables",
+        "embedded"
+      ],
+      "adapters": [
+        "codex",
+        "claude",
+        "cursor",
+        "copilot",
+        "windsurf",
+        "kiro",
+        "grok"
+      ]
     }
   ]
 }

package/collections/wearables.json

@@ -0,0 +1,7 @@
+{
+  "name": "wearables",
+  "description": "Skills for building software that runs on wearable devices.",
+  "packages": [
+    "garmin-watchface"
+  ]
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@olegkoval/agent-skills",
-  "version": "1.19.1",
+  "version": "1.20.0",
   "private": false,
   "publishConfig": {
     "access": "public"

package/packages/marketing/viral-launch/adapters/claude/skills/viral-launch/references/external-skills.md

@@ -0,0 +1,12 @@
+# External skills
+
+Skill search found these related launch and marketing skills:
+
+- `coreyhaines31/marketingskills@launch-strategy` - broad launch strategy skill, about 37K installs in Skills CLI search; source repo `coreyhaines31/marketingskills` has about 20K GitHub stars.
+- `refoundai/lenny-skills@launch-marketing` - product management and launch marketing skill, under 1K installs in Skills CLI search.
+
+Prefer this local `olko:viral-launch` skill when the work is specifically to make a repository launch-ready. Consider installing `coreyhaines31/marketingskills@launch-strategy` when the user wants a broader marketing strategy workflow:
+
+```bash
+npx skills add coreyhaines31/marketingskills@launch-strategy -g -y
+```

package/packages/marketing/viral-launch/adapters/claude/skills/viral-launch/references/launch-checklist.md

@@ -0,0 +1,42 @@
+# Launch checklist
+
+Use this checklist before calling a project launch-ready.
+
+## Repo
+
+- README headline says what the project does and for whom.
+- First screen contains a demo, screenshot, or quickstart.
+- Install steps work from a clean checkout.
+- Examples cover the highest-intent use cases.
+- License and contribution expectations are clear.
+- Known limitations are stated without weakening the launch angle.
+
+## Message
+
+- One-sentence positioning is specific.
+- The hook names a real problem or desire.
+- Differentiation is concrete.
+- Claims are backed by repo content, screenshots, demos, benchmarks, or examples.
+- Copy avoids fake urgency, fake social proof, and generic hype.
+
+## Distribution
+
+- Launch channels are chosen for the actual audience.
+- Each channel gets native copy, not pasted generic copy.
+- Assets include at least one short post, one longer post, and one direct outreach note.
+- Launch timing includes a response window for comments, issues, and feedback.
+
+## Shareability
+
+- There is a public artifact people can link to.
+- The demo shows a before/after or clear transformation.
+- Users have a reason to share the output, not only the product.
+- Any referral or waitlist mechanism is tied to user value.
+
+## Metrics
+
+- Activation event is defined.
+- Share event is defined.
+- Conversion event is defined.
+- Feedback collection path is defined.
+- Launch review date is defined before launch.

package/packages/marketing/viral-launch/adapters/cursor/skills/viral-launch/references/external-skills.md

@@ -0,0 +1,12 @@
+# External skills
+
+Skill search found these related launch and marketing skills:
+
+- `coreyhaines31/marketingskills@launch-strategy` - broad launch strategy skill, about 37K installs in Skills CLI search; source repo `coreyhaines31/marketingskills` has about 20K GitHub stars.
+- `refoundai/lenny-skills@launch-marketing` - product management and launch marketing skill, under 1K installs in Skills CLI search.
+
+Prefer this local `olko:viral-launch` skill when the work is specifically to make a repository launch-ready. Consider installing `coreyhaines31/marketingskills@launch-strategy` when the user wants a broader marketing strategy workflow:
+
+```bash
+npx skills add coreyhaines31/marketingskills@launch-strategy -g -y
+```

package/packages/marketing/viral-launch/adapters/cursor/skills/viral-launch/references/launch-checklist.md

@@ -0,0 +1,42 @@
+# Launch checklist
+
+Use this checklist before calling a project launch-ready.
+
+## Repo
+
+- README headline says what the project does and for whom.
+- First screen contains a demo, screenshot, or quickstart.
+- Install steps work from a clean checkout.
+- Examples cover the highest-intent use cases.
+- License and contribution expectations are clear.
+- Known limitations are stated without weakening the launch angle.
+
+## Message
+
+- One-sentence positioning is specific.
+- The hook names a real problem or desire.
+- Differentiation is concrete.
+- Claims are backed by repo content, screenshots, demos, benchmarks, or examples.
+- Copy avoids fake urgency, fake social proof, and generic hype.
+
+## Distribution
+
+- Launch channels are chosen for the actual audience.
+- Each channel gets native copy, not pasted generic copy.
+- Assets include at least one short post, one longer post, and one direct outreach note.
+- Launch timing includes a response window for comments, issues, and feedback.
+
+## Shareability
+
+- There is a public artifact people can link to.
+- The demo shows a before/after or clear transformation.
+- Users have a reason to share the output, not only the product.
+- Any referral or waitlist mechanism is tied to user value.
+
+## Metrics
+
+- Activation event is defined.
+- Share event is defined.
+- Conversion event is defined.
+- Feedback collection path is defined.
+- Launch review date is defined before launch.