claudecode-omc 5.6.7 → 5.9.1

package/bundled/upstream/ecc/skills/latency-critical-systems/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: latency-critical-systems
+description: Use for latency-sensitive systems such as realtime dashboards, market data, streaming agents, execution gateways, queues, caches, or HFT-like infrastructure where freshness and p95 latency matter.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Latency Critical Systems
+
+Use this skill when the user cares about realtime behavior, hot paths, streaming
+freshness, or execution speed. This includes HFT-like infrastructure, but the
+skill is engineering-focused. It does not authorize live trading or financial
+advice.
+
+## Split The Metrics
+
+Do not collapse everything into "fast." Track:
+
+- p50, p95, and p99 latency;
+- throughput;
+- freshness age;
+- queue depth;
+- cache hit rate;
+- provider/API response time;
+- browser render time;
+- correctness under load;
+- failure and retry behavior.
+
+## Map The Hot Path
+
+Write the path from user/event to final visible state:
+
+```text
+source event -> provider API -> ingest worker -> queue -> cache -> edge route
+-> client stream -> browser render -> user-visible state
+```
+
+Then measure each segment separately.
+
+## Optimization Order
+
+1. Remove unnecessary round trips.
+2. Cache stable reads with freshness metadata.
+3. Batch small calls and writes.
+4. Move compute closer to the data or the user.
+5. Split hot and cold paths.
+6. Apply backpressure before queues grow unbounded.
+7. Use streaming only when it improves freshness or user experience.
+8. Add canaries for stale data, degraded providers, and bad cache state.
+
+## Verification
+
+Use live readbacks when a deployed surface exists:
+
+- HTTP timing and response headers;
+- provider freshness timestamp;
+- queue or job state;
+- edge/cache state;
+- browser verification for actual UI freshness;
+- logs around retries and degraded mode.
+
+For market-data or execution-adjacent paths, also verify orderbook age, VWAP
+assumptions, provider status, and kill-switch behavior before calling the path
+ready.
+
+## Guardrails
+
+- Do not optimize latency by dropping required validation.
+- Do not hide stale data behind fast cache hits.
+- Do not claim millisecond behavior from client labels without measurement.
+- Do not run live orders, destructive migrations, or customer-impacting deploys
+  without an explicit approval gate.
+- Keep secrets and private payloads out of logs and benchmark artifacts.

package/bundled/upstream/ecc/skills/marketing-campaign/SKILL.md

@@ -0,0 +1,113 @@
+---
+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.
+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/bundled/upstream/ecc/skills/nextjs-turbopack/SKILL.md

@@ -37,6 +37,19 @@ next start
 
 Run `next dev` for local development with Turbopack. Use the Bundle Analyzer (see Next.js docs) to optimize code-splitting and trim large dependencies. Prefer App Router and server components where possible.
 
+## Middleware File Naming
+
+Next.js 16 introduced `proxy.ts` as the middleware filename, replacing the older `middleware.ts` convention:
+
+- **Next.js 16+**: use `proxy.ts` at the project root
+- **Pre-Next.js 16**: use `middleware.ts` at the project root
+
+The filename change is tied to the **Next.js version**, not to which bundler (Turbopack or webpack) is in use. Always check the official docs for the version you are reviewing.
+
+**Do not flag `proxy.ts` as a misnamed or missing middleware file in Next.js 16 projects.** The file is correct and intentional. Suggesting a rename to `middleware.ts` will break middleware execution.
+
+Reference: [Next.js proxy docs](https://nextjs.org/docs/app/getting-started/proxy)
+
 ## Best Practices
 
 - Stay on a recent Next.js 16.x for stable Turbopack and caching behavior.

package/bundled/upstream/ecc/skills/parallel-execution-optimizer/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: parallel-execution-optimizer
+description: Use when the user wants a task done much faster through parallel work, concurrent agents, batched tool calls, isolated worktrees, or many independent verification lanes without losing correctness.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Parallel Execution Optimizer
+
+Use this skill when speed comes from doing independent work at the same time:
+repo inspection, file reads, API checks, browser checks, build/test lanes,
+deploy readbacks, or multi-worktree implementation passes.
+
+## Core Pattern
+
+Turn urgency into a dependency graph before acting.
+
+1. Define the objective and done signal.
+2. Split work into lanes.
+3. Mark each lane as parallel, sequential, or gated.
+4. Run independent reads/checks together.
+5. Keep writes isolated by file, worktree, branch, service, or dataset.
+6. Merge only after evidence shows the lanes are compatible.
+7. End with a verification table, not a vague speed claim.
+
+## Lane Matrix
+
+Before a large push, write a compact matrix:
+
+```text
+Lane | Can run in parallel? | Write surface | Risk | Verification
+Repo scan | yes | none | low | rg/git status outputs
+Backend patch | maybe | src/api | medium | unit tests
+Frontend patch | maybe | app/components | medium | browser screenshot
+Deploy readback | after build | remote service | high | live URL + logs
+```
+
+Only run lanes in parallel when their write surfaces do not collide.
+
+## Execution Rules
+
+- Batch file reads, searches, status checks, and metadata queries.
+- Use isolated worktrees for large unrelated implementation lanes.
+- Start long-running tests, builds, backfills, and deploys in separate sessions,
+  then poll them deliberately.
+- If a lane discovers a blocker that changes the plan, pause dependent lanes
+  and update the matrix.
+- Never let a background process outlive the turn unless the user explicitly
+  asked for a continuing service.
+- Do not parallelize destructive commands, migrations, writes to the same table,
+  or live customer-impacting deploys without an explicit gate.
+
+## Output Shape
+
+Use this when reporting:
+
+```text
+Parallel execution result:
+- Lanes run: 5
+- Lanes completed: 4
+- Blocked lane: deploy readback, waiting on DNS propagation
+- Fast path found: batched repo scan + focused tests
+- Verification: lint pass, unit pass, live smoke pass
+```
+
+## Failure Modes
+
+- More concurrency that creates conflicting edits.
+- Benchmarking the tool instead of the task.
+- Treating "fast" as done before correctness is proven.
+- Forgetting to poll running sessions.
+- Hiding skipped checks behind a success summary.

package/bundled/upstream/ecc/skills/prediction-market-oracle-research/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: prediction-market-oracle-research
+description: Research prediction markets as data sources or oracle signals for products, agents, dashboards, and corporate decision intelligence. Use for source-grounded analysis of market-implied probabilities, caveats, and integration patterns without investment advice.
+origin: ECC
+---
+
+# Prediction Market Oracle Research
+
+Use this skill when prediction markets are being considered as a data source,
+forecasting input, oracle-like signal, or decision-intelligence layer.
+
+## Guardrails
+
+- Do not treat market prices as objective truth.
+- Do not provide investment advice or trading recommendations.
+- Separate venue mechanics, liquidity, incentives, and resolution rules from the
+  implied signal.
+- Call out manipulation, thin liquidity, stale markets, and ambiguous outcomes.
+- For on-chain or execution-linked systems, run `llm-trading-agent-security`
+  before granting any write authority.
+
+## Research Workflow
+
+1. Define the decision the signal is meant to inform.
+2. Find relevant markets, events, tags, and venues.
+3. Record market-implied probabilities with timestamps and source links.
+4. Evaluate signal quality:
+   - liquidity
+   - spread
+   - market age
+   - trader/incentive concentration if known
+   - resolution authority
+   - geography or account restrictions
+5. Compare against non-market sources such as filings, news, polls, research,
+   customer data, or internal KPIs.
+6. Recommend whether the signal is usable, weak, or unsuitable for the stated
+   decision.
+
+## Integration Patterns
+
+- Research assistant: source-grounded context for a human analyst.
+- Dashboard signal: market-implied probability alongside internal metrics.
+- Agent memory input: a time-stamped signal that can be retrieved later.
+- Alerting input: notify when probabilities, spreads, or liquidity cross a
+  threshold.
+- Scenario planning: compare multiple event outcomes without automating trades.
+
+## Output Contract
+
+Use:
+
+1. decision context
+2. market sources
+3. signal quality
+4. comparison sources
+5. integration recommendation
+6. caveats
+
+End with:
+
+```text
+Prediction-market signals are informational inputs, not investment advice.
+```

package/bundled/upstream/ecc/skills/prediction-market-risk-review/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: prediction-market-risk-review
+description: Review prediction-market, basket, oracle, and trading-agent workflows for compliance, safety, data-quality, privacy, and execution risk. Use before any workflow handles venue auth, user portfolio data, API keys, or trade planning.
+origin: ECC
+---
+
+# Prediction Market Risk Review
+
+Use this skill before a prediction-market workflow touches user financial
+context, venue authentication, portfolio data, automation, or execution-capable
+tools.
+
+## Review Gates
+
+### Advice Boundary
+
+- Confirm the output is informational.
+- Remove buy/sell/hold/size recommendations.
+- Keep manual user decision points explicit.
+
+### Venue And Regulatory Boundary
+
+- Identify venue terms, geography restrictions, account limits, and API rules.
+- Flag betting, derivatives, securities, or commodities ambiguity for legal
+  review when relevant.
+- Do not bypass venue restrictions or rate limits.
+
+### Data Quality
+
+- Check market liquidity, spread, resolution rules, stale prices, and source
+  timestamps.
+- Separate public venue data from Itô gated data.
+- Do not mix public and private sources without labels.
+
+### Security
+
+- Do not request or store private keys, seed phrases, or passwords.
+- Keep `ITO_API_KEY` and venue API keys out of logs and docs.
+- Use read-only scopes by default.
+- Require circuit breakers, spend limits, dry runs, and human approval before
+  any private implementation adds execution.
+
+### Privacy
+
+- Minimize user portfolio, financial, and knowledge-base data.
+- Redact private sources in public artifacts.
+- Preserve only the fields needed for the review.
+
+## Output Contract
+
+Return:
+
+1. scope reviewed
+2. pass/warn/fail findings
+3. blocked actions
+4. required mitigations
+5. safe next step
+
+If any execution-capable step is requested, require a separate implementation
+plan and explicit user approval.