codeply-cli 0.5.6 → 0.6.0

package/skills/marketing-campaign/SKILL.md

@@ -1,114 +1,114 @@
----
-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.
-metadata:
-  origin: ECC
----
-
-# 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
+---
+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.
+metadata:
+  origin: ECC
+---
+
+# 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/skills/mcp-server-patterns/SKILL.md

@@ -1,70 +1,70 @@
----
-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.
-metadata:
-  origin: ECC
----
-
-# 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.
+---
+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.
+metadata:
+  origin: ECC
+---
+
+# 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/skills/messages-ops/SKILL.md

@@ -1,105 +1,105 @@
----
-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.
-metadata:
-  origin: ECC
----
-
-# 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
+---
+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.
+metadata:
+  origin: ECC
+---
+
+# 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