claudecode-omc 5.9.1 → 5.12.0

package/bundled/upstream/ecc/skills/brand-discovery/references/70_founder-tension.md

@@ -0,0 +1,49 @@
+# Module 70 — Founder Brand vs Organisation Brand
+
+> **Frameworks:** Enns *Win Without Pitching* · Personal brand vs institutional
+> brand spectrum
+>
+> **Goal:** Map the relationship between the founder's personal reputation and the
+> organisation's brand. Clarify how much equity each carries, what the healthy
+> boundary is, and how to sequence personal vs organisation brand investment.
+> Unresolved founder-brand tension is a common scaling bottleneck.
+
+---
+
+## Raw
+
+<!-- Verbatim quotes. -->
+
+### Is the founder personally known in the market? How?
+
+### Do clients buy the founder or the organisation? (ask for evidence, not instinct)
+
+### What happens to the brand if the founder steps back or is unavailable?
+
+### What does the founder want for their personal brand in 3–5 years?
+
+### What does the organisation's brand need to be able to do independently?
+
+### Where has the founder-brand been an asset? Where has it been a constraint?
+
+---
+
+## Synthesis
+
+### Current state: where on the spectrum?
+
+```
+[Founder IS the brand] ←————————→ [Organisation brand stands alone]
+         1         2         3         4         5
+```
+Current position: `___`   Target position (3-year): `___`
+
+### What the founder brand should own (and keeps owning)
+
+### What the organisation brand needs to own (independently of the founder)
+
+### Transition plan sketch (if moving from founder-centric toward institutional)
+
+### Risk if nothing changes
+
+### Open questions / threads for Module 90 Synthesis

package/bundled/upstream/ecc/skills/brand-discovery/references/90_SYNTHESIS.md

@@ -0,0 +1,133 @@
+# Module 90 — Master Brandbook (Synthesis)
+
+> **Frameworks:** Kapferer Brand Identity Prism · Aaker brand system (identity /
+> personality / associations / equity)
+>
+> **Goal:** Reconcile all seven preceding modules into a single, actionable
+> brandbook. This document is the source of truth the brand uses to brief
+> designers, writers, and external collaborators. It resolves tensions between
+> modules, commits to specific formulations, and translates them into practical
+> guidelines.
+
+---
+
+## Raw
+
+<!-- Module 90 consolidates outputs from Modules 10–70; minimal new raw input is
+     collected here. Capture any final founder statements or corrections made
+     during the synthesis pass below. -->
+
+---
+
+## Synthesis
+
+### 1. The Why (from Module 10)
+
+> **Core belief:**
+>
+> **Behavioural How (values in action):**
+>
+> **What we refuse to be:**
+
+---
+
+### 2. Positioning (from Module 20)
+
+> **Positioning statement:**
+> For **[target client]** who **[situation]**, **[brand name]** is the
+> **[category]** that **[unique value]**. Unlike **[alternatives]**, we
+> **[key differentiator]**.
+>
+> **White-space the brand owns:**
+
+---
+
+### 3. Audience (from Module 30)
+
+> **Ideal Client Profile (one-paragraph portrait):**
+>
+> **Niche the brand is building toward:**
+>
+> **Red-flag / disqualifier:**
+
+---
+
+### 4. Kapferer Brand Identity Prism
+
+| Facet | Content |
+|---|---|
+| **Physique** (visible, tangible brand attributes) | |
+| **Personality** (character if the brand were a person) | |
+| **Culture** (values and principles behind the brand) | |
+| **Relationship** (how the brand relates to clients) | |
+| **Reflection** (how clients see themselves using this brand) | |
+| **Self-image** (how clients feel inside when using this brand) | |
+
+---
+
+### 4b. Aaker Brand System (from Module 40)
+
+> **Primary archetype** (Mark & Pearson):
+>
+> **Secondary archetype** (if present):
+>
+> **Aaker brand identity** — four dimensions:
+> - *Brand as product:*
+> - *Brand as organisation:*
+> - *Brand as person (personality):*
+> - *Brand as symbol:*
+>
+> **Brand associations** (3–5 key associations the brand should own):
+>
+> **Brand equity signals** (what clients would lose if this brand disappeared):
+
+---
+
+### 5. Voice & Tone summary (from Module 50)
+
+> **Voice statement (one paragraph):**
+>
+> **The three checks every draft must pass:**
+> 1.
+> 2.
+> 3.
+
+---
+
+### 6. Narrative assets (from Module 60)
+
+> **Trueline:**
+>
+> **Brand story arc (one paragraph, usable as an About page starting point):**
+
+---
+
+### 7. Founder / organisation brand boundary (from Module 70)
+
+> **What the founder brand owns:**
+>
+> **What the organisation brand owns:**
+
+---
+
+### 8. Tensions resolved (record any module-to-module conflicts and how they were settled)
+
+| Tension | Module A | Module B | Resolution |
+|---|---|---|---|
+| | | | |
+
+---
+
+### 9. Open questions deferred to next session
+
+<!-- Anything that couldn't be resolved with the current data. -->
+
+---
+
+### 10. Practical next steps
+
+<!-- 3–5 concrete actions the brand can take based on this brandbook. -->
+
+1.
+2.
+3.

package/bundled/upstream/ecc/skills/brand-voice/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: brand-voice
 description: Build a source-derived writing style profile from real posts, essays, launch notes, docs, or site copy, then reuse that profile across content, outreach, and social workflows. Use when the user wants voice consistency without generic AI writing tropes.
-origin: ECC
+metadata:
+  origin: ECC
 ---
 
 # Brand Voice

package/bundled/upstream/ecc/skills/browser-qa/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: browser-qa
 description: Use this skill to automate visual testing and UI interaction verification using browser automation after deploying features.
-origin: ECC
+metadata:
+  origin: ECC
 ---
 
 # Browser QA — Automated Visual Testing & Interaction
@@ -18,6 +19,14 @@ origin: ECC
 
 Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user.
 
+### Safety first — blast radius (run read-only by default)
+
+Browser QA drives real auth and real user journeys, so treat the blast radius explicitly.
+Default to **read-only**: never run a **mutating** journey (checkout, payment, delete,
+mass-update) against a production URL — require an explicit opt-in **and** a staging/preview
+URL. Use seeded **test credentials**, never real production logins, and **redact**
+credentials/tokens/PII before saving any screenshot.
+
 ### Phase 1: Smoke Test
 ```
 1. Navigate to target URL
@@ -25,6 +34,7 @@ Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to
 3. Verify no 4xx/5xx in network requests
 4. Screenshot above-the-fold on desktop + mobile viewport
 5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
+   (INP replaced FID in March 2024; thresholds per web.dev)
 ```
 
 ### Phase 2: Interaction Test
@@ -32,14 +42,17 @@ Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to
 1. Click every nav link — verify no dead links
 2. Submit forms with valid data — verify success state
 3. Submit forms with invalid data — verify error state
-4. Test auth flow: login → protected page → logout
+4. Test auth flow: login → protected page → logout (test creds only, never prod)
 5. Test critical user journeys (checkout, onboarding, search)
+   — read-only by default; only exercise mutating journeys against staging
+     with explicit opt-in (see "Safety first" above)
 ```
 
 ### Phase 3: Visual Regression
 ```
 1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
-2. Compare against baseline screenshots (if stored)
+2. Compare against committed baseline screenshots
+   — no baseline ⇒ report INCONCLUSIVE, never a silent PASS
 3. Flag layout shifts > 5px, missing elements, overflow
 4. Check dark mode if applicable
 ```
@@ -47,11 +60,15 @@ Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to
 ### Phase 4: Accessibility
 ```
 1. Run axe-core or equivalent on each page
-2. Flag WCAG AA violations (contrast, labels, focus order)
+2. Flag WCAG 2.2 AA violations (contrast, labels, focus order)
 3. Verify keyboard navigation works end-to-end
 4. Check screen reader landmarks
 ```
 
+> Note: axe-core automatically covers roughly 30–40% of WCAG. A clean run is **necessary,
+> not sufficient** — keyboard nav, focus order, and a screen-reader pass still need a manual
+> check. Don't report "accessible" from an automated pass alone.
+
 ## Output Format
 
 ```markdown
@@ -75,6 +92,7 @@ Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to
 - 2 AA violations: missing alt text on hero image, low contrast on footer links
 
 ### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
+# verdict ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; use INCONCLUSIVE if no visual baseline
 ```
 
 ## Integration

package/bundled/upstream/ecc/skills/bun-runtime/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: bun-runtime
 description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
-origin: ECC
+metadata:
+  origin: ECC
 ---
 
 # Bun Runtime

package/bundled/upstream/ecc/skills/canary-watch/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: canary-watch
 description: Use this skill to monitor and verify a deployed URL after releases — checks HTTP endpoints, SSE streams, static assets, console errors, and performance regressions after deploys, merges, or dependency upgrades. Smoke / canary / post-deploy verification.
-origin: ECC
+metadata:
+  origin: ECC
 ---
 
 # Canary Watch — Post-Deploy Monitoring

package/bundled/upstream/ecc/skills/carrier-relationship-management/SKILL.md

@@ -10,8 +10,8 @@ description: >
 license: Apache-2.0
 version: 1.0.0
 homepage: https://github.com/affaan-m/everything-claude-code
-origin: ECC
 metadata:
+  origin: ECC
   author: evos
   clawdbot:
     emoji: ""

package/bundled/upstream/ecc/skills/cisco-ios-patterns/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: cisco-ios-patterns
 description: Cisco IOS and IOS-XE review patterns for show commands, config hierarchy, wildcard masks, ACL placement, interface hygiene, and safe change-window verification.
-origin: community
+metadata:
+  origin: community
 ---
 
 # Cisco IOS Patterns

package/bundled/upstream/ecc/skills/ck/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: ck
 description: Persistent per-project memory for Claude Code. Auto-loads project context on session start, tracks sessions with git activity, and writes to native memory. Commands run deterministic Node.js scripts — behavior is consistent across model versions.
-origin: community
+metadata:
+  origin: community
 version: 2.0.0
 author: sreedhargs89
 repo: https://github.com/sreedhargs89/context-keeper

package/bundled/upstream/ecc/skills/claude-devfleet/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: claude-devfleet
 description: Orchestrate multi-agent coding tasks via Claude DevFleet — plan projects, dispatch parallel agents in isolated worktrees, monitor progress, and read structured reports.
-origin: community
+metadata:
+  origin: community
 ---
 
 # Claude DevFleet Multi-Agent Orchestration
@@ -10,11 +11,19 @@ origin: community
 
 Use this skill when you need to dispatch multiple Claude Code agents to work on coding tasks in parallel. Each agent runs in an isolated git worktree with full tooling.
 
-Requires a running Claude DevFleet instance connected via MCP:
+## Setup
+
+The DevFleet server is a separate project, not bundled with ECC. Install and
+run it from its repository first: <https://github.com/LEC-AI/claude-devfleet>
+
+Then connect the running instance via MCP:
 ```bash
 claude mcp add devfleet --transport http http://localhost:18801/mcp
 ```
 
+Before first use, verify the process listening on port 18801 is the DevFleet
+binary you installed (see SECURITY.md on localhost MCP servers).
+
 ## How It Works
 
 ```

package/bundled/upstream/ecc/skills/click-path-audit/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: click-path-audit
 description: "Trace every user-facing button/touchpoint through its full state change sequence to find bugs where functions individually work but cancel each other out, produce wrong final state, or leave the UI in an inconsistent state. Use when: systematic debugging found no bugs but users report broken buttons, or after any major refactor touching shared state stores."
-origin: community
+metadata:
+  origin: community
 ---
 
 # /click-path-audit — Behavioural Flow Audit

package/bundled/upstream/ecc/skills/clickhouse-io/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: clickhouse-io
 description: ClickHouse database patterns, query optimization, analytics, and data engineering best practices for high-performance analytical workloads.
-origin: ECC
+metadata:
+  origin: ECC
 ---
 
 # ClickHouse Analytics Patterns

package/bundled/upstream/ecc/skills/code-tour/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: code-tour
 description: Create CodeTour `.tour` files — persona-targeted, step-by-step walkthroughs with real file and line anchors. Use for onboarding tours, architecture walkthroughs, PR tours, RCA tours, and structured "explain how this works" requests.
-origin: ECC
+metadata:
+  origin: ECC
 ---
 
 # Code Tour

package/bundled/upstream/ecc/skills/codebase-onboarding/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: codebase-onboarding
 description: Analyze an unfamiliar codebase and generate a structured onboarding guide with architecture map, key entry points, conventions, and a starter CLAUDE.md. Use when joining a new project or setting up Claude Code for the first time in a repo.
-origin: ECC
+metadata:
+  origin: ECC
 ---
 
 # Codebase Onboarding

package/bundled/upstream/ecc/skills/codehealth-mcp/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: codehealth-mcp
+description: Real-time structural Code Health via CodeScene MCP — review before edits, verify score deltas after changes, gate commits and PRs. Use when reviewing code quality, refactoring, checking if AI changes degraded a file, or before commit/PR.
+metadata:
+  origin: community
+---
+
+# Code Health MCP (CodeScene)
+
+Structural maintainability feedback for AI-assisted coding. Complements style/lint skills (`coding-standards`, `plankton-code-quality`) with **design-level** health scores and regression gates.
+
+**Upstream:** [codescene-oss/codescene-mcp-server](https://github.com/codescene-oss/codescene-mcp-server)
+**Package:** `@codescene/codehealth-mcp` (stdio via npx)
+
+## Security and boundaries
+
+**Opt-in (ECC):** The `codescene` block in `mcp-configs/mcp-servers.json` is a template only. ECC plugin installs do not auto-enable bundled MCP servers. Copy the entry into your config only if you want it. You can exclude it during ECC install/sync with `ECC_DISABLED_MCPS=codescene,...`.
+
+**Credentials:** No bundled token. Set `CS_ACCESS_TOKEN` yourself (see [getting-a-personal-access-token.md](https://github.com/codescene-oss/codescene-mcp-server/blob/main/docs/getting-a-personal-access-token.md) in the upstream repo). Never commit tokens to the repo.
+
+**What the tools read:** When invoked, tools analyze files and git state **in the local repository** you point them at (paths you pass, plus branch context for `analyze_change_set`). They do not run by themselves. For standalone mode, follow upstream privacy docs: [codescene-mcp-server README](https://github.com/codescene-oss/codescene-mcp-server#frequently-asked-questions) and [CodeScene policies](https://codescene.com/policies). Do not use this skill for secrets, credentials, or paths you do not want analyzed.
+
+**If the MCP is unavailable (offline, bad token, server crash):** Do not invent Code Health scores. Tell the user the check was skipped. Continue only with explicit user approval. Prefer lint/tests/verification-loop for gating when MCP is down. Re-enable checks once the server connects.
+
+## When to Use
+
+- User asks to **review code quality**, **refactor** a file, or check if **AI changes degraded** maintainability
+- Before editing a **hotspot**, legacy module, or unfamiliar file
+- Before **commit** or **pull request** when you need a maintainability safeguard
+- After a large agent-written diff — verify Code Health did not regress
+- Pair with `verification-loop`, `tdd-workflow`, or `/quality-gate` as a structural check (not a replacement for tests/lint)
+
+## When to Activate
+
+Same triggers as **When to Use** above — this heading is what ECC uses for skill auto-activation.
+
+## How It Works
+
+### 1. Connect the MCP server
+
+Copy the `codescene` entry from `mcp-configs/mcp-servers.json` into your harness MCP config.
+
+**Claude Code** (`~/.claude.json` → `mcpServers`):
+
+```json
+"codescene": {
+  "command": "npx",
+  "args": ["-y", "@codescene/codehealth-mcp"],
+  "env": {
+    "CS_ACCESS_TOKEN": "YOUR_CS_ACCESS_TOKEN_HERE"
+  }
+}
+```
+
+**Project-scoped:** merge the same block into `.mcp.json` at the repo root.
+
+Token setup is documented in the upstream repo (link above). Standalone mode does not require a paid CodeScene platform account for the four tools listed below. Restart the session and confirm the `codescene` server is connected before relying on scores.
+
+### 2. Call standalone tools only
+
+| Tool | When to use |
+|------|-------------|
+| `code_health_review` | Full structural analysis **before** modifying a file |
+| `code_health_score` | Quick numeric score after each change (delta check) |
+| `pre_commit_code_health_safeguard` | Block commits that introduce Code Health regressions |
+| `analyze_change_set` | Branch-level check **before** opening a PR |
+
+Do **not** call platform-only tools (e.g. repository-wide technical debt hotspot lists). Do **not** reference `delta_analysis` — not available on standalone.
+
+### 3. Interpret scores (1–10)
+
+| Range | Meaning | Agent behavior |
+|-------|---------|----------------|
+| **9.0–10.0** | Green — healthy | Safer to extend; still prefer vertical slices |
+| **4.0–8.9** | Yellow — debt | Tread carefully; no drive-by refactors |
+| **1.0–3.9** | Red — severe debt | Narrow scope only |
+
+### 4. Run the feedback loop
+
+**Before touching a file**
+
+1. Run `code_health_review` on the target path.
+2. Record baseline score and listed code smells.
+3. Plan the smallest change that addresses the task.
+
+Scope by score: **below 5** — minimal diff only; **5–7** — no broad refactors; **above 7** — safer to refactor, still verify after each edit.
+
+**After each change**
+
+1. Run `code_health_score` on the same file.
+2. Compare to the baseline from `code_health_review`.
+3. If the score **regressed**, fix before continuing. Never mark the task done while the score is lower than when you started.
+
+**Before every commit** — run `pre_commit_code_health_safeguard` on the repository path.
+
+**Before a PR** — run `analyze_change_set` against the base branch (e.g. `main`).
+
+## Examples
+
+### Example: Flask maintainability improvement
+
+On `pallets/flask`, an agent loop using only standalone tools:
+
+1. `code_health_review` on a target module (baseline **4.82**)
+2. Targeted refactor addressing listed smells
+3. `code_health_score` after each edit
+4. `pre_commit_code_health_safeguard` before commit
+5. `analyze_change_set` before PR
+
+Result: Code Health **4.82 → 9.1** (free standalone token only).
+
+### Example: AGENTS.md enforcement block
+
+Paste into the project `AGENTS.md` or `CLAUDE.md`:
+
+```md
+## Code Health (CodeScene MCP)
+
+Before modifying any file: run `code_health_review`, note score and issues.
+
+- Score below 5: problematic range — scope changes narrowly.
+- Score 5–7: warning range — no broad refactors.
+
+After each change: run `code_health_score` to verify delta.
+
+- If score regressed: fix before continuing; never declare done if score dropped.
+
+Before every commit: run `pre_commit_code_health_safeguard`.
+
+Before PR: run `analyze_change_set`.
+```
+
+### Example: anti-patterns vs correct loop
+
+```markdown
+# BAD: Edit first, check later
+[large refactor without code_health_review]
+
+# BAD: Ignore score drop
+"Tests pass" → mark task done while Code Health decreased
+
+# BAD: Broad refactor on red-score file (below 5)
+Drive-by cleanup across the module
+
+# GOOD: review → small change → score → commit safeguard → analyze_change_set
+```
+
+## Pairing with ECC
+
+| ECC skill / flow | Code Health MCP role |
+|------------------|----------------------|
+| `coding-standards` | Style/naming; Code Health = structure/complexity |
+| `plankton-code-quality` | Write-time lint/format; Code Health = pre/post edit structural gate |
+| `verification-loop` / `/quality-gate` | Add structural regression check before "done" |
+| `security-review` | Security vs maintainability — use both when relevant |
+| `tdd-workflow` | Tests pass ≠ healthy design — check score after refactors |
+
+**Context tip:** ECC recommends keeping MCP count low. Enable `codescene` when doing substantive edits; disable when not needed.
+
+## Related Skills
+
+- `coding-standards` — baseline conventions
+- `plankton-code-quality` — write-time lint/format hooks
+- `verification-loop` — build/test/lint gate
+- `tdd-workflow` — test-first development
+- `security-review` — security checklist
+- `documentation-lookup` — library docs via Context7 (orthogonal)

package/bundled/upstream/ecc/skills/coding-standards/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: coding-standards
 description: Baseline cross-project coding conventions for naming, readability, immutability, and code-quality review. Use detailed frontend or backend skills for framework-specific patterns.
-origin: ECC
+metadata:
+  origin: ECC
 ---
 
 # Coding Standards & Best Practices
@@ -415,8 +416,9 @@ export async function searchMarkets(
 import { useMemo, useCallback } from 'react'
 
 // PASS: GOOD: Memoize expensive computations
+// Copy before sorting - Array.prototype.sort mutates in place
 const sortedMarkets = useMemo(() => {
-  return markets.sort((a, b) => b.volume - a.volume)
+  return [...markets].sort((a, b) => b.volume - a.volume)
 }, [markets])
 
 // PASS: GOOD: Memoize callbacks