@rune-kit/rune 2.11.0 → 2.12.2

package/skills/marketing/SKILL.md

@@ -3,7 +3,7 @@ name: marketing
 description: Create marketing assets and execute launch strategy. Generates landing copy, social banners, SEO meta, blog posts, and video scripts.
 metadata:
   author: runedev
-  version: "0.4.0"
+  version: "0.5.0"
   layer: L2
   model: sonnet
   group: delivery
@@ -112,6 +112,61 @@ Using product understanding, market research, and **brand voice contract**, prod
 
 **Secondary CTA** (bottom of page)
 
+### Step 3.5 — Competitive Response Playbook
+
+When `trend-scout` identifies active competitors or market threats, generate pre-planned counter-strategies. This turns reactive scrambling into prepared responses.
+
+**Four Threat Scenarios:**
+
+| Scenario | Trigger Signal | Response Window |
+|----------|---------------|-----------------|
+| **Price War** | Competitor drops price >20% | 24-48 hours |
+| **New Market Entry** | New competitor launches in your space | 1-2 weeks |
+| **Viral Competitor** | Competitor content goes viral (10x normal engagement) | 24-72 hours |
+| **Fast Follower** | Competitor copies your feature within 30 days of launch | 1 week |
+
+**For each relevant scenario, document:**
+
+```markdown
+## Counter-Strategy: [Scenario Name]
+
+### Trigger
+- Signal: [what to watch for]
+- Detection: [how to monitor — social listening, price tracking, etc.]
+- Response window: [how fast to react]
+
+### Counter-Move
+- **Immediate (Day 1)**: [first response — usually messaging/positioning]
+- **Short-term (Week 1)**: [tactical moves — promos, content, outreach]
+- **Medium-term (Month 1)**: [strategic adjustments — product, pricing, positioning]
+
+### Resources Required
+- Team: [who needs to be involved]
+- Budget: [estimated cost]
+- Assets: [what to prepare in advance]
+
+### Success Metric
+- [How to know the counter-strategy worked]
+
+### Pre-Built Assets
+- [ ] Response messaging template
+- [ ] Social post drafts
+- [ ] Email to existing customers
+- [ ] FAQ for sales/support team
+```
+
+**Rules:**
+- Only generate playbooks for scenarios relevant to this market (skip if no direct competitors)
+- Pre-build assets NOW — when the trigger fires, you execute, not create
+- Response window is real — if you can't respond in time, the playbook failed
+- Test the detection mechanism — if you can't see the trigger, you can't respond
+
+**Skip this step if:**
+- Product is in a blue ocean (no direct competitors yet)
+- User explicitly requests marketing assets only, no strategy
+
+Save to `marketing/counter-playbook.md`.
+
 ### Step 4 — Social posts
 
 Produce ready-to-post content:
@@ -218,6 +273,7 @@ Output all assets as structured markdown sections. Present to user for review be
 After user approves, use `Write` to save:
 - `marketing/brand-voice.md` — voice contract from Step 2.5
 - `marketing/landing-copy.md` — all copy from Step 3
+- `marketing/counter-playbook.md` — competitive response strategies from Step 3.5 (if competitors exist)
 - `marketing/social-posts.md` — all posts from Step 4
 - `marketing/seo-meta.json` — SEO data from Step 5
 - `marketing/seo-audit.md` — SEO audit results from Step 5.5 (if existing site)
@@ -258,12 +314,16 @@ Known failure modes for this skill. Check these before declaring done.
 | Copy not based on actual codebase features (invented value props) | HIGH | scout must run in Step 1 — features extracted from actual code, not assumptions |
 | Missing SEO keyword analysis (no research call) | MEDIUM | Step 2: research call for keyword data is mandatory for SEO section |
 | Files saved without user approval | MEDIUM | Step 7: present ALL assets to user, wait for approval before writing files |
+| Counter-playbook without detection mechanism | HIGH | Every scenario needs a monitoring method — "watch for price drops" is useless without specifying WHERE to watch and HOW to automate |
+| Counter-playbook with unrealistic response windows | MEDIUM | If response window is 24h but pre-built assets don't exist, the playbook will fail — either extend window or create assets NOW |
+| Generating counter-playbook for blue ocean products | LOW | Skip Step 3.5 if no direct competitors — counter-strategies need someone to counter |
 
 ## Done When
 
 - scout completed and actual feature list extracted
 - Brand voice contract established (or existing one loaded)
 - Competitor/trend analysis done via trend-scout + research
+- Competitive response playbook generated (if competitors exist) with pre-built asset checklist
 - Hero copy, value props, social posts, and SEO metadata generated (following brand voice)
 - SEO audit completed (if existing site) with pass/fail results
 - Visual assets requested from asset-creator
@@ -278,6 +338,7 @@ Known failure modes for this skill. Check these before declaring done.
 |----------|--------|----------|
 | Brand voice contract | Markdown | `marketing/brand-voice.md` |
 | Landing page copy | Markdown | `marketing/landing-copy.md` |
+| Competitive response playbook | Markdown | `marketing/counter-playbook.md` |
 | Social media posts | Markdown | `marketing/social-posts.md` |
 | SEO metadata | JSON | `marketing/seo-meta.json` |
 | SEO audit report | Markdown | `marketing/seo-audit.md` |

package/skills/neural-memory/SKILL.md

@@ -55,25 +55,22 @@ Without this skill, each project is an island. With it, a caching pattern discov
 
 ## Calls (outbound)
 
-| Skill | When | Why |
-|-------|------|-----|
-| `session-bridge` | After Capture Mode | Sync key decisions back to `.rune/` files |
+- `session-bridge` (L3): after Capture Mode — sync key decisions back to `.rune/` files
 
 ## Called By (inbound)
 
-| Skill | When | Why |
-|-------|------|-----|
-| `cook` | Phase 0 (resume) + Phase 8 (complete) | Recall project context at start, capture learnings at end |
-| `debug` | After root cause found | Capture error pattern for future recognition |
-| `fix` | After fix verified | Capture fix pattern (cause → solution) |
-| `review` | After review complete | Capture code quality insight |
-| `rescue` | Phase start + phase end | Recall past refactoring patterns, capture new ones |
-| `plan` | Before architecture decisions | Recall past decisions on similar problems |
-| `session-bridge` | Step 6 (cross-project extraction) | Extract generalizable patterns to nmem |
-| `journal` | After ADR written | Extract decision + rejected alternatives to nmem |
-| `context-engine` | Before compaction | Trigger Flush Mode to preserve context |
-| `sentinel` | After security finding | Capture vulnerability pattern |
-| `incident` | After resolution | Capture incident root cause + fix |
+- `cook` (L1): Phase 0 (resume) + Phase 8 (complete) — recall context at start, capture learnings at end
+- `rescue` (L1): phase start + phase end — recall past refactoring patterns, capture new ones
+- `debug` (L2): after root cause found — capture error pattern for future recognition
+- `fix` (L2): after fix verified — capture fix pattern (cause → solution)
+- `review` (L2): after review complete — capture code quality insight
+- `plan` (L2): before architecture decisions — recall past decisions on similar problems
+- `sentinel` (L2): after security finding — capture vulnerability pattern
+- `incident` (L2): after resolution — capture incident root cause + fix
+- `retro` (L2): during retrospective — capture retro insights and patterns
+- `session-bridge` (L3): Step 6 (cross-project extraction) — extract generalizable patterns
+- `journal` (L3): after ADR written — extract decision + rejected alternatives
+- `context-engine` (L3): before compaction — trigger Flush Mode to preserve context
 
 ## Modes
 

package/skills/onboard/SKILL.md

@@ -8,7 +8,7 @@ metadata:
   model: sonnet
   group: quality
   tools: "Read, Write, Edit, Glob, Grep"
-  emit: project.onboarded
+  emit: project.onboarded, invariants.seeded
 ---
 
 # onboard
@@ -39,7 +39,7 @@ Auto-generate project context for AI sessions. Scans the codebase and creates a
 
 ```
 project/
-├── CLAUDE.md              # Project config for AI sessions
+├── CLAUDE.md              # Project config for AI sessions (with invariants pointer block)
 └── .rune/
     ├── conventions.md     # Detected patterns & style
     ├── decisions.md       # Empty, ready for session-bridge
@@ -47,6 +47,7 @@ project/
     ├── session-log.md     # Empty, ready for session-bridge
     ├── instincts.md       # Empty, ready for session-bridge instinct learning
     ├── contract.md        # Project invariants enforced by cook/sentinel
+    ├── INVARIANTS.md      # Danger zones + cross-file rules, consumed by logic-guardian
     └── DEVELOPER-GUIDE.md # Human-readable onboarding for new developers
 ```
 
@@ -114,6 +115,33 @@ Use `Write` to create each file:
   - Remove sections that don't apply (e.g., `contract.operations` for a library with no deployed service)
   - The contract is a starting point — tell the user to review and customize it
 
+### Step 5.4 — Detect Invariants (Auto-Discipline Seed)
+
+Scan the project for rules that span files — the kind of mistake a linter cannot catch but a single agent edit can introduce. The goal is to seed `.rune/INVARIANTS.md` with ≥3 plausible rules so `logic-guardian` has something to enforce on day one.
+
+Invoke the scanner directly:
+
+```bash
+node skills/onboard/scripts/onboard-invariants.js --root <project-root>
+```
+
+What it produces:
+- `.rune/INVARIANTS.md` — rendered from `skills/onboard/references/invariants-template.md` plus auto-detected rules in four buckets:
+  - **Danger Zones** — directories with the most cross-file references
+  - **Critical Invariants** — shared constants exported and imported in ≥3 places
+  - **State Machine Rules** — reducer/switch shapes with state literal pairs
+  - **Cross-File Consistency** — literal tuples mirrored across ≥3 files
+- `CLAUDE.md` — adds a pointer block between `<!-- @rune-invariants-pointer:start -->` and `<!-- @rune-invariants-pointer:end -->` listing top danger-zone globs so every session sees them.
+
+Merge rules (safe re-runs):
+- If `.rune/INVARIANTS.md` exists, user edits above `## Auto-detected (new)` are **never** overwritten.
+- New detections replace **only** the content under `## Auto-detected (new)`.
+- If a user sets `<!-- @rune-invariants-pointer:skip -->` anywhere in `CLAUDE.md`, the pointer block is not re-injected.
+
+Emit signal `invariants.seeded` with `{danger_count, critical_count, state_count, cross_count}` when done. `session-bridge` listens in Phase 3 to surface the loudest rules at session start.
+
+**Do not fabricate rules.** If detection yields zero results, write `_No new detections on this run._` under `## Auto-detected (new)` and move on. A quiet INVARIANTS.md is better than fake rules the user has to prune.
+
 ### Step 5.5 — Load Existing Instincts
 
 If `.rune/instincts.md` already exists and contains instinct entries, read it and include a summary in the Onboard Report under `### Learned Instincts`. This tells the agent what project-specific behaviors have been learned from previous sessions.

package/skills/onboard/references/invariants-template.md

@@ -0,0 +1,76 @@
+# Project Invariants
+
+> Auto-seeded by `rune onboard`. Edit freely — your changes survive re-runs.
+> Append-only: new auto-detections land under `## Auto-detected (new)` and never
+> overwrite existing rules.
+
+This file is the project's truth-source for rules that code changes must respect.
+`logic-guardian` loads it as a pre-edit gate, and `session-bridge` surfaces the
+most critical rules at session start so agents know the danger zones immediately.
+
+## How to read an entry
+
+```
+### <short rule title>
+- **WHAT**: one-sentence statement of the rule (what must hold)
+- **WHERE**: glob patterns for files this rule applies to
+- **WHY**: why this rule exists — past incident, cross-file coupling,
+  compliance, external contract, etc.
+```
+
+If an entry becomes stale, move it to `## Archived` with a one-line note.
+Never delete — the archive is evidence of past decisions.
+
+---
+
+## Danger Zones
+
+Paths that disproportionately affect the rest of the codebase. Test coverage,
+review, and change-review should be stricter here.
+
+<!-- auto-generated entries appear below -->
+
+---
+
+## Critical Invariants
+
+Rules that cross file boundaries — shared constants, contract values, protocol
+fields. Breaking any one silently breaks downstream code.
+
+<!-- auto-generated entries appear below -->
+
+---
+
+## State Machine Rules
+
+Legal transitions for state machines in the project. Illegal transitions are
+often the root cause of hard-to-reproduce bugs.
+
+<!-- auto-generated entries appear below -->
+
+---
+
+## Cross-File Consistency
+
+Fields, enums, or schemas mirrored in multiple places. Updates must propagate
+together or the project enters an inconsistent state.
+
+<!-- auto-generated entries appear below -->
+
+---
+
+## Auto-detected (new)
+
+New detections from the most recent `rune onboard` run. Review these, promote
+the real ones into the sections above, and drop the noise.
+
+<!-- placeholder — each run appends or replaces this block -->
+
+---
+
+## Archived
+
+Rules that were once invariants but are no longer — kept here as history. Do
+not delete; their absence later makes reasoning harder.
+
+<!-- empty on first run -->