@baselane/packs 0.1.5 → 0.1.6

package/packs/full-harness/rendered/.claude/skills/manim-video/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: manim-video
+description: Build reusable Manim explainers for technical concepts, graphs, system diagrams, and product walkthroughs, then hand off to the wider ECC video stack if needed. Use when the user wants a clean animated explainer rather than a generic talking-head script.
+---
+
+# Manim Video
+
+Use Manim for technical explainers where motion, structure, and clarity matter more than photorealism.
+
+## When to Activate
+
+- the user wants a technical explainer animation
+- the concept is a graph, workflow, architecture, metric progression, or system diagram
+- the user wants a short product or launch explainer for X or a landing page
+- the visual should feel precise instead of generically cinematic
+
+## Tool Requirements
+
+- `manim` CLI for scene rendering
+- `ffmpeg` for post-processing if needed
+- `video-editing` for final assembly or polish
+- `remotion-video-creation` when the final package needs composited UI, captions, or additional motion layers
+
+## Default Output
+
+- short 16:9 MP4
+- one thumbnail or poster frame
+- storyboard plus scene plan
+
+## Workflow
+
+1. Define the core visual thesis in one sentence.
+2. Break the concept into 3 to 6 scenes.
+3. Decide what each scene proves.
+4. Write the scene outline before writing Manim code.
+5. Render the smallest working version first.
+6. Tighten typography, spacing, color, and pacing after the render works.
+7. Hand off to the wider video stack only if it adds value.
+
+## Scene Planning Rules
+
+- each scene should prove one thing
+- avoid overstuffed diagrams
+- prefer progressive reveal over full-screen clutter
+- use motion to explain state change, not just to keep the screen busy
+- title cards should be short and loaded with meaning
+
+## Network Graph Default
+
+For social-graph and network-optimization explainers:
+
+- show the current graph before showing the optimized graph
+- distinguish low-signal follow clutter from high-signal bridges
+- highlight warm-path nodes and target clusters
+- if useful, add a final scene showing the self-improvement lineage that informed the skill
+
+## Render Conventions
+
+- default to 16:9 landscape unless the user asks for vertical
+- start with a low-quality smoke test render
+- only push to higher quality after composition and timing are stable
+- export one clean thumbnail frame that reads at social size
+
+## Reusable Starter
+
+Use [assets/network_graph_scene.py](assets/network_graph_scene.py) as a starting point for network-graph explainers.
+
+Example smoke test:
+
+```bash
+manim -ql assets/network_graph_scene.py NetworkGraphExplainer
+```
+
+## Output Format
+
+Return:
+
+- core visual thesis
+- storyboard
+- scene outline
+- render plan
+- any follow-on polish recommendations
+
+## Related Skills
+
+- `video-editing` for final polish
+- `remotion-video-creation` for motion-heavy post-processing or compositing
+- `content-engine` when the animation is part of a broader launch

package/packs/full-harness/rendered/.claude/skills/market-research/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: market-research
+description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
+---
+
+# Market Research
+
+Produce research that supports decisions, not research theater.
+
+## When to Activate
+
+- researching a market, category, company, investor, or technology trend
+- building TAM/SAM/SOM estimates
+- comparing competitors or adjacent products
+- preparing investor dossiers before outreach
+- pressure-testing a thesis before building, funding, or entering a market
+
+## Research Standards
+
+1. Every important claim needs a source.
+2. Prefer recent data and call out stale data.
+3. Include contrarian evidence and downside cases.
+4. Translate findings into a decision, not just a summary.
+5. Separate fact, inference, and recommendation clearly.
+
+## Common Research Modes
+
+### Investor / Fund Diligence
+Collect:
+- fund size, stage, and typical check size
+- relevant portfolio companies
+- public thesis and recent activity
+- reasons the fund is or is not a fit
+- any obvious red flags or mismatches
+
+### Competitive Analysis
+Collect:
+- product reality, not marketing copy
+- funding and investor history if public
+- traction metrics if public
+- distribution and pricing clues
+- strengths, weaknesses, and positioning gaps
+
+### Market Sizing
+Use:
+- top-down estimates from reports or public datasets
+- bottom-up sanity checks from realistic customer acquisition assumptions
+- explicit assumptions for every leap in logic
+
+### Technology / Vendor Research
+Collect:
+- how it works
+- trade-offs and adoption signals
+- integration complexity
+- lock-in, security, compliance, and operational risk
+
+## Output Format
+
+Default structure:
+1. executive summary
+2. key findings
+3. implications
+4. risks and caveats
+5. recommendation
+6. sources
+
+## Quality Gate
+
+Before delivering:
+- all numbers are sourced or labeled as estimates
+- old data is flagged
+- the recommendation follows from the evidence
+- risks and counterarguments are included
+- the output makes a decision easier

package/packs/full-harness/rendered/.claude/skills/marketing-campaign/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: marketing-campaign
+description: End-to-end marketing campaign planning and execution. Covers audience research, positioning, campaign angle definition, landing page copy, email sequences, social posts, ad copy, short-form video scripts, and content calendars. Use as the orchestration layer for multi-channel product launches.
+---
+
+# Marketing Campaign
+
+Plan and execute launch campaigns that convert — not just campaigns that ship.
+
+## When to Activate
+
+- planning a product or feature launch
+- building a full content suite from a single product brief
+- defining positioning and campaign angle before writing any copy
+- orchestrating multiple content types across channels
+- reviewing copy for conversion quality and brand consistency
+
+## Non-Negotiables
+
+1. Define positioning before writing any copy. All copy flows from the angle.
+2. Research the audience before assuming you know their language or fears.
+3. Each deliverable must serve one clear purpose in the campaign arc.
+4. Specificity beats adjectives in every format and on every channel.
+5. The same voice must run across every channel and every piece.
+6. No copy ships without passing the quality gate.
+
+## Campaign Workflow
+
+### Phase 1: Research
+
+Use `market-research` to:
+- profile the target audience (jobs-to-be-done, fears, language, alternatives they use)
+- map 3+ direct or adjacent competitors (positioning, gaps, messaging weaknesses)
+- identify 1–3 audience insights the campaign angle will exploit
+
+Deliverable: a short research brief (audience profile + competitive summary + key insights).
+
+### Phase 2: Positioning
+
+Produce:
+- core benefit statement (one sentence, no feature list, no jargon)
+- positioning formula: "[Product] helps [audience] [achieve outcome] by [mechanism]"
+- campaign angle: the specific tension, insight, or moment the whole campaign lives in
+- tone profile: lock before writing (delegate to `brand-voice` for durable, session-reusable voice capture)
+
+Do not write any copy until positioning and angle are approved.
+
+### Phase 3: Content Production
+
+Produce in this order — each layer informs the next:
+
+1. **Landing page copy** (all sections: hero, problem, solution, features, how it works, proof, CTA)
+2. **Email sequence** (each email has one purpose; follow the arc: problem → education → agitation → solution → proof → urgency → final CTA)
+3. **Social posts** (platform-native via `content-engine`; LinkedIn and X are different formats, not the same copy resized)
+4. **Short-form video scripts** (timestamp-blocked; written for screen and ear, not the page)
+5. **Ad copy variants** (3–4 variants testing different angles or audience segments)
+6. **Content calendar** (day-by-day schedule with channel, type, timing, and dependencies)
+
+### Phase 4: Review
+
+Gate every deliverable:
+- 5-second test on all hero / above-fold copy (clear who it's for, what it does, why act now)
+- CTA audit (one per piece, specific, earned — not demanded)
+- Tone consistency check across all channels
+- Claim audit (every claim is specific and supportable)
+- Cross-channel consistency (ad claims match landing page; email body matches subject)
+
+## Output Contract
+
+A full campaign delivers:
+
+1. **Positioning brief** — angle, core benefit statement, tone profile
+2. **Landing page copy** — hero, problem, solution, features, how it works, proof, CTA
+3. **Email sequence** — subject + preview + body + CTA for each email, labelled by day and purpose
+4. **LinkedIn posts** — 3+ platform-native posts with distinct angles
+5. **X posts** — 5+ standalone posts + 1 thread
+6. **Short-form video scripts** — 2+ timestamp-blocked scripts with visual direction notes
+7. **Ad copy variants** — short headline / long headline / body per variant
+8. **Content calendar** — day-by-day schedule with channel, content type, timing, and dependencies
+9. **Copy review summary** — flagged issues and open questions before anything goes live
+
+## Quality Gate
+
+Before delivering any piece:
+
+- every deliverable sounds like the same author
+- no hollow superlatives or filler adjectives remain
+- every CTA is specific and earned (never "learn more" or "click here")
+- no copy is duplicated verbatim across platforms
+- hero copy passes the 5-second test
+- email subjects match email body (no bait-and-switch)
+- ad claims match landing page claims exactly
+- no copy would work unchanged for any other product in the category
+
+## Hard Bans
+
+Delete and rewrite any:
+
+- "game-changing", "revolutionary", "world-class", "cutting-edge"
+- "In today's competitive landscape"
+- fake urgency not backed by a real deadline
+- hollow social proof without specifics ("thousands trust us")
+- generic CTAs ("learn more", "find out more", "click here")
+- copy that could be unplugged and dropped into a competitor's campaign unchanged
+
+## Related Skills
+
+- `brand-voice` — source-derived voice capture (run before content production)
+- `content-engine` — platform-native content production
+- `crosspost` — multi-platform distribution
+- `market-research` — audience and competitive intelligence
+- `seo` — on-page optimisation for landing page copy

package/packs/full-harness/rendered/.claude/skills/mcp-server-patterns/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: mcp-server-patterns
+description: Build MCP servers with Node/TypeScript SDK — tools, resources, prompts, Zod validation, stdio vs Streamable HTTP. Use Context7 or official MCP docs for latest API.
+---
+
+# MCP Server Patterns
+
+The Model Context Protocol (MCP) lets AI assistants call tools, read resources, and use prompts from your server. Use this skill when building or maintaining MCP servers. The SDK API evolves; check Context7 (query-docs for "MCP") or the official MCP documentation for current method names and signatures.
+
+For the broader routing decision of when a capability should be a rule, a skill, MCP, or a plain CLI/API workflow, see [docs/capability-surface-selection.md](../../docs/capability-surface-selection.md).
+
+## When to Use
+
+Use when: implementing a new MCP server, adding tools or resources, choosing stdio vs HTTP, upgrading the SDK, or debugging MCP registration and transport issues.
+
+## How It Works
+
+### Core concepts
+
+- **Tools**: Actions the model can invoke (e.g. search, run a command). Register with `registerTool()` or `tool()` depending on SDK version.
+- **Resources**: Read-only data the model can fetch (e.g. file contents, API responses). Register with `registerResource()` or `resource()`. Handlers typically receive a `uri` argument.
+- **Prompts**: Reusable, parameterised prompt templates the client can surface (e.g. in Claude Desktop). Register with `registerPrompt()` or equivalent.
+- **Transport**: stdio for local clients (e.g. Claude Desktop); Streamable HTTP is preferred for remote (Cursor, cloud). Legacy HTTP/SSE is for backward compatibility.
+
+The Node/TypeScript SDK may expose `tool()` / `resource()` or `registerTool()` / `registerResource()`; the official SDK has changed over time. Always verify against the current [MCP docs](https://modelcontextprotocol.io) or Context7.
+
+### Connecting with stdio
+
+For local clients, create a stdio transport and pass it to your server’s connect method. The exact API varies by SDK version (e.g. constructor vs factory). See the official MCP documentation or query Context7 for "MCP stdio server" for the current pattern.
+
+Keep server logic (tools + resources) independent of transport so you can plug in stdio or HTTP in the entrypoint.
+
+### Remote (Streamable HTTP)
+
+For Cursor, cloud, or other remote clients, use **Streamable HTTP** (single MCP HTTP endpoint per current spec). Support legacy HTTP/SSE only when backward compatibility is required.
+
+## Examples
+
+### Install and server setup
+
+```bash
+npm install @modelcontextprotocol/sdk zod
+```
+
+```typescript
+import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { z } from "zod";
+
+const server = new McpServer({ name: "my-server", version: "1.0.0" });
+```
+
+Register tools and resources using the API your SDK version provides: some versions use `server.tool(name, description, schema, handler)` (positional args), others use `server.tool({ name, description, inputSchema }, handler)` or `registerTool()`. Same for resources — include a `uri` in the handler when the API provides it. Check the official MCP docs or Context7 for the current `@modelcontextprotocol/sdk` signatures to avoid copy-paste errors.
+
+Use **Zod** (or the SDK’s preferred schema format) for input validation.
+
+## Best Practices
+
+- **Schema first**: Define input schemas for every tool; document parameters and return shape.
+- **Errors**: Return structured errors or messages the model can interpret; avoid raw stack traces.
+- **Idempotency**: Prefer idempotent tools where possible so retries are safe.
+- **Rate and cost**: For tools that call external APIs, consider rate limits and cost; document in the tool description.
+- **Versioning**: Pin SDK version in package.json; check release notes when upgrading.
+
+## Official SDKs and Docs
+
+- **JavaScript/TypeScript**: `@modelcontextprotocol/sdk` (npm). Use Context7 with library name "MCP" for current registration and transport patterns.
+- **Go**: Official Go SDK on GitHub (`modelcontextprotocol/go-sdk`).
+- **C#**: Official C# SDK for .NET.

package/packs/full-harness/rendered/.claude/skills/messages-ops/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: messages-ops
+description: Evidence-first live messaging workflow for ECC. Use when the user wants to read texts or DMs, recover a recent one-time code, inspect a thread before replying, or prove which message source was actually checked.
+---
+
+# Messages Ops
+
+Use this when the task is live-message retrieval: iMessage, DMs, recent one-time codes, or thread inspection before a follow-up.
+
+This is not email work. If the dominant surface is a mailbox, use `email-ops`.
+
+## Skill Stack
+
+Pull these ECC-native skills into the workflow when relevant:
+
+- `email-ops` when the message task is really mailbox work
+- `connections-optimizer` when the DM thread belongs to outbound network work
+- `lead-intelligence` when the live thread should inform targeting or warm-path outreach
+- `knowledge-ops` when the thread contents need to be captured into durable context
+
+## When to Use
+
+- user says "read my messages", "check texts", "look in DMs", or "find the code"
+- the task depends on a live thread or a recent code delivered to a local messaging surface
+- the user wants proof of which source or thread was inspected
+
+## Guardrails
+
+- resolve the source first:
+  - local messages
+  - X / social DM
+  - another browser-gated message surface
+- do not claim a thread was checked without naming the source
+- do not improvise raw database access if a checked helper or standard path exists
+- if auth or MFA blocks the surface, report the exact blocker
+
+## Workflow
+
+### 1. Resolve the exact thread
+
+Before doing anything else, settle:
+
+- message surface
+- sender / recipient / service
+- time window
+- whether the task is retrieval, inspection, or prep for a reply
+
+### 2. Read before drafting
+
+If the task may turn into an outbound follow-up:
+
+- read the latest inbound
+- identify the open loop
+- then hand off to the correct outbound skill if needed
+
+### 3. Handle codes as a focused retrieval task
+
+For one-time codes:
+
+- search the recent local message window first
+- narrow by service or sender when possible
+- stop once the code is found or the focused search is exhausted
+
+### 4. Report exact evidence
+
+Return:
+
+- source used
+- thread or sender when possible
+- time window
+- exact status:
+  - read
+  - code-found
+  - blocked
+  - awaiting reply draft
+
+## Output Format
+
+```text
+SOURCE
+- message surface
+- sender / thread / service
+
+RESULT
+- message summary or code
+- time window
+
+STATUS
+- read / code-found / blocked / awaiting reply draft
+```
+
+## Pitfalls
+
+- do not blur mailbox work and DM/text work
+- do not claim retrieval without naming the source
+- do not burn time on broad searches when the ask is a recent-code lookup
+- do not keep retrying a blocked auth path without surfacing the blocker
+
+## Verification
+
+- the response names the message source
+- the response includes a sender, service, thread, or clear blocker
+- the final state is explicit and bounded

package/packs/full-harness/rendered/.claude/skills/ml-adoption-playbook/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: ml-adoption-playbook
+description: End-to-end methodology for AI agents and software engineers to add machine learning algorithms to existing non-ML codebases. Covers problem framing, data readiness, architectural decoupling, and baseline model integration.
+---
+
+# ML Adoption Playbook
+
+This skill provides an adaptive methodology for implementing machine learning models into existing software engineering projects. It bridges the gap between traditional SWE and MLOps by structuring how ML should be researched, decoupled, trained, and integrated.
+
+## When to Activate
+
+- A user asks to "add ML" or "add an algorithm" to their existing codebase.
+- Planning the integration of a new model (e.g., recommendation, classification, forecasting) into a non-ML application.
+- Structuring a workflow for an agent to build, train, and deploy an ML component adaptively.
+
+## Phase 1: Problem Framing & Feasibility
+
+Before writing model code, establish the "why" and "how".
+- **Heuristic Check:** Ask the user if a simple heuristic (e.g., regex, rule-based sorting) could solve the problem faster. If yes, start there.
+- **Metric Definition:** Define what business metric the ML model is trying to improve (e.g., click-through rate, reduced latency).
+- **Mistake Budget:** Define what a "bad" prediction looks like and how the system should handle it.
+
+## Phase 2: Data Readiness
+
+ML is useless without clean, accessible data.
+- **Audit Data Sources:** Identify where the training data lives. Is it a live database, a static CSV, or an API?
+- **Data Contract:** Establish a schema for the input data. What features are required? What happens if a feature is missing?
+- **Leakage Prevention:** Ensure the user's proposed data split does not accidentally leak future information into the training set (e.g., chronological splitting for time-series data).
+
+## Phase 3: Architectural Integration & Decoupling
+
+Do not tightly couple model inference to core business logic.
+- **API Boundary:** Suggest placing the model behind an API endpoint (e.g., using `fastapi-patterns` or `django-patterns`) or a dedicated service class.
+- **Fallback Mechanisms:** Design a default state. If the model takes too long to respond or throws an error, the system must gracefully fall back to a hardcoded rule.
+- **Feature Flags:** Wrap the new ML inference call in a feature flag so it can be rolled out (or rolled back) safely.
+
+## Phase 4: Model Implementation & Training
+
+Structure the code for reproducibility and iteration.
+- **Start Simple:** Build a baseline model first (e.g., a simple scikit-learn Logistic Regression or a barebones PyTorch linear layer).
+- **Reproducibility:** Apply `pytorch-patterns` or similar best practices: fix random seeds, make code device-agnostic, and explicitly document tensor/array shapes.
+- **Automated Evidence:** Require tests for the data transforms and inference schema. Do not accept a model without an evaluation script comparing it against the baseline.
+
+## Phase 5: Handoff to MLOps
+
+Once the baseline model is integrated, shift focus to continuous operations.
+- **Refer to `mle-workflow`:** Guide the user toward setting up experiment tracking, model registries, and drift detection.
+- **CI/CD:** Add the model evaluation step to the existing CI pipeline to ensure future commits do not degrade model performance.
+
+## Iterative Agent Workflow
+
+When assisting a user via this playbook, agents should:
+1. **Ask clarifying questions** to complete Phase 1 before proposing architectures.
+2. **Draft a data contract** in Phase 2 for user approval.
+3. **Write the decoupling interface** (API/Service) in Phase 3 *before* writing the training loop.
+4. **Deliver a reproducible script** in Phase 4 that trains the model and saves the artifact.