@rune-kit/rune 2.1.1

package/skills/logic-guardian/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: logic-guardian
+description: Protects complex business logic from accidental deletion or overwrite. Maintains a logic manifest, enforces pre-edit gates, and validates post-edit diffs.
+metadata:
+  author: runedev
+  version: "0.1.0"
+  layer: L2
+  model: sonnet
+  group: quality
+  tools: "Read, Write, Edit, Glob, Grep"
+---
+
+# logic-guardian
+
+## Purpose
+
+Complex projects (trading bots, payment systems, game engines, state machines) contain interconnected logic that AI agents routinely destroy by accident. The pattern is always the same: new session starts, agent doesn't know existing logic, rewrites or deletes working code, project regresses. `logic-guardian` breaks this cycle by maintaining a machine-readable logic manifest, enforcing a pre-edit gate on logic files, and validating that edits don't silently remove existing logic. It is the "institutional memory" for business logic.
+
+## Triggers
+
+- `/rune logic-guardian` — manual invocation (scan project, generate/update manifest)
+- Auto-trigger: when `cook` or `fix` targets a file listed in `.rune/logic-manifest.json`
+- Auto-trigger: when `surgeon` plans refactoring on logic-heavy modules
+- Auto-trigger: when `.rune/logic-manifest.json` exists in project root
+
+## Calls (outbound connections)
+
+- `scout` (L2): scan project to discover logic files and extract function signatures
+- `verification` (L3): run tests after logic edits to confirm no regression
+- `hallucination-guard` (L3): verify that referenced functions/imports actually exist after edit
+- `journal` (L3): record logic changes as ADRs for cross-session persistence
+- `session-bridge` (L3): save manifest state so next session loads it immediately
+
+## Called By (inbound connections)
+
+- `cook` (L1): Phase 1.5 — when complex logic project detected, load manifest before planning
+- `fix` (L2): pre-edit gate — before modifying any file in the manifest
+- `surgeon` (L2): pre-refactor — before restructuring logic modules
+- `team` (L1): validate logic integrity across parallel workstreams
+- `review` (L2): check if reviewed diff removes or modifies manifested logic
+
+## Workflow
+
+### Phase 0 — Load or Initialize Manifest
+
+1. Use `Read` on `.rune/logic-manifest.json`
+2. If file exists:
+   - Parse manifest, display summary: "Loaded logic manifest: N components, M functions, K parameters"
+   - Proceed to Phase 1 (Validate)
+3. If file does NOT exist:
+   - Announce: "No logic manifest found. Scanning project to generate one."
+   - Proceed to Phase 3 (Generate)
+
+### Phase 1 — Validate Manifest Against Codebase
+
+Ensure the manifest matches the actual code (detect drift):
+
+1. For each component in the manifest:
+   - Use `Read` on the component's `file_path`
+   - Verify each listed function exists (by name + signature match)
+   - Check if any NEW functions exist in the file that aren't in the manifest
+2. Report:
+   - `SYNCED` — manifest matches code perfectly
+   - `DRIFT_DETECTED` — list specific discrepancies (missing functions, new unlisted functions, changed signatures)
+3. If drift detected: ask user whether to update manifest or investigate changes
+
+### Phase 2 — Pre-Edit Gate (called by fix/surgeon/cook)
+
+Before ANY edit to a manifested file:
+
+1. Load the manifest (Phase 0)
+2. Display the affected component's current spec:
+   ```
+   COMPONENT: [name]
+   STATUS: ACTIVE | TESTING | DEPRECATED
+   FUNCTIONS: [list with one-line descriptions]
+   PARAMETERS: [configurable values with current settings]
+   DEPENDENCIES: [what other components depend on this]
+   LAST_MODIFIED: [date]
+   ```
+3. Require the agent to explicitly state:
+   - What it intends to change
+   - What it will NOT change
+   - Which existing functions/logic will be preserved
+4. If the agent cannot list the existing functions → BLOCK the edit. Force a `Read` of the file first.
+
+### Phase 3 — Generate Manifest (first-time or rescan)
+
+Scan the project and build the manifest:
+
+1. Use `scout` to find logic-heavy files:
+   - Search for files with complex conditionals, state machines, strategy patterns
+   - Look for files matching: `**/logic/**`, `**/strategy/**`, `**/engine/**`, `**/core/**`, `**/scenarios/**`, `**/rules/**`, `**/pipeline/**`, `**/trailing/**`, `**/signals/**`
+   - Also search for files with high cyclomatic complexity (many if/else/switch branches)
+2. For each discovered file:
+   - `Read` the file
+   - Extract: functions/methods, their parameters, return types, key conditionals
+   - Classify the component's role: ENTRY_LOGIC, EXIT_LOGIC, FILTER, VALIDATOR, STATE_MACHINE, PIPELINE, CALCULATOR, etc.
+   - Determine status: ACTIVE (has callers + tests), TESTING (no production callers), DEPRECATED (commented out or unused)
+3. Map dependencies between components:
+   - Which component calls which
+   - Which share state or config
+   - Which must be modified together (co-change groups)
+4. Write manifest to `.rune/logic-manifest.json`
+5. Save summary to neural memory via `session-bridge`
+
+### Phase 4 — Post-Edit Validation
+
+After any edit to a manifested file:
+
+1. Re-read the edited file
+2. Compare against the manifest's function list:
+   - Any function REMOVED? → ALERT: "Function [name] was removed. Was this intentional?"
+   - Any function SIGNATURE changed? → WARN: "Signature of [name] changed. Check callers."
+   - Any PARAMETERS changed? → WARN: "Parameter [name] changed from [old] to [new]. Verify downstream."
+3. Run `verification` to execute tests
+4. If all checks pass: update the manifest with new state
+5. If function was removed unintentionally: offer to restore from git
+
+### Phase 5 — Cross-Session Handoff
+
+Ensure the next session can pick up where this one left off:
+
+1. Update `.rune/logic-manifest.json` with:
+   - Current component states
+   - Last validation timestamp
+   - Any pending changes or known issues
+2. Save key decisions to `journal` as ADRs
+3. Save manifest summary to neural memory:
+   - "Project X has N active logic components: [list]. Last validated [date]."
+   - "Component Y was modified: [what changed and why]"
+
+## Output Format
+
+### Manifest Schema (`.rune/logic-manifest.json`)
+
+```json
+{
+  "version": "1.0",
+  "project": "project-name",
+  "last_validated": "2026-03-05T10:00:00Z",
+  "components": [
+    {
+      "name": "rsi-entry-detector",
+      "file_path": "src/scenarios/rsi_entry/detect.py",
+      "role": "ENTRY_LOGIC",
+      "status": "ACTIVE",
+      "functions": [
+        {
+          "name": "detect_entry_signal",
+          "signature": "(df: DataFrame, ticket: Ticket, config: Settings) -> Signal | None",
+          "description": "3-step RSI entry detection: challenge -> zone check -> entry point",
+          "critical": true
+        }
+      ],
+      "parameters": [
+        { "name": "rsi_period", "value": 7, "source": "settings.py" },
+        { "name": "challenge_threshold_long", "value": 65, "source": "settings.py" }
+      ],
+      "dependencies": ["trend-pass-tracker", "indicator-calculator"],
+      "dependents": ["production-worker", "backtest-engine"],
+      "last_modified": "2026-03-01",
+      "last_modifier": "human",
+      "checksum": "sha256:abc123..."
+    }
+  ],
+  "co_change_groups": [
+    {
+      "name": "entry-pipeline",
+      "components": ["trend-pass-tracker", "rsi-entry-detector", "indicator-calculator"],
+      "reason": "These components share RSI parameters and must be modified together"
+    }
+  ]
+}
+```
+
+### Validation Report
+
+```
+## Logic Guardian Report
+
+### Manifest Status: SYNCED | DRIFT_DETECTED
+- Components: N active, M testing, K deprecated
+- Last validated: [timestamp]
+
+### Pre-Edit Gate
+- File: [path]
+- Component: [name] (ACTIVE)
+- Functions preserved: [list]
+- Intended change: [description]
+- Impact: [downstream effects]
+
+### Post-Edit Validation
+- Functions removed: [none | list]
+- Signatures changed: [none | list]
+- Parameters changed: [none | list]
+- Tests: PASS | FAIL
+- Manifest: UPDATED | NEEDS_REVIEW
+```
+
+## Constraints
+
+1. MUST load manifest before ANY edit to a manifested file — the entire point is pre-edit awareness
+2. MUST NOT allow edits to ACTIVE logic without the agent explicitly listing what will be preserved — prevents silent overwrites
+3. MUST alert on function removal — the #1 failure mode is deleting working logic
+4. MUST run tests after editing manifested files — logic changes without test verification are blind
+5. MUST update manifest after validated edits — stale manifests provide false confidence
+6. MUST NOT auto-generate manifest for files the agent hasn't read — manifest must reflect actual understanding
+
+## Mesh Gates
+
+| Gate | Requires | If Missing |
+|------|----------|------------|
+| PRE_EDIT | `.rune/logic-manifest.json` loaded + component spec displayed | BLOCK edit. Run Phase 0 + Phase 2 first. |
+| POST_EDIT | All manifest functions still present OR removal explicitly acknowledged | ALERT + offer git restore |
+| CROSS_SESSION | Manifest updated + summary saved to journal/nmem | WARN: next session will lack context |
+
+## Sharp Edges
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Agent edits manifested file without loading manifest first | CRITICAL | Phase 2 gate: cook/fix MUST call logic-guardian before editing manifested files |
+| Manifest drifts from actual code (manual edits not tracked) | HIGH | Phase 1 validation on every load — detect and reconcile drift |
+| Agent acknowledges existing logic but still overwrites it | HIGH | Post-edit Phase 4 diff check catches removed functions regardless of agent claims |
+| Manifest becomes too large (100+ components) | MEDIUM | Group related functions into composite components; track at module level not function level |
+| False sense of security — manifest exists but is outdated | MEDIUM | Checksum comparison on every load; warn if file hash doesn't match manifest |
+| Agent treats manifest generation as a one-time task | LOW | Phase 5 cross-session handoff ensures manifest stays alive across sessions |
+
+## Done When
+
+- `.rune/logic-manifest.json` exists and passes Phase 1 validation (SYNCED)
+- All manifested components have status (ACTIVE/TESTING/DEPRECATED) and function listings
+- Pre-edit gate blocks edits without manifest awareness (Phase 2 enforced)
+- Post-edit validation confirms no unintended function removal (Phase 4 passed)
+- Manifest summary saved to journal + neural memory for cross-session handoff
+- Tests pass after any logic edit
+
+## Cost Profile
+
+~1,000-2,000 tokens for manifest load + pre-edit gate. ~3,000-5,000 tokens for full project scan (Phase 3). Sonnet for code analysis; haiku for file scanning via scout.

package/skills/marketing/SKILL.md

@@ -0,0 +1,229 @@
+---
+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.3.0"
+  layer: L2
+  model: sonnet
+  group: delivery
+  tools: "Read, Write, Edit, Glob, Grep, WebFetch, WebSearch"
+---
+
+# marketing
+
+## Purpose
+
+Create marketing assets and execute launch strategy. Marketing generates landing page copy, social media banners, SEO metadata, blog posts, and video scripts. Analyzes the project to create authentic, data-driven marketing content.
+
+## Called By (inbound)
+
+- `launch` (L1): Phase 4 MARKET — marketing phase of launch pipeline
+- User: `/rune marketing` direct invocation
+
+## Calls (outbound)
+
+- `scout` (L2): scan codebase for features, README, value props
+- `trend-scout` (L3): market trends, competitor positioning
+- `research` (L3): competitor analysis, SEO keyword data
+- `asset-creator` (L3): generate OG images, social cards, banners
+- `video-creator` (L3): create demo/explainer video plan
+- `browser-pilot` (L3): capture screenshots for marketing assets
+- L4 extension packs: domain-specific content when context matches (e.g., @rune/content for blog posts, @rune/analytics for campaign measurement)
+
+## Execution Steps
+
+### Step 1 — Understand the product
+
+Call `rune:scout` to scan the codebase. Ask scout to extract:
+- Feature list (what the product actually does)
+- README summary
+- Target audience signals (from code, comments, config)
+- Tech stack (relevant for developer marketing)
+
+Read any existing `marketing/`, `docs/`, or `landing/` directories if present.
+
+### Step 2 — Research market
+
+Call `rune:trend-scout` with the product category to identify:
+- Top 3 competitors and their positioning
+- Current market trends relevant to this product
+- Differentiators to emphasize
+
+Call `rune:research` for:
+- SEO keyword opportunities (volume vs. competition)
+- Competitor messaging patterns to avoid or counter
+
+### Step 2.5 — Establish Brand Voice
+
+Before generating any copy, define the brand voice contract. This prevents inconsistent tone across marketing assets.
+
+**Brand Voice Matrix** — answer these for the product:
+
+| Dimension | Spectrum | This product |
+|-----------|----------|--------------|
+| Formality | Casual ←→ Formal | [position] |
+| Humor | Serious ←→ Playful | [position] |
+| Authority | Peer ←→ Expert | [position] |
+| Warmth | Clinical ←→ Friendly | [position] |
+| Urgency | Patient ←→ Urgent | [position] |
+
+**Voice rules** (generate 3-5):
+- "We say [X], never [Y]" — e.g., "We say 'start free', never 'sign up now'"
+- "Our tone is [X] because our users are [Y]"
+- "Avoid [specific words/phrases] because [reason]"
+
+**Vocabulary list** (5-10 terms):
+- Preferred terms: [words this brand uses]
+- Forbidden terms: [words to avoid and why]
+- Jargon policy: [use/avoid/explain technical terms]
+
+Save voice contract to `marketing/brand-voice.md`. All subsequent copy MUST follow this voice.
+
+If `marketing/brand-voice.md` already exists → Read it and apply. Do NOT regenerate without user request.
+
+### Step 3 — Generate copy
+
+Using product understanding, market research, and **brand voice contract**, produce:
+
+**Hero section**
+- Headline (under 10 words, outcome-focused)
+- Subheadline (1-2 sentences expanding the promise)
+- Primary CTA button text
+
+**Value propositions** (3 items)
+- Icon/emoji, title, 1-sentence description each
+
+**Feature list** (pulled from Step 1 scout output)
+- Name + benefit phrasing for each feature
+
+**Social proof section** (placeholder copy if no real testimonials)
+
+**Secondary CTA** (bottom of page)
+
+### Step 4 — Social posts
+
+Produce ready-to-post content:
+
+**Twitter/X thread** (5-7 tweets)
+- Tweet 1: hook (the big claim)
+- Tweets 2-5: one feature or benefit per tweet with specifics
+- Tweet 6: social proof or stat
+- Tweet 7: CTA with link
+
+**LinkedIn post** (150-300 words)
+- Professional tone, problem-solution-proof structure
+
+**Product Hunt tagline** (under 60 characters)
+
+### Step 5 — SEO metadata
+
+Produce for the landing page:
+
+```html
+<title>[Meta title — under 60 chars, primary keyword first]</title>
+<meta name="description" content="[150-160 chars, includes CTA]">
+<meta property="og:title" content="[OG title]">
+<meta property="og:description" content="[OG description]">
+<meta property="og:image" content="[OG image path]">
+<link rel="canonical" href="[canonical URL]">
+```
+
+Target keywords list (5-10 terms with rationale).
+
+### Step 5.5 — SEO Audit (if existing site)
+
+If the project already has a deployed site or existing pages, run a technical SEO audit before generating new metadata.
+
+**Automated checks** (use Grep + Read on codebase):
+
+1. **Meta tags completeness**: Every page has `<title>`, `<meta description>`, `og:title`, `og:description`, `og:image`. Flag pages missing any.
+2. **Heading hierarchy**: Every page has exactly one `<h1>`. No skipped levels (h1→h3 without h2). Use Grep for `<h1`, `<h2`, `<h3` patterns.
+3. **Image alt text**: Search for `<img` without `alt=` attribute. Every image needs descriptive alt text (not "image", not empty).
+4. **Canonical URLs**: Check for `<link rel="canonical"`. Missing canonical = duplicate content risk.
+5. **Structured data**: Check for `application/ld+json` or microdata. Recommend adding if missing (Product, Organization, Article schemas).
+6. **Performance signals**: Check for `next/image` or lazy loading on images. Flag `<img>` without `loading="lazy"` below fold.
+7. **Sitemap**: Check for `sitemap.xml` or sitemap generation in build config. Flag if missing.
+8. **Robots**: Check for `robots.txt`. Verify it doesn't accidentally block important pages.
+
+**Output**: SEO Audit Report with pass/fail per check. Save to `marketing/seo-audit.md`.
+
+Fix critical SEO issues (missing titles, broken heading hierarchy) in the implementation plan. Non-critical issues go to `marketing/seo-backlog.md`.
+
+### Step 6 — Visual assets
+
+Call `rune:asset-creator` to generate:
+- OG image (1200x630px) — product name, tagline, brand colors
+- Twitter card image (1200x628px)
+- Product Hunt thumbnail (240x240px)
+
+Call `rune:video-creator` to produce:
+- 60-second demo video script (screen recording plan)
+- Shot list with timestamps
+
+If `rune:browser-pilot` is available, capture screenshots of the running app to use as real product imagery.
+
+### Step 7 — Present for approval
+
+Output all assets as structured markdown sections. Present to user for review before saving files.
+
+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/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)
+- `marketing/video-script.md` — video plan from Step 6
+
+## Constraints
+
+1. MUST base all claims on actual product capabilities — no aspirational features
+2. MUST verify deploy is live before generating marketing materials
+3. MUST NOT fabricate testimonials, stats, or benchmarks
+4. MUST include accurate technical details — wrong tech specs destroy credibility
+
+## Output Format
+
+```
+## Marketing Assets
+- **Landing Copy**: [generated — headline, subheadline, value props, features, CTAs]
+- **Social Posts**: Twitter thread (N tweets), LinkedIn post, PH tagline
+- **SEO Metadata**: title, description, OG tags, N target keywords
+- **Visuals**: OG image, Twitter card, PH thumbnail
+- **Video**: 60s demo script with shot list
+
+### Generated Files
+- marketing/landing-copy.md
+- marketing/social-posts.md
+- marketing/seo-meta.json
+- marketing/video-script.md
+```
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Fabricating statistics, benchmarks, or testimonials | CRITICAL | Constraint 3: no fabrication — if no real stats exist, use honest placeholder copy |
+| Generating copy before deploy verified live | HIGH | Constraint 2: deploy must be confirmed live before marketing runs |
+| 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 |
+
+## 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
+- 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
+- Video script requested from video-creator (if requested)
+- User has approved all content
+- Files saved to marketing/ directory
+- Marketing Assets report emitted with file list
+
+## Cost Profile
+
+~2000-5000 tokens input, ~1000-3000 tokens output. Sonnet for copywriting quality.