docs: record ECC Tools followup flood control

Record ECC-Tools PR #30 follow-up flood-control evidence in the ECC 2.0 GA roadmap.

.agents/skills/claude-api/SKILL.md

@@ -1,336 +0,0 @@
----
-name: claude-api
-description: Anthropic Claude API patterns for Python and TypeScript. Covers Messages API, streaming, tool use, vision, extended thinking, batches, prompt caching, and Claude Agent SDK. Use when building applications with the Claude API or Anthropic SDKs.
----
-
-# Claude API
-
-Build applications with the Anthropic Claude API and SDKs.
-
-## When to Activate
-
-- Building applications that call the Claude API
-- Code imports `anthropic` (Python) or `@anthropic-ai/sdk` (TypeScript)
-- User asks about Claude API patterns, tool use, streaming, or vision
-- Implementing agent workflows with Claude Agent SDK
-- Optimizing API costs, token usage, or latency
-
-## Model Selection
-
-| Model | ID | Best For |
-|-------|-----|----------|
-| Opus 4.6 | `claude-opus-4-6` | Complex reasoning, architecture, research |
-| Sonnet 4.6 | `claude-sonnet-4-6` | Balanced coding, most development tasks |
-| Haiku 4.5 | `claude-haiku-4-5-20251001` | Fast responses, high-volume, cost-sensitive |
-
-Default to Sonnet 4.6 unless the task requires deep reasoning (Opus) or speed/cost optimization (Haiku).
-
-## Python SDK
-
-### Installation
-
-```bash
-pip install anthropic
-```
-
-### Basic Message
-
-```python
-import anthropic
-
-client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from env
-
-message = client.messages.create(
-    model="claude-sonnet-4-6",
-    max_tokens=1024,
-    messages=[
-        {"role": "user", "content": "Explain async/await in Python"}
-    ]
-)
-print(message.content[0].text)
-```
-
-### Streaming
-
-```python
-with client.messages.stream(
-    model="claude-sonnet-4-6",
-    max_tokens=1024,
-    messages=[{"role": "user", "content": "Write a haiku about coding"}]
-) as stream:
-    for text in stream.text_stream:
-        print(text, end="", flush=True)
-```
-
-### System Prompt
-
-```python
-message = client.messages.create(
-    model="claude-sonnet-4-6",
-    max_tokens=1024,
-    system="You are a senior Python developer. Be concise.",
-    messages=[{"role": "user", "content": "Review this function"}]
-)
-```
-
-## TypeScript SDK
-
-### Installation
-
-```bash
-npm install @anthropic-ai/sdk
-```
-
-### Basic Message
-
-```typescript
-import Anthropic from "@anthropic-ai/sdk";
-
-const client = new Anthropic(); // reads ANTHROPIC_API_KEY from env
-
-const message = await client.messages.create({
-  model: "claude-sonnet-4-6",
-  max_tokens: 1024,
-  messages: [
-    { role: "user", content: "Explain async/await in TypeScript" }
-  ],
-});
-console.log(message.content[0].text);
-```
-
-### Streaming
-
-```typescript
-const stream = client.messages.stream({
-  model: "claude-sonnet-4-6",
-  max_tokens: 1024,
-  messages: [{ role: "user", content: "Write a haiku" }],
-});
-
-for await (const event of stream) {
-  if (event.type === "content_block_delta" && event.delta.type === "text_delta") {
-    process.stdout.write(event.delta.text);
-  }
-}
-```
-
-## Tool Use
-
-Define tools and let Claude call them:
-
-```python
-tools = [
-    {
-        "name": "get_weather",
-        "description": "Get current weather for a location",
-        "input_schema": {
-            "type": "object",
-            "properties": {
-                "location": {"type": "string", "description": "City name"},
-                "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
-            },
-            "required": ["location"]
-        }
-    }
-]
-
-message = client.messages.create(
-    model="claude-sonnet-4-6",
-    max_tokens=1024,
-    tools=tools,
-    messages=[{"role": "user", "content": "What's the weather in SF?"}]
-)
-
-# Handle tool use response
-for block in message.content:
-    if block.type == "tool_use":
-        # Execute the tool with block.input
-        result = get_weather(**block.input)
-        # Send result back
-        follow_up = client.messages.create(
-            model="claude-sonnet-4-6",
-            max_tokens=1024,
-            tools=tools,
-            messages=[
-                {"role": "user", "content": "What's the weather in SF?"},
-                {"role": "assistant", "content": message.content},
-                {"role": "user", "content": [
-                    {"type": "tool_result", "tool_use_id": block.id, "content": str(result)}
-                ]}
-            ]
-        )
-```
-
-## Vision
-
-Send images for analysis:
-
-```python
-import base64
-
-with open("diagram.png", "rb") as f:
-    image_data = base64.standard_b64encode(f.read()).decode("utf-8")
-
-message = client.messages.create(
-    model="claude-sonnet-4-6",
-    max_tokens=1024,
-    messages=[{
-        "role": "user",
-        "content": [
-            {"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": image_data}},
-            {"type": "text", "text": "Describe this diagram"}
-        ]
-    }]
-)
-```
-
-## Extended Thinking
-
-For complex reasoning tasks:
-
-```python
-message = client.messages.create(
-    model="claude-sonnet-4-6",
-    max_tokens=16000,
-    thinking={
-        "type": "enabled",
-        "budget_tokens": 10000
-    },
-    messages=[{"role": "user", "content": "Solve this math problem step by step..."}]
-)
-
-for block in message.content:
-    if block.type == "thinking":
-        print(f"Thinking: {block.thinking}")
-    elif block.type == "text":
-        print(f"Answer: {block.text}")
-```
-
-## Prompt Caching
-
-Cache large system prompts or context to reduce costs:
-
-```python
-message = client.messages.create(
-    model="claude-sonnet-4-6",
-    max_tokens=1024,
-    system=[
-        {"type": "text", "text": large_system_prompt, "cache_control": {"type": "ephemeral"}}
-    ],
-    messages=[{"role": "user", "content": "Question about the cached context"}]
-)
-# Check cache usage
-print(f"Cache read: {message.usage.cache_read_input_tokens}")
-print(f"Cache creation: {message.usage.cache_creation_input_tokens}")
-```
-
-## Batches API
-
-Process large volumes asynchronously at 50% cost reduction:
-
-```python
-import time
-
-batch = client.messages.batches.create(
-    requests=[
-        {
-            "custom_id": f"request-{i}",
-            "params": {
-                "model": "claude-sonnet-4-6",
-                "max_tokens": 1024,
-                "messages": [{"role": "user", "content": prompt}]
-            }
-        }
-        for i, prompt in enumerate(prompts)
-    ]
-)
-
-# Poll for completion
-while True:
-    status = client.messages.batches.retrieve(batch.id)
-    if status.processing_status == "ended":
-        break
-    time.sleep(30)
-
-# Get results
-for result in client.messages.batches.results(batch.id):
-    print(result.result.message.content[0].text)
-```
-
-## Claude Agent SDK
-
-Build multi-step agents:
-
-```python
-# Note: Agent SDK API surface may change — check official docs
-import anthropic
-
-# Define tools as functions
-tools = [{
-    "name": "search_codebase",
-    "description": "Search the codebase for relevant code",
-    "input_schema": {
-        "type": "object",
-        "properties": {"query": {"type": "string"}},
-        "required": ["query"]
-    }
-}]
-
-# Run an agentic loop with tool use
-client = anthropic.Anthropic()
-messages = [{"role": "user", "content": "Review the auth module for security issues"}]
-
-while True:
-    response = client.messages.create(
-        model="claude-sonnet-4-6",
-        max_tokens=4096,
-        tools=tools,
-        messages=messages,
-    )
-    if response.stop_reason == "end_turn":
-        break
-    # Handle tool calls and continue the loop
-    messages.append({"role": "assistant", "content": response.content})
-    # ... execute tools and append tool_result messages
-```
-
-## Cost Optimization
-
-| Strategy | Savings | When to Use |
-|----------|---------|-------------|
-| Prompt caching | Up to 90% on cached tokens | Repeated system prompts or context |
-| Batches API | 50% | Non-time-sensitive bulk processing |
-| Haiku instead of Sonnet | ~75% | Simple tasks, classification, extraction |
-| Shorter max_tokens | Variable | When you know output will be short |
-| Streaming | None (same cost) | Better UX, same price |
-
-## Error Handling
-
-```python
-import time
-
-from anthropic import APIError, RateLimitError, APIConnectionError
-
-try:
-    message = client.messages.create(...)
-except RateLimitError:
-    # Back off and retry
-    time.sleep(60)
-except APIConnectionError:
-    # Network issue, retry with backoff
-    pass
-except APIError as e:
-    print(f"API error {e.status_code}: {e.message}")
-```
-
-## Environment Setup
-
-```bash
-# Required
-export ANTHROPIC_API_KEY="your-api-key-here"
-
-# Optional: set default model
-export ANTHROPIC_MODEL="claude-sonnet-4-6"
-```
-
-Never hardcode API keys. Always use environment variables.

.agents/skills/claude-api/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Claude API"
-  short_description: "Claude API patterns for Python and TypeScript"
-  brand_color: "#D97706"
-  default_prompt: "Use $claude-api to build with Claude API and Anthropic SDK patterns."
-policy:
-  allow_implicit_invocation: true

.agents/skills/frontend-design/SKILL.md

@@ -1,144 +0,0 @@
----
-name: frontend-design
-description: Create distinctive, production-grade frontend interfaces with high design quality. Use when the user asks to build web components, pages, or applications and the visual direction matters as much as the code quality.
----
-
-# Frontend Design
-
-Use this when the task is not just "make it work" but "make it look designed."
-
-This skill is for product pages, dashboards, app shells, components, or visual systems that need a clear point of view instead of generic AI-looking UI.
-
-## When To Use
-
-- building a landing page, dashboard, or app surface from scratch
-- upgrading a bland interface into something intentional and memorable
-- translating a product concept into a concrete visual direction
-- implementing a frontend where typography, composition, and motion matter
-
-## Core Principle
-
-Pick a direction and commit to it.
-
-Safe-average UI is usually worse than a strong, coherent aesthetic with a few bold choices.
-
-## Design Workflow
-
-### 1. Frame the interface first
-
-Before coding, settle:
-
-- purpose
-- audience
-- emotional tone
-- visual direction
-- one thing the user should remember
-
-Possible directions:
-
-- brutally minimal
-- editorial
-- industrial
-- luxury
-- playful
-- geometric
-- retro-futurist
-- soft and organic
-- maximalist
-
-Do not mix directions casually. Choose one and execute it cleanly.
-
-### 2. Build the visual system
-
-Define:
-
-- type hierarchy
-- color variables
-- spacing rhythm
-- layout logic
-- motion rules
-- surface / border / shadow treatment
-
-Use CSS variables or the project's token system so the interface stays coherent as it grows.
-
-### 3. Compose with intention
-
-Prefer:
-
-- asymmetry when it sharpens hierarchy
-- overlap when it creates depth
-- strong whitespace when it clarifies focus
-- dense layouts only when the product benefits from density
-
-Avoid defaulting to a symmetrical card grid unless it is clearly the right fit.
-
-### 4. Make motion meaningful
-
-Use animation to:
-
-- reveal hierarchy
-- stage information
-- reinforce user action
-- create one or two memorable moments
-
-Do not scatter generic micro-interactions everywhere. One well-directed load sequence is usually stronger than twenty random hover effects.
-
-## Strong Defaults
-
-### Typography
-
-- pick fonts with character
-- pair a distinctive display face with a readable body face when appropriate
-- avoid generic defaults when the page is design-led
-
-### Color
-
-- commit to a clear palette
-- one dominant field with selective accents usually works better than evenly weighted rainbow palettes
-- avoid cliché purple-gradient-on-white unless the product genuinely calls for it
-
-### Background
-
-Use atmosphere:
-
-- gradients
-- meshes
-- textures
-- subtle noise
-- patterns
-- layered transparency
-
-Flat empty backgrounds are rarely the best answer for a product-facing page.
-
-### Layout
-
-- break the grid when the composition benefits from it
-- use diagonals, offsets, and grouping intentionally
-- keep reading flow obvious even when the layout is unconventional
-
-## Anti-Patterns
-
-Never default to:
-
-- interchangeable SaaS hero sections
-- generic card piles with no hierarchy
-- random accent colors without a system
-- placeholder-feeling typography
-- motion that exists only because animation was easy to add
-
-## Execution Rules
-
-- preserve the established design system when working inside an existing product
-- match technical complexity to the visual idea
-- keep accessibility and responsiveness intact
-- frontends should feel deliberate on desktop and mobile
-
-## Quality Gate
-
-Before delivering:
-
-- the interface has a clear visual point of view
-- typography and spacing feel intentional
-- color and motion support the product instead of decorating it randomly
-- the result does not read like generic AI UI
-- the implementation is production-grade, not just visually interesting

.agents/skills/frontend-design/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Frontend Design"
-  short_description: "Production-grade frontend interface design"
-  brand_color: "#0EA5E9"
-  default_prompt: "Use $frontend-design to build a distinctive production-grade interface."
-policy:
-  allow_implicit_invocation: true

.agents/skills/frontend-patterns/SKILL.md

@@ -17,6 +17,12 @@ Modern frontend patterns for React, Next.js, and performant user interfaces.
 - Handling client-side routing and navigation
 - Building accessible, responsive UI patterns
 
+## Privacy and Data Boundaries
+
+Frontend examples should use synthetic or domain-generic data. Do not collect, log, persist, or display credentials, access tokens, SSNs, health data, payment details, private emails, phone numbers, or other sensitive personal data unless the user explicitly requests a scoped implementation with appropriate validation, redaction, and access controls.
+
+Avoid adding analytics, tracking pixels, third-party scripts, or external data sinks without explicit approval. When handling user data, prefer least-privilege APIs, client-side redaction before logging, and server-side validation for every boundary.
+
 ## Component Patterns
 
 ### Composition Over Inheritance

.agents/skills/mle-workflow/SKILL.md

@@ -0,0 +1,346 @@
+---
+name: mle-workflow
+description: Production machine-learning engineering workflow for data contracts, reproducible training, model evaluation, deployment, monitoring, and rollback. Use when building, reviewing, or hardening ML systems beyond one-off notebooks.
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Machine Learning Engineering Workflow
+
+Use this skill to turn model work into a production ML system with clear data contracts, repeatable training, measurable quality gates, deployable artifacts, and operational monitoring.
+
+## When to Activate
+
+- Planning or reviewing a production ML feature, model refresh, ranking system, recommender, classifier, embedding workflow, or forecasting pipeline
+- Converting notebook code into a reusable training, evaluation, batch inference, or online inference pipeline
+- Designing model promotion criteria, offline/online evals, experiment tracking, or rollback paths
+- Debugging failures caused by data drift, label leakage, stale features, artifact mismatch, or inconsistent training and serving logic
+- Adding model monitoring, canary rollout, shadow traffic, or post-deploy quality checks
+
+## Scope Calibration
+
+Use only the lanes that fit the system in front of you. This skill is useful for ranking, search, recommendations, classifiers, forecasting, embeddings, LLM workflows, anomaly detection, and batch analytics, but it should not force one architecture onto all of them.
+
+- Do not assume every model has supervised labels, online serving, a feature store, PyTorch, GPUs, human review, A/B tests, or real-time feedback.
+- Do not add heavyweight MLOps machinery when a data contract, baseline, eval script, and rollback note would make the change reviewable.
+- Do make assumptions explicit when the project lacks labels, delayed outcomes, slice definitions, production traffic, or monitoring ownership.
+- Treat examples as interchangeable scaffolds. Replace metrics, serving mode, data stores, and rollout mechanics with the project-native equivalents.
+
+## Related Skills
+
+- `python-patterns` and `python-testing` for Python implementation and pytest coverage
+- `pytorch-patterns` for deep learning models, data loaders, device handling, and training loops
+- `eval-harness` and `ai-regression-testing` for promotion gates and agent-assisted regression checks
+- `database-migrations`, `postgres-patterns`, and `clickhouse-io` for data storage and analytics surfaces
+- `deployment-patterns`, `docker-patterns`, and `security-review` for serving, secrets, containers, and production hardening
+
+## Reuse the SWE Surface
+
+Do not treat MLE as separate from software engineering. Most ECC SWE workflows apply directly to ML systems, often with stricter failure modes:
+
+The recommended `minimal --with capability:machine-learning` install keeps the core agent surface available alongside this skill. For skill-only or agent-limited harnesses, pair `skill:mle-workflow` with `agent:mle-reviewer` where the target supports agents.
+
+| SWE surface | MLE use |
+|-------------|---------|
+| `product-capability` / `architecture-decision-records` | Turn model work into explicit product contracts and record irreversible data, model, and rollout choices |
+| `repo-scan` / `codebase-onboarding` / `code-tour` | Find existing training, feature, serving, eval, and monitoring paths before introducing a parallel ML stack |
+| `plan` / `feature-dev` | Scope model changes as product capabilities with data, eval, serving, and rollback phases |
+| `tdd-workflow` / `python-testing` | Test feature transforms, split logic, metric calculations, artifact loading, and inference schemas before implementation |
+| `code-reviewer` / `mle-reviewer` | Review code quality plus ML-specific leakage, reproducibility, promotion, and monitoring risks |
+| `build-fix` / `pr-test-analyzer` | Diagnose broken CI, flaky evals, missing fixtures, and environment-specific model or dependency failures |
+| `quality-gate` / `test-coverage` | Require automated evidence for transforms, metrics, inference contracts, promotion gates, and rollback behavior |
+| `eval-harness` / `verification-loop` | Turn offline metrics, slice checks, latency budgets, and rollback drills into repeatable gates |
+| `ai-regression-testing` | Preserve every production bug as a regression: missing feature, stale label, bad artifact, schema drift, or serving mismatch |
+| `api-design` / `backend-patterns` | Design prediction APIs, batch jobs, idempotent retraining endpoints, and response envelopes |
+| `database-migrations` / `postgres-patterns` / `clickhouse-io` | Version labels, feature snapshots, prediction logs, experiment metrics, and drift analytics |
+| `deployment-patterns` / `docker-patterns` | Package reproducible training and serving images with health checks, resource limits, and rollback |
+| `canary-watch` / `dashboard-builder` | Make rollout health visible with model-version, slice, drift, latency, cost, and delayed-label dashboards |
+| `security-review` / `security-scan` | Check model artifacts, notebooks, prompts, datasets, and logs for secrets, PII, unsafe deserialization, and supply-chain risk |
+| `e2e-testing` / `browser-qa` / `accessibility` | Test critical product flows that consume predictions, including explainability and fallback UI states |
+| `benchmark` / `performance-optimizer` | Measure throughput, p95 latency, memory, GPU utilization, and cost per prediction or retrain |
+| `cost-aware-llm-pipeline` / `token-budget-advisor` | Route LLM/embedding workloads by quality, latency, and budget instead of defaulting to the largest model |
+| `documentation-lookup` / `search-first` | Verify current library behavior for model serving, feature stores, vector DBs, and eval tooling before coding |
+| `git-workflow` / `github-ops` / `opensource-pipeline` | Package MLE changes for review with crisp scope, generated artifacts excluded, and reproducible test evidence |
+| `strategic-compact` / `dmux-workflows` | Split long ML work into parallel tracks: data contract, eval harness, serving path, monitoring, and docs |
+
+## Ten MLE Task Simulations
+
+Use these simulations as coverage checks when planning or reviewing MLE work. A strong MLE workflow should reduce each task to explicit contracts, reusable SWE surfaces, automated evidence, and a reviewable artifact.
+
+| ID | Common MLE task | Streamlined ECC path | Required output | Pipeline lanes covered |
+|----|-----------------|----------------------|-----------------|------------------------|
+| MLE-01 | Frame an ambiguous prediction, ranking, recommender, classifier, embedding, or forecast capability | `product-capability`, `plan`, `architecture-decision-records`, `mle-workflow` | Iteration Compact naming who cares, decision owner, success metric, unacceptable mistakes, assumptions, constraints, and first experiment | product contract, stakeholder loss, risk, rollout |
+| MLE-02 | Define metric goals, labels, data sources, and the mistake budget | `repo-scan`, `database-reviewer`, `database-migrations`, `postgres-patterns`, `clickhouse-io` | Data and metric contract with entity grain, label timing, label confidence, feature timing, point-in-time joins, split policy, and dataset snapshot | data contract, metric design, leakage, reproducibility |
+| MLE-03 | Build a baseline model and scoring path before adding complexity | `tdd-workflow`, `python-testing`, `python-patterns`, `code-reviewer` | Baseline scorer with confusion matrix, calibration notes, latency/cost estimate, known weaknesses, and tests for score shape and determinism | baseline, scoring, testing, serving parity |
+| MLE-04 | Generate features from hypotheses about what separates outcomes | `python-patterns`, `pytorch-patterns`, `docker-patterns`, `deployment-patterns` | Feature plan and transform module covering signal source, missing values, outliers, correlations, leakage checks, and train/serve equivalence | feature pipeline, leakage, training, artifacts |
+| MLE-05 | Tune thresholds, configs, and model complexity under tradeoffs | `eval-harness`, `ai-regression-testing`, `quality-gate`, `test-coverage` | Threshold/config report comparing precision, recall, F1, AUC, calibration, group slices, latency, cost, complexity, and acceptable error classes | evaluation, threshold, promotion, regression |
+| MLE-06 | Run error analysis and turn mistakes into the next experiment | `eval-harness`, `ai-regression-testing`, `mle-reviewer`, `silent-failure-hunter` | Error cluster report for false positives, false negatives, ambiguous labels, stale features, missing signals, and bug traces with lessons captured | error analysis, bug trace, iteration, regression |
+| MLE-07 | Package a model artifact for batch or online inference | `api-design`, `backend-patterns`, `security-review`, `security-scan` | Versioned artifact bundle with preprocessing, config, dependency constraints, schema validation, safe loading, and PII-safe logs | artifact, security, inference contract |
+| MLE-08 | Ship online serving or batch scoring with feedback capture | `api-design`, `backend-patterns`, `e2e-testing`, `browser-qa`, `accessibility` | Prediction endpoint or batch job with response envelope, timeout, batching, fallback, model version, confidence, feedback logging, and product-flow tests | serving, batch inference, fallback, user workflow |
+| MLE-09 | Roll out a model with shadow traffic, canary, A/B test, or rollback | `canary-watch`, `dashboard-builder`, `verification-loop`, `performance-optimizer` | Rollout plan naming traffic split, dashboards, p95 latency, cost, quality guardrails, rollback artifact, and rollback trigger | deployment, canary, rollback |
+| MLE-10 | Operate, debug, and refresh a production model after launch | `silent-failure-hunter`, `dashboard-builder`, `mle-reviewer`, `doc-updater`, `github-ops` | Observation ledger and refresh plan with drift checks, delayed-label health, alert owners, runbook updates, retrain criteria, and PR evidence | monitoring, incident response, retraining |
+
+## Iteration Compact
+
+Before touching model code, compress the work into one reviewable artifact. This should be short enough to fit in a PR description and precise enough that another engineer can challenge the tradeoffs.
+
+```text
+Goal:
+Who cares:
+Decision owner:
+User or system action changed by the model:
+Success metric:
+Guardrail metrics:
+Mistake budget:
+Unacceptable mistakes:
+Acceptable mistakes:
+Assumptions:
+Constraints:
+Labels and data snapshot:
+Baseline:
+Candidate signals:
+Threshold or config plan:
+Eval slices:
+Known risks:
+Next experiment:
+Rollback or fallback:
+```
+
+This compact is the MLE equivalent of a strong SWE design note. It keeps the team from optimizing a metric no one trusts, adding features that do not address the real error mode, or shipping complexity without a rollback.
+
+## Decision Brain
+
+Use this loop whenever the task is ambiguous, high-impact, or metric-heavy:
+
+1. Start from the decision, not the model. Name the action that changes downstream behavior.
+2. Name who cares and why. Different stakeholders pay different costs for false positives, false negatives, latency, compute spend, opacity, or missed opportunities.
+3. Convert ambiguity into hypotheses. Ask what signal would separate outcomes, what evidence would disprove it, and what simple baseline should be hard to beat.
+4. Research prior art or a nearby known problem before inventing a bespoke system.
+5. Score choices with `(probability, confidence) x (cost, severity, importance, impact)`.
+6. Consider adversarial behavior, incentives, selective disclosure, distribution shift, and feedback loops.
+7. Prefer the simplest change that reduces the most important mistake. Simplicity is not laziness; it is a way to minimize blunders while preserving iteration speed.
+8. Capture the decision, evidence, counterargument, and next reversible step.
+
+## Metric and Mistake Economics
+
+Choose metrics from failure costs, not habit:
+
+- Use a confusion matrix early so the team can discuss concrete false positives and false negatives instead of abstract accuracy.
+- Favor precision when the cost of an incorrect positive decision dominates.
+- Favor recall when the cost of a missed positive dominates.
+- Use F1 only when the precision/recall tradeoff is genuinely balanced and explainable.
+- Use AUC or ranking metrics when ordering quality matters more than a single threshold.
+- Track latency, throughput, memory, and cost as first-class metrics because they shape feasible model complexity.
+- Compare against a baseline and the current production model before celebrating an offline gain.
+- Treat real-world feedback signals as delayed labels with bias, lag, and coverage gaps; do not treat them as ground truth without analysis.
+
+Every metric choice should state which mistake it makes cheaper, which mistake it makes more likely, and who absorbs that cost.
+
+## Data and Feature Hypotheses
+
+Features should come from a theory of separation:
+
+- Text, categorical fields, numeric histories, graph relationships, recency, frequency, and aggregates are candidate signal families, not automatic features.
+- For every feature family, state why it should separate outcomes and how it could leak future information.
+- For noisy labels, consider adjudication, label confidence, soft targets, or confidence weighting.
+- For class imbalance, compare weighted loss, resampling, threshold movement, and calibrated decision rules.
+- For missing values, decide whether absence is informative, imputable, or a reason to abstain.
+- For outliers, decide whether to clip, bucket, investigate, or preserve them as rare but important signal.
+- For correlated features, check whether they are redundant, unstable, or proxies for unavailable future state.
+
+Do not add model complexity until error analysis shows that the baseline is failing for a reason additional signal or capacity can plausibly fix.
+
+## Error Analysis Loop
+
+After each baseline, training run, threshold change, or config change:
+
+1. Split mistakes into false positives, false negatives, abstentions, low-confidence cases, and system failures.
+2. Cluster errors by shared traits: language, entity type, source, time, geography, device, sparsity, recency, feature freshness, label source, or model version.
+3. Separate model mistakes from data bugs, label ambiguity, product ambiguity, instrumentation gaps, and serving mismatches.
+4. Trace each major cluster to one of four moves: better labels, better features, better threshold/config, or better product fallback.
+5. Preserve every important mistake as a regression test, eval slice, dashboard panel, or runbook entry.
+6. Write the next iteration as a falsifiable experiment, not a vague "improve model" task.
+
+The strongest MLE loop is not train -> metric -> ship. It is mistake -> cluster -> hypothesis -> experiment -> evidence -> simpler system.
+
+## Observation Ledger
+
+Keep a compact decision and evidence trail beside the code, PR, experiment report, or runbook:
+
+```text
+Iteration:
+Change:
+Why this mattered:
+Metric movement:
+Slice movement:
+False positives:
+False negatives:
+Unexpected errors:
+Decision:
+Tradeoff accepted:
+Lesson captured:
+Regression added:
+Debt created:
+Next iteration:
+```
+
+Use the ledger to make model work cumulative. The goal is for each iteration to make the next decision easier, not merely to produce another artifact.
+
+## Core Workflow
+
+### 1. Define the Prediction Contract
+
+Capture the product-level contract before writing model code:
+
+- Prediction target and decision owner
+- Input entity, output schema, confidence/calibration fields, and allowed latency
+- Batch, online, streaming, or hybrid serving mode
+- Fallback behavior when the model, feature store, or dependency is unavailable
+- Human review or override path for high-impact decisions
+- Privacy, retention, and audit requirements for inputs, predictions, and labels
+
+Do not accept "improve the model" as a requirement. Tie the model to an observable product behavior and a measurable acceptance gate.
+
+### 2. Lock the Data Contract
+
+Every ML task needs an explicit data contract:
+
+- Entity grain and primary key
+- Label definition, label timestamp, and label availability delay
+- Feature timestamp, freshness SLA, and point-in-time join rules
+- Train, validation, test, and backtest split policy
+- Required columns, allowed nulls, ranges, categories, and units
+- PII or sensitive fields that must not enter training artifacts or logs
+- Dataset version or snapshot ID for reproducibility
+
+Guard against leakage first. If a feature is not available at prediction time, or is joined using future information, remove it or move it to an analysis-only path.
+
+### 3. Build a Reproducible Pipeline
+
+Training code should be runnable by another engineer without hidden notebook state:
+
+- Use typed config files or dataclasses for all hyperparameters and paths
+- Pin package and model dependencies
+- Set random seeds and document any nondeterministic GPU behavior
+- Record dataset version, code SHA, config hash, metrics, and artifact URI
+- Save preprocessing logic with the model artifact, not separately in a notebook
+- Keep train, eval, and inference transformations shared or generated from one source
+- Make every step idempotent so retries do not corrupt artifacts or metrics
+
+Prefer immutable values and pure transformation functions. Avoid mutating shared data frames or global config during feature generation.
+
+```python
+import hashlib
+from dataclasses import dataclass
+from pathlib import Path
+
+
+@dataclass(frozen=True)
+class TrainingConfig:
+    dataset_uri: str
+    model_dir: Path
+    seed: int
+    learning_rate: float
+    batch_size: int
+
+
+def artifact_name(config: TrainingConfig, code_sha: str) -> str:
+    config_key = f"{config.dataset_uri}:{config.seed}:{config.learning_rate}:{config.batch_size}"
+    config_hash = hashlib.sha256(config_key.encode("utf-8")).hexdigest()[:12]
+    return f"{code_sha[:12]}-{config_hash}"
+```
+
+### 4. Evaluate Before Promotion
+
+Promotion criteria should be declared before training finishes:
+
+- Baseline model and current production model comparison
+- Primary metric aligned to product behavior
+- Guardrail metrics for latency, calibration, fairness slices, cost, and error concentration
+- Slice metrics for important cohorts, geographies, devices, languages, or data sources
+- Confidence intervals or repeated-run variance when metrics are noisy
+- Failure examples reviewed by a human for high-impact models
+- Explicit "do not ship" thresholds
+
+```python
+PROMOTION_GATES = {
+    "auc": ("min", 0.82),
+    "calibration_error": ("max", 0.04),
+    "p95_latency_ms": ("max", 80),
+}
+
+
+def assert_promotion_ready(metrics: dict[str, float]) -> None:
+    missing = sorted(name for name in PROMOTION_GATES if name not in metrics)
+    if missing:
+        raise ValueError(f"Model promotion metrics missing required gates: {missing}")
+
+    failures = {
+        name: value
+        for name, (direction, threshold) in PROMOTION_GATES.items()
+        for value in [metrics[name]]
+        if (direction == "min" and value < threshold)
+        or (direction == "max" and value > threshold)
+    }
+    if failures:
+        raise ValueError(f"Model failed promotion gates: {failures}")
+```
+
+Use offline metrics as gates, not guarantees. When the model changes product behavior, plan shadow evaluation, canary rollout, or A/B testing before full rollout.
+
+### 5. Package for Serving
+
+An ML artifact is production-ready only when the serving contract is testable:
+
+- Model artifact includes version, training data reference, config, and preprocessing
+- Input schema rejects invalid, stale, or out-of-range features
+- Output schema includes model version and confidence or explanation fields when useful
+- Serving path has timeout, batching, resource limits, and fallback behavior
+- CPU/GPU requirements are explicit and tested
+- Prediction logs avoid PII and include enough identifiers for debugging and label joins
+- Integration tests cover missing features, stale features, bad types, empty batches, and fallback path
+
+Never let training-only feature code diverge from serving feature code without a test that proves equivalence.
+
+### 6. Operate the Model
+
+Model monitoring needs both system and quality signals:
+
+- Availability, error rate, timeout rate, queue depth, and p50/p95/p99 latency
+- Feature null rate, range drift, categorical drift, and freshness drift
+- Prediction distribution drift and confidence distribution drift
+- Label arrival health and delayed quality metrics
+- Business KPI guardrails and rollback triggers
+- Per-version dashboards for canaries and rollbacks
+
+Every deployment should have a rollback plan that names the previous artifact, config, data dependency, and traffic-switch mechanism.
+
+## Review Checklist
+
+- [ ] Prediction contract is explicit and testable
+- [ ] Data contract defines entity grain, label timing, feature timing, and snapshot/version
+- [ ] Leakage risks were checked against prediction-time availability
+- [ ] Training is reproducible from code, config, data version, and seed
+- [ ] Metrics compare against baseline and current production model
+- [ ] Slice metrics and guardrails are included for high-risk cohorts
+- [ ] Promotion gates are automated and fail closed
+- [ ] Training and serving transformations are shared or equivalence-tested
+- [ ] Model artifact carries version, config, dataset reference, and preprocessing
+- [ ] Serving path validates inputs and has timeout, fallback, and rollback behavior
+- [ ] Monitoring covers system health, feature drift, prediction drift, and delayed labels
+- [ ] Sensitive data is excluded from artifacts, logs, prompts, and examples
+
+## Anti-Patterns
+
+- Notebook state is required to reproduce the model
+- Random split leaks future data into validation or test sets
+- Feature joins ignore event time and label availability
+- Offline metric improves while important slices regress
+- Thresholds are tuned on the test set repeatedly
+- Training preprocessing is copied manually into serving code
+- Model version is missing from prediction logs
+- Monitoring only checks service uptime, not data or prediction quality
+- Rollback requires retraining instead of switching to a known-good artifact
+
+## Output Expectations
+
+When using this skill, return concrete artifacts: data contract, promotion gates, pipeline steps, test plan, deployment plan, or review findings. Call out unknowns that block production readiness instead of filling them with assumptions.

.agents/skills/mle-workflow/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "MLE Workflow"
+  short_description: "Production ML workflow and review gates"
+  brand_color: "#2563EB"
+  default_prompt: "Use $mle-workflow to plan or review a production ML pipeline."
+policy:
+  allow_implicit_invocation: true

.claude-plugin/PLUGIN_SCHEMA_NOTES.md

@@ -132,6 +132,27 @@ The test `plugin.json does NOT have explicit hooks declaration` in `tests/hooks/
 
 ---
 
+## The `mcpServers` Field: Keep the Empty Opt-Out
+
+ECC keeps `.mcp.json` at the repository root for Codex plugin installs and manual MCP setup.
+Claude Code also auto-discovers plugin-root `.mcp.json` files by convention, which would bundle the same MCP servers into Claude plugin installs.
+The Claude plugin slug is intentionally short (`ecc`), but this opt-out is still required because legacy installs and strict provider gateways have failed on generated names from longer plugin identifiers.
+
+Keep this field in `.claude-plugin/plugin.json`:
+
+```json
+{
+  "mcpServers": {}
+}
+```
+
+This explicit empty object prevents Claude plugin installs from auto-loading ECC's root MCP definitions.
+Without the opt-out, strict OpenAI-compatible gateways can reject plugin MCP tool names such as `mcp__plugin_everything-claude-code_github__create_pull_request_review` because they exceed 64 characters.
+
+Users who want the bundled MCP servers should configure them manually from `.mcp.json` or `mcp-configs/mcp-servers.json`.
+
+---
+
 ## Known Anti-Patterns
 
 These look correct but are rejected:
@@ -142,6 +163,7 @@ These look correct but are rejected:
 * Relying on inferred paths
 * Assuming marketplace behavior matches local validation
 * **Adding `"hooks": "./hooks/hooks.json"`** - auto-loaded by convention, causes duplicate error
+* Removing `"mcpServers": {}` - re-enables root `.mcp.json` auto-discovery for Claude plugin installs and can produce overlong MCP tool names
 
 Avoid cleverness. Be explicit.
 
@@ -170,7 +192,8 @@ Before submitting changes that touch `plugin.json`:
 1. Ensure all component fields are arrays
 2. Include a `version`
 3. Do NOT add `agents` or `hooks` fields (both are auto-loaded by convention)
-4. Run:
+4. Preserve `"mcpServers": {}` unless you are intentionally changing Claude plugin MCP bundling behavior
+5. Run:
 
 ```bash
 claude plugin validate .claude-plugin/plugin.json

.claude-plugin/marketplace.json

@@ -1,5 +1,5 @@
 {
-  "name": "everything-claude-code",
+  "name": "ecc",
   "owner": {
     "name": "Affaan Mustafa",
     "email": "me@affaanmustafa.com"
@@ -9,9 +9,9 @@
   },
   "plugins": [
     {
-      "name": "everything-claude-code",
+      "name": "ecc",
       "source": "./",
-      "description": "The most comprehensive Claude Code plugin — 48 agents, 184 skills, 79 legacy command shims, selective install profiles, and production-ready hooks for TDD, security scanning, code review, and continuous learning",
+      "description": "The most comprehensive Claude Code plugin — 58 agents, 220 skills, 74 legacy command shims, selective install profiles, and production-ready hooks for TDD, security scanning, code review, and continuous learning",
       "version": "2.0.0-rc.1",
       "author": {
         "name": "Affaan Mustafa",

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
-  "name": "everything-claude-code",
+  "name": "ecc",
   "version": "2.0.0-rc.1",
-  "description": "Battle-tested Claude Code plugin for engineering teams — 48 agents, 184 skills, 79 legacy command shims, production-ready hooks, and selective install workflows evolved through continuous real-world use",
+  "description": "Battle-tested Claude Code plugin for engineering teams — 58 agents, 220 skills, 74 legacy command shims, production-ready hooks, and selective install workflows evolved through continuous real-world use",
   "author": {
     "name": "Affaan Mustafa",
     "url": "https://x.com/affaanmustafa"
@@ -22,6 +22,11 @@
     "automation",
     "best-practices"
   ],
-  "skills": ["./skills/"],
-  "commands": ["./commands/"]
+  "mcpServers": {},
+  "skills": [
+    "./skills/"
+  ],
+  "commands": [
+    "./commands/"
+  ]
 }

.codex-plugin/README.md

@@ -12,7 +12,7 @@ This directory contains the **Codex plugin manifest** for Everything Claude Code
 
 ## What This Provides
 
-- **156 skills** from `./skills/` — reusable Codex workflows for TDD, security,
+- **200 skills** from `./skills/` — reusable Codex workflows for TDD, security,
   code review, architecture, and more
 - **6 MCP servers** — GitHub, Context7, Exa, Memory, Playwright, Sequential Thinking
 

.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "ecc",
   "version": "2.0.0-rc.1",
-  "description": "Battle-tested Codex workflows — 156 shared ECC skills, production-ready MCP configs, and selective-install-aligned conventions for TDD, security scanning, code review, and autonomous development.",
+  "description": "Battle-tested Codex workflows — 207 shared ECC skills, production-ready MCP configs, and selective-install-aligned conventions for TDD, security scanning, code review, and autonomous development.",
   "author": {
     "name": "Affaan Mustafa",
     "email": "me@affaanmustafa.com",
@@ -15,7 +15,7 @@
   "mcpServers": "./.mcp.json",
   "interface": {
     "displayName": "Everything Claude Code",
-    "shortDescription": "156 battle-tested ECC skills plus MCP configs for TDD, security, code review, and autonomous development.",
+    "shortDescription": "207 battle-tested ECC skills plus MCP configs for TDD, security, code review, and autonomous development.",
     "longDescription": "Everything Claude Code (ECC) is a community-maintained collection of Codex-ready skills and MCP configs evolved over 10+ months of intensive daily use. It covers TDD workflows, security scanning, code review, architecture decisions, operator workflows, and more — all in one installable plugin.",
     "developerName": "Affaan Mustafa",
     "category": "Productivity",

.codex/AGENTS.md

@@ -60,6 +60,12 @@ The sync script (`scripts/sync-ecc-to-codex.sh`) uses a Node-based TOML parser t
 - **`--update-mcp`** — explicitly replaces all ECC-managed servers with the latest recommended config (safely removes subtables like `[mcp_servers.supabase.env]`).
 - **User config is always preserved** — custom servers, args, env vars, and credentials outside ECC-managed sections are never touched.
 
+## External Action Boundaries
+
+Treat networked tools as read-only by default. Search, inspect, and draft freely within the user's requested scope, but require explicit user approval before posting, publishing, pushing, merging, opening paid jobs, dispatching remote agents, changing third-party resources, or modifying credentials.
+
+When approval is ambiguous, produce a local plan or draft artifact instead of taking the external action. Preserve user config and private state unless the user specifically asks for a scoped change.
+
 ## Multi-Agent Support
 
 Codex now supports multi-agent workflows behind the experimental `features.multi_agent` flag.

.env.example

@@ -20,6 +20,16 @@ GITHUB_TOKEN=
 # ─── Optional: Package manager override ──────────────────────────────────────
 # CLAUDE_CODE_PACKAGE_MANAGER=npm  # npm | pnpm | yarn | bun
 
+# --- Optional: Astraflow / UModelVerse (OpenAI-compatible) -------------------
+# Global endpoint: https://api.umodelverse.ai/v1
+ASTRAFLOW_API_KEY=
+# ASTRAFLOW_MODEL=gpt-4o-mini
+# ASTRAFLOW_BASE_URL=https://api.umodelverse.ai/v1
+# China endpoint: https://api.modelverse.cn/v1
+ASTRAFLOW_CN_API_KEY=
+# ASTRAFLOW_CN_MODEL=gpt-4o-mini
+# ASTRAFLOW_CN_BASE_URL=https://api.modelverse.cn/v1
+
 # ─── Session & Security ─────────────────────────────────────────────────────
 # GitHub username (used by CI scripts for credential context)
 GITHUB_USER="your-github-username"

.github/workflows/ci.yml

@@ -45,7 +45,7 @@ jobs:
       # Package manager setup
       - name: Setup pnpm
         if: matrix.pm == 'pnpm' && matrix.node != '18.x'
-        uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
+        uses: pnpm/action-setup@91ab88e2619ed1f46221f0ba42d1492c02baf788 # v6.0.6
         with:
           # Keep an explicit pnpm major because this repo's packageManager is Yarn.
           version: 10
@@ -77,7 +77,7 @@ jobs:
 
       - name: Cache npm
         if: matrix.pm == 'npm'
-        uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: ${{ steps.npm-cache-dir.outputs.dir }}
           key: ${{ runner.os }}-node-${{ matrix.node }}-npm-${{ hashFiles('**/package-lock.json') }}
@@ -94,7 +94,7 @@ jobs:
 
       - name: Cache pnpm
         if: matrix.pm == 'pnpm'
-        uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: ${{ steps.pnpm-cache-dir.outputs.dir }}
           key: ${{ runner.os }}-node-${{ matrix.node }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
@@ -115,7 +115,7 @@ jobs:
 
       - name: Cache yarn
         if: matrix.pm == 'yarn'
-        uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: ${{ steps.yarn-cache-dir.outputs.dir }}
           key: ${{ runner.os }}-node-${{ matrix.node }}-yarn-${{ hashFiles('**/yarn.lock') }}
@@ -124,7 +124,7 @@ jobs:
 
       - name: Cache bun
         if: matrix.pm == 'bun'
-        uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: ~/.bun/install/cache
           key: ${{ runner.os }}-bun-${{ hashFiles('**/bun.lockb') }}
@@ -220,6 +220,10 @@ jobs:
         run: node scripts/ci/check-unicode-safety.js
         continue-on-error: false
 
+      - name: Validate no personal paths
+        run: node scripts/ci/validate-no-personal-paths.js
+        continue-on-error: false
+
   security:
     name: Security Scan
     runs-on: ubuntu-latest

.github/workflows/reusable-test.yml

@@ -36,7 +36,7 @@ jobs:
 
       - name: Setup pnpm
         if: inputs.package-manager == 'pnpm' && inputs.node-version != '18.x'
-        uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
+        uses: pnpm/action-setup@91ab88e2619ed1f46221f0ba42d1492c02baf788 # v6.0.6
         with:
           # Keep an explicit pnpm major because this repo's packageManager is Yarn.
           version: 10
@@ -67,7 +67,7 @@ jobs:
 
       - name: Cache npm
         if: inputs.package-manager == 'npm'
-        uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: ${{ steps.npm-cache-dir.outputs.dir }}
           key: ${{ runner.os }}-node-${{ inputs.node-version }}-npm-${{ hashFiles('**/package-lock.json') }}
@@ -84,7 +84,7 @@ jobs:
 
       - name: Cache pnpm
         if: inputs.package-manager == 'pnpm'
-        uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: ${{ steps.pnpm-cache-dir.outputs.dir }}
           key: ${{ runner.os }}-node-${{ inputs.node-version }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
@@ -105,7 +105,7 @@ jobs:
 
       - name: Cache yarn
         if: inputs.package-manager == 'yarn'
-        uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: ${{ steps.yarn-cache-dir.outputs.dir }}
           key: ${{ runner.os }}-node-${{ inputs.node-version }}-yarn-${{ hashFiles('**/yarn.lock') }}
@@ -114,7 +114,7 @@ jobs:
 
       - name: Cache bun
         if: inputs.package-manager == 'bun'
-        uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
+        uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: ~/.bun/install/cache
           key: ${{ runner.os }}-bun-${{ hashFiles('**/bun.lockb') }}

.github/workflows/reusable-validate.yml

@@ -50,3 +50,6 @@ jobs:
 
       - name: Check unicode safety
         run: node scripts/ci/check-unicode-safety.js
+
+      - name: Validate no personal paths
+        run: node scripts/ci/validate-no-personal-paths.js

.kiro/skills/search-first/SKILL.md

@@ -21,6 +21,12 @@ Use this skill when:
 - The user asks "add X functionality" and you're about to write code
 - Before creating a new utility, helper, or abstraction
 
+## Scope and Approval Rules
+
+Default to read-only research: inspect the repo, package metadata, docs, and public examples before recommending a dependency or integration. Do not install packages, configure MCP servers, publish artifacts, open PRs, or make external write actions from this skill unless the user has explicitly approved that action in the current task.
+
+When a candidate requires credentials, paid services, network writes, or project-wide config changes, return a recommendation and approval checkpoint instead of applying it directly.
+
 ## Workflow
 
 ```
@@ -45,9 +51,9 @@ Use this skill when:
 │     │ as-is   │  │  /Wrap   │  │  Custom  │  │
 │     └─────────┘  └──────────┘  └─────────┘  │
 ├─────────────────────────────────────────────┤
-│  5. IMPLEMENT                               │
-│     Install package / Configure MCP /       │
-│     Write minimal custom code               │
+│  5. APPROVAL CHECKPOINT / IMPLEMENT         │
+│     Recommend package / MCP / custom code   │
+│     Apply only after explicit approval      │
 └─────────────────────────────────────────────┘
 ```
 
@@ -55,10 +61,10 @@ Use this skill when:
 
 | Signal | Action |
 |--------|--------|
-| Exact match, well-maintained, MIT/Apache | **Adopt** — install and use directly |
-| Partial match, good foundation | **Extend** — install + write thin wrapper |
-| Multiple weak matches | **Compose** — combine 2-3 small packages |
-| Nothing suitable found | **Build** — write custom, but informed by research |
+| Exact match, well-maintained, MIT/Apache | **Adopt** — recommend the package and request approval before install or config changes |
+| Partial match, good foundation | **Extend** — recommend the package plus a thin wrapper, then wait for approval before applying |
+| Multiple weak matches | **Compose** — propose 2-3 small packages and the integration plan before installing anything |
+| Nothing suitable found | **Build** — explain why custom code is warranted, then implement only within the approved task scope |
 
 ## How to Use
 
@@ -135,8 +141,8 @@ Combine for progressive discovery:
 Need: Check markdown files for broken links
 Search: npm "markdown dead link checker"
 Found: textlint-rule-no-dead-link (score: 9/10)
-Action: ADOPT — npm install textlint-rule-no-dead-link
-Result: Zero custom code, battle-tested solution
+Action: ADOPT — recommend `textlint-rule-no-dead-link` and ask before installing it
+Result: Zero custom code if approved, battle-tested solution
 ```
 
 ### Example 2: "Add HTTP client wrapper"
@@ -144,8 +150,8 @@ Result: Zero custom code, battle-tested solution
 Need: Resilient HTTP client with retries and timeout handling
 Search: npm "http client retry", PyPI "httpx retry"
 Found: got (Node) with retry plugin, httpx (Python) with built-in retry
-Action: ADOPT — use got/httpx directly with retry config
-Result: Zero custom code, production-proven libraries
+Action: ADOPT — recommend `got`/`httpx` directly with retry config and ask before changing dependencies
+Result: Zero custom code if approved, production-proven libraries
 ```
 
 ### Example 3: "Add config file linter"
@@ -153,8 +159,8 @@ Result: Zero custom code, production-proven libraries
 Need: Validate project config files against a schema
 Search: npm "config linter schema", "json schema validator cli"
 Found: ajv-cli (score: 8/10)
-Action: ADOPT + EXTEND — install ajv-cli, write project-specific schema
-Result: 1 package + 1 schema file, no custom validation logic
+Action: ADOPT + EXTEND — recommend `ajv-cli` plus a project-specific schema, then wait for approval before install/write
+Result: 1 package + 1 schema file if approved, no custom validation logic
 ```
 
 ## Anti-Patterns

.opencode/commands/harness-audit.md

@@ -1,3 +1,7 @@
+---
+description: Run a deterministic repository harness audit and return a prioritized scorecard.
+---
+
 # Harness Audit Command
 
 Run a deterministic repository harness audit and return a prioritized scorecard.

.opencode/commands/security-scan.md

@@ -0,0 +1,92 @@
+---
+description: Run AgentShield against agent, hook, MCP, permission, and secret surfaces.
+agent: everything-claude-code:security-reviewer
+subtask: true
+---
+
+# Security Scan Command
+
+Run AgentShield against the current project or a target path, then turn the findings into a prioritized remediation plan.
+
+## Usage
+
+`/security-scan [path] [--format text|json|markdown|html] [--min-severity low|medium|high|critical] [--fix]`
+
+- `path` (optional): defaults to the current project. Use a `.claude/` path, a repo root, or a checked-in template directory.
+- `--format`: output format. Use `json` for CI, `markdown` for handoffs, and `html` for standalone review reports.
+- `--min-severity`: filters lower-priority findings.
+- `--fix`: applies only AgentShield fixes explicitly marked as safe and auto-fixable.
+
+## Deterministic Engine
+
+Prefer the packaged scanner:
+
+```bash
+npx ecc-agentshield scan --path "${TARGET_PATH:-.}" --format text
+```
+
+For local AgentShield development, run from the AgentShield checkout:
+
+```bash
+npm run scan -- --path "${TARGET_PATH:-.}" --format text
+```
+
+Do not invent findings. Use AgentShield output as the source of truth and separate scanner facts from follow-up judgment.
+
+## Review Checklist
+
+1. Identify active runtime findings first:
+   - hardcoded secrets
+   - broad permissions
+   - executable hooks
+   - MCP servers with shell, filesystem, remote transport, or unpinned `npx`
+   - agent prompts that handle untrusted content without defenses
+2. Separate lower-confidence inventory:
+   - docs examples
+   - template examples
+   - plugin manifests
+   - project-local optional settings
+3. For each critical or high finding, return:
+   - file path
+   - severity
+   - runtime confidence
+   - why it matters
+   - exact remediation
+   - whether it is safe to auto-fix
+4. If `--fix` is requested, state the planned edits before applying fixes.
+5. Re-run the scan after fixes and report the before/after score.
+
+## Output Contract
+
+Return:
+
+1. Security grade and score.
+2. Counts by severity and runtime confidence.
+3. Critical/high findings with exact paths.
+4. Lower-confidence findings grouped separately.
+5. A remediation order.
+6. Commands run and whether the scan was local, CI, or npx-backed.
+
+## CI Pattern
+
+Use AgentShield in GitHub Actions for enforced gates:
+
+```yaml
+- uses: affaan-m/agentshield@v1
+  with:
+    path: "."
+    min-severity: "medium"
+    fail-on-findings: true
+```
+
+## Links
+
+- Skill: `skills/security-scan/SKILL.md`
+- Agent: `agents/security-reviewer.md`
+- Scanner: <https://github.com/affaan-m/agentshield>
+
+## Arguments
+
+$ARGUMENTS:
+- optional target path
+- optional AgentShield flags

.opencode/opencode.json

@@ -22,6 +22,11 @@
   "plugin": [
     "./plugins"
   ],
+  "skills": {
+    "paths": [
+      "../skills"
+    ]
+  },
   "agent": {
     "build": {
       "description": "Primary coding agent for development work",

.opencode/plugins/ecc-hooks.ts

@@ -43,6 +43,14 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
     return path.join(worktreePath, p)
   }
 
+  function hasProjectFile(relativePath: string): boolean {
+    try {
+      return fs.statSync(resolvePath(relativePath)).isFile()
+    } catch {
+      return false
+    }
+  }
+
   const pendingToolChanges = new Map<string, { path: string; type: "added" | "modified" }>()
   let writeCounter = 0
 
@@ -275,13 +283,8 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
       log("info", `[ECC] Session started - profile=${currentProfile}`)
 
       // Check for project-specific context files
-      try {
-        const hasClaudeMd = await $`test -f ${worktree}/CLAUDE.md && echo "yes"`.text()
-        if (hasClaudeMd.trim() === "yes") {
-          log("info", "[ECC] Found CLAUDE.md - loading project context")
-        }
-      } catch {
-        // No CLAUDE.md found
+      if (hasProjectFile("CLAUDE.md")) {
+        log("info", "[ECC] Found CLAUDE.md - loading project context")
       }
     },
 
@@ -400,7 +403,7 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
         ECC_PLUGIN: "true",
         ECC_HOOK_PROFILE: currentProfile,
         ECC_DISABLED_HOOKS: process.env.ECC_DISABLED_HOOKS || "",
-        PROJECT_ROOT: worktree || directory,
+        PROJECT_ROOT: worktreePath,
       }
 
       // Detect package manager
@@ -411,12 +414,9 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
         "package-lock.json": "npm",
       }
       for (const [lockfile, pm] of Object.entries(lockfiles)) {
-        try {
-          await $`test -f ${worktree}/${lockfile}`
+        if (hasProjectFile(lockfile)) {
           env.PACKAGE_MANAGER = pm
           break
-        } catch {
-          // Not found, try next
         }
       }
 
@@ -430,11 +430,8 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
       }
       const detected: string[] = []
       for (const [file, lang] of Object.entries(langDetectors)) {
-        try {
-          await $`test -f ${worktree}/${file}`
+        if (hasProjectFile(file)) {
           detected.push(lang)
-        } catch {
-          // Not found
         }
       }
       if (detected.length > 0) {

.qwen/QWEN.md

@@ -0,0 +1,25 @@
+# Qwen CLI Configuration
+
+This directory contains ECC's Qwen CLI install template.
+
+## Runtime Location
+
+The source `.qwen/` directory in this repository is copied into a user's home-level `~/.qwen/` install root when running:
+
+```bash
+./install.sh --target qwen --profile minimal
+```
+
+The managed install also writes `~/.qwen/ecc-install-state.json` so future ECC updates and uninstalls can distinguish ECC-owned files from user-owned Qwen configuration.
+
+## Installed Surface
+
+The Qwen target installs the same managed manifest modules used by other harness adapters:
+
+- `rules/`
+- `agents/`
+- `commands/`
+- `skills/`
+- `mcp-configs/`
+
+Hook runtime files are intentionally not selected for Qwen until the Qwen hook/event contract is verified.

AGENTS.md

@@ -1,6 +1,6 @@
 # Everything Claude Code (ECC) — Agent Instructions
 
-This is a **production-ready AI coding plugin** providing 48 specialized agents, 184 skills, 79 commands, and automated hook workflows for software development.
+This is a **production-ready AI coding plugin** providing 58 specialized agents, 220 skills, 74 commands, and automated hook workflows for software development.
 
 **Version:** 2.0.0-rc.1
 
@@ -27,6 +27,7 @@ This is a **production-ready AI coding plugin** providing 48 specialized agents,
 | doc-updater | Documentation and codemaps | Updating docs |
 | cpp-reviewer | C/C++ code review | C and C++ projects |
 | cpp-build-resolver | C/C++ build errors | C and C++ build failures |
+| fsharp-reviewer | F# functional code review | F# projects |
 | docs-lookup | Documentation lookup via Context7 | API/docs questions |
 | go-reviewer | Go code review | Go projects |
 | go-build-resolver | Go build errors | Go build failures |
@@ -41,6 +42,7 @@ This is a **production-ready AI coding plugin** providing 48 specialized agents,
 | rust-reviewer | Rust code review | Rust projects |
 | rust-build-resolver | Rust build errors | Rust build failures |
 | pytorch-build-resolver | PyTorch runtime/CUDA/training errors | PyTorch build/training failures |
+| mle-reviewer | Production ML pipeline review | ML pipelines, evals, serving, monitoring, rollback |
 | typescript-reviewer | TypeScript/JavaScript code review | TypeScript/JavaScript projects |
 
 ## Agent Orchestration
@@ -145,9 +147,9 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
 ## Project Structure
 
 ```
-agents/          — 48 specialized subagents
-skills/          — 184 workflow skills and domain knowledge
-commands/        — 79 slash commands
+agents/          — 58 specialized subagents
+skills/          — 220 workflow skills and domain knowledge
+commands/        — 74 slash commands
 hooks/           — Trigger-based automations
 rules/           — Always-follow guidelines (common + per-language)
 scripts/         — Cross-platform Node.js utilities

CONTRIBUTING.md

@@ -167,6 +167,8 @@ Short version:
 - [ ] Tested with Claude Code
 - [ ] Links to related skills
 - [ ] No sensitive data (API keys, tokens, paths)
+- [ ] Frontmatter declares `name:` matching the directory name
+- [ ] Frontmatter `description:` is an inline string or folded (`>`) scalar — not a literal block (`|`, `|-`, or `|+`), which preserves internal newlines and breaks flat-table renderers
 
 ### Example Skills
 

README.md

@@ -1,4 +1,4 @@
-**Language:** English | [Português (Brasil)](docs/pt-BR/README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md) | [Türkçe](docs/tr/README.md)
+**Language:** English | [Português (Brasil)](docs/pt-BR/README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md) | [Türkçe](docs/tr/README.md) | [Русский](docs/ru/README.md) | [Tiếng Việt](docs/vi-VN/README.md)
 
 # Everything Claude Code
 
@@ -25,10 +25,10 @@
 
 <div align="center">
 
-**Language / 语言 / 語言 / Dil**
+**Language / 语言 / 語言 / Dil / Язык / Ngôn ngữ**
 
 [**English**](README.md) | [Português (Brasil)](docs/pt-BR/README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md)
- | [Türkçe](docs/tr/README.md)
+ | [Türkçe](docs/tr/README.md) | [Русский](docs/ru/README.md) | [Tiếng Việt](docs/vi-VN/README.md)
 
 </div>
 
@@ -89,11 +89,12 @@ This repo is the raw code only. The guides explain everything.
 ### v2.0.0-rc.1 — Surface Refresh, Operator Workflows, and ECC 2.0 Alpha (Apr 2026)
 
 - **Dashboard GUI** — New Tkinter-based desktop application (`ecc_dashboard.py` or `npm run dashboard`) with dark/light theme toggle, font customization, and project logo in header and taskbar.
-- **Public surface synced to the live repo** — metadata, catalog counts, plugin manifests, and install-facing docs now match the actual OSS surface: 38 agents, 156 skills, and 72 legacy command shims.
+- **Public surface synced to the live repo** — metadata, catalog counts, plugin manifests, and install-facing docs now match the actual OSS surface: 55 agents, 208 skills, and 72 legacy command shims.
 - **Operator and outbound workflow expansion** — `brand-voice`, `social-graph-ranker`, `connections-optimizer`, `customer-billing-ops`, `ecc-tools-cost-audit`, `google-workspace-ops`, `project-flow-ops`, and `workspace-surface-audit` round out the operator lane.
 - **Media and launch tooling** — `manim-video`, `remotion-video-creation`, and upgraded social publishing surfaces make technical explainers and launch content part of the same system.
 - **Framework and product surface growth** — `nestjs-patterns`, richer Codex/OpenCode install surfaces, and expanded cross-harness packaging keep the repo usable beyond Claude Code alone.
 - **ECC 2.0 alpha is in-tree** — the Rust control-plane prototype in `ecc2/` now builds locally and exposes `dashboard`, `start`, `sessions`, `status`, `stop`, `resume`, and `daemon` commands. It is usable as an alpha, not yet a general release.
+- **Operator status snapshots** — `ecc status --markdown --write status.md` turns the local state store into a portable handoff covering readiness, active sessions, skill-run health, install health, pending governance events, and linked work items from Linear/GitHub/handoffs. Use `ecc work-items upsert ...` for manual entries, `ecc work-items sync-github --repo owner/repo` for PR/issue queue state, and `ecc status --exit-code` to fail automation when readiness needs attention.
 - **Ecosystem hardening** — AgentShield, ECC Tools cost controls, billing portal work, and website refreshes continue to ship around the core plugin instead of drifting into separate silos.
 
 ### v1.9.0 — Selective Install & Language Expansion (Mar 2026)
@@ -179,6 +180,51 @@ Most Claude Code users should use exactly one install path:
 
 If you already layered multiple installs and things look duplicated, skip straight to [Reset / Uninstall ECC](#reset--uninstall-ecc).
 
+### Low-context / no-hooks path
+
+If hooks feel too global or you only want ECC's rules, agents, commands, and core workflow skills, skip the plugin and use the minimal manual profile:
+
+```bash
+./install.sh --profile minimal --target claude
+```
+
+```powershell
+.\install.ps1 --profile minimal --target claude
+# or
+npx ecc-install --profile minimal --target claude
+```
+
+This profile intentionally excludes `hooks-runtime`.
+
+If you want the normal core profile but need hooks off, use:
+
+```bash
+./install.sh --profile core --without baseline:hooks --target claude
+```
+
+Add hooks later only if you want runtime enforcement:
+
+```bash
+./install.sh --target claude --modules hooks-runtime
+```
+
+### Find the right components first
+
+If you are not sure which ECC profile or component to install, ask the packaged advisor from any project:
+
+```bash
+npx ecc consult "security reviews" --target claude
+```
+
+It returns matching components, related profiles, and preview/install commands. Use the preview command before installing if you want to inspect the exact file plan.
+
+For production ML/MLOps workflows, keep the install opt-in and component-scoped:
+
+```bash
+npx ecc consult "mlops training model deployment" --target claude
+npx ecc install --profile minimal --target claude --with capability:machine-learning
+```
+
 ### Step 1: Install the Plugin (Recommended)
 
 > NOTE: The plugin is convenient, but the OSS installer below is still the most reliable path if your Claude Code build has trouble resolving self-hosted marketplace entries.
@@ -188,7 +234,7 @@ If you already layered multiple installs and things look duplicated, skip straig
 /plugin marketplace add https://github.com/affaan-m/everything-claude-code
 
 # Install plugin
-/plugin install everything-claude-code@everything-claude-code
+/plugin install ecc@ecc
 ```
 
 ### Naming + Migration Note
@@ -196,18 +242,18 @@ If you already layered multiple installs and things look duplicated, skip straig
 ECC now has three public identifiers, and they are not interchangeable:
 
 - GitHub source repo: `affaan-m/everything-claude-code`
-- Claude marketplace/plugin identifier: `everything-claude-code@everything-claude-code`
+- Claude marketplace/plugin identifier: `ecc@ecc`
 - npm package: `ecc-universal`
 
-This is intentional. Anthropic marketplace/plugin installs are keyed by a canonical plugin identifier, so ECC standardized on `everything-claude-code@everything-claude-code` to keep the listing name, `/plugin install`, `/plugin list`, and repo docs aligned to one public install surface. Older posts may still show the old short-form nickname; that shorthand is deprecated. Separately, the npm package stayed on `ecc-universal`, so npm installs and marketplace installs intentionally use different names.
+This is intentional. Anthropic marketplace/plugin installs are keyed by a canonical plugin identifier, so ECC uses `ecc@ecc` to keep tool names and slash-command namespaces short enough for strict Desktop/API validators. Older posts may still show the former long marketplace identifier; treat that as a legacy alias only. Separately, the npm package stayed on `ecc-universal`, so npm installs and marketplace installs intentionally use different names.
 
-### Step 2: Install Rules (Required)
+### Step 2: Install Rules Only If You Need Them
 
 > WARNING: **Important:** Claude Code plugins cannot distribute `rules` automatically.
 >
 > If you already installed ECC via `/plugin install`, **do not run `./install.sh --profile full`, `.\install.ps1 --profile full`, or `npx ecc-install --profile full` afterward**. The plugin already loads ECC skills, commands, and hooks. Running the full installer after a plugin install copies those same surfaces into your user directories and can create duplicate skills plus duplicate runtime behavior.
 >
-> For plugin installs, manually copy only the `rules/` directories you want. Start with `rules/common` plus one language or framework pack you actually use. Do not copy every rules directory unless you explicitly want all of that context in Claude.
+> For plugin installs, manually copy only the `rules/` directories you want under `~/.claude/rules/ecc/`. Start with `rules/common` plus one language or framework pack you actually use. Do not copy every rules directory unless you explicitly want all of that context in Claude.
 >
 > Use the full installer only when you are doing a fully manual ECC install instead of the plugin path.
 >
@@ -221,10 +267,10 @@ cd everything-claude-code
 # Install dependencies (pick your package manager)
 npm install        # or: pnpm install | yarn install | bun install
 
-# Plugin install path: copy only rules
-mkdir -p ~/.claude/rules
-cp -R rules/common ~/.claude/rules/
-cp -R rules/typescript ~/.claude/rules/
+# Plugin install path: copy only ECC rules into an ECC-owned namespace
+mkdir -p ~/.claude/rules/ecc
+cp -R rules/common ~/.claude/rules/ecc/
+cp -R rules/typescript ~/.claude/rules/ecc/
 
 # Fully manual ECC install path (use this instead of /plugin install)
 # ./install.sh --profile full
@@ -233,10 +279,10 @@ cp -R rules/typescript ~/.claude/rules/
 ```powershell
 # Windows PowerShell
 
-# Plugin install path: copy only rules
-New-Item -ItemType Directory -Force -Path "$HOME/.claude/rules" | Out-Null
-Copy-Item -Recurse rules/common "$HOME/.claude/rules/"
-Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
+# Plugin install path: copy only ECC rules into an ECC-owned namespace
+New-Item -ItemType Directory -Force -Path "$HOME/.claude/rules/ecc" | Out-Null
+Copy-Item -Recurse rules/common "$HOME/.claude/rules/ecc/"
+Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/ecc/"
 
 # Fully manual ECC install path (use this instead of /plugin install)
 # .\install.ps1 --profile full
@@ -265,7 +311,7 @@ If you choose this path, stop there. Do not also run `/plugin install`.
 
 If ECC feels duplicated, intrusive, or broken, do not keep reinstalling it on top of itself.
 
-- **Plugin path:** remove the plugin from Claude Code, then delete the specific rule folders you manually copied under `~/.claude/rules/`.
+- **Plugin path:** remove the plugin from Claude Code, then delete the specific rule folders you manually copied under `~/.claude/rules/ecc/`.
 - **Manual installer / CLI path:** from the repo root, preview removal first:
 
 ```bash
@@ -302,17 +348,17 @@ If you stacked methods, clean up in this order:
 # Skills are the primary workflow surface.
 # Existing slash-style command names still work while ECC migrates off commands/.
 
-# Plugin install uses the namespaced form
+# Plugin install uses the canonical namespaced form
 /ecc:plan "Add user authentication"
 
 # Manual install keeps the shorter slash form:
 # /plan "Add user authentication"
 
 # Check available commands
-/plugin list everything-claude-code@everything-claude-code
+/plugin list ecc@ecc
 ```
 
-**That's it!** You now have access to 48 agents, 184 skills, and 79 legacy command shims.
+**That's it!** You now have access to 58 agents, 220 skills, and 74 legacy command shims.
 
 ### Dashboard GUI
 
@@ -390,6 +436,12 @@ export ECC_HOOK_PROFILE=standard
 
 # Comma-separated hook IDs to disable
 export ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
+
+# Cap SessionStart additional context (default: 8000 chars)
+export ECC_SESSION_START_MAX_CHARS=4000
+
+# Disable SessionStart additional context entirely for low-context/local-model setups
+export ECC_SESSION_START_CONTEXT=off
 ```
 
 ---
@@ -404,7 +456,7 @@ everything-claude-code/
 |   |-- plugin.json         # Plugin metadata and component paths
 |   |-- marketplace.json    # Marketplace catalog for /plugin marketplace add
 |
-|-- agents/           # 36 specialized subagents for delegation
+|-- agents/           # 58 specialized subagents for delegation
 |   |-- planner.md           # Feature implementation planning
 |   |-- architect.md         # System design decisions
 |   |-- tdd-guide.md         # Test-driven development
@@ -420,6 +472,7 @@ everything-claude-code/
 |   |-- harness-optimizer.md # Harness config tuning
 |   |-- cpp-reviewer.md      # C++ code review
 |   |-- cpp-build-resolver.md # C++ build error resolution
+|   |-- fsharp-reviewer.md   # F# functional code review
 |   |-- go-reviewer.md       # Go code review
 |   |-- go-build-resolver.md # Go build error resolution
 |   |-- python-reviewer.md   # Python code review
@@ -429,9 +482,11 @@ everything-claude-code/
 |   |-- java-build-resolver.md # Java/Maven/Gradle build errors
 |   |-- kotlin-reviewer.md   # Kotlin/Android/KMP code review
 |   |-- kotlin-build-resolver.md # Kotlin/Gradle build errors
+|   |-- harmonyos-app-resolver.md # HarmonyOS/ArkTS app development
 |   |-- rust-reviewer.md     # Rust code review
 |   |-- rust-build-resolver.md # Rust build error resolution
 |   |-- pytorch-build-resolver.md # PyTorch/CUDA training errors
+|   |-- mle-reviewer.md      # Production ML pipeline, eval, serving, and monitoring review
 |
 |-- skills/           # Workflow definitions and domain knowledge
 |   |-- coding-standards/           # Language best practices
@@ -471,6 +526,10 @@ everything-claude-code/
 |   |-- springboot-security/        # Spring Boot security (NEW)
 |   |-- springboot-tdd/             # Spring Boot TDD (NEW)
 |   |-- springboot-verification/    # Spring Boot verification (NEW)
+|   |-- quarkus-patterns/           # Quarkus REST, Panache, and messaging patterns (NEW)
+|   |-- quarkus-security/           # Quarkus JWT/OIDC and RBAC security (NEW)
+|   |-- quarkus-tdd/                # Quarkus testing with JUnit, REST Assured, and Dev Services (NEW)
+|   |-- quarkus-verification/       # Quarkus build, test, security, and native verification (NEW)
 |   |-- configure-ecc/              # Interactive installation wizard (NEW)
 |   |-- security-scan/              # AgentShield security auditor integration (NEW)
 |   |-- java-coding-standards/     # Java coding standards (NEW)
@@ -493,23 +552,22 @@ everything-claude-code/
 |   |-- liquid-glass-design/         # iOS 26 Liquid Glass design system (NEW)
 |   |-- foundation-models-on-device/ # Apple on-device LLM with FoundationModels (NEW)
 |   |-- swift-concurrency-6-2/       # Swift 6.2 Approachable Concurrency (NEW)
+|   |-- mle-workflow/               # Production ML data contracts, evals, deployment, monitoring (NEW)
 |   |-- perl-patterns/             # Modern Perl 5.36+ idioms and best practices (NEW)
 |   |-- perl-security/             # Perl security patterns, taint mode, safe I/O (NEW)
 |   |-- perl-testing/              # Perl TDD with Test2::V0, prove, Devel::Cover (NEW)
 |   |-- autonomous-loops/           # Autonomous loop patterns: sequential pipelines, PR loops, DAG orchestration (NEW)
 |   |-- plankton-code-quality/      # Write-time code quality enforcement with Plankton hooks (NEW)
 |
-|-- commands/         # Legacy slash-entry shims; prefer skills/
-|   |-- tdd.md              # /tdd - Test-driven development
+|-- commands/         # Maintained slash-entry compatibility; prefer skills/
 |   |-- plan.md             # /plan - Implementation planning
-|   |-- e2e.md              # /e2e - E2E test generation
 |   |-- code-review.md      # /code-review - Quality review
 |   |-- build-fix.md        # /build-fix - Fix build errors
 |   |-- refactor-clean.md   # /refactor-clean - Dead code removal
+|   |-- quality-gate.md     # /quality-gate - Verification gate
 |   |-- learn.md            # /learn - Extract patterns mid-session (Longform Guide)
 |   |-- learn-eval.md       # /learn-eval - Extract, evaluate, and save patterns (NEW)
 |   |-- checkpoint.md       # /checkpoint - Save verification state (Longform Guide)
-|   |-- verify.md           # /verify - Run verification loop (Longform Guide)
 |   |-- setup-pm.md         # /setup-pm - Configure package manager
 |   |-- go-review.md        # /go-review - Go code review (NEW)
 |   |-- go-test.md          # /go-test - Go TDD workflow (NEW)
@@ -526,15 +584,19 @@ everything-claude-code/
 |   |-- multi-backend.md    # /multi-backend - Backend multi-service orchestration (NEW)
 |   |-- multi-frontend.md   # /multi-frontend - Frontend multi-service orchestration (NEW)
 |   |-- multi-workflow.md   # /multi-workflow - General multi-service workflows (NEW)
-|   |-- orchestrate.md      # /orchestrate - Multi-agent coordination
 |   |-- sessions.md         # /sessions - Session history management
-|   |-- eval.md             # /eval - Evaluate against criteria
 |   |-- test-coverage.md    # /test-coverage - Test coverage analysis
 |   |-- update-docs.md      # /update-docs - Update documentation
 |   |-- update-codemaps.md  # /update-codemaps - Update codemaps
 |   |-- python-review.md    # /python-review - Python code review (NEW)
+|-- legacy-command-shims/   # Opt-in archive for retired shims such as /tdd and /eval
+|   |-- tdd.md              # /tdd - Prefer the tdd-workflow skill
+|   |-- e2e.md              # /e2e - Prefer the e2e-testing skill
+|   |-- eval.md             # /eval - Prefer the eval-harness skill
+|   |-- verify.md           # /verify - Prefer the verification-loop skill
+|   |-- orchestrate.md      # /orchestrate - Prefer dmux-workflows or multi-workflow
 |
-|-- rules/            # Always-follow guidelines (copy to ~/.claude/rules/)
+|-- rules/            # Always-follow guidelines (copy to ~/.claude/rules/ecc/)
 |   |-- README.md            # Structure overview and installation guide
 |   |-- common/              # Language-agnostic principles
 |   |   |-- coding-style.md    # Immutability, file organization
@@ -550,6 +612,7 @@ everything-claude-code/
 |   |-- golang/              # Go specific
 |   |-- swift/               # Swift specific
 |   |-- php/                 # PHP specific (NEW)
+|   |-- arkts/               # HarmonyOS / ArkTS specific
 |
 |-- hooks/            # Trigger-based automations
 |   |-- README.md                 # Hook documentation, recipes, and customization guide
@@ -721,7 +784,7 @@ The easiest way to use this repo - install as a Claude Code plugin:
 /plugin marketplace add https://github.com/affaan-m/everything-claude-code
 
 # Install the plugin
-/plugin install everything-claude-code@everything-claude-code
+/plugin install ecc@ecc
 ```
 
 Or add directly to your `~/.claude/settings.json`:
@@ -737,7 +800,7 @@ Or add directly to your `~/.claude/settings.json`:
     }
   },
   "enabledPlugins": {
-    "everything-claude-code@everything-claude-code": true
+    "ecc@ecc": true
   }
 }
 ```
@@ -751,17 +814,17 @@ This gives you instant access to all commands, agents, skills, and hooks.
 > git clone https://github.com/affaan-m/everything-claude-code.git
 >
 > # Option A: User-level rules (applies to all projects)
-> mkdir -p ~/.claude/rules
-> cp -r everything-claude-code/rules/common ~/.claude/rules/
-> cp -r everything-claude-code/rules/typescript ~/.claude/rules/   # pick your stack
-> cp -r everything-claude-code/rules/python ~/.claude/rules/
-> cp -r everything-claude-code/rules/golang ~/.claude/rules/
-> cp -r everything-claude-code/rules/php ~/.claude/rules/
+> mkdir -p ~/.claude/rules/ecc
+> cp -r everything-claude-code/rules/common ~/.claude/rules/ecc/
+> cp -r everything-claude-code/rules/typescript ~/.claude/rules/ecc/   # pick your stack
+> cp -r everything-claude-code/rules/python ~/.claude/rules/ecc/
+> cp -r everything-claude-code/rules/golang ~/.claude/rules/ecc/
+> cp -r everything-claude-code/rules/php ~/.claude/rules/ecc/
 >
 > # Option B: Project-level rules (applies to current project only)
-> mkdir -p .claude/rules
-> cp -r everything-claude-code/rules/common .claude/rules/
-> cp -r everything-claude-code/rules/typescript .claude/rules/     # pick your stack
+> mkdir -p .claude/rules/ecc
+> cp -r everything-claude-code/rules/common .claude/rules/ecc/
+> cp -r everything-claude-code/rules/typescript .claude/rules/ecc/     # pick your stack
 > ```
 
 ---
@@ -778,26 +841,31 @@ git clone https://github.com/affaan-m/everything-claude-code.git
 cp everything-claude-code/agents/*.md ~/.claude/agents/
 
 # Copy rules directories (common + language-specific)
-mkdir -p ~/.claude/rules
-cp -r everything-claude-code/rules/common ~/.claude/rules/
-cp -r everything-claude-code/rules/typescript ~/.claude/rules/   # pick your stack
-cp -r everything-claude-code/rules/python ~/.claude/rules/
-cp -r everything-claude-code/rules/golang ~/.claude/rules/
-cp -r everything-claude-code/rules/php ~/.claude/rules/
+mkdir -p ~/.claude/rules/ecc
+cp -r everything-claude-code/rules/common ~/.claude/rules/ecc/
+cp -r everything-claude-code/rules/typescript ~/.claude/rules/ecc/   # pick your stack
+cp -r everything-claude-code/rules/python ~/.claude/rules/ecc/
+cp -r everything-claude-code/rules/golang ~/.claude/rules/ecc/
+cp -r everything-claude-code/rules/php ~/.claude/rules/ecc/
+cp -r everything-claude-code/rules/arkts ~/.claude/rules/ecc/
 
 # Copy skills first (primary workflow surface)
 # Recommended (new users): core/general skills only
-cp -r everything-claude-code/.agents/skills/* ~/.claude/skills/
-cp -r everything-claude-code/skills/search-first ~/.claude/skills/
+mkdir -p ~/.claude/skills/ecc
+cp -r everything-claude-code/.agents/skills/* ~/.claude/skills/ecc/
+cp -r everything-claude-code/skills/search-first ~/.claude/skills/ecc/
 
 # Optional: add niche/framework-specific skills only when needed
 # for s in django-patterns django-tdd laravel-patterns springboot-patterns; do
-# cp -r everything-claude-code/skills/$s ~/.claude/skills/
+# cp -r everything-claude-code/skills/$s ~/.claude/skills/ecc/
 # done
 
-# Optional: keep legacy slash-command compatibility during migration
+# Optional: keep maintained slash-command compatibility during migration
 mkdir -p ~/.claude/commands
 cp everything-claude-code/commands/*.md ~/.claude/commands/
+
+# Retired shims live in legacy-command-shims/commands/.
+# Copy individual files from there only if you still need old names such as /tdd.
 ```
 
 #### Install hooks
@@ -824,7 +892,11 @@ Windows note: the Claude config directory is `%USERPROFILE%\\.claude`, not `~/cl
 
 #### Configure MCPs
 
-Copy desired MCP server definitions from `mcp-configs/mcp-servers.json` into your official Claude Code config in `~/.claude/settings.json`, or into a project-scoped `.mcp.json` if you want repo-local MCP access.
+Claude plugin installs intentionally do not auto-enable ECC's bundled MCP server definitions. This avoids overlong plugin MCP tool names on strict third-party gateways while keeping manual MCP setup available.
+
+Use Claude Code's `/mcp` command or CLI-managed MCP setup for live Claude Code server changes. Use `/mcp` for Claude Code runtime disables; Claude Code persists those choices in `~/.claude.json`.
+
+For repo-local MCP access, copy desired MCP server definitions from `mcp-configs/mcp-servers.json` into a project-scoped `.mcp.json`.
 
 If you already run your own copies of ECC-bundled MCPs, set:
 
@@ -832,7 +904,7 @@ If you already run your own copies of ECC-bundled MCPs, set:
 export ECC_DISABLED_MCPS="github,context7,exa,playwright,sequential-thinking,memory"
 ```
 
-ECC-managed install and Codex sync flows will skip or remove those bundled servers instead of re-adding duplicates.
+ECC-managed install and Codex sync flows will skip or remove those bundled servers instead of re-adding duplicates. `ECC_DISABLED_MCPS` is an ECC install/sync filter, not a live Claude Code toggle.
 
 **Important:** Replace `YOUR_*_HERE` placeholders with your actual API keys.
 
@@ -857,7 +929,7 @@ You are a senior code reviewer...
 
 ### Skills
 
-Skills are the primary workflow surface. They can be invoked directly, suggested automatically, and reused by agents. ECC still ships `commands/` during migration, but new workflow development should land in `skills/` first.
+Skills are the primary workflow surface. They can be invoked directly, suggested automatically, and reused by agents. ECC still ships maintained `commands/` during migration, while retired short-name shims live under `legacy-command-shims/` for explicit opt-in only. New workflow development should land in `skills/` first.
 
 ```markdown
 # TDD Workflow
@@ -895,6 +967,7 @@ rules/
   golang/          # Go specific patterns and tools
   swift/           # Swift specific patterns and tools
   php/             # PHP specific patterns and tools
+  arkts/           # HarmonyOS / ArkTS patterns and constraints
 ```
 
 See [`rules/README.md`](rules/README.md) for installation and structure details.
@@ -903,39 +976,42 @@ See [`rules/README.md`](rules/README.md) for installation and structure details.
 
 ## Which Agent Should I Use?
 
-Not sure where to start? Use this quick reference. Skills are the canonical workflow surface; slash entries below are the compatibility form most users already know.
+Not sure where to start? Use this quick reference. Skills are the canonical workflow surface; maintained slash entries stay available for command-first workflows.
 
-| I want to... | Use this command | Agent used |
+| I want to... | Use this surface | Agent used |
 |--------------|-----------------|------------|
 | Plan a new feature | `/ecc:plan "Add auth"` | planner |
 | Design system architecture | `/ecc:plan` + architect agent | architect |
-| Write code with tests first | `/tdd` | tdd-guide |
+| Write code with tests first | `tdd-workflow` skill | tdd-guide |
 | Review code I just wrote | `/code-review` | code-reviewer |
 | Fix a failing build | `/build-fix` | build-error-resolver |
-| Run end-to-end tests | `/e2e` | e2e-runner |
+| Run end-to-end tests | `e2e-testing` skill | e2e-runner |
 | Find security vulnerabilities | `/security-scan` | security-reviewer |
 | Remove dead code | `/refactor-clean` | refactor-cleaner |
 | Update documentation | `/update-docs` | doc-updater |
 | Review Go code | `/go-review` | go-reviewer |
 | Review Python code | `/python-review` | python-reviewer |
+| Review F# code | *(invoke `fsharp-reviewer` directly)* | fsharp-reviewer |
 | Review TypeScript/JavaScript code | *(invoke `typescript-reviewer` directly)* | typescript-reviewer |
+| Develop HarmonyOS apps | *(invoke `harmonyos-app-resolver` directly)* | harmonyos-app-resolver |
 | Audit database queries | *(auto-delegated)* | database-reviewer |
+| Review production ML changes | `mle-workflow` skill + `mle-reviewer` agent | mle-reviewer |
 
 ### Common Workflows
 
-Slash forms below are shown because they are still the fastest familiar entrypoint. Under the hood, ECC is shifting these workflows toward skills-first definitions.
+Slash forms below are shown where they remain part of the maintained command surface. Retired short-name shims such as `/tdd` and `/eval` live in `legacy-command-shims/` for explicit opt-in only.
 
 **Starting a new feature:**
 ```
 /ecc:plan "Add user authentication with OAuth"
                                               → planner creates implementation blueprint
-/tdd                                          → tdd-guide enforces write-tests-first
+tdd-workflow skill                            → tdd-guide enforces write-tests-first
 /code-review                                  → code-reviewer checks your work
 ```
 
 **Fixing a bug:**
 ```
-/tdd                                          → tdd-guide: write a failing test that reproduces it
+tdd-workflow skill                            → tdd-guide: write a failing test that reproduces it
                                               → implement the fix, verify test passes
 /code-review                                  → code-reviewer: catch regressions
 ```
@@ -943,7 +1019,7 @@ Slash forms below are shown because they are still the fastest familiar entrypoi
 **Preparing for production:**
 ```
 /security-scan                                → security-reviewer: OWASP Top 10 audit
-/e2e                                          → e2e-runner: critical user flow tests
+e2e-testing skill                             → e2e-runner: critical user flow tests
 /test-coverage                                → verify 80%+ coverage
 ```
 
@@ -955,7 +1031,7 @@ Slash forms below are shown because they are still the fastest familiar entrypoi
 <summary><b>How do I check which agents/commands are installed?</b></summary>
 
 ```bash
-/plugin list everything-claude-code@everything-claude-code
+/plugin list ecc@ecc
 ```
 
 This shows all available agents, commands, and skills from the plugin.
@@ -995,15 +1071,9 @@ Official references:
 <details>
 <summary><b>My context window is shrinking / Claude is running out of context</b></summary>
 
-Too many MCP servers eat your context. Each MCP tool description consumes tokens from your 200k window, potentially reducing it to ~70k.
+Too many MCP servers eat your context. Each MCP tool description consumes tokens from your 200k window, potentially reducing it to ~70k. SessionStart context is capped at 8000 characters by default; lower it with `ECC_SESSION_START_MAX_CHARS=4000` or disable it with `ECC_SESSION_START_CONTEXT=off` for local-model or low-context setups.
 
-**Fix:** Disable unused MCPs per project:
-```json
-// In your project's .claude/settings.json
-{
-  "disabledMcpServers": ["supabase", "railway", "vercel"]
-}
-```
+**Fix:** Disable unused MCPs from Claude Code with `/mcp`. Claude Code writes those runtime choices to `~/.claude.json`; `.claude/settings.json` and `.claude/settings.local.json` are not reliable toggles for already-loaded MCP servers.
 
 Keep under 10 MCPs enabled and under 80 tools active.
 </details>
@@ -1018,8 +1088,8 @@ Yes. Use Option 2 (manual installation) and copy only what you need:
 cp everything-claude-code/agents/*.md ~/.claude/agents/
 
 # Just rules
-mkdir -p ~/.claude/rules/
-cp -r everything-claude-code/rules/common ~/.claude/rules/
+mkdir -p ~/.claude/rules/ecc/
+cp -r everything-claude-code/rules/common ~/.claude/rules/ecc/
 ```
 
 Each component is fully independent.
@@ -1034,6 +1104,8 @@ Yes. ECC is cross-platform:
 - **OpenCode**: Full plugin support in `.opencode/`. See [OpenCode Support](#opencode-support).
 - **Codex**: First-class support for both macOS app and CLI, with adapter drift guards and SessionStart fallback. See PR [#257](https://github.com/affaan-m/everything-claude-code/pull/257).
 - **Antigravity**: Tightly integrated setup for workflows, skills, and flattened rules in `.agent/`. See [Antigravity Guide](docs/ANTIGRAVITY-GUIDE.md).
+- **JoyCode / CodeBuddy**: Project-local selective install adapters for commands, agents, skills, and flattened rules. See [JoyCode Adapter Guide](docs/JOYCODE-GUIDE.md).
+- **Qwen CLI**: Home-directory selective install adapter for commands, agents, skills, rules, and Qwen config. See [Qwen CLI Adapter Guide](docs/QWEN-GUIDE.md).
 - **Non-native harnesses**: Manual fallback path for Grok and similar interfaces. See [Manual Adaptation Guide](docs/MANUAL-ADAPTATION-GUIDE.md).
 - **Claude Code**: Native — this is the primary target.
 </details>
@@ -1080,7 +1152,7 @@ Please contribute! See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
 
 ### Ideas for Contributions
 
-- Language-specific skills (Rust, C#, Kotlin, Java) — Go, Python, Perl, Swift, and TypeScript already included
+- Language-specific skills (Rust, C#, Kotlin, Java) — Go, Python, Perl, Swift, TypeScript, and HarmonyOS/ArkTS already included
 - Framework-specific configs (Rails, FastAPI) — Django, NestJS, Spring Boot, and Laravel already included
 - DevOps agents (Kubernetes, Terraform, AWS, Docker)
 - Testing strategies (different frameworks, visual regression)
@@ -1098,7 +1170,7 @@ These are not bundled with ECC and are not audited by this repo, but they are wo
 
 ## Cursor IDE Support
 
-ECC provides **full Cursor IDE support** with hooks, rules, agents, skills, commands, and MCP configs adapted for Cursor's native format.
+ECC provides Cursor IDE support with hooks, rules, agents, skills, commands, and MCP configs adapted for Cursor's project layout.
 
 ### Quick Start (Cursor)
 
@@ -1121,11 +1193,17 @@ ECC provides **full Cursor IDE support** with hooks, rules, agents, skills, comm
 | Hook Events | 15 | sessionStart, beforeShellExecution, afterFileEdit, beforeMCPExecution, beforeSubmitPrompt, and 10 more |
 | Hook Scripts | 16 | Thin Node.js scripts delegating to `scripts/hooks/` via shared adapter |
 | Rules | 34 | 9 common (alwaysApply) + 25 language-specific (TypeScript, Python, Go, Swift, PHP) |
-| Agents | Shared | Via AGENTS.md at root (read by Cursor natively) |
-| Skills | Shared + Bundled | Via AGENTS.md at root and `.cursor/skills/` for translated additions |
+| Agents | 48 | `.cursor/agents/ecc-*.md` when installed; prefixed to avoid collisions with user or marketplace agents |
+| Skills | Shared + Bundled | `.cursor/skills/` for translated additions |
 | Commands | Shared | `.cursor/commands/` if installed |
 | MCP Config | Shared | `.cursor/mcp.json` if installed |
 
+### Cursor Loading Notes
+
+ECC does not install root `AGENTS.md` into `.cursor/`. Cursor treats nested `AGENTS.md` files as directory context, so copying ECC's repo identity into a host project would pollute that project.
+
+Cursor-native loading behavior can vary by Cursor build. ECC installs agents as `.cursor/agents/ecc-*.md`; if your Cursor build does not expose project agents, those files still work as explicit reference definitions instead of hidden global prompt context.
+
 ### Hook Architecture (DRY Adapter Pattern)
 
 Cursor has **more hook events than Claude Code** (20 vs 8). The `.cursor/hooks/adapter.js` module transforms Cursor's stdin JSON to Claude Code's format, allowing existing `scripts/hooks/*.js` to be reused without duplication.
@@ -1193,7 +1271,7 @@ Codex macOS app:
 |-----------|-------|---------|
 | Config | 1 | `.codex/config.toml` — top-level approvals/sandbox/web_search, MCP servers, notifications, profiles |
 | AGENTS.md | 2 | Root (universal) + `.codex/AGENTS.md` (Codex-specific supplement) |
-| Skills | 30 | `.agents/skills/` — SKILL.md + agents/openai.yaml per skill |
+| Skills | 32 | `.agents/skills/` — SKILL.md + agents/openai.yaml per skill |
 | MCP Servers | 6 | GitHub, Context7, Exa, Memory, Playwright, Sequential Thinking (7 with Supabase via `--update-mcp` sync) |
 | Profiles | 2 | `strict` (read-only sandbox) and `yolo` (full auto-approve) |
 | Agent Roles | 3 | `.codex/agents/` — explorer, reviewer, docs-researcher |
@@ -1202,14 +1280,17 @@ Codex macOS app:
 
 Skills at `.agents/skills/` are auto-loaded by Codex:
 
+Canonical Anthropic skills such as `claude-api`, `frontend-design`, and `skill-creator` are intentionally not re-bundled here. Install those from [`anthropics/skills`](https://github.com/anthropics/skills) when you want the official versions.
+
 | Skill | Description |
 |-------|-------------|
+| agent-introspection-debugging | Debug agent behavior, routing, and prompt boundaries |
+| agent-sort | Sort agent catalogs and assignment surfaces |
 | api-design | REST API design patterns |
 | article-writing | Long-form writing from notes and voice references |
 | backend-patterns | API design, database, caching |
 | brand-voice | Source-derived writing style profiles from real content |
 | bun-runtime | Bun as runtime, package manager, bundler, and test runner |
-| claude-api | Anthropic Claude API patterns for Python and TypeScript |
 | coding-standards | Universal coding standards |
 | content-engine | Platform-native social content and repurposing |
 | crosspost | Multi-platform content distribution across X, LinkedIn, Threads |
@@ -1228,6 +1309,7 @@ Skills at `.agents/skills/` are auto-loaded by Codex:
 | market-research | Source-attributed market and competitor research |
 | mcp-server-patterns | Build MCP servers with Node/TypeScript SDK |
 | nextjs-turbopack | Next.js 16+ and Turbopack incremental bundling |
+| product-capability | Translate product goals into scoped capability maps |
 | security-review | Comprehensive security checklist |
 | strategic-compact | Context management |
 | tdd-workflow | Test-driven development with 80%+ coverage |
@@ -1278,9 +1360,9 @@ The configuration is automatically detected from `.opencode/opencode.json`.
 
 | Feature | Claude Code | OpenCode | Status |
 |---------|-------------|----------|--------|
-| Agents | PASS: 48 agents | PASS: 12 agents | **Claude Code leads** |
-| Commands | PASS: 79 commands | PASS: 31 commands | **Claude Code leads** |
-| Skills | PASS: 184 skills | PASS: 37 skills | **Claude Code leads** |
+| Agents | PASS: 58 agents | PASS: 12 agents | **Claude Code leads** |
+| Commands | PASS: 74 commands | PASS: 35 commands | **Claude Code leads** |
+| Skills | PASS: 220 skills | PASS: 37 skills | **Claude Code leads** |
 | Hooks | PASS: 8 event types | PASS: 11 events | **OpenCode has more!** |
 | Rules | PASS: 29 rules | PASS: 13 instructions | **Claude Code leads** |
 | MCP Servers | PASS: 14 servers | PASS: Full | **Full parity** |
@@ -1300,21 +1382,17 @@ OpenCode's plugin system is MORE sophisticated than Claude Code with 20+ event t
 
 **Additional OpenCode events**: `file.edited`, `file.watcher.updated`, `message.updated`, `lsp.client.diagnostics`, `tui.toast.show`, and more.
 
-### Available Slash Entry Shims (31+)
+### Maintained Slash Entries
 
 | Command | Description |
 |---------|-------------|
 | `/plan` | Create implementation plan |
-| `/tdd` | Enforce TDD workflow |
 | `/code-review` | Review code changes |
 | `/build-fix` | Fix build errors |
-| `/e2e` | Generate E2E tests |
 | `/refactor-clean` | Remove dead code |
-| `/orchestrate` | Multi-agent workflow |
 | `/learn` | Extract patterns from session |
 | `/checkpoint` | Save verification state |
-| `/verify` | Run verification loop |
-| `/eval` | Evaluate against criteria |
+| `/quality-gate` | Run the maintained verification gate |
 | `/update-docs` | Update documentation |
 | `/update-codemaps` | Update codemaps |
 | `/test-coverage` | Analyze coverage |
@@ -1387,9 +1465,9 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
 
 | Feature | Claude Code | Cursor IDE | Codex CLI | OpenCode |
 |---------|------------|------------|-----------|----------|
-| **Agents** | 48 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
-| **Commands** | 79 | Shared | Instruction-based | 31 |
-| **Skills** | 184 | Shared | 10 (native format) | 37 |
+| **Agents** | 58 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
+| **Commands** | 74 | Shared | Instruction-based | 35 |
+| **Skills** | 220 | Shared | 10 (native format) | 37 |
 | **Hook Events** | 8 types | 15 types | None yet | 11 types |
 | **Hook Scripts** | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks |
 | **Rules** | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions |
@@ -1475,7 +1553,8 @@ The `strategic-compact` skill (included in this plugin) suggests `/compact` at l
 
 - Keep under 10 MCPs enabled per project
 - Keep under 80 tools active
-- Use `disabledMcpServers` in project config to disable unused ones
+- Use `/mcp` to disable unused Claude Code MCP servers; those runtime choices persist in `~/.claude.json`
+- Use `ECC_DISABLED_MCPS` only to filter ECC-generated MCP configs during install/sync flows
 
 ### Agent Teams Cost Warning
 
@@ -1522,6 +1601,7 @@ Projects built on or inspired by Everything Claude Code:
 | Project | Description |
 |---------|-------------|
 | [EVC](https://github.com/SaigonXIII/evc) | Marketing agent workspace — 42 commands for content operators, brand governance, and multi-channel publishing. [Visual overview](https://saigonxiii.github.io/evc). |
+| [trading-skills](https://github.com/VictorVVedtion/trading-skills) | 68 trading-themed Claude Code skills with pre-trade review prompts and risk gates inspired by market operators. |
 
 Built something with ECC? Open a PR to add it here.
 

README.zh-CN.md

@@ -21,9 +21,9 @@
 
 <div align="center">
 
-**Language / 语言 / 語言 / Dil**
+**Language / 语言 / 語言 / Dil / Язык / Ngôn ngữ**
 
-[**English**](README.md) | [Português (Brasil)](docs/pt-BR/README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md) | [Türkçe](docs/tr/README.md)
+[**English**](README.md) | [Português (Brasil)](docs/pt-BR/README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md) | [Türkçe](docs/tr/README.md) | [Русский](docs/ru/README.md) | [Tiếng Việt](docs/vi-VN/README.md)
 
 </div>
 
@@ -102,12 +102,12 @@
 /plugin marketplace add https://github.com/affaan-m/everything-claude-code
 
 # 安装插件
-/plugin install everything-claude-code@everything-claude-code
+/plugin install ecc@ecc
 ```
 
-> 安装名称说明：较早的帖子里可能还会出现旧的短别名。那个旧缩写现在已经废弃。Anthropic 的 marketplace/plugin 安装是按规范化插件标识符寻址的，因此 ECC 统一为 `everything-claude-code@everything-claude-code`，这样市场条目、安装命令、`/plugin list` 输出和仓库文档都使用同一个公开名称，不再出现两个名字指向同一插件的混乱。
+> 安装名称说明：较早的帖子里可能还会出现较长的旧标识符。Anthropic 的 marketplace/plugin 安装是按规范化插件标识符寻址的，因此 ECC 现在统一为 `ecc@ecc`，让工具名和 slash command 命名空间保持简短。
 
-### 第二步：安装规则（必需）
+### 第二步：仅在需要时安装规则
 
 > WARNING: **重要提示：** Claude Code 插件无法自动分发 `rules`。
 >
@@ -157,10 +157,10 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
 # /plan "添加用户认证"
 
 # 查看可用命令
-/plugin list everything-claude-code@everything-claude-code
+/plugin list ecc@ecc
 ```
 
-**完成！** 你现在可以使用 48 个代理、184 个技能和 79 个命令。
+**完成！** 你现在可以使用 58 个代理、220 个技能和 74 个命令。
 
 ### multi-* 命令需要额外配置
 
@@ -330,17 +330,15 @@ everything-claude-code/
 |   |-- autonomous-loops/           # 自主循环模式：顺序流水线、PR 循环、DAG 编排（新增）
 |   |-- plankton-code-quality/      # 基于 Plankton 钩子的实时代码质量管控（新增）
 |
-|-- commands/         # 传统斜杠命令兼容层；优先使用 skills/
-|   |-- tdd.md              # /tdd - 测试驱动开发
+|-- commands/         # 维护中的斜杠命令兼容层；优先使用 skills/
 |   |-- plan.md             # /plan - 实现规划
-|   |-- e2e.md              # /e2e - 生成端到端测试
 |   |-- code-review.md      # /code-review - 代码质量审查
 |   |-- build-fix.md        # /build-fix - 修复构建错误
+|   |-- quality-gate.md     # /quality-gate - 验证门禁
 |   |-- refactor-clean.md   # /refactor-clean - 清理无效代码
 |   |-- learn.md            # /learn - 会话中提取模式（长文本指南）
 |   |-- learn-eval.md       # /learn-eval - 提取、评估并保存模式（新增）
 |   |-- checkpoint.md       # /checkpoint - 保存验证状态（长文本指南）
-|   |-- verify.md           # /verify - 运行验证循环（长文本指南）
 |   |-- setup-pm.md         # /setup-pm - 配置包管理器
 |   |-- go-review.md        # /go-review - Go 代码审查（新增）
 |   |-- go-test.md          # /go-test - Go TDD 工作流（新增）
@@ -357,13 +355,17 @@ everything-claude-code/
 |   |-- multi-backend.md    # /multi-backend - 后端多服务编排（新增）
 |   |-- multi-frontend.md   # /multi-frontend - 前端多服务编排（新增）
 |   |-- multi-workflow.md   # /multi-workflow - 通用多服务工作流（新增）
-|   |-- orchestrate.md      # /orchestrate - 多智能体协同调度
 |   |-- sessions.md         # /sessions - 会话历史管理
-|   |-- eval.md             # /eval - 按标准评估
 |   |-- test-coverage.md    # /test-coverage - 测试覆盖率分析
 |   |-- update-docs.md      # /update-docs - 更新文档
 |   |-- update-codemaps.md  # /update-codemaps - 更新代码映射
 |   |-- python-review.md    # /python-review - Python 代码审查（新增）
+|-- legacy-command-shims/   # 已退役短命令的按需归档，例如 /tdd 和 /eval
+|   |-- tdd.md              # /tdd - 优先使用 tdd-workflow 技能
+|   |-- e2e.md              # /e2e - 优先使用 e2e-testing 技能
+|   |-- eval.md             # /eval - 优先使用 eval-harness 技能
+|   |-- verify.md           # /verify - 优先使用 verification-loop 技能
+|   |-- orchestrate.md      # /orchestrate - 优先使用 dmux-workflows 或 multi-workflow
 |
 |-- rules/            # 必须遵守的规范（复制到 ~/.claude/rules/）
 |   |-- README.md            # 结构概览与安装指南
@@ -544,7 +546,7 @@ Claude Code v2.1+ 会**按照约定自动加载**已安装插件中的 `hooks/ho
 /plugin marketplace add https://github.com/affaan-m/everything-claude-code
 
 # 安装插件
-/plugin install everything-claude-code@everything-claude-code
+/plugin install ecc@ecc
 ```
 
 或直接添加到你的 `~/.claude/settings.json`：
@@ -560,7 +562,7 @@ Claude Code v2.1+ 会**按照约定自动加载**已安装插件中的 `hooks/ho
     }
   },
   "enabledPlugins": {
-    "everything-claude-code@everything-claude-code": true
+    "ecc@ecc": true
   }
 }
 ```
@@ -618,9 +620,12 @@ cp -r everything-claude-code/skills/search-first ~/.claude/skills/
 # cp -r everything-claude-code/skills/$s ~/.claude/skills/
 # done
 
-# 可选：迁移期间保留传统斜杠命令兼容
+# 可选：迁移期间保留维护中的斜杠命令兼容
 mkdir -p ~/.claude/commands
 cp everything-claude-code/commands/*.md ~/.claude/commands/
+
+# 已退役短命令位于 legacy-command-shims/commands/。
+# 仅在仍需要 /tdd 等旧名称时，单独复制对应文件。
 ```
 
 #### 将钩子配置添加到 settings.json

SECURITY.md

@@ -45,6 +45,53 @@ This policy covers:
 - MCP configurations shipped with ECC
 - The AgentShield security scanner ([github.com/affaan-m/agentshield](https://github.com/affaan-m/agentshield))
 
+## Operational Guidance
+
+### Secrets Handling
+
+`mcp-configs/mcp-servers.json` is a **template**. All `YOUR_*_HERE` values must be replaced at install time from env-vars or a secrets manager. Never commit real credentials. If a secret is accidentally committed, rotate it immediately and rewrite history; do not rely on a plain revert.
+
+The same rule applies to your user-scope Claude Code config (`~/.claude/settings.json` or `%USERPROFILE%\.claude\settings.json`). That file is outside this repository, but it is commonly shared via `claude doctor` output, screenshots, or bug reports. Do not hardcode PATs, API keys, or OAuth tokens into its `mcpServers[*].env` blocks; resolve them at spawn time from the OS keychain or env-vars your MCP server already supports. A quick audit:
+
+```bash
+# macOS / Linux
+grep -EnH '(TOKEN|SECRET|KEY|PASSWORD)\s*"\s*:\s*"[A-Za-z0-9_-]{16,}"' ~/.claude/settings.json
+# Windows PowerShell
+Select-String -Path "$env:USERPROFILE\.claude\settings.json" -Pattern '(TOKEN|SECRET|KEY|PASSWORD)"\s*:\s*"[A-Za-z0-9_-]{16,}"'
+```
+
+If the audit matches, rotate the secret at the issuing provider, then move it out of the file (per-provider env-var or `credentialHelper` for servers that support it).
+
+### Local MCP Ports
+
+Some bundled MCP servers connect over plain HTTP to a localhost port (e.g. `devfleet` to `http://localhost:18801/mcp`). Before first use, verify the listening process:
+
+```bash
+# Windows
+netstat -ano | findstr :18801
+# macOS / Linux
+lsof -iTCP:18801 -sTCP:LISTEN
+```
+
+Compare the PID against the expected devfleet binary. Any other process on that port can intercept MCP traffic.
+
+## Triage: suspicious `<system-reminder>` blocks
+
+ECC runs inside Claude Code, which injects **ephemeral client-side system reminders** into the model's input on every turn (TodoWrite nudges, date-changed notices, file-modified notices, etc.). These blocks:
+
+- typically end with phrasing like *"ignore if not applicable"* or *"NEVER mention this reminder to the user"* / *"Don't tell the user this, since they are already aware"*; that wording is Anthropic's own prompt, not a malicious tail;
+- are added by the CLI per turn and are **not persisted** in the session transcript at `~/.claude/projects/<slug>/<sessionId>.jsonl`.
+
+That combination makes them easy to mistake for a prompt-injection appended to a tool result. Before treating one as an attack, verify:
+
+1. Is the block actually in a file under this repo? `grep -rEn "system-reminder|NEVER mention|DO NOT mention" .`; if nothing, it is not carried by the repo.
+2. Is the block stored in the transcript? Inspect the current session's `.jsonl`; if the exact text does not appear inside a `tool_result` body there, it is a client-injected ephemeral reminder, not a payload from any tool.
+3. Is the content contextually consistent with Anthropic's known reminders (TodoWrite nudge, date-changed, file-modified notice)? If yes, it is the ephemeral-reminder mechanism and no action is needed.
+
+Escalate to Anthropic only if a block is **both** (a) present in the transcript inside a `tool_result` **and** (b) not attributable to the file or URL that was actually read. Minimal report: a fresh session, a read of a clean local file, the exact text observed, and the transcript excerpt. Send to <https://github.com/anthropics/claude-code/issues> (non-sensitive) or <mailto:security@anthropic.com> (embargo-class).
+
+Do not sanitize repo files in response to ephemeral reminders; they are not the carrier.
+
 ## Security Resources
 
 - **AgentShield**: Scan your agent config for vulnerabilities — `npx ecc-agentshield scan`

agent.yaml

@@ -9,10 +9,12 @@ model:
   fallback:
     - claude-sonnet-4-6
 skills:
+  - agent-architecture-audit
   - agent-eval
   - agent-harness-construction
   - agent-payment-x402
   - agentic-engineering
+  - agentic-os
   - ai-first-engineering
   - ai-regression-testing
   - android-clean-architecture
@@ -28,7 +30,6 @@ skills:
   - canary-watch
   - carrier-relationship-management
   - ck
-  - claude-api
   - claude-devfleet
   - click-path-audit
   - clickhouse-io
@@ -62,6 +63,7 @@ skills:
   - e2e-testing
   - energy-procurement
   - enterprise-agent-ops
+  - error-handling
   - eval-harness
   - exa-search
   - fal-ai-media
@@ -69,6 +71,7 @@ skills:
   - foundation-models-on-device
   - frontend-patterns
   - frontend-slides
+  - fsharp-testing
   - git-workflow
   - golang-patterns
   - golang-testing
@@ -96,6 +99,7 @@ skills:
   - logistics-exception-management
   - market-research
   - mcp-server-patterns
+  - motion-ui
   - nanoclaw-repl
   - nextjs-turbopack
   - nutrient-document-processing
@@ -104,6 +108,7 @@ skills:
   - perl-security
   - perl-testing
   - plankton-code-quality
+  - plan-orchestrate
   - postgres-patterns
   - product-lens
   - production-scheduling
@@ -112,6 +117,10 @@ skills:
   - python-testing
   - pytorch-patterns
   - quality-nonconformance
+  - quarkus-patterns
+  - quarkus-security
+  - quarkus-tdd
+  - quarkus-verification
   - ralphinho-rfc-pipeline
   - regex-vs-llm-structured-text
   - repo-scan
@@ -144,21 +153,17 @@ skills:
   - visa-doc-translate
   - x-api
 commands:
-  - agent-sort
   - aside
+  - auto-update
   - build-fix
   - checkpoint
-  - claw
   - code-review
-  - context-budget
   - cpp-build
   - cpp-review
   - cpp-test
-  - devfleet
-  - docs
-  - e2e
-  - eval
+  - ecc-guide
   - evolve
+  - fastapi-review
   - feature-dev
   - flutter-build
   - flutter-review
@@ -191,12 +196,13 @@ commands:
   - multi-frontend
   - multi-plan
   - multi-workflow
-  - orchestrate
   - plan
+  - plan-prd
   - pm2
   - projects
   - promote
-  - prompt-optimize
+  - project-init
+  - pr
   - prp-commit
   - prp-implement
   - prp-plan
@@ -208,21 +214,19 @@ commands:
   - refactor-clean
   - resume-session
   - review-pr
-  - rules-distill
   - rust-build
   - rust-review
   - rust-test
   - santa-loop
   - save-session
+  - security-scan
   - sessions
   - setup-pm
   - skill-create
   - skill-health
-  - tdd
   - test-coverage
   - update-codemaps
   - update-docs
-  - verify
 tags:
   - agent-harness
   - developer-tools

agents/a11y-architect.md

@@ -3,7 +3,6 @@ name: a11y-architect
 description: Accessibility Architect specializing in WCAG 2.2 compliance for Web and Native platforms. Use PROACTIVELY when designing UI components, establishing design systems, or auditing code for inclusive user experiences.
 model: sonnet
 tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
-model: opus
 ---
 
 You are a Senior Accessibility Architect. Your goal is to ensure that every digital product is Perceivable, Operable, Understandable, and Robust (POUR) for all users, including those with visual, auditory, motor, or cognitive disabilities.

agents/fastapi-reviewer.md

@@ -0,0 +1,70 @@
+---
+name: fastapi-reviewer
+description: Reviews FastAPI applications for async correctness, dependency injection, Pydantic schemas, security, OpenAPI quality, testing, and production readiness.
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+You are a senior FastAPI reviewer focused on production Python APIs.
+
+## Review Scope
+
+- FastAPI app construction, routing, middleware, and exception handling.
+- Pydantic request, update, and response models.
+- Async database and HTTP patterns.
+- Dependency injection for database sessions, auth, pagination, and settings.
+- Authentication, authorization, CORS, rate limits, logging, and secret handling.
+- Test dependency overrides and client setup.
+- OpenAPI metadata and generated docs.
+
+## Out of Scope
+
+- Non-FastAPI frameworks unless they directly interact with the FastAPI app.
+- Broad Python style review already covered by `python-reviewer`.
+- Dependency additions without a concrete problem and maintenance rationale.
+
+## Review Workflow
+
+1. Locate the app entry point, usually `main.py`, `app.py`, or `app/main.py`.
+2. Identify routers, schemas, dependencies, database session setup, and tests.
+3. Run available local checks when safe, such as `pytest`, `ruff`, `mypy`, or `uv run pytest`.
+4. Review the changed files first, then inspect adjacent definitions needed to prove findings.
+5. Report only actionable issues with file and line references when available.
+
+## Finding Priorities
+
+### Critical
+
+- Hardcoded secrets or tokens.
+- SQL built through string interpolation.
+- Passwords, token hashes, or internal auth fields exposed in response models.
+- Auth dependencies that can be bypassed or do not validate expiry/signature.
+
+### High
+
+- Blocking database or HTTP clients inside async routes.
+- Database sessions created inline in handlers instead of dependencies.
+- Test overrides targeting the wrong dependency.
+- `allow_origins=["*"]` combined with credentialed CORS.
+- Missing request validation for write endpoints.
+
+### Medium
+
+- Missing pagination on list endpoints.
+- OpenAPI docs missing response models or error response descriptions.
+- Duplicated route logic that should move into a service/dependency.
+- Missing timeout settings for external HTTP clients.
+
+## Output Format
+
+```text
+[SEVERITY] Short issue title
+File: path/to/file.py:42
+Issue: What is wrong and why it matters.
+Fix: Concrete change to make.
+```
+
+End with:
+
+- `Tests checked:` commands run or why they were skipped.
+- `Residual risk:` anything important that could not be verified.

agents/fsharp-reviewer.md

@@ -0,0 +1,100 @@
+---
+name: fsharp-reviewer
+description: Expert F# code reviewer specializing in functional idioms, type safety, pattern matching, computation expressions, and performance. Use for all F# code changes. MUST BE USED for F# projects.
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+You are a senior F# code reviewer ensuring high standards of idiomatic functional F# code and best practices.
+
+When invoked:
+1. Run `git diff -- '*.fs' '*.fsx'` to see recent F# file changes
+2. Run `dotnet build` and `fantomas --check .` if available
+3. Focus on modified `.fs` and `.fsx` files
+4. Begin review immediately
+
+## Review Priorities
+
+### CRITICAL - Security
+- **SQL Injection**: String concatenation/interpolation in queries - use parameterized queries
+- **Command Injection**: Unvalidated input in `Process.Start` - validate and sanitize
+- **Path Traversal**: User-controlled file paths - use `Path.GetFullPath` + prefix check
+- **Insecure Deserialization**: `BinaryFormatter`, unsafe JSON settings
+- **Hardcoded secrets**: API keys, connection strings in source - use configuration/secret manager
+- **CSRF/XSS**: Missing anti-forgery tokens, unencoded output in views
+
+### CRITICAL - Error Handling
+- **Swallowed exceptions**: `with _ -> ()` or `with _ -> None` - handle or reraise
+- **Missing disposal**: Manual disposal of `IDisposable` - use `use` or `use!` bindings
+- **Blocking async**: `.Result`, `.Wait()`, `.GetAwaiter().GetResult()` - use `let!` or `do!`
+- **Bare `failwith` in library code**: Prefer `Result` or `Option` for expected failures
+
+### HIGH - Functional Idioms
+- **Mutable state in domain logic**: `mutable`, `ref` cells where immutable alternatives exist
+- **Incomplete pattern matches**: Missing cases or catch-all `_` that hides new union cases
+- **Imperative loops**: `for`/`while` where `List.map`, `Seq.filter`, `Array.fold` are clearer
+- **Null usage**: Using `null` instead of `Option<'T>` for missing values
+- **Class-heavy design**: OOP-style classes where modules + functions + records suffice
+
+### HIGH - Type Safety
+- **Primitive obsession**: Raw strings/ints for domain concepts - use single-case DUs
+- **Unvalidated input**: Missing validation at system boundaries - use smart constructors
+- **Downcasting**: `:?>` without type test - use pattern matching with `:? T as t`
+- **`obj` usage**: Avoid `obj` boxing; prefer generics or explicit union types
+
+### HIGH - Code Quality
+- **Large functions**: Over 40 lines - extract helper functions
+- **Deep nesting**: More than 3 levels - use early returns, `Result.bind`, or computation expressions
+- **Missing `[<RequireQualifiedAccess>]`**: On modules/unions that could cause name collisions
+- **Unused `open` declarations**: Remove unused module imports
+
+### MEDIUM - Performance
+- **Seq in hot paths**: Lazy sequences recomputed repeatedly - materialize with `Seq.toList` or `Seq.toArray`
+- **String concatenation in loops**: Use `StringBuilder` or `String.concat`
+- **Excessive boxing**: Value types passed through `obj` - use generic functions
+- **N+1 queries**: Lazy loading in loops when using EF Core - use eager loading
+
+### MEDIUM - Best Practices
+- **Naming conventions**: camelCase for functions/values, PascalCase for types/modules/DU cases
+- **Pipe operator readability**: Overly long chains - break into named intermediate bindings
+- **Computation expression misuse**: Nested `task { task { } }` - flatten with `let!`
+- **Module organization**: Related functions scattered across files - group cohesively
+
+## Diagnostic Commands
+
+```bash
+dotnet build                                          # Compilation check
+fantomas --check .                                    # Format check
+dotnet test --no-build                                # Run tests
+dotnet test --collect:"XPlat Code Coverage"           # Coverage
+```
+
+## Review Output Format
+
+```text
+[SEVERITY] Issue title
+File: path/to/File.fs:42
+Issue: Description
+Fix: What to change
+```
+
+## Approval Criteria
+
+- **Approve**: No CRITICAL or HIGH issues
+- **Warning**: MEDIUM issues only (can merge with caution)
+- **Block**: CRITICAL or HIGH issues found
+
+## Framework Checks
+
+- **ASP.NET Core**: Giraffe or Saturn handlers, model validation, auth policies, middleware order
+- **EF Core**: Migration safety, eager loading, `AsNoTracking` for reads
+- **Fable**: Elmish architecture, message handling completeness, view function purity
+
+## Reference
+
+For detailed .NET patterns, see skill: `dotnet-patterns`.
+For testing guidelines, see skill: `fsharp-testing`.
+
+---
+
+Review with the mindset: "Is this idiomatic F# that leverages the type system and functional patterns effectively?"

agents/harmonyos-app-resolver.md

@@ -0,0 +1,173 @@
+---
+name: harmonyos-app-resolver
+description: HarmonyOS application development expert specializing in ArkTS and ArkUI. Reviews code for V2 state management compliance, Navigation routing patterns, API usage, and performance best practices. Use for HarmonyOS/OpenHarmony projects.
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# HarmonyOS Application Development Expert
+
+You are a senior HarmonyOS application development expert specializing in ArkTS and ArkUI for building high-quality HarmonyOS native applications. You have deep understanding of HarmonyOS system components, APIs, and underlying mechanisms, and always apply industry best practices.
+
+## Core Tech Stack Constraints (Strictly Enforced)
+
+In all code generation, Q&A, and technical recommendations, you MUST strictly follow these technology choices - **no compromise**:
+
+### 1. State Management: V2 Only (ArkUI State Management V2)
+
+- **MUST use**: ArkUI State Management V2 decorators/patterns (use applicable decorators by context), including `@ComponentV2`, `@Local`, `@Param`, `@Event`, `@Provider`, `@Consumer`, `@Monitor`, `@Computed`; use `@ObservedV2` + `@Trace` for observable model classes/properties when needed.
+- **MUST NOT use**: V1 decorators (`@Component`, `@State`, `@Prop`, `@Link`, `@ObjectLink`, `@Observed`, `@Provide`, `@Consume`, `@Watch`)
+
+### 2. Routing: Navigation Only
+
+- **MUST use**: `Navigation` component with `NavPathStack` for route management; use `NavDestination` as root container for sub-pages
+- **MUST NOT use**: Legacy `router` module (`@ohos.router`) for page navigation
+
+## Your Role
+
+- **ArkTS & ArkUI mastery** - Write elegant, efficient, type-safe declarative UI code with deep understanding of V2 state management observation mechanisms and UI update logic
+- **Full-stack component & API expertise** - Proficient with UI components (List, Grid, Swiper, Tabs, etc.) and system APIs (network, media, file, preferences, etc.) to rapidly implement complex business requirements
+- **Best practice enforcement**:
+  - **Architecture**: Modular, layered architecture ensuring high cohesion and low coupling
+  - **Performance**: Use `LazyForEach`, component reuse, async processing for expensive tasks
+  - **Code standards**: Consistent style, rigorous logic, clear comments, compliant with HarmonyOS official guidelines
+
+## Workflow
+
+### Step 1: Understand Project Context
+
+- Read `CLAUDE.md`, `module.json5`, `oh-package.json5` for project conventions
+- Identify existing state management version (V1 vs V2) and routing approach
+- Check `build-profile.json5` for API level and device targets
+
+### Step 2: Review or Implement
+
+When reviewing code:
+- Flag any V1 state management usage - recommend V2 migration
+- Flag any `@ohos.router` usage - recommend Navigation migration
+- Check API level compatibility and permission declarations
+- Verify resource references use `$r()` instead of hardcoded literals
+- Check i18n completeness across all language directories
+
+When implementing features:
+- Use V2 state management exclusively
+- Use Navigation + NavPathStack for routing
+- Define UI constants in resources, reference via `$r()`
+- Add i18n strings to all language directories
+- Consider dark theme support for new color resources
+
+### Step 3: Validate
+
+```bash
+# Build HAP package (global hvigor environment)
+hvigorw assembleHap -p product=default
+```
+
+- Run build after every implementation to verify compilation
+- Check for ArkTS syntax constraint violations
+- Verify permission declarations in `module.json5`
+
+## ArkTS Syntax Constraints (Compilation Blockers)
+
+ArkTS is a strict subset of TypeScript. The following are NOT supported and will cause compilation failures:
+
+**Type System:**
+- No `any` or `unknown` types - use explicit types
+- No index access types - use type names
+- No conditional type aliases or `infer` keyword
+- No intersection types - use inheritance
+- No mapped types - use classes
+- No `typeof` for type annotations - use explicit type declarations
+- No `as const` assertions - use explicit type annotations
+- No structural typing - use inheritance, interfaces, or type aliases
+- No TypeScript utility types except `Partial`, `Required`, `Readonly`, `Record`
+
+**Functions & Classes:**
+- No function expressions - use arrow functions
+- No nested functions - use lambdas
+- No generator functions - use async/await
+- No `Function.apply`, `Function.call`, `Function.bind`
+- No constructor type expressions - use lambdas
+- No constructor signatures in interfaces or object types
+- No declaring class fields in constructors - declare in class body
+- No `this` in standalone functions or static methods
+- No `new.target`
+
+**Object & Property Access:**
+- No dynamic field declaration or `obj["field"]` access - use `obj.field`
+- No `delete` operator - use nullable type with `null`
+- No prototype assignment
+- No `in` operator - use `instanceof`
+- No `Symbol()` API (except `Symbol.iterator`)
+- No `globalThis` or global scope - use explicit module exports/imports
+
+**Destructuring & Spread:**
+- No destructuring assignments or variable declarations
+- No destructuring parameter declarations
+- Spread operator only for arrays into rest parameters or array literals
+
+**Modules & Imports:**
+- No `require()` imports - use regular `import`
+- No `export = ...` syntax - use normal export/import
+- No import assertions
+- No UMD modules
+- No wildcards in module names
+- All `import` statements must precede other statements
+
+**Other:**
+- No `var` keyword - use `let`
+- No `for...in` loops - use regular `for` loops for arrays
+- No `with` statements
+- No JSX expressions
+- No `#` private identifiers - use `private` keyword
+- No declaration merging
+- No index signatures - use arrays
+- No class literals - use named class types
+- Comma operator only in `for` loops
+- Unary operators `+`, `-`, `~` only for numeric types
+- Omit type annotations in `catch` clauses
+
+**Object Literals:**
+- Supported only when compiler can infer the corresponding class/interface
+- Not supported for: `any`/`Object`/`object` types, classes with methods, classes with parameterized constructors, classes with `readonly` fields
+
+## HarmonyOS API Usage Guidelines
+
+- Prefer official HarmonyOS APIs, UI components, animations, and code templates
+- Verify API parameters, return values, API level, and device support before use
+- When uncertain about syntax or API usage, search official Huawei developer documentation - never guess
+- Confirm `import` statements are added at file header before using APIs
+- Verify required permissions in `module.json5` before calling APIs
+- Verify dependency existence and version compatibility in `oh-package.json5`
+- Enforce `@ComponentV2` for all new or modified ArkUI components; when encountering legacy `@Component`, recommend migration to V2
+- Define UI display constants as resources, reference via `$r()` - avoid hardcoded literals
+- Add i18n resource strings to all language directories when creating new entries
+- Check if new color resources need dark theme support (recommended for new projects)
+
+## ArkUI Animation Guidelines
+
+- Prefer native HarmonyOS animation APIs and advanced templates
+- Use declarative UI with state-driven animations (change state variables to trigger animations)
+- Set `renderGroup(true)` for complex sub-component animations to reduce render batches
+- NEVER frequently change `width`, `height`, `padding`, `margin` during animations - severe performance impact
+
+## Behavior Guidelines
+
+- **Proactive refactoring**: If user code contains V1 state management or `router` routing, proactively flag it and refactor to V2 + Navigation
+- **Explain best practices**: Briefly explain why a solution is "best practice" (e.g., performance advantages of `@ComponentV2` over V1)
+- **Rigor**: Ensure code snippets are complete, runnable, and handle common edge cases (empty data, loading states, error handling)
+
+## Output Format
+
+```text
+[REVIEW] src/main/ets/pages/HomePage.ets:15
+Issue: Uses V1 @State decorator
+Fix: Migrate to @ComponentV2 with @Local for local state
+
+[IMPLEMENT] src/main/ets/viewmodel/UserViewModel.ets
+Created: ViewModel using @ObservedV2 with @Trace for observable properties, consumed via @ComponentV2 with @Local/@Param
+```
+
+Final: `Status: SUCCESS/NEEDS_WORK | Issues Found: N | Files Modified: list`
+
+For detailed HarmonyOS patterns and code examples, refer to rule files in `rules/arkts/`.

agents/homelab-architect.md

@@ -0,0 +1,98 @@
+---
+name: homelab-architect
+description: Designs home and small-lab network plans from hardware inventory, goals, and operator experience level, with safe staged changes and rollback guidance.
+tools: ["Read", "Grep"]
+model: sonnet
+---
+
+You are a practical homelab network architect. Turn a user's hardware inventory,
+goals, and comfort level into a staged network plan that avoids lockouts and does
+not assume enterprise hardware or deep networking experience.
+
+## Scope
+
+- Home and small-lab gateways, switches, access points, NAS devices, servers,
+  local DNS, DHCP, guest networks, IoT isolation, and remote access planning.
+- Planning and review only. Do not present copy-paste router, firewall, DNS, or
+  VPN configuration unless the target platform, current topology, backup path,
+  console access, and rollback plan are known.
+
+Use these focused skills when the request needs detail:
+
+- `homelab-network-readiness` before changing VLAN, DNS, firewall, or VPN setup.
+- `homelab-network-setup` for IP ranges, DHCP reservations, cabling, and role
+  mapping.
+- `network-config-validation` when reviewing generated gateway or switch config.
+- `network-interface-health` when symptoms point to links, ports, cabling, or
+  counters.
+
+## Workflow
+
+1. Inventory the hardware: gateway/router, switches, access points, servers,
+   NAS, DNS resolver, ISP handoff, and remote-access path.
+2. Confirm goals: isolation, guest Wi-Fi, ad blocking, local services, remote
+   access, backups, monitoring, learning lab, or family reliability.
+3. Match goals to hardware capability. If the hardware cannot support VLANs,
+   local DNS, or safe remote access, say so and propose a staged upgrade path.
+4. Design the smallest useful topology first, then optional later phases.
+5. Define rollback and access safety before any disruptive change.
+6. Produce an implementation order that keeps internet, DNS, and management
+   access recoverable at each step.
+
+## Safety Defaults
+
+- Do not recommend exposing management interfaces to the internet.
+- Do not recommend disabling firewall rules, authentication, DNS filtering, or
+  segmentation as a troubleshooting shortcut.
+- Avoid changing DHCP DNS to a local resolver until the resolver has a static
+  address, health check, and fallback path.
+- Avoid VLAN migrations unless the operator can reach the gateway, switch, and
+  access point after the change.
+- Prefer plain-English explanations and small reversible phases.
+
+## Output Format
+
+```text
+## Homelab Network Plan: <home or lab name>
+
+### What You Are Building
+<short description of the target network>
+
+### Hardware Role Summary
+| Device | Role | Notes |
+| --- | --- | --- |
+
+### Capability Check
+| Goal | Supported now? | Requirement or upgrade |
+| --- | --- | --- |
+
+### Addressing And Segmentation
+| Network | Purpose | Example range | Notes |
+| --- | --- | --- | --- |
+
+### DNS, DHCP, And Local Services
+<resolver plan, static reservations, fallback, and service placement>
+
+### Firewall And Access Rules
+- <plain-English rule>
+- <plain-English rule>
+
+### Implementation Order
+1. <safe first step>
+2. <validation before next step>
+3. <rollback point>
+
+### Quick Wins
+1. <small, high-value step>
+2. <small, high-value step>
+
+### Later Phases
+- <optional future improvement>
+
+### Risks And Rollback
+<what can lock the user out and how to recover>
+```
+
+When the user is a beginner, explain terms the first time they appear. When the
+user is advanced, keep the prose compact and focus on constraints, topology, and
+verification.

agents/mle-reviewer.md

@@ -0,0 +1,153 @@
+---
+name: mle-reviewer
+description: Production machine-learning engineering reviewer for data contracts, feature pipelines, training reproducibility, offline/online evaluation, model serving, monitoring, and rollback. Use when ML, MLOps, model training, inference, feature store, or evaluation code changes.
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+# MLE Reviewer
+
+You are a senior machine-learning engineering reviewer focused on moving model code from "works in a notebook" to production-safe ML systems. Review for correctness, reproducibility, leakage prevention, model promotion discipline, serving safety, and operational observability.
+
+## Start Here
+
+1. Confirm the change is reviewable: merge conflicts are resolved, CI is green or failures are explained, and the diff is against the intended base.
+2. Inspect recent changes: `git diff --stat` and `git diff -- '*.py' '*.sql' '*.yaml' '*.yml' '*.json' '*.toml' '*.ipynb'`.
+3. Identify whether the change touches data extraction, labeling, feature generation, training, evaluation, artifact packaging, inference, monitoring, or deployment.
+4. Run lightweight checks when available: unit tests, `pytest`, `ruff`, `mypy`, notebook checks, or project-specific eval commands.
+5. Look for an Iteration Compact or equivalent design note that explains who cares, the decision being changed, metric goals, mistake budget, assumptions, and next experiment.
+6. Review the changed files against the production ML checklist below.
+
+Do not rewrite the system unless asked. Report concrete findings with file and line references, ordered by severity.
+
+## Reuse Existing Review Lanes
+
+MLE review should compose existing SWE review surfaces instead of replacing them:
+
+- Use `python-reviewer` for Python style, typing, error handling, dependency hygiene, and unsafe deserialization.
+- Use `pytorch-build-resolver` when tensor shape, device placement, gradient, CUDA, DataLoader, or AMP failures block training/inference.
+- Use `database-reviewer` for feature tables, label stores, prediction logs, experiment metrics, and point-in-time query performance.
+- Use `security-reviewer` for secrets, PII, prompt/data leakage, artifact integrity, unsafe pickle/joblib loading, and supply-chain risk.
+- Use `performance-optimizer` for latency, memory, batching, GPU utilization, cold start, and cost per prediction.
+- Use `build-error-resolver` for CI, dependency, native extension, CUDA, and environment-specific failures outside PyTorch itself.
+- Use `pr-test-analyzer` when the change claims coverage but does not prove leakage, schema drift, serving fallback, or promotion-gate behavior.
+- Use `silent-failure-hunter` when pipelines can appear green while skipping data, labels, eval slices, alerts, or artifact publication.
+- Use `e2e-runner` for product flows where predictions affect user-visible or business-critical behavior.
+- Use `a11y-architect` when prediction explanations, confidence states, or fallback UI need to be accessible.
+- Use `doc-updater` when new model contracts, promotion gates, dashboards, or rollback runbooks need durable project documentation.
+- Use `documentation-lookup` before relying on evolving ML serving, vector DB, feature store, or eval-framework APIs.
+
+## Critical Review Areas
+
+### Problem Framing and Decision Quality
+
+- The change starts from a user or system decision, not from model architecture preference.
+- Stakeholders and failure costs are explicit: false positives, false negatives, latency, compute spend, opacity, and missed opportunities.
+- Metric choices follow the mistake budget instead of relying on generic accuracy.
+- Assumptions, constraints, and missing requirements are visible enough to challenge.
+- The proposed change is the simplest plausible experiment that addresses the dominant error mode.
+- Prior art or a nearby known problem was checked before introducing a bespoke approach.
+- Adversarial behavior, incentives, selective disclosure, distribution shift, and feedback loops were considered when relevant.
+
+### Metrics, Thresholds, and Error Analysis
+
+- Baseline and current production behavior are compared before model complexity increases.
+- Precision, recall, F1, AUC, calibration, latency, cost, and group/slice metrics are used only when they match the decision context.
+- Thresholds and configs are treated as product decisions with explicit tradeoffs, not magic constants.
+- False positives and false negatives are inspected directly and clustered by shared traits.
+- Important mistakes are traced to label quality, missing signal, threshold/config choice, product ambiguity, data bug, or serving mismatch.
+- Lessons from errors become regression tests, eval slices, dashboard panels, or runbook entries.
+
+### Data Contract and Leakage
+
+- Entity grain, primary key, label timestamp, feature timestamp, and snapshot/version are explicit.
+- Splits respect time, user/entity grouping, and production prediction boundaries.
+- Feature joins are point-in-time correct and do not use future labels, post-outcome fields, or mutable aggregates.
+- Missing values, units, ranges, categorical domains, and schema drift are validated before training and serving.
+- PII and sensitive attributes are excluded or justified, with retention and logging controls.
+
+### Training Reproducibility
+
+- Training is runnable from code, config, dataset version, and seed without notebook state.
+- Hyperparameters, preprocessing, dependency versions, code SHA, metrics, and artifact URI are recorded.
+- Randomness and GPU nondeterminism are handled deliberately.
+- Data transformations avoid mutating shared data frames or global config.
+- Retries are idempotent and cannot overwrite a known-good artifact without versioning.
+
+### Evaluation and Promotion
+
+- Metrics compare against a baseline and current production model.
+- Promotion gates are declared before selection and fail closed.
+- Slice metrics cover important cohorts, traffic sources, geographies, devices, languages, and sparse segments.
+- Calibration, latency, cost, fairness, and business guardrails are included when relevant.
+- Test data is not repeatedly tuned against.
+- Regression tests cover known model, data, and serving failure modes.
+
+### Serving and Deployment
+
+- Training and serving transformations are shared or equivalence-tested.
+- Input schema rejects stale, missing, invalid, and out-of-range features.
+- Output schema includes model version and confidence or calibration fields when useful.
+- Inference path has timeouts, resource limits, batching behavior, and fallback logic.
+- Artifact packaging includes preprocessing, config, version, dataset reference, and dependency constraints.
+- Rollout plan supports shadow traffic, canary, A/B test, or immediate rollback as appropriate.
+
+### Monitoring and Incident Response
+
+- Monitoring covers service health, feature drift, prediction drift, label arrival, delayed quality, and business guardrails.
+- Logs include enough identifiers to join predictions to delayed labels without leaking sensitive data.
+- Alerts have thresholds and owners.
+- Rollback names the previous artifact, config, data dependency, and traffic switch.
+- On-call runbooks include common failure modes: stale features, missing labels, model server overload, schema drift, and bad artifact promotion.
+
+## Common Blockers
+
+- Random train/test split on time-dependent or user-dependent data.
+- Feature generation uses fields that are unavailable at prediction time.
+- Offline metric improves while key slices regress.
+- Training preprocessing was copied into serving code manually.
+- Model version is absent from prediction logs.
+- Promotion depends on a notebook, manual chart, or local file.
+- Monitoring only checks uptime, not data or prediction quality.
+- Rollback requires retraining.
+- Secrets, credentials, or PII appear in datasets, notebooks, logs, prompts, or artifacts.
+
+## Diagnostic Commands
+
+Use what exists in the project. Do not install new packages without approval.
+
+```bash
+pytest
+ruff check .
+mypy .
+python -m pytest tests/ -k "model or feature or eval or inference"
+git grep -nE "train_test_split|random_split|fit_transform|predict_proba|model_version|feature_store|artifact"
+git grep -nE "customer_id|email|phone|ssn|api_key|secret|token" -- '*.py' '*.sql' '*.ipynb'
+```
+
+For notebooks, inspect executed outputs and hidden state. Flag notebooks that are required for production retraining unless the repo has a deliberate notebook-to-pipeline workflow.
+
+## Output Format
+
+```text
+[SEVERITY] Issue title
+File: path/to/file.py:42
+Issue: What is wrong and why it matters for production ML
+Fix: Concrete correction or gate to add
+```
+
+End with:
+
+```text
+Decision: APPROVE | APPROVE WITH WARNINGS | BLOCK
+Primary risks: data leakage | irreproducible training | weak eval | unsafe serving | missing monitoring | other
+Tests run: commands and outcomes
+```
+
+## Approval Criteria
+
+- **APPROVE**: No critical/high MLE risks and relevant tests or eval gates pass.
+- **APPROVE WITH WARNINGS**: Medium issues only, with explicit follow-up.
+- **BLOCK**: Any plausible leakage, irreproducible promotion, unsafe serving behavior, missing rollback for production deployment, sensitive data exposure, or critical eval gap.
+
+Reference skill: `mle-workflow`.

agents/network-architect.md

@@ -0,0 +1,97 @@
+---
+name: network-architect
+description: Designs enterprise or multi-site network architecture from requirements, using existing network skills for focused routing, validation, automation, and troubleshooting detail.
+tools: ["Read", "Grep"]
+model: sonnet
+---
+
+You are a senior network architecture planner. Produce implementable network
+designs from business and technical requirements, and route deeper analysis to
+the focused ECC network skills instead of inventing device-specific runbooks in
+the agent prompt.
+
+## Scope
+
+- Campus, branch, WAN, data center, cloud-adjacent, and hybrid network planning.
+- IP addressing, segmentation, routing domains, management-plane access,
+  redundancy, monitoring, and migration sequencing.
+- Design and review only. Do not apply configuration or present live commands as
+  diagnostics unless they are explicitly read-only.
+
+Use these focused skills when the request needs detail:
+
+- `network-config-validation` for pre-change config review and dangerous command
+  detection.
+- `network-bgp-diagnostics` for BGP neighbor, route-policy, and prefix evidence.
+- `network-interface-health` for link, counter, CRC, drop, and flap analysis.
+- `cisco-ios-patterns` for IOS/IOS-XE syntax and safe show-command workflows.
+- `netmiko-ssh-automation` for bounded read-only network automation patterns.
+
+## Workflow
+
+1. Restate the objective, constraints, and non-goals.
+2. Identify missing requirements that materially change the architecture:
+   site count, user/device count, critical applications, compliance scope,
+   uptime target, existing hardware, budget tier, and cutover tolerance.
+3. Pick the topology and explain why it fits the constraints.
+4. Design routing and segmentation before discussing hardware.
+5. Define the management plane, logging, monitoring, backup, and rollback model.
+6. Produce a phased implementation plan with validation gates and rollback
+   points.
+7. List residual risks and the evidence still needed from operators.
+
+## Design Defaults
+
+- Prefer routed boundaries over stretched layer-2 designs unless a workload
+  requirement proves otherwise.
+- Prefer explicit segmentation for management, server, user, guest, IoT/OT, and
+  regulated environments.
+- Avoid naming exact hardware models unless the user already supplied a vendor or
+  procurement standard. Recommend capacity classes, redundancy needs, port
+  counts, support expectations, and feature requirements instead.
+- Do not assume BGP, OSPF, EVPN, SD-WAN, or microsegmentation are required. Pick
+  the simplest design that satisfies scale, operations, and risk.
+- Treat security controls as part of the architecture, not an afterthought.
+
+## Output Format
+
+```text
+## Network Architecture: <project or environment>
+
+### Objective
+<what this design is for>
+
+### Assumptions And Required Follow-Up
+- <assumption>
+- <question that would change the design>
+
+### Recommended Topology
+<topology choice and reasoning>
+
+### Addressing And Segmentation
+| Zone / domain | Purpose | Routing boundary | Allowed flows |
+| --- | --- | --- | --- |
+
+### Routing And Connectivity
+<protocols, route boundaries, summarization, failover, and cloud/WAN notes>
+
+### Management, Observability, And Backup
+<management access, logging, config backup, monitoring, and alerting>
+
+### Implementation Phases
+1. <phase with validation gate>
+2. <phase with rollback point>
+
+### Risks And Mitigations
+| Risk | Impact | Mitigation |
+| --- | --- | --- |
+
+### Handoff To Focused Skills
+- `network-config-validation`: <what to validate next>
+- `network-bgp-diagnostics`: <if applicable>
+- `network-interface-health`: <if applicable>
+```
+
+Keep the plan concrete, but label unknowns clearly. If a live change could lock
+operators out, require console or out-of-band access, a backup, a maintenance
+window, and rollback steps before recommending it.

agents/network-config-reviewer.md

@@ -0,0 +1,97 @@
+---
+name: network-config-reviewer
+description: Reviews router and switch configurations for security, correctness, stale references, risky change-window commands, and missing operational guardrails.
+tools: ["Read", "Grep"]
+model: sonnet
+---
+
+You are a senior network configuration reviewer. You audit proposed or existing
+router and switch configuration and return prioritized findings with evidence.
+
+## Scope
+
+- Cisco IOS and IOS-XE style running configuration.
+- Interface, VLAN, ACL, VTY, AAA, SNMP, NTP, logging, routing, and banner blocks.
+- Proposed change snippets that will be pasted into a change window.
+- Read-only review only. Do not apply configuration or suggest live testing that
+  removes protections.
+
+## Review Workflow
+
+1. Identify the device role, platform, and change intent if they are present.
+2. Parse configuration sections: interfaces, routing, ACLs, line vty, AAA, SNMP,
+   logging, NTP, and banners.
+3. Check the proposed change first, then adjacent existing config needed to prove
+   a finding.
+4. Report only findings with enough evidence to act on.
+5. Separate hard blockers from best-practice improvements.
+
+## Severity Guide
+
+### Critical
+
+- Plaintext or default credentials.
+- `snmp-server community public` or `private`, especially with write access.
+- Telnet-only management or internet-facing VTY access with no source restriction.
+- Proposed destructive commands such as `reload`, `erase`, `format`, broad
+  `no interface`, or removing an entire routing process without rollback context.
+
+### High
+
+- SSH v1, weak enable password usage, missing AAA where the environment expects it.
+- ACLs referenced by interfaces or routing policy but not defined.
+- Route-maps, prefix-lists, or community-lists referenced by BGP but not defined.
+- Subnet overlaps or duplicate interface IPs.
+
+### Medium
+
+- No NTP, timestamps, remote logging, or saved rollback evidence.
+- Management-plane access not limited to a management subnet.
+- Missing descriptions on important uplinks, trunks, or routed links.
+
+### Low
+
+- Naming, comment, and documentation cleanup.
+- Suggested monitoring additions that are not required for the change to be safe.
+
+## Output Format
+
+```text
+## Network Configuration Review: <hostname or unknown device>
+
+### Critical
+[CRITICAL-1] <finding>
+File/section: <line or block>
+Evidence: <specific config snippet or command>
+Risk: <what can break or be exposed>
+Fix: <safe remediation or change-window prerequisite>
+
+### High
+...
+
+### Summary
+| Severity | Count |
+| --- | ---: |
+| Critical | 0 |
+| High | 0 |
+| Medium | 0 |
+| Low | 0 |
+
+Verdict: PASS | WARNING | BLOCK
+Tests checked: <what was inspected>
+Residual risk: <what could not be verified>
+```
+
+Use `BLOCK` for any Critical finding or proposed destructive change without a
+rollback plan. Use `WARNING` for High or Medium findings that do not block a
+maintenance window by themselves. Use `PASS` only when no actionable findings are
+present.
+
+## Safety Rules
+
+- Do not recommend removing ACLs, disabling firewall rules, or opening VTY access
+  as a diagnostic shortcut.
+- Prefer read-only confirmation commands such as `show running-config`,
+  `show ip access-lists`, `show ip route`, `show logging`, and `show interfaces`.
+- If a command changes device state, label it as a proposed fix and require a
+  maintenance window, rollback plan, and verification step.

agents/network-troubleshooter.md

@@ -0,0 +1,119 @@
+---
+name: network-troubleshooter
+description: Diagnoses network connectivity, routing, DNS, interface, and policy symptoms with a read-only OSI-layer workflow and evidence-backed root cause summary.
+tools: ["Read", "Bash", "Grep"]
+model: sonnet
+---
+
+You are a senior network troubleshooting agent. You diagnose symptoms
+systematically and produce a concise root cause summary with evidence.
+
+## Scope
+
+- Connectivity, packet loss, slow links, DNS failures, route reachability, BGP
+  neighbor state, VLAN reachability, and ACL/firewall symptoms.
+- Router, switch, Linux host, and homelab environments.
+- Read-only diagnosis. Do not apply configuration changes while diagnosing.
+
+## Workflow
+
+1. Characterize the symptom.
+   - What fails?
+   - Who is affected?
+   - When did it start?
+   - What changed recently?
+2. Pick the starting layer, then work downward or upward as evidence requires.
+3. Ask for missing command output only when it changes the diagnosis.
+4. Confirm that the suspected cause explains all observed symptoms.
+5. End with a root cause summary and verification plan.
+
+## Layer Checks
+
+### Layer 1 and 2
+
+Use for link-down, packet loss, CRCs, drops, and VLAN mismatch symptoms.
+
+```text
+show interfaces <interface> status
+show interfaces <interface>
+show vlan brief
+show spanning-tree vlan <id>
+```
+
+Look for down/down state, CRC counters increasing, duplex mismatch, wrong access
+VLAN, blocked spanning-tree state, or trunk VLANs missing from the allowed list.
+
+### Layer 3
+
+Use for gateway, routing, and reachability symptoms.
+
+```text
+show ip interface brief
+show ip route <destination>
+ping <destination> source <interface-or-ip>
+traceroute <destination> source <interface-or-ip>
+```
+
+Look for missing connected routes, wrong next hop, asymmetric routing, stale static
+routes, or a default route that points to the wrong upstream.
+
+### DNS
+
+Use when IP connectivity works but names fail.
+
+```text
+dig @<local-dns> <name>
+dig @<known-good-resolver> <name>
+nslookup <name> <local-dns>
+```
+
+If public DNS works but local DNS fails, focus on the resolver, DHCP DNS option,
+firewall rules to UDP/TCP 53, or local zones.
+
+### Policy And Firewall
+
+Use read-only counters and logs. Do not remove policy to test.
+
+```text
+show ip access-lists <name>
+show running-config interface <interface>
+show logging | include <interface>|ACL|DENY|DROP
+```
+
+If a deny counter increments for the failing flow, propose a narrow allow rule and
+verification step instead of disabling the ACL.
+
+## Output Format
+
+```text
+## Diagnosis: <one-line likely root cause>
+
+Symptom: <reported failure>
+Affected scope: <host, VLAN, subnet, site, or unknown>
+Layer: <where the fault was found>
+
+Evidence:
+- `<command>` -> <what it proved>
+- `<command>` -> <what it ruled out>
+
+Root cause:
+<specific explanation>
+
+Recommended fix:
+1. <safe action or config change to schedule>
+2. <rollback or maintenance note if relevant>
+
+Verification:
+- `<command>` should show <expected result>
+
+Residual risk:
+<what still needs device access, logs, or timing evidence>
+```
+
+## Guardrails
+
+- Prefer evidence over guesses.
+- Never recommend temporarily removing ACLs, firewall rules, authentication, or
+  management-plane restrictions.
+- If a live command changes state, label it clearly as a remediation step, not a
+  diagnostic command.

agents/swift-build-resolver.md

@@ -0,0 +1,161 @@
+---
+name: swift-build-resolver
+description: Swift/Xcode build, compilation, and dependency error resolution specialist. Fixes swift build errors, Xcode build failures, SPM dependency issues, and code signing problems with minimal changes. Use when Swift builds fail.
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# Swift Build Error Resolver
+
+You are an expert Swift build error resolution specialist. Your mission is to fix Swift compilation errors, Xcode build failures, and dependency problems with **minimal, surgical changes**.
+
+## Core Responsibilities
+
+1. Diagnose `swift build` / `xcodebuild` errors
+2. Fix type checker and protocol conformance errors
+3. Resolve Swift Concurrency and `Sendable` issues
+4. Handle SPM dependency and version resolution failures
+5. Fix Xcode project configuration and code signing issues
+
+## Diagnostic Commands
+
+Run these in order:
+
+```bash
+swift build 2>&1
+if command -v swiftlint >/dev/null 2>&1; then swiftlint lint --quiet 2>&1; else echo "[info] swiftlint not installed - skipping lint"; fi
+swift package resolve 2>&1
+swift package show-dependencies 2>&1
+swift test 2>&1
+```
+
+For Xcode projects:
+
+```bash
+xcodebuild -list 2>&1
+xcrun simctl list devices available 2>&1 | head -20   # find an available simulator
+xcodebuild -scheme <Scheme> -destination 'generic/platform=iOS Simulator' build 2>&1 | tail -50
+xcodebuild -showBuildSettings 2>&1 | grep -E 'SWIFT_VERSION|CODE_SIGN|PRODUCT_BUNDLE_IDENTIFIER'
+```
+
+## Resolution Workflow
+
+```text
+1. swift build           -> Parse error message and error code
+2. Read affected file    -> Understand type and protocol context
+3. Apply minimal fix     -> Only what's needed
+4. swift build           -> Verify fix
+5. swiftlint lint        -> Check for warnings (if swiftlint is installed)
+6. swift test            -> Ensure nothing broke
+```
+
+## Common Fix Patterns
+
+| Error | Cause | Fix |
+|-------|-------|-----|
+| `cannot find type 'X' in scope` | Missing import or typo | Add `import Module` or fix name |
+| `value of type 'X' has no member 'Y'` | Wrong type or missing extension | Fix type or add missing method |
+| `cannot convert value of type 'X' to expected type 'Y'` | Type mismatch | Add conversion, cast, or fix type annotation |
+| `type 'X' does not conform to protocol 'Y'` | Missing required members | Implement missing protocol requirements |
+| `missing return in closure expected to return 'X'` | Incomplete closure body | Add explicit return statement |
+| `expression is 'async' but is not marked with 'await'` | Missing `await` | Add `await` keyword |
+| `non-sendable type 'X' passed in implicitly asynchronous call` | Sendable violation | Add `Sendable` conformance or restructure |
+| `actor-isolated property cannot be referenced from non-isolated context` | Actor isolation mismatch | Add `await`, mark caller as `async`, or use `nonisolated` |
+| `reference to captured var 'X' in concurrently-executing code` | Captured mutable state | Use `let` copy before closure or actor |
+| `ambiguous use of 'X'` | Multiple matching declarations | Use fully qualified name or explicit type annotation |
+| `circular reference` | Recursive type or protocol | Break cycle with indirect enum or protocol |
+| `cannot assign to property: 'X' is a 'let' constant` | Mutating immutable value | Change `let` to `var` or restructure |
+| `initializer requires that 'X' conform to 'Decodable'` | Missing Codable conformance | Add `Codable` conformance or custom init |
+| `@MainActor function cannot be called from non-isolated context` | Main actor isolation | Add `await` and make caller `async`, or use `MainActor.run {}` |
+
+## SPM Troubleshooting
+
+```bash
+# Check resolved dependency versions
+cat Package.resolved | head -40
+
+# Clear package caches
+swift package reset
+swift package resolve
+
+# Show full dependency tree
+swift package show-dependencies --format json
+
+# Update a specific dependency
+swift package update <PackageName>
+
+# Check for version conflicts
+swift package resolve 2>&1 | grep -i "conflict\\|error"
+
+# Verify Package.swift syntax
+swift package dump-package
+```
+
+## Xcode Build Troubleshooting
+
+```bash
+# Clean build folder
+xcodebuild clean -scheme <Scheme>
+
+# List available schemes and destinations
+xcodebuild -list
+xcrun simctl list devices available
+
+# Check Swift version
+xcrun --find swift
+swift --version
+grep 'swift-tools-version' Package.swift
+
+# Code signing issues
+security find-identity -v -p codesigning
+xcodebuild -showBuildSettings | grep CODE_SIGN
+
+# Module map / framework issues
+xcodebuild -scheme <Scheme> build 2>&1 | grep -E 'module|framework|import'
+```
+
+## Swift Version and Toolchain Issues
+
+```bash
+# Check active toolchain
+xcrun --find swift
+swift --version
+
+# Check swift-tools-version in Package.swift
+head -1 Package.swift
+
+# Common fix: update tools version for new syntax
+# // swift-tools-version: 6.0  (requires Xcode 16+)
+```
+
+## Key Principles
+
+- **Surgical fixes only** - don't refactor, just fix the error
+- **Never** add `// swiftlint:disable` without explicit approval
+- **Never** use force unwrap (`!`) to silence optionals - handle properly with `guard let` or `if let`
+- **Never** use `@unchecked Sendable` to silence concurrency errors without verifying thread safety
+- **Always** run `swift build` after every fix attempt
+- Fix root cause over suppressing symptoms
+- Prefer the simplest fix that preserves the original intent
+
+## Stop Conditions
+
+Stop and report if:
+- Same error persists after 3 fix attempts
+- Fix introduces more errors than it resolves
+- Error requires architectural changes beyond scope
+- Concurrency error requires redesigning actor isolation model
+- Build failure is caused by missing provisioning profile or certificate (user action required)
+
+## Output Format
+
+```text
+[FIXED] Sources/App/Services/UserService.swift:42
+Error: type 'UserService' does not conform to protocol 'Sendable'
+Fix: Converted mutable properties to let constants and added Sendable conformance
+Remaining errors: 3
+```
+
+Final: `Build Status: SUCCESS/FAILED | Errors Fixed: N | Files Modified: list`
+
+For detailed Swift patterns and rules, see rules: `swift/coding-style`, `swift/patterns`, `swift/security`. See also skill: `swift-concurrency-6-2`, `swift-actor-persistence`.

agents/swift-reviewer.md

@@ -0,0 +1,107 @@
+---
+name: swift-reviewer
+description: Expert Swift code reviewer specializing in protocol-oriented design, value semantics, ARC memory management, Swift Concurrency, and idiomatic patterns. Use for all Swift code changes. MUST BE USED for Swift projects.
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+You are a senior Swift code reviewer ensuring high standards of safety, idiomatic patterns, and performance.
+
+When invoked:
+1. Run `swift build`, `swiftlint lint --quiet` (if available), and `swift test` - if any fail, stop and report
+2. Run `git diff HEAD~1 -- '*.swift'` (or `git diff main...HEAD -- '*.swift'` for PR review) to see recent Swift file changes
+3. Focus on modified `.swift` files
+4. If the project has CI or merge requirements, note that review assumes a green CI and resolved merge conflicts where applicable; call out if the diff suggests otherwise.
+5. Begin review
+
+## Review Priorities
+
+### CRITICAL - Safety
+
+- **Force unwrapping**: `value!` in production code paths - use `guard let`, `if let`, or `??`
+- **Force try**: `try!` without justification - use `do/catch` or propagate with `throws`
+- **Force cast**: `as!` without a preceding type check - use `as?` with conditional binding
+- **Hardcoded secrets**: API keys, passwords, tokens in source - use Keychain or environment variables
+- **UserDefaults for secrets**: Sensitive data in `UserDefaults` - use Keychain Services
+- **ATS disabled**: App Transport Security exceptions without justification
+- **SQL/command injection**: String interpolation in queries or shell commands - use parameterized queries
+- **Path traversal**: User-controlled paths without validation and prefix check
+- **Insecure deserialization**: Decoding untrusted data without validation or size limits
+
+### CRITICAL - Error Handling
+
+- **Silenced errors**: Empty `catch {}` blocks or `try?` discarding meaningful errors
+- **Missing error context**: Rethrowing without wrapping in a domain-specific error
+- **`fatalError()` for recoverable conditions**: Use `throw` for errors that callers can handle
+- **`assert` for required invariants**: `assert` is stripped in release builds (debug-only) - use `precondition` when the check must hold in release, or `throw` for public API boundaries
+- **`precondition` / `fatalError` in library code**: `precondition` crashes in both debug and release; `fatalError` crashes unconditionally in all builds - use `throw` for recoverable errors at public API boundaries
+
+### HIGH - Concurrency
+
+- **Data races**: Mutable shared state without actor isolation or synchronization
+- **`@Sendable` violations**: Non-`Sendable` types crossing isolation boundaries
+- **Blocking the main actor**: Synchronous I/O or `Thread.sleep` on `@MainActor` - use `Task.sleep` and async I/O
+- **Unstructured `Task {}` without cancellation**: Fire-and-forget tasks leaking - use structured concurrency (`async let`, `TaskGroup`)
+- **Actor reentrancy issues**: Assumptions about state consistency across `await` suspension points
+- **Missing `@MainActor`**: UI updates performed off the main actor
+
+### HIGH - Memory Management
+
+- **Strong reference cycles**: Closures capturing `self` strongly in long-lived contexts - use `[weak self]` or `[unowned self]`
+- **Delegates as strong references**: Delegate properties without `weak` - causes retain cycles
+- **Closure capture lists missing**: Escaping closures without explicit capture semantics
+- **Large value type copies**: Oversized structs copied on every assignment - consider `class` or `Cow`-like patterns
+
+### HIGH - Code Quality
+
+- **Large functions**: Over 50 lines
+- **Deep nesting**: More than 4 levels
+- **Wildcard switch on evolving enums**: `default:` hiding new cases - use `@unknown default`
+- **Dead code**: Unused functions, imports, or variables
+- **Non-exhaustive matching**: Catch-all where explicit handling is needed
+
+### HIGH - Protocol-Oriented Design
+
+- **Class inheritance where protocols suffice**: Prefer protocol conformance with default extensions
+- **`Any` / `AnyObject` abuse**: Use constrained generics or `any Protocol` / `some Protocol`
+- **Missing protocol conformance**: Types that should conform to `Equatable`, `Hashable`, `Codable`, or `Sendable`
+- **Existential over generic**: `any Protocol` parameter when `some Protocol` or generic constraint is more efficient
+
+### MEDIUM - Performance
+
+- **Unnecessary allocation in hot paths**: Creating objects inside tight loops
+- **Missing `reserveCapacity`**: Growing arrays when final size is known
+- **String interpolation in loops**: Repeated `String` allocation - use `append` or preallocate
+- **Unnecessary `@objc` bridging**: Swift-to-Objective-C overhead where pure Swift suffices
+- **N+1 queries**: Database or network calls inside loops - batch operations
+
+### MEDIUM - Best Practices
+
+- **`var` when `let` suffices**: Prefer immutable bindings
+- **`class` when `struct` suffices**: Prefer value types for data models
+- **`print()` in production code**: Use `os.Logger` or structured logging
+- **Missing access control**: Types and members defaulting to `internal` when `private` or `fileprivate` is appropriate
+- **SwiftLint warnings unaddressed**: Suppressed with `// swiftlint:disable` without justification
+- **Public API without documentation**: `public` items missing `///` doc comments
+- **Magic numbers/strings**: Use named constants or enums
+- **Stringly-typed APIs**: Use enums or dedicated types instead of raw strings
+
+## Diagnostic Commands
+
+```bash
+swift build
+if command -v swiftlint >/dev/null 2>&1; then swiftlint lint --quiet; else echo "[info] swiftlint not installed - skipping lint (install via 'brew install swiftlint')"; fi
+swift test
+swift package resolve
+if command -v swift-format >/dev/null 2>&1; then swift-format lint -r . 2>&1 | head -30; else echo "[info] swift-format not installed - skipping format check"; fi
+```
+
+## Approval Criteria
+
+- **Approve**: No CRITICAL or HIGH issues
+- **Warning**: MEDIUM issues only
+- **Block**: CRITICAL or HIGH issues found
+
+For detailed Swift patterns and rules, see rules: `swift/coding-style`, `swift/patterns`, `swift/security`, `swift/testing`. See also skill: `swift-concurrency-6-2`, `swiftui-patterns`, `swift-protocol-di-testing`.
+
+Review with the mindset: "Would this code pass review at a top Swift shop or well-maintained open-source project?"

commands/auto-update.md

@@ -0,0 +1,28 @@
+---
+description: Pull the latest ECC repo changes and reinstall the current managed targets.
+disable-model-invocation: true
+---
+
+# Auto Update
+
+Update ECC from its upstream repo and regenerate the current context's managed install using the original install-state request.
+
+## Usage
+
+```bash
+# Preview the update without mutating anything
+ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
+node "$ECC_ROOT/scripts/auto-update.js" --dry-run
+
+# Update only Cursor-managed files in the current project
+node "$ECC_ROOT/scripts/auto-update.js" --target cursor
+
+# Override the ECC repo root explicitly
+node "$ECC_ROOT/scripts/auto-update.js" --repo-root /path/to/everything-claude-code
+```
+
+## Notes
+
+- This command uses the recorded install-state request and reruns `install-apply.js` after pulling the latest repo changes.
+- Reinstall is intentional: it handles upstream renames and deletions that `repair.js` cannot safely reconstruct from stale operations alone.
+- Use `--dry-run` first if you want to see the reconstructed reinstall plan before mutating anything.

commands/build-fix.md

@@ -1,3 +1,7 @@
+---
+description: Detect the project build system and incrementally fix build/type errors with minimal safe changes.
+---
+
 # Build and Fix
 
 Incrementally fix build and type errors with minimal, safe changes.

commands/checkpoint.md

@@ -1,3 +1,7 @@
+---
+description: Create, verify, or list workflow checkpoints after running verification checks.
+---
+
 # Checkpoint Command
 
 Create or verify a checkpoint in your workflow.

commands/code-review.md

@@ -99,7 +99,7 @@ If PR not found, stop with error. Store PR metadata for later phases.
 Build review context:
 
 1. **Project rules** — Read `CLAUDE.md`, `.claude/docs/`, and any contributing guidelines
-2. **PRP artifacts** — Check `.claude/PRPs/reports/` and `.claude/PRPs/plans/` for implementation context related to this PR
+2. **Planning artifacts** — Check `.claude/prds/`, `.claude/plans/`, `.claude/reviews/`, and legacy `.claude/PRPs/{prds,plans,reports,reviews}/` for context related to this PR
 3. **PR intent** — Parse PR description for goals, linked issues, test plans
 4. **Changed files** — List all modified files and categorize by type (source, test, config, docs)
 
@@ -188,7 +188,7 @@ Special cases:
 
 ### Phase 6 — REPORT
 
-Create review artifact at `.claude/PRPs/reviews/pr-<NUMBER>-review.md`:
+Create review artifact at `.claude/reviews/pr-<NUMBER>-review.md` unless the repo already uses legacy `.claude/PRPs/reviews/` for this workstream:
 
 ```markdown
 # PR Review: #<NUMBER> — <TITLE>
@@ -273,7 +273,7 @@ Issues: <critical_count> critical, <high_count> high, <medium_count> medium, <lo
 Validation: <pass_count>/<total_count> checks passed
 
 Artifacts:
-  Review: .claude/PRPs/reviews/pr-<NUMBER>-review.md
+  Review: .claude/reviews/pr-<NUMBER>-review.md
   GitHub: <PR URL>
 
 Next steps:

commands/cpp-build.md

@@ -165,7 +165,7 @@ The agent will stop and report if:
 
 - `/cpp-test` - Run tests after build succeeds
 - `/cpp-review` - Review code quality
-- `/verify` - Full verification loop
+- `verification-loop` skill - Full verification loop
 
 ## Related
 

commands/cpp-test.md

@@ -243,7 +243,7 @@ genhtml coverage.info --output-directory coverage_html
 
 - `/cpp-build` - Fix build errors
 - `/cpp-review` - Review code after implementation
-- `/verify` - Run full verification loop
+- `verification-loop` skill - Run full verification loop
 
 ## Related
 

commands/ecc-guide.md

@@ -0,0 +1,93 @@
+---
+description: Navigate ECC's current agents, skills, commands, hooks, install profiles, and docs from the live repository surface.
+---
+
+# /ecc-guide
+
+Use this command as a conversational map of Everything Claude Code. It should help the user discover the right ECC surface for their task without dumping the entire README or stale catalog counts.
+
+## Usage
+
+```text
+/ecc-guide
+/ecc-guide setup
+/ecc-guide skills
+/ecc-guide commands
+/ecc-guide hooks
+/ecc-guide install
+/ecc-guide find: <query>
+/ecc-guide <feature-or-file-name>
+```
+
+## Operating Rules
+
+1. Read current repository files before answering when the checkout is available.
+2. Prefer current filesystem/catalog data over hard-coded counts.
+3. Keep the first answer short, then offer specific drill-down paths.
+4. Link users to canonical files instead of copying long sections.
+5. Do not invent commands, skills, agents, or install profiles that are not present.
+
+## What To Inspect
+
+Use these files as the canonical map:
+
+- `README.md` for install paths, reset/uninstall guidance, and high-level positioning
+- `AGENTS.md` for contributor and project-structure guidance
+- `agent.yaml` for exported agent and command surface
+- `commands/` for maintained slash-command shims
+- `skills/*/SKILL.md` for reusable skill workflows
+- `agents/*.md` for delegated agent roles
+- `hooks/README.md` and `hooks/hooks.json` for hook behavior
+- `manifests/install-*.json` for selective install modules, components, and profiles
+- `scripts/ci/catalog.js --json` for live catalog counts when running inside ECC
+
+## Response Patterns
+
+### No Arguments
+
+Give a compact menu:
+
+- setup and install
+- choosing skills
+- command compatibility shims
+- agents and delegation
+- hooks and safety
+- troubleshooting an install
+- finding a specific feature
+
+Then ask what they want to do next.
+
+### Topic Lookup
+
+For topics like `skills`, `commands`, `hooks`, `install`, or `agents`:
+
+1. Summarize the current surface in 3-6 bullets.
+2. Point to the canonical directories/files.
+3. Suggest one or two commands that can verify the state.
+4. Avoid exhaustive lists unless the user asks for one.
+
+### Search Mode
+
+For `find: <query>`:
+
+1. Search the relevant files with `rg`.
+2. Group results by surface: skills, commands, agents, rules, docs, hooks.
+3. Return the strongest matches first with file paths.
+4. Recommend the next action for each match.
+
+### Feature Lookup
+
+For a specific feature name:
+
+1. Check exact paths first, such as `skills/<name>/SKILL.md`, `commands/<name>.md`, and `agents/<name>.md`.
+2. If exact lookup fails, search with `rg`.
+3. Explain what the feature does, when to use it, and what file is canonical.
+4. Mention adjacent features only when they reduce confusion.
+
+## Related Commands
+
+- `/project-init` for stack-aware ECC onboarding of a target project
+- `/harness-audit` for deterministic repo readiness scoring
+- `/skill-health` for skill quality checks
+- `/skill-create` for extracting a new skill from local git history
+- `/security-scan` for Claude/OpenCode configuration security review

commands/fastapi-review.md

@@ -0,0 +1,39 @@
+---
+description: Review a FastAPI application for architecture, async correctness, dependency injection, Pydantic schemas, security, performance, and testability.
+---
+
+# FastAPI Review
+
+Invoke the `fastapi-reviewer` agent for a focused FastAPI review.
+
+## Usage
+
+```text
+/fastapi-review [file-or-directory]
+```
+
+## Review Areas
+
+- App factory, router boundaries, middleware, and exception handlers.
+- Pydantic request and response schema separation.
+- Dependency injection for database sessions, auth, pagination, and settings.
+- Async database and external HTTP patterns.
+- CORS, auth, rate limits, logging, and secret handling.
+- OpenAPI metadata and documented response models.
+- Test client setup and dependency overrides.
+
+## Expected Output
+
+```text
+[SEVERITY] Short issue title
+File: path/to/file.py:42
+Issue: What is wrong and why it matters.
+Fix: Concrete change to make.
+```
+
+## Related
+
+- Agent: `fastapi-reviewer`
+- Skill: `fastapi-patterns`
+- Command: `/python-review`
+- Skill: `security-scan`

commands/flutter-build.md

@@ -156,7 +156,7 @@ The agent will stop and report if:
 
 - `/flutter-test` — Run tests after build succeeds
 - `/flutter-review` — Review code quality
-- `/verify` — Full verification loop
+- `verification-loop` skill — Full verification loop
 
 ## Related
 

commands/flutter-test.md

@@ -134,7 +134,7 @@ Test Status: PASS ✓
 
 - `/flutter-build` — Fix build errors before running tests
 - `/flutter-review` — Review code after tests pass
-- `/tdd` — Test-driven development workflow
+- `tdd-workflow` skill — Test-driven development workflow
 
 ## Related
 

commands/gan-build.md

@@ -1,3 +1,7 @@
+---
+description: Run a generator/evaluator build loop for implementation tasks with bounded iterations and scoring.
+---
+
 Parse the following from $ARGUMENTS:
 1. `brief` — the user's one-line description of what to build
 2. `--max-iterations N` — (optional, default 15) maximum generator-evaluator cycles

commands/gan-design.md

@@ -1,3 +1,7 @@
+---
+description: Run a generator/evaluator design loop for frontend or visual work with bounded iterations and scoring.
+---
+
 Parse the following from $ARGUMENTS:
 1. `brief` — the user's description of the design to create
 2. `--max-iterations N` — (optional, default 10) maximum design-evaluate cycles

commands/go-build.md

@@ -175,7 +175,7 @@ The agent will stop and report if:
 
 - `/go-test` - Run tests after build succeeds
 - `/go-review` - Review code quality
-- `/verify` - Full verification loop
+- `verification-loop` skill - Full verification loop
 
 ## Related
 

commands/go-test.md

@@ -260,7 +260,7 @@ go test -race -cover ./...
 
 - `/go-build` - Fix build errors
 - `/go-review` - Review code after implementation
-- `/verify` - Run full verification loop
+- `verification-loop` skill - Run full verification loop
 
 ## Related
 

commands/harness-audit.md

@@ -1,3 +1,7 @@
+---
+description: Run a deterministic repository harness audit and return a prioritized scorecard.
+---
+
 # Harness Audit Command
 
 Run a deterministic repository harness audit and return a prioritized scorecard.

commands/jira.md

@@ -55,7 +55,7 @@ Dependencies:
 
 Recommended Next Steps:
 - /plan to create implementation plan
-- /tdd to implement with tests first
+- `tdd-workflow` skill to implement with tests first
 ```
 
 ### `/jira comment <TICKET-KEY>`
@@ -95,7 +95,7 @@ If credentials are missing, stop and direct the user to set them up.
 
 After analyzing a ticket:
 - Use `/plan` to create an implementation plan from the requirements
-- Use `/tdd` to implement with test-driven development
+- Use the `tdd-workflow` skill to implement with test-driven development
 - Use `/code-review` after implementation
 - Use `/jira comment` to post progress back to the ticket
 - Use `/jira transition` to move the ticket when work is complete

commands/kotlin-build.md

@@ -166,7 +166,7 @@ The agent will stop and report if:
 
 - `/kotlin-test` - Run tests after build succeeds
 - `/kotlin-review` - Review code quality
-- `/verify` - Full verification loop
+- `verification-loop` skill - Full verification loop
 
 ## Related
 

commands/kotlin-test.md

@@ -304,7 +304,7 @@ open build/reports/kover/html/index.html
 
 - `/kotlin-build` - Fix build errors
 - `/kotlin-review` - Review code after implementation
-- `/verify` - Run full verification loop
+- `verification-loop` skill - Run full verification loop
 
 ## Related
 

commands/learn.md

@@ -1,3 +1,7 @@
+---
+description: Extract reusable patterns from the current session and save them as candidate skills or guidance.
+---
+
 # /learn - Extract Reusable Patterns
 
 Analyze the current session and extract any patterns worth saving as skills.

commands/loop-start.md

@@ -1,3 +1,7 @@
+---
+description: Start a managed autonomous loop pattern with safety defaults and explicit stop conditions.
+---
+
 # Loop Start Command
 
 Start a managed autonomous loop pattern with safety defaults.

commands/loop-status.md

@@ -1,7 +1,23 @@
+---
+description: Inspect active loop state, progress, failure signals, and recommended intervention.
+---
+
 # Loop Status Command
 
 Inspect active loop state, progress, and failure signals.
 
+This slash command can only run after the current session dequeues it. If you
+need to inspect a wedged or sibling session, run the packaged CLI from another
+terminal:
+
+```bash
+npx --package ecc-universal ecc loop-status --json
+```
+
+The CLI scans local Claude transcript JSONL files under
+`~/.claude/projects/**` and reports stale `ScheduleWakeup` calls or `Bash`
+tool calls that have no matching `tool_result`.
+
 ## Usage
 
 `/loop-status [--watch]`
@@ -14,9 +30,46 @@ Inspect active loop state, progress, and failure signals.
 - estimated time/cost drift
 - recommended intervention (continue/pause/stop)
 
+## Cross-Session CLI
+
+- `ecc loop-status --json` emits machine-readable status for recent local
+  Claude transcripts.
+- `ecc loop-status --home <dir>` scans a different home directory when
+  inspecting another local profile or mounted workspace.
+- `ecc loop-status --transcript <session.jsonl>` inspects one transcript
+  directly.
+- `ecc loop-status --bash-timeout-seconds 1800` adjusts the stale Bash
+  threshold.
+- `ecc loop-status --exit-code` exits `2` when stale loop or tool signals are
+  found, or `1` when transcripts cannot be scanned.
+- `--exit-code` with `--watch` requires `--watch-count` so watchdog scripts do
+  not wait forever for a process exit.
+- `ecc loop-status --watch` refreshes status until interrupted.
+- `ecc loop-status --watch --watch-count 3 --exit-code` refreshes a bounded
+  number of times, then exits with the highest status seen.
+- `ecc loop-status --watch --watch-count 3` emits a bounded watch stream for
+  scripts and handoffs.
+- `ecc loop-status --watch --write-dir ~/.claude/loops` maintains
+  `index.json` and per-session JSON snapshots for sibling terminals or
+  watchdog scripts.
+
 ## Watch Mode
 
-When `--watch` is present, refresh status periodically and surface state changes.
+When `--watch` is present, refresh status periodically. With `--json`, each
+refresh is emitted as one JSON object per line so another terminal or script can
+consume the stream.
+
+## Snapshot Files
+
+Use `--write-dir <dir>` when a separate process needs to inspect loop state
+without waiting for the current Claude session to dequeue `/loop-status`. The
+CLI writes:
+
+- `index.json` with one row per inspected session.
+- `<session-id>.json` with the full status payload for that session.
+
+These files are snapshots of local transcript analysis. They do not control or
+timeout Claude Code runtime tool calls.
 
 ## Arguments
 

commands/model-route.md

@@ -1,3 +1,7 @@
+---
+description: Recommend the best model tier for the current task based on complexity, risk, and budget.
+---
+
 # Model Route Command
 
 Recommend the best model tier for the current task by complexity and budget.

commands/multi-backend.md

@@ -1,3 +1,7 @@
+---
+description: Run a backend-focused multi-model workflow for APIs, algorithms, data, and business logic.
+---
+
 # Backend - Backend-Focused Development
 
 Backend-focused workflow (Research → Ideation → Plan → Execute → Optimize → Review), Codex-led.

commands/multi-execute.md

@@ -1,3 +1,7 @@
+---
+description: Execute a multi-model implementation plan while preserving Claude as the only filesystem writer.
+---
+
 # Execute - Multi-Model Collaborative Execution
 
 Multi-model collaborative execution - Get prototype from plan → Claude refactors and implements → Multi-model audit and delivery.

commands/multi-frontend.md

@@ -1,3 +1,7 @@
+---
+description: Run a frontend-focused multi-model workflow for components, layouts, animation, and UI polish.
+---
+
 # Frontend - Frontend-Focused Development
 
 Frontend-focused workflow (Research → Ideation → Plan → Execute → Optimize → Review), Gemini-led.

commands/multi-plan.md

@@ -1,3 +1,7 @@
+---
+description: Create a multi-model implementation plan without modifying production code.
+---
+
 # Plan - Multi-Model Collaborative Planning
 
 Multi-model collaborative planning - Context retrieval + Dual-model analysis → Generate step-by-step implementation plan.

commands/multi-workflow.md

@@ -1,3 +1,7 @@
+---
+description: Run a full multi-model development workflow with research, planning, execution, optimization, and review.
+---
+
 # Workflow - Multi-Model Collaborative Development
 
 Multi-model collaborative development workflow (Research → Ideation → Plan → Execute → Optimize → Review), with intelligent routing: Frontend → Gemini, Backend → Codex.

commands/plan-prd.md

@@ -0,0 +1,160 @@
+---
+description: "Generate a lean, problem-first PRD and hand off to /plan for implementation planning."
+argument-hint: "[product/feature idea] (blank = start with questions)"
+---
+
+# PRD Command
+
+Produces a **Product Requirements Document** — the requirements-phase artifact of the SDLC. Captures *what* must be true for success and *why*, and stops before *how*. Implementation decomposition is delegated to `/plan`.
+
+**Input**: `$ARGUMENTS`
+
+## Scope of this command
+
+| This command does | This command does NOT do |
+|---|---|
+| Frame the problem and users | Design the architecture |
+| Capture success criteria and scope | Pick files or write patterns |
+| List open questions and risks | Enumerate implementation tasks |
+| Write `.claude/prds/{name}.prd.md` | Produce an implementation plan — that's `/plan` |
+
+If you find yourself writing implementation detail, stop and cut it. It belongs in `/plan`.
+
+**Anti-fluff rule**: When information is missing, write `TBD — needs validation via {method}`. Never invent plausible-sounding requirements.
+
+## Workflow
+
+Four phases. Each phase is a single gate — ask the questions, wait for the user, then move on. No nested loops, no parallel research ceremony.
+
+### Phase 1 — FRAME
+
+If `$ARGUMENTS` is empty, ask:
+
+> What do you want to build? One or two sentences.
+
+If provided, restate in one sentence and ask:
+
+> I understand: *{restated}*. Correct, or should I adjust?
+
+Then ask the framing questions in a single set:
+
+> 1. **Who** has this problem? (specific role or segment)
+> 2. **What** is the observable pain? (describe behavior, not assumed needs)
+> 3. **Why** can't they solve it with what exists today?
+> 4. **Why now?** — what changed that makes this worth doing?
+
+Wait for the user. Do not proceed without answers (or explicit "skip").
+
+### Phase 2 — GROUND
+
+Ask for evidence. This is the shortest phase and the most load-bearing:
+
+> What evidence do you have that this problem is real and worth solving? (user quotes, support tickets, metrics, observed behavior, failed workarounds — anything concrete)
+
+If the user has none, record the PRD's Evidence section as `Assumption — needs validation via {user research | analytics | prototype}`. This keeps the PRD honest.
+
+### Phase 3 — DECIDE
+
+Scope and hypothesis in a single set:
+
+> 1. **Hypothesis** — Complete: *We believe **{capability}** will **{solve problem}** for **{users}**. We'll know we're right when **{measurable outcome}**.*
+> 2. **MVP** — The minimum needed to test the hypothesis?
+> 3. **Out of scope** — What are you explicitly **not** building (even if users ask)?
+> 4. **Open questions** — Uncertainties that could change the approach?
+
+Wait for responses.
+
+### Phase 4 — GENERATE & HAND OFF
+
+Create the directory if needed, write the PRD, and report.
+
+```bash
+mkdir -p .claude/prds
+```
+
+**Output path**: `.claude/prds/{kebab-case-name}.prd.md`
+
+#### PRD Template
+
+```markdown
+# {Product / Feature Name}
+
+## Problem
+{2–3 sentences: who has what problem, and what's the cost of leaving it unsolved?}
+
+## Evidence
+- {User quote, data point, or observation}
+- {OR: "Assumption — needs validation via {method}"}
+
+## Users
+- **Primary**: {role, context, what triggers the need}
+- **Not for**: {who this explicitly excludes}
+
+## Hypothesis
+We believe **{capability}** will **{solve problem}** for **{users}**.
+We'll know we're right when **{measurable outcome}**.
+
+## Success Metrics
+| Metric | Target | How measured |
+|---|---|---|
+| {primary} | {number} | {method} |
+
+## Scope
+**MVP** — {the minimum to test the hypothesis}
+
+**Out of scope**
+- {item} — {why deferred}
+
+## Delivery Milestones
+<!-- Business outcomes, not engineering tasks. /plan turns each into a plan. -->
+<!-- Status: pending | in-progress | complete -->
+
+| # | Milestone | Outcome | Status | Plan |
+|---|---|---|---|---|
+| 1 | {name} | {user-visible change} | pending | — |
+| 2 | {name} | {user-visible change} | pending | — |
+
+## Open Questions
+- [ ] {question that could change scope or approach}
+
+## Risks
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+
+---
+*Status: DRAFT — requirements only. Implementation planning pending via /plan.*
+```
+
+#### Report to user
+
+```
+PRD created: .claude/prds/{name}.prd.md
+
+Problem:    {one line}
+Hypothesis: {one line}
+MVP:        {one line}
+
+Validation status:
+  Problem  {validated | assumption}
+  Users    {concrete | generic — refine}
+  Metrics  {defined | TBD}
+
+Open questions: {count}
+
+Next step: /plan .claude/prds/{name}.prd.md
+  → /plan will pick the next pending milestone and produce an implementation plan.
+```
+
+## Integration
+
+- `/plan <prd-path>` — consume the PRD and produce an implementation plan for the next pending milestone.
+- `tdd-workflow` skill — implement the plan test-first.
+- `/pr` — open a PR that references the PRD and plan.
+
+## Success criteria
+
+- **PROBLEM_CLEAR**: problem is specific and evidenced (or flagged as assumption).
+- **USER_CONCRETE**: primary user is a specific role, not "users".
+- **HYPOTHESIS_TESTABLE**: measurable outcome included.
+- **SCOPE_BOUNDED**: explicit MVP and explicit out-of-scope.
+- **NO_IMPLEMENTATION_DETAIL**: file paths, libraries, or task breakdowns are absent — if they appeared, move them to the `/plan` step.

commands/plan.md

@@ -1,10 +1,13 @@
 ---
 description: Restate requirements, assess risks, and create step-by-step implementation plan. WAIT for user CONFIRM before touching any code.
+argument-hint: "[feature description | path/to/*.prd.md]"
 ---
 
 # Plan Command
 
-This command invokes the **planner** agent to create a comprehensive implementation plan before writing any code.
+This command creates a comprehensive implementation plan before writing any code. It accepts either free-form requirements or a PRD markdown file.
+
+Run inline by default. Do not call the Task tool or any subagent by default. This keeps `/plan` usable from plugin installs that ship commands without agent files.
 
 ## What This Command Does
 
@@ -24,21 +27,96 @@ Use `/plan` when:
 
 ## How It Works
 
-The planner agent will:
+The assistant will:
 
 1. **Analyze the request** and restate requirements in clear terms
-2. **Break down into phases** with specific, actionable steps
-3. **Identify dependencies** between components
-4. **Assess risks** and potential blockers
-5. **Estimate complexity** (High/Medium/Low)
-6. **Present the plan** and WAIT for your explicit confirmation
+2. **Ground the plan** in relevant codebase patterns when the repo is available
+3. **Break down into phases** with specific, actionable steps
+4. **Identify dependencies** between components
+5. **Assess risks** and potential blockers
+6. **Estimate complexity** (High/Medium/Low)
+7. **Present the plan** and WAIT for your explicit confirmation
+
+## Input Modes
+
+| Input | Mode | Behavior |
+|---|---|---|
+| `path/to/name.prd.md` | PRD artifact mode | Read the PRD, pick the next pending delivery milestone or implementation phase, and write `.claude/plans/{name}.plan.md` |
+| Any other markdown path | Reference mode | Read the file as context and produce an inline plan |
+| Free-form text | Conversational mode | Produce an inline plan |
+| Empty input | Clarification mode | Ask what should be planned |
+
+In PRD artifact mode, create `.claude/plans/` if needed. If the PRD contains a `Delivery Milestones` table, update only the selected row from `pending` to `in-progress` and set its `Plan` cell to the generated plan path. If the PRD uses the legacy `.claude/PRPs/prds/` format with `Implementation Phases`, read it without migrating paths.
+
+## Pattern Grounding
+
+Before writing the plan, search the codebase for conventions the implementation should mirror. Capture the top example for each relevant category with file references:
+
+| Category | What to capture |
+|---|---|
+| Naming | File, function, type, command, or script naming in the affected area |
+| Error handling | How failures are raised, returned, logged, or handled gracefully |
+| Logging | Levels, format, and what gets logged |
+| Data access | Repository, service, query, or filesystem patterns |
+| Tests | Test file location, framework, fixtures, and assertion style |
+
+If no similar code exists, state that explicitly. Do not invent a pattern.
+
+## PRD Artifact Output
+
+When called with a `.prd.md` file, write the plan to `.claude/plans/{kebab-case-name}.plan.md` using this structure:
+
+````markdown
+# Plan: {Feature Name}
+
+**Source PRD**: {path}
+**Selected Milestone**: {milestone or phase name}
+**Complexity**: {Small | Medium | Large}
+
+## Summary
+{2-3 sentences}
+
+## Patterns to Mirror
+| Category | Source | Pattern |
+|---|---|---|
+| Naming | `path:line` | {short description} |
+| Errors | `path:line` | {short description} |
+| Tests | `path:line` | {short description} |
+
+## Files to Change
+| File | Action | Why |
+|---|---|---|
+| `path` | CREATE / UPDATE / DELETE | {reason} |
+
+## Tasks
+### Task 1: {name}
+- **Action**: {what to do}
+- **Mirror**: {pattern to follow}
+- **Validate**: {command that proves correctness}
+
+## Validation
+```bash
+{project-specific validation commands}
+```
+
+## Risks
+| Risk | Likelihood | Mitigation |
+|---|---|---|
+
+## Acceptance
+- [ ] All tasks complete
+- [ ] Validation passes
+- [ ] Patterns mirrored, not reinvented
+````
+
+After writing the artifact, report its path and WAIT for confirmation before writing code.
 
 ## Example Usage
 
 ```
 User: /plan I need to add real-time notifications when markets resolve
 
-Agent (planner):
+Assistant:
 # Implementation Plan: Real-Time Market Resolution Notifications
 
 ## Requirements Restatement
@@ -93,7 +171,7 @@ Agent (planner):
 
 ## Important Notes
 
-**CRITICAL**: The planner agent will **NOT** write any code until you explicitly confirm the plan with "yes" or "proceed" or similar affirmative response.
+**CRITICAL**: This command will **NOT** write any code until you explicitly confirm the plan with "yes" or "proceed" or similar affirmative response.
 
 If you want changes, respond with:
 - "modify: [your changes]"
@@ -103,15 +181,20 @@ If you want changes, respond with:
 ## Integration with Other Commands
 
 After planning:
-- Use `/tdd` to implement with test-driven development
+- Use the `tdd-workflow` skill to implement with test-driven development
 - Use `/build-fix` if build errors occur
 - Use `/code-review` to review completed implementation
+- Use `/pr` or `/prp-pr` to open a pull request
 
-> **Need deeper planning?** Use `/prp-plan` for artifact-producing planning with PRD integration, codebase analysis, and pattern extraction. Use `/prp-implement` to execute those plans with rigorous validation loops.
+> **Need requirements first?** Use `/plan-prd` for a lean PRD at `.claude/prds/{name}.prd.md`.
+>
+> **Need the legacy PRP flow?** Use `/prp-plan` for deep PRP planning with `.claude/PRPs/` artifacts. Use `/prp-implement` to execute those plans with rigorous validation loops.
 
-## Related Agents
+## Optional Planner Agent
 
-This command invokes the `planner` agent provided by ECC.
+ECC also provides a `planner` agent for manual installs that include agent files. Use it only when the local runtime already exposes that subagent and the user explicitly asks you to delegate planning.
+
+If the `planner` subagent is unavailable, continue planning inline instead of surfacing an "Agent type 'planner' not found" error.
 
 For manual installs, the source file lives at:
 `agents/planner.md`

commands/pm2.md

@@ -1,3 +1,7 @@
+---
+description: Analyze a project and generate PM2 service commands for detected frontend, backend, or database services.
+---
+
 # PM2 Init
 
 Auto-analyze project and generate PM2 service commands.

commands/pr.md

@@ -0,0 +1,184 @@
+---
+description: "Create a GitHub PR from current branch with unpushed commits — discovers templates, analyzes changes, pushes"
+argument-hint: "[base-branch] (default: main)"
+---
+
+# Create Pull Request
+
+**Input**: `$ARGUMENTS` — optional, may contain a base branch name and/or flags (e.g., `--draft`).
+
+**Parse `$ARGUMENTS`**:
+- Extract any recognized flags (`--draft`)
+- Treat remaining non-flag text as the base branch name
+- Default base branch to `main` if none specified
+
+---
+
+## Phase 1 — VALIDATE
+
+Check preconditions:
+
+```bash
+git branch --show-current
+git status --short
+git log origin/<base>..HEAD --oneline
+```
+
+| Check | Condition | Action if Failed |
+|---|---|---|
+| Not on base branch | Current branch ≠ base | Stop: "Switch to a feature branch first." |
+| Clean working directory | No uncommitted changes | Warn: "You have uncommitted changes. Commit or stash first." |
+| Has commits ahead | `git log origin/<base>..HEAD` not empty | Stop: "No commits ahead of `<base>`. Nothing to PR." |
+| No existing PR | `gh pr list --head <branch> --json number` is empty | Stop: "PR already exists: #<number>. Use `gh pr view <number> --web` to open it." |
+
+If all checks pass, proceed.
+
+---
+
+## Phase 2 — DISCOVER
+
+### PR Template
+
+Search for PR template in order:
+
+1. `.github/PULL_REQUEST_TEMPLATE/` directory — if exists, list files and let user choose (or use `default.md`)
+2. `.github/PULL_REQUEST_TEMPLATE.md`
+3. `.github/pull_request_template.md`
+4. `docs/pull_request_template.md`
+
+If found, read it and use its structure for the PR body.
+
+### Commit Analysis
+
+```bash
+git log origin/<base>..HEAD --format="%h %s" --reverse
+```
+
+Analyze commits to determine:
+- **PR title**: Use conventional commit format with type prefix — `feat: ...`, `fix: ...`, etc.
+  - If multiple types, use the dominant one
+  - If single commit, use its message as-is
+- **Change summary**: Group commits by type/area
+
+### File Analysis
+
+```bash
+git diff origin/<base>..HEAD --stat
+git diff origin/<base>..HEAD --name-only
+```
+
+Categorize changed files: source, tests, docs, config, migrations.
+
+### Planning Artifacts
+
+Check for related artifacts produced by `/plan-prd`, `/plan`, or the legacy PRP workflow:
+- `.claude/prds/` — PRDs this PR implements a milestone of
+- `.claude/plans/` — Plans executed by this PR
+- `.claude/PRPs/prds/` — legacy PRP PRDs
+- `.claude/PRPs/plans/` — legacy PRP implementation plans
+- `.claude/PRPs/reports/` — legacy PRP implementation reports
+
+Reference these in the PR body if they exist.
+
+---
+
+## Phase 3 — PUSH
+
+```bash
+git push -u origin HEAD
+```
+
+If push fails due to divergence:
+```bash
+git fetch origin
+git rebase origin/<base>
+git push -u origin HEAD
+```
+
+If rebase conflicts occur, stop and inform the user.
+
+---
+
+## Phase 4 — CREATE
+
+### With Template
+
+If a PR template was found in Phase 2, fill in each section using the commit and file analysis. Preserve all template sections — leave sections as "N/A" if not applicable rather than removing them.
+
+### Without Template
+
+Use this default format:
+
+```markdown
+## Summary
+
+<1-2 sentence description of what this PR does and why>
+
+## Changes
+
+<bulleted list of changes grouped by area>
+
+## Files Changed
+
+<table or list of changed files with change type: Added/Modified/Deleted>
+
+## Testing
+
+<description of how changes were tested, or "Needs testing">
+
+## Related Issues
+
+<linked issues with Closes/Fixes/Relates to #N, or "None">
+```
+
+### Create the PR
+
+```bash
+gh pr create \
+  --title "<PR title>" \
+  --base <base-branch> \
+  --body "<PR body>"
+  # Add --draft if the --draft flag was parsed from $ARGUMENTS
+```
+
+---
+
+## Phase 5 — VERIFY
+
+```bash
+gh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles
+gh pr checks --json name,status,conclusion 2>/dev/null || true
+```
+
+---
+
+## Phase 6 — OUTPUT
+
+Report to user:
+
+```
+PR #<number>: <title>
+URL: <url>
+Branch: <head> → <base>
+Changes: +<additions> -<deletions> across <changedFiles> files
+
+CI Checks: <status summary or "pending" or "none configured">
+
+Artifacts referenced:
+  - <any PRDs/plans linked in PR body>
+
+Next steps:
+  - gh pr view <number> --web   → open in browser
+  - /code-review <number>       → review the PR
+  - gh pr merge <number>        → merge when ready
+```
+
+---
+
+## Edge Cases
+
+- **No `gh` CLI**: Stop with: "GitHub CLI (`gh`) is required. Install: <https://cli.github.com/>"
+- **Not authenticated**: Stop with: "Run `gh auth login` first."
+- **Force push needed**: If remote has diverged and rebase was done, use `git push --force-with-lease` (never `--force`).
+- **Multiple PR templates**: If `.github/PULL_REQUEST_TEMPLATE/` has multiple files, list them and ask user to choose.
+- **Large PR (>20 files)**: Warn about PR size. Suggest splitting if changes are logically separable.

commands/project-init.md

@@ -0,0 +1,86 @@
+---
+description: Detect a project's stack and produce a dry-run ECC onboarding plan using the repository's install manifests and stack mappings.
+---
+
+# /project-init
+
+Create a safe, reviewable ECC onboarding plan for the current project. This command should start in dry-run mode and only write files after explicit user approval.
+
+## Usage
+
+```text
+/project-init
+/project-init --dry-run
+/project-init --target claude
+/project-init --target cursor
+/project-init --skills continuous-learning-v2,security-review
+/project-init --config ecc-install.json
+```
+
+## Safety Rules
+
+1. Default to dry-run. Do not modify `CLAUDE.md`, settings files, rules, skills, or install state until the user approves the concrete plan.
+2. Preserve existing project guidance. If `CLAUDE.md`, `.claude/settings.local.json`, `.cursor/`, `.codex/`, `.gemini/`, `.opencode/`, `.codebuddy/`, `.joycode/`, or `.qwen/` already exists, inspect it and propose a merge/append plan instead of overwriting.
+3. Use ECC's installer and manifest tooling. Do not hand-copy files or clone arbitrary remotes as an install shortcut.
+4. Keep permissions narrow. Any generated settings should match detected build/test/lint tools and avoid broad shell access.
+5. Report exactly what would change before applying anything.
+
+## Detection Inputs
+
+Read the current project root and detect stack signals from:
+
+- package manager files: `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lockb`
+- language manifests: `pyproject.toml`, `requirements.txt`, `go.mod`, `Cargo.toml`, `pom.xml`, `build.gradle`, `build.gradle.kts`
+- framework files: `next.config.*`, `vite.config.*`, `tailwind.config.*`, `Dockerfile`, `docker-compose.yml`
+- ECC config: `ecc-install.json`
+- optional stack map: `config/project-stack-mappings.json` in the ECC repo
+
+When the ECC checkout is available, use `config/project-stack-mappings.json` as the stack-to-rules/skills reference. If the file is unavailable, fall back to the installed ECC manifests and explicit user choices.
+
+## Planning Flow
+
+1. Identify the target harness. Default to `claude` unless the user asks for `cursor`, `codex`, `gemini`, `opencode`, `codebuddy`, `joycode`, or `qwen`.
+2. Detect stacks from project files and show the evidence for each match.
+3. Resolve the smallest useful ECC plan:
+   - project has an `ecc-install.json`: `node scripts/install-plan.js --config ecc-install.json --json`
+   - user named a profile: `node scripts/install-plan.js --profile <profile> --target <target> --json`
+   - user named skills: `node scripts/install-plan.js --skills <skill-ids> --target <target> --json`
+   - only language stacks are detected: use the legacy language install dry-run with those language names
+4. Run a dry-run apply command before writing:
+
+```bash
+node scripts/install-apply.js --target <target> --dry-run --json <language-or-profile-args>
+```
+
+5. Summarize detected stacks, selected modules/components/skills, target paths, skipped unsupported modules, and files that would be changed.
+6. Ask for approval before applying the non-dry-run command.
+
+## Output Contract
+
+Return:
+
+1. detected stack evidence
+2. proposed target harness
+3. exact dry-run command used
+4. exact apply command to run after approval
+5. files/directories that would be created or changed
+6. warnings about existing files, broad permissions, missing scripts, or unsupported targets
+
+## CLAUDE.md Guidance
+
+If the user wants a `CLAUDE.md` starter, generate it separately from the installer plan and keep it minimal:
+
+- build command, if detected
+- test command, if detected
+- lint/typecheck command, if detected
+- dev server command, if detected
+- repo-specific notes from existing package scripts or manifests
+
+Never replace an existing `CLAUDE.md` without showing a diff and receiving approval.
+
+## Related
+
+- `config/project-stack-mappings.json` for stack-to-surface hints
+- `scripts/install-plan.js` for deterministic plan resolution
+- `scripts/install-apply.js` for dry-run and apply operations
+- `/ecc-guide` for interactive feature discovery before installing

commands/python-review.md

@@ -171,7 +171,7 @@ Run: `black app/routes/user.py app/services/auth.py`
 
 ## Integration with Other Commands
 
-- Use `/tdd` first to ensure tests pass
+- Use the `tdd-workflow` skill first to ensure tests pass
 - Use `/code-review` for non-Python specific concerns
 - Use `/python-review` before committing
 - Use `/build-fix` if static analysis tools fail

commands/quality-gate.md

@@ -1,3 +1,7 @@
+---
+description: Run the ECC quality pipeline for a file or project scope and report remediation steps.
+---
+
 # Quality Gate Command
 
 Run the ECC quality pipeline on demand for a file or project scope.

commands/refactor-clean.md

@@ -1,3 +1,7 @@
+---
+description: Safely identify and remove dead code with verification after each change.
+---
+
 # Refactor Clean
 
 Safely identify and remove dead code with test verification at every step.

commands/rust-build.md

@@ -179,7 +179,7 @@ The agent will stop and report if:
 
 - `/rust-test` - Run tests after build succeeds
 - `/rust-review` - Review code quality
-- `/verify` - Full verification loop
+- `verification-loop` skill - Full verification loop
 
 ## Related
 

commands/rust-test.md

@@ -300,7 +300,7 @@ cargo test --no-fail-fast
 
 - `/rust-build` - Fix build errors
 - `/rust-review` - Review code after implementation
-- `/verify` - Run full verification loop
+- `verification-loop` skill - Run full verification loop
 
 ## Related
 

commands/security-scan.md

@@ -0,0 +1,92 @@
+---
+description: Run AgentShield against agent, hook, MCP, permission, and secret surfaces.
+agent: everything-claude-code:security-reviewer
+subtask: true
+---
+
+# Security Scan Command
+
+Run AgentShield against the current project or a target path, then turn the findings into a prioritized remediation plan.
+
+## Usage
+
+`/security-scan [path] [--format text|json|markdown|html] [--min-severity low|medium|high|critical] [--fix]`
+
+- `path` (optional): defaults to the current project. Use a `.claude/` path, a repo root, or a checked-in template directory.
+- `--format`: output format. Use `json` for CI, `markdown` for handoffs, and `html` for standalone review reports.
+- `--min-severity`: filters lower-priority findings.
+- `--fix`: applies only AgentShield fixes explicitly marked as safe and auto-fixable.
+
+## Deterministic Engine
+
+Prefer the packaged scanner:
+
+```bash
+npx ecc-agentshield scan --path "${TARGET_PATH:-.}" --format text
+```
+
+For local AgentShield development, run from the AgentShield checkout:
+
+```bash
+npm run scan -- --path "${TARGET_PATH:-.}" --format text
+```
+
+Do not invent findings. Use AgentShield output as the source of truth and separate scanner facts from follow-up judgment.
+
+## Review Checklist
+
+1. Identify active runtime findings first:
+   - hardcoded secrets
+   - broad permissions
+   - executable hooks
+   - MCP servers with shell, filesystem, remote transport, or unpinned `npx`
+   - agent prompts that handle untrusted content without defenses
+2. Separate lower-confidence inventory:
+   - docs examples
+   - template examples
+   - plugin manifests
+   - project-local optional settings
+3. For each critical or high finding, return:
+   - file path
+   - severity
+   - runtime confidence
+   - why it matters
+   - exact remediation
+   - whether it is safe to auto-fix
+4. If `--fix` is requested, state the planned edits before applying fixes.
+5. Re-run the scan after fixes and report the before/after score.
+
+## Output Contract
+
+Return:
+
+1. Security grade and score.
+2. Counts by severity and runtime confidence.
+3. Critical/high findings with exact paths.
+4. Lower-confidence findings grouped separately.
+5. A remediation order.
+6. Commands run and whether the scan was local, CI, or npx-backed.
+
+## CI Pattern
+
+Use AgentShield in GitHub Actions for enforced gates:
+
+```yaml
+- uses: affaan-m/agentshield@v1
+  with:
+    path: "."
+    min-severity: "medium"
+    fail-on-findings: true
+```
+
+## Links
+
+- Skill: `skills/security-scan/SKILL.md`
+- Agent: `agents/security-reviewer.md`
+- Scanner: <https://github.com/affaan-m/agentshield>
+
+## Arguments
+
+$ARGUMENTS:
+- optional target path
+- optional AgentShield flags

commands/sessions.md

@@ -29,7 +29,7 @@ Use `/sessions info` when you need operator-surface context for a swarm: branch,
 **Script:**
 ```bash
 node -e "
-const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
+const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
 const sm = require(_r + '/scripts/lib/session-manager');
 const aa = require(_r + '/scripts/lib/session-aliases');
 const path = require('path');
@@ -71,7 +71,7 @@ Load and display a session's content (by ID or alias).
 **Script:**
 ```bash
 node -e "
-const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
+const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
 const sm = require(_r + '/scripts/lib/session-manager');
 const aa = require(_r + '/scripts/lib/session-aliases');
 const id = process.argv[1];
@@ -145,7 +145,7 @@ Create a memorable alias for a session.
 **Script:**
 ```bash
 node -e "
-const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
+const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
 const sm = require(_r + '/scripts/lib/session-manager');
 const aa = require(_r + '/scripts/lib/session-aliases');
 
@@ -186,7 +186,7 @@ Delete an existing alias.
 **Script:**
 ```bash
 node -e "
-const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
+const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
 const aa = require(_r + '/scripts/lib/session-aliases');
 
 const aliasName = process.argv[1];
@@ -216,7 +216,7 @@ Show detailed information about a session.
 **Script:**
 ```bash
 node -e "
-const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
+const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
 const sm = require(_r + '/scripts/lib/session-manager');
 const aa = require(_r + '/scripts/lib/session-aliases');
 
@@ -267,7 +267,7 @@ Show all session aliases.
 **Script:**
 ```bash
 node -e "
-const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
+const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
 const aa = require(_r + '/scripts/lib/session-aliases');
 
 const aliases = aa.listAliases();

commands/skill-health.md

@@ -13,21 +13,21 @@ Shows a comprehensive health dashboard for all skills in the portfolio with succ
 Run the skill health CLI in dashboard mode:
 
 ```bash
-ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
+ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
 node "$ECC_ROOT/scripts/skills-health.js" --dashboard
 ```
 
 For a specific panel only:
 
 ```bash
-ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
+ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
 node "$ECC_ROOT/scripts/skills-health.js" --dashboard --panel failures
 ```
 
 For machine-readable output:
 
 ```bash
-ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
+ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
 node "$ECC_ROOT/scripts/skills-health.js" --dashboard --json
 ```
 

commands/test-coverage.md

@@ -1,3 +1,7 @@
+---
+description: Analyze coverage, identify gaps, and generate missing tests toward the target threshold.
+---
+
 # Test Coverage
 
 Analyze test coverage, identify gaps, and generate missing tests to reach 80%+ coverage.

commands/update-codemaps.md

@@ -1,3 +1,7 @@
+---
+description: Scan project structure and generate token-lean architecture codemaps.
+---
+
 # Update Codemaps
 
 Analyze the codebase structure and generate token-lean architecture documentation.

commands/update-docs.md

@@ -1,3 +1,7 @@
+---
+description: Sync documentation from source-of-truth files such as scripts, schemas, routes, and exports.
+---
+
 # Update Documentation
 
 Sync documentation with the codebase, generating from source-of-truth files.

config/project-stack-mappings.json

@@ -0,0 +1,539 @@
+{
+  "version": 1,
+  "description": "Maps project indicator files to ECC skills, rules, hooks, and default commands. Used by /project-init to auto-configure projects.",
+  "stacks": [
+    {
+      "id": "typescript",
+      "name": "TypeScript / JavaScript",
+      "indicators": [
+        { "file": "tsconfig.json" },
+        { "file": "tsconfig.*.json" },
+        { "file": "package.json", "contains": "typescript" }
+      ],
+      "rules": ["common", "typescript"],
+      "skills": [
+        "coding-standards",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["npx tsc --noEmit", "npm run build"],
+        "test": ["npm test", "npx jest", "npx vitest"],
+        "lint": ["npx eslint .", "npx tsc --noEmit"],
+        "format": ["npx prettier --write ."]
+      },
+      "permissions": {
+        "allow": ["npx tsc", "npx eslint", "npx prettier", "npm test", "npm run *", "npx jest", "npx vitest"],
+        "deny": ["npm publish"]
+      }
+    },
+    {
+      "id": "javascript",
+      "name": "JavaScript (Node.js)",
+      "indicators": [
+        { "file": "package.json" },
+        { "file": ".eslintrc*" },
+        { "file": "eslint.config.*" }
+      ],
+      "rules": ["common", "typescript"],
+      "skills": [
+        "coding-standards",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["npm run build"],
+        "test": ["npm test", "npx jest", "npx vitest"],
+        "lint": ["npx eslint ."],
+        "format": ["npx prettier --write ."]
+      },
+      "permissions": {
+        "allow": ["npx eslint", "npx prettier", "npm test", "npm run *", "npx jest", "npx vitest"],
+        "deny": ["npm publish"]
+      }
+    },
+    {
+      "id": "react",
+      "name": "React",
+      "indicators": [
+        { "file": "package.json", "contains": "\"react\":" }
+      ],
+      "rules": ["common", "typescript", "web"],
+      "skills": [
+        "coding-standards",
+        "frontend-patterns",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["npm run build"],
+        "test": ["npm test", "npx jest", "npx vitest"],
+        "lint": ["npx eslint ."],
+        "format": ["npx prettier --write ."]
+      },
+      "permissions": {
+        "allow": ["npx eslint", "npx prettier", "npm test", "npm run *", "npx jest", "npx vitest"],
+        "deny": ["npm publish"]
+      }
+    },
+    {
+      "id": "nextjs",
+      "name": "Next.js",
+      "indicators": [
+        { "file": "next.config.*" },
+        { "file": "package.json", "contains": "\"next\":" }
+      ],
+      "rules": ["common", "typescript", "web"],
+      "skills": [
+        "coding-standards",
+        "frontend-patterns",
+        "backend-patterns",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["npm run build", "npx next build"],
+        "test": ["npm test", "npx jest", "npx vitest"],
+        "lint": ["npx next lint", "npx eslint ."],
+        "format": ["npx prettier --write ."],
+        "dev": ["npm run dev", "npx next dev"]
+      },
+      "permissions": {
+        "allow": ["npx next *", "npx eslint", "npx prettier", "npm test", "npm run *", "npx jest", "npx vitest"],
+        "deny": ["npm publish"]
+      }
+    },
+    {
+      "id": "golang",
+      "name": "Go",
+      "indicators": [
+        { "file": "go.mod" },
+        { "file": "go.sum" }
+      ],
+      "rules": ["common", "golang"],
+      "skills": [
+        "golang-patterns",
+        "golang-testing",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["go build ./..."],
+        "test": ["go test ./..."],
+        "lint": ["golangci-lint run", "go vet ./..."],
+        "format": ["gofmt -w ."]
+      },
+      "permissions": {
+        "allow": ["go build *", "go test *", "go vet *", "go mod *", "go run *", "golangci-lint *", "gofmt *"],
+        "deny": []
+      }
+    },
+    {
+      "id": "python",
+      "name": "Python",
+      "indicators": [
+        { "file": "pyproject.toml" },
+        { "file": "setup.py" },
+        { "file": "setup.cfg" },
+        { "file": "requirements.txt" },
+        { "file": "Pipfile" },
+        { "file": "poetry.lock" }
+      ],
+      "rules": ["common", "python"],
+      "skills": [
+        "python-patterns",
+        "python-testing",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["python -m build", "pip install -e ."],
+        "test": ["pytest", "python -m pytest"],
+        "lint": ["ruff check .", "flake8", "mypy ."],
+        "format": ["ruff format .", "black ."]
+      },
+      "permissions": {
+        "allow": ["python *", "pip install *", "pytest *", "ruff *", "black *", "mypy *", "flake8 *"],
+        "deny": ["pip install --user *"]
+      }
+    },
+    {
+      "id": "rust",
+      "name": "Rust",
+      "indicators": [
+        { "file": "Cargo.toml" },
+        { "file": "Cargo.lock" }
+      ],
+      "rules": ["common", "rust"],
+      "skills": [
+        "rust-patterns",
+        "rust-testing",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["cargo build"],
+        "test": ["cargo test"],
+        "lint": ["cargo clippy -- -D warnings"],
+        "format": ["cargo fmt"]
+      },
+      "permissions": {
+        "allow": ["cargo build *", "cargo test *", "cargo clippy *", "cargo fmt *", "cargo run *", "cargo check *"],
+        "deny": ["cargo publish"]
+      }
+    },
+    {
+      "id": "java",
+      "name": "Java",
+      "indicators": [
+        { "file": "pom.xml" },
+        { "file": "build.gradle" },
+        { "file": "build.gradle.kts" }
+      ],
+      "rules": ["common", "java"],
+      "skills": [
+        "java-coding-standards",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["./mvnw compile", "./gradlew build", "mvn compile", "gradle build"],
+        "test": ["./mvnw test", "./gradlew test", "mvn test", "gradle test"],
+        "lint": ["./mvnw checkstyle:check", "./gradlew checkstyleMain"],
+        "format": ["./mvnw spotless:apply", "./gradlew spotlessApply"]
+      },
+      "permissions": {
+        "allow": ["./mvnw *", "./gradlew *", "mvn *", "gradle *", "java *"],
+        "deny": ["./mvnw deploy", "./gradlew publish", "mvn deploy", "gradle publish"]
+      }
+    },
+    {
+      "id": "springboot",
+      "name": "Spring Boot (Java/Kotlin)",
+      "indicators": [
+        { "file": "pom.xml", "contains": "spring-boot" },
+        { "file": "build.gradle", "contains": "spring-boot" },
+        { "file": "build.gradle.kts", "contains": "spring-boot" }
+      ],
+      "rules": ["common", "java"],
+      "skills": [
+        "springboot-patterns",
+        "springboot-tdd",
+        "springboot-verification",
+        "springboot-security",
+        "java-coding-standards",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["./mvnw compile", "./gradlew build"],
+        "test": ["./mvnw test", "./gradlew test"],
+        "lint": ["./mvnw checkstyle:check"],
+        "format": ["./mvnw spotless:apply"],
+        "dev": ["./mvnw spring-boot:run", "./gradlew bootRun"]
+      },
+      "permissions": {
+        "allow": ["./mvnw *", "./gradlew *", "mvn *", "gradle *", "java *"],
+        "deny": ["./mvnw deploy", "./gradlew publish", "mvn deploy", "gradle publish"]
+      }
+    },
+    {
+      "id": "kotlin",
+      "name": "Kotlin",
+      "indicators": [
+        { "file": "build.gradle.kts" },
+        { "file": "settings.gradle.kts" },
+        { "file": "build.gradle", "contains": "kotlin" }
+      ],
+      "rules": ["common", "kotlin"],
+      "skills": [
+        "kotlin-patterns",
+        "kotlin-testing",
+        "kotlin-coroutines-flows",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["./gradlew build"],
+        "test": ["./gradlew test"],
+        "lint": ["./gradlew ktlintCheck", "./gradlew detekt"],
+        "format": ["./gradlew ktlintFormat"]
+      },
+      "permissions": {
+        "allow": ["./gradlew *", "gradle *", "kotlin *"],
+        "deny": ["./gradlew publish"]
+      }
+    },
+    {
+      "id": "swift",
+      "name": "Swift / SwiftUI",
+      "indicators": [
+        { "file": "Package.swift" },
+        { "file": "*.xcodeproj" },
+        { "file": "*.xcworkspace" },
+        { "file": "Podfile" }
+      ],
+      "rules": ["common", "swift"],
+      "skills": [
+        "swiftui-patterns",
+        "swift-concurrency-6-2",
+        "swift-actor-persistence",
+        "swift-protocol-di-testing",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["swift build", "xcodebuild build"],
+        "test": ["swift test", "xcodebuild test"],
+        "lint": ["swiftlint"],
+        "format": ["swiftformat ."]
+      },
+      "permissions": {
+        "allow": ["swift build *", "swift test *", "swift run *", "xcodebuild *", "swiftlint *", "swiftformat *"],
+        "deny": []
+      }
+    },
+    {
+      "id": "dart-flutter",
+      "name": "Dart / Flutter",
+      "indicators": [
+        { "file": "pubspec.yaml" },
+        { "file": "pubspec.lock" }
+      ],
+      "rules": ["common", "dart"],
+      "skills": [
+        "dart-flutter-patterns",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["flutter build", "dart compile"],
+        "test": ["flutter test", "dart test"],
+        "lint": ["dart analyze"],
+        "format": ["dart format ."]
+      },
+      "permissions": {
+        "allow": ["flutter *", "dart *"],
+        "deny": ["flutter pub publish"]
+      }
+    },
+    {
+      "id": "php-laravel",
+      "name": "PHP / Laravel",
+      "indicators": [
+        { "file": "composer.json" },
+        { "file": "artisan" },
+        { "file": "composer.lock" }
+      ],
+      "rules": ["common", "php"],
+      "skills": [
+        "laravel-patterns",
+        "laravel-tdd",
+        "laravel-verification",
+        "laravel-security",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["composer install"],
+        "test": ["php artisan test", "vendor/bin/phpunit", "vendor/bin/pest"],
+        "lint": ["vendor/bin/phpstan analyse", "vendor/bin/pint"],
+        "format": ["vendor/bin/pint"]
+      },
+      "permissions": {
+        "allow": ["php artisan *", "composer *", "vendor/bin/*"],
+        "deny": []
+      }
+    },
+    {
+      "id": "ruby",
+      "name": "Ruby / Rails",
+      "indicators": [
+        { "file": "Gemfile" },
+        { "file": "Gemfile.lock" },
+        { "file": "Rakefile" }
+      ],
+      "rules": ["common"],
+      "skills": [
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["bundle install"],
+        "test": ["bundle exec rspec", "bundle exec rake test"],
+        "lint": ["bundle exec rubocop"],
+        "format": ["bundle exec rubocop -A"]
+      },
+      "permissions": {
+        "allow": ["bundle exec *", "rails *", "rake *", "ruby *"],
+        "deny": ["gem push"]
+      }
+    },
+    {
+      "id": "csharp-dotnet",
+      "name": "C# / .NET",
+      "indicators": [
+        { "file": "*.csproj" },
+        { "file": "*.sln" },
+        { "file": "global.json" }
+      ],
+      "rules": ["common", "csharp"],
+      "skills": [
+        "dotnet-patterns",
+        "csharp-testing",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["dotnet build"],
+        "test": ["dotnet test"],
+        "lint": ["dotnet format --verify-no-changes"],
+        "format": ["dotnet format"]
+      },
+      "permissions": {
+        "allow": ["dotnet build *", "dotnet test *", "dotnet run *", "dotnet format *"],
+        "deny": ["dotnet nuget push"]
+      }
+    },
+    {
+      "id": "cpp",
+      "name": "C / C++",
+      "indicators": [
+        { "file": "CMakeLists.txt" },
+        { "file": "Makefile" },
+        { "file": "meson.build" },
+        { "file": "*.vcxproj" }
+      ],
+      "rules": ["common", "cpp"],
+      "skills": [
+        "cpp-coding-standards",
+        "cpp-testing",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["cmake --build build", "make"],
+        "test": ["ctest --test-dir build", "make test"],
+        "lint": ["clang-tidy -p build"],
+        "format": ["clang-format -i **/*.cpp **/*.h **/*.c **/*.hpp"]
+      },
+      "permissions": {
+        "allow": ["cmake *", "make *", "ctest *", "clang-tidy *", "clang-format *", "gcc *", "g++ *"],
+        "deny": []
+      }
+    },
+    {
+      "id": "perl",
+      "name": "Perl",
+      "indicators": [
+        { "file": "cpanfile" },
+        { "file": "Makefile.PL" },
+        { "file": "Build.PL" },
+        { "file": "dist.ini" }
+      ],
+      "rules": ["common", "perl"],
+      "skills": [
+        "perl-patterns",
+        "perl-testing",
+        "perl-security",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["perl Makefile.PL && make", "perl Build.PL && ./Build"],
+        "test": ["prove -lr t/", "make test"],
+        "lint": ["perlcritic lib/"],
+        "format": ["perltidy -b lib/**/*.pl"]
+      },
+      "permissions": {
+        "allow": ["perl *", "prove *", "make *", "perlcritic *", "perltidy *"],
+        "deny": []
+      }
+    },
+    {
+      "id": "django",
+      "name": "Django (Python)",
+      "indicators": [
+        { "file": "manage.py" },
+        { "file": "requirements.txt", "contains": "django" },
+        { "file": "pyproject.toml", "contains": "django" }
+      ],
+      "rules": ["common", "python"],
+      "skills": [
+        "django-patterns",
+        "django-tdd",
+        "django-verification",
+        "django-security",
+        "python-patterns",
+        "python-testing",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["pip install -e ."],
+        "test": ["python manage.py test", "pytest"],
+        "lint": ["ruff check .", "mypy ."],
+        "format": ["ruff format .", "black ."],
+        "dev": ["python manage.py runserver"]
+      },
+      "permissions": {
+        "allow": ["python *", "pip install *", "pytest *", "ruff *", "black *", "mypy *"],
+        "deny": []
+      }
+    },
+    {
+      "id": "android",
+      "name": "Android (Kotlin/Java)",
+      "indicators": [
+        { "file": "settings.gradle.kts", "contains": "android" },
+        { "file": "build.gradle", "contains": "android" },
+        { "file": "AndroidManifest.xml" }
+      ],
+      "rules": ["common", "kotlin"],
+      "skills": [
+        "android-clean-architecture",
+        "kotlin-patterns",
+        "kotlin-testing",
+        "kotlin-coroutines-flows",
+        "compose-multiplatform-patterns",
+        "tdd-workflow",
+        "verification-loop"
+      ],
+      "commands": {
+        "build": ["./gradlew assembleDebug"],
+        "test": ["./gradlew testDebugUnitTest"],
+        "lint": ["./gradlew lint", "./gradlew ktlintCheck"],
+        "format": ["./gradlew ktlintFormat"]
+      },
+      "permissions": {
+        "allow": ["./gradlew *", "adb *"],
+        "deny": []
+      }
+    },
+    {
+      "id": "docker",
+      "name": "Docker / Containerized",
+      "indicators": [
+        { "file": "Dockerfile" },
+        { "file": "docker-compose.yml" },
+        { "file": "docker-compose.yaml" },
+        { "file": "compose.yml" },
+        { "file": "compose.yaml" }
+      ],
+      "rules": [],
+      "skills": [
+        "docker-patterns",
+        "deployment-patterns"
+      ],
+      "commands": {
+        "build": ["docker compose build", "docker build ."],
+        "test": ["docker compose run --rm app test"],
+        "dev": ["docker compose up"]
+      },
+      "permissions": {
+        "allow": ["docker compose *", "docker build *"],
+        "deny": ["docker push"]
+      }
+    }
+  ]
+}

docs/ARCHITECTURE-IMPROVEMENTS.md

@@ -110,7 +110,7 @@ This document captures architect-level improvements for the Everything Claude Co
 
 ### 5.1 Hook Runtime Consistency
 
-**Issue:** Most hooks invoke Node scripts via `run-with-flags.js`; one path uses `run-with-flags-shell.sh` + `observe.sh`. The mixed runtime is documented but could be simplified over time.
+**Issue:** Hooks should keep a consistent Node-mode dispatch surface. Continuous-learning observation now dispatches through `run-with-flags.js` and `observe-runner.js`, which delegates to the existing `observe.sh` implementation without exposing a shell-mode hook entry.
 
 **Recommendation:**
 

docs/ECC-2.0-GA-ROADMAP.md

@@ -0,0 +1,246 @@
+# ECC 2.0 GA Roadmap
+
+This roadmap is the durable repo mirror for the Linear project:
+
+<https://linear.app/ecctools/project/ecc-20-ga-harness-os-security-platform-de2a0ecace6f>
+
+Linear issue creation is currently blocked by the workspace active issue limit,
+so the live execution truth is split across:
+
+- the Linear project description, status updates, and milestones;
+- this repo document;
+- merged PR evidence;
+- handoffs under `~/.cluster-swarm/handoffs/`.
+
+## Current Evidence
+
+As of 2026-05-12:
+
+- Public GitHub queues are clean across `everything-claude-code`,
+  `agentshield`, `JARVIS`, `ECC-Tools`, and `ECC-website`.
+- `npm run harness:audit -- --format json` reports 70/70 on current `main`.
+- `npm run observability:ready` reports 14/14 readiness on current `main`.
+- `docs/architecture/harness-adapter-compliance.md` maps Claude Code, Codex,
+  OpenCode, Cursor, Gemini, Zed-adjacent, dmux, Orca, Superset, Ghast, and
+  terminal-only support to install paths, verification commands, and risk
+  notes.
+- `npm run harness:adapters -- --check` validates that the public adapter
+  matrix still matches the source data in
+  `scripts/lib/harness-adapter-compliance.js`.
+- `docs/releases/2.0.0-rc.1/publication-readiness.md` gates GitHub release,
+  npm dist-tag, Claude plugin, Codex plugin, OpenCode package, billing, and
+  announcement publication on fresh evidence fields.
+- `docs/legacy-artifact-inventory.md` records that no `_legacy-documents-*`
+  directories exist in the current checkout, inventories the two sibling
+  workspace-level `_legacy-documents-*` repos as sanitized extraction sources,
+  and classifies `legacy-command-shims/` as an opt-in archive/no-action
+  surface.
+- `docs/stale-pr-salvage-ledger.md` records stale PR salvage outcomes,
+  skipped PRs, superseded work, and the remaining #1687 translator/manual
+  review tail.
+- AgentShield PR #53 reduced two context-rule false positives and closed the
+  remaining AgentShield issues.
+- AgentShield PR #55 added GitHub Action organization-policy enforcement with
+  `policy` / `fail-on-policy` inputs, `policy-status` /
+  `policy-violations` outputs, job-summary evidence, and policy violation
+  annotations.
+- AgentShield PR #56 added SARIF/code-scanning output for organization-policy
+  violations as `agentshield-policy/*` results.
+- AgentShield PR #57 added OSS, team, enterprise, regulated,
+  high-risk-hooks/MCP, and CI-enforcement policy-pack presets plus
+  `agentshield policy init --pack`.
+- AgentShield PR #58 added MCP package provenance fields and report-level
+  counts for npm vs git, pinned vs unpinned, known-good, and registry-backed
+  supply-chain evidence.
+- AgentShield PR #59 added self-contained HTML executive summaries with risk
+  posture, critical/high priority findings, category exposure, README/API
+  docs, built-CLI smoke validation, and 1,704-test coverage.
+- AgentShield PR #60 added category-level built-in corpus benchmark output,
+  a `readyForRegressionGate` signal, terminal `--corpus` category coverage,
+  README/API docs, built-CLI smoke validation, and 1,705-test coverage.
+- ECC PR #1778 recovered the useful stale #1413 network/homelab architect-agent
+  concepts.
+- ECC-Tools PR #26 added cost/token-risk predictive follow-ups for AI routing,
+  Claude/model calls, usage limits, quota, and analysis-budget changes that lack
+  budget, quota, rate-limit, or cost validation evidence.
+- ECC-Tools PR #27 added the non-blocking `ECC Tools / PR Risk Taxonomy`
+  check-run for Security Evidence, Harness Drift, Install Manifest Integrity,
+  CI/CD Recommendation, Cost/Token Risk, and Agent Config Review buckets.
+- ECC-Tools PR #28 added billing readiness audit checks for plan limits,
+  entitlements, Marketplace plan shape, subscription source, seats, and
+  overage metering.
+- ECC-Tools PR #29 added deterministic Reference Set Validation signals for
+  analyzer, skill, agent, command, and harness-guidance changes that lack eval,
+  golden trace, benchmark, or reference-set evidence.
+- ECC-Tools PR #30 capped follow-up generation to three new GitHub issues and
+  one draft PR per run, then emits the remaining deterministic findings as a
+  project sync backlog for Linear/status tracking without flooding trackers.
+
+## Operating Rules
+
+- Keep public PRs and issues below 20, with zero as the preferred release-lane
+  target.
+- Maintain 70/70 harness audit and 14/14 observability readiness after every
+  GA-readiness batch.
+- Do not publish release or social announcements until the GitHub release,
+  npm/package state, billing state, and plugin submission surfaces are verified
+  with fresh evidence.
+- Do not treat closed stale PRs as discarded. Pair each cleanup batch with a
+  salvage pass: inspect the closed diffs, port useful compatible work on
+  maintainer-owned branches, and credit the source PR.
+- Do not create new Linear issues until the active issue limit is cleared.
+
+## Reference Pressure
+
+The GA roadmap is informed by these reference surfaces:
+
+- `stablyai/orca` and `superset-sh/superset` for worktree-native parallel agent
+  UX, review loops, and workspace presets.
+- `standardagents/dmux` and `aidenybai/ghast` for terminal/worktree
+  multiplexing, session grouping, and lifecycle hooks.
+- `jarrodwatts/claude-hud` for always-visible status, tool, agent, todo, and
+  context telemetry.
+- `stanford-iris-lab/meta-harness` and `greyhaven-ai/autocontext` for
+  evaluation-driven harness improvement, traces, playbooks, and promotion
+  loops.
+- `NousResearch/hermes-agent` for operator shell, gateway, memory, skills, and
+  multi-platform command patterns.
+- `anthropics/claude-code`, active `sst/opencode` / `anomalyco/opencode`, Zed,
+  Codex, Cursor, Gemini, and terminal-only workflows for adapter expectations.
+
+The output of this reference work should be concrete ECC deltas, not a second
+strategy memo.
+
+## Milestones
+
+### 1. GA Release, Naming, And Plugin Publication Readiness
+
+Target: 2026-05-24
+
+Acceptance:
+
+- Naming matrix covers product name, npm package, Claude plugin, Codex plugin,
+  OpenCode package, marketplace metadata, docs, and migration copy.
+- GitHub release, npm dist-tag, plugin publication, and announcement gates are
+  mapped to fresh command evidence.
+- Release notes, migration guide, known issues, quickstart, X thread, LinkedIn
+  post, and GitHub release copy are ready but not posted before release URLs
+  exist.
+- Plugin publication/contact paths for Claude and Codex are documented with
+  owner, required artifacts, and submission status.
+
+### 2. Harness Adapter Compliance Matrix And Scorecard Onramp
+
+Target: 2026-05-31
+
+Acceptance:
+
+- Adapter matrix covers Claude Code, Codex, OpenCode, Cursor, Gemini,
+  Zed-adjacent surfaces, dmux, Orca, Superset, Ghast, and terminal-only use.
+- Each adapter has supported assets, unsupported surfaces, install path,
+  verification command, and risk notes.
+- Harness audit remains 70/70 and gains a public onramp that explains how teams
+  use the scorecard.
+- Reference findings are converted into concrete adapter, observability, or
+  operator-surface deltas.
+
+### 3. Local Observability, HUD/Status, And Session Control Plane
+
+Target: 2026-06-07
+
+Acceptance:
+
+- Observability readiness remains 14/14 and is backed by JSONL traces, status
+  snapshots, risk ledger, and exportable handoff contracts.
+- HUD/status model covers context, tool calls, active agents, todos, checks,
+  cost, risk, and queue state.
+- Worktree/session controls cover create, resume, status, stop, diff, PR,
+  merge queue, and conflict queue.
+- Linear/GitHub/handoff sync model is explicit enough for real-time progress
+  tracking.
+
+### 4. Self-Improving Harness Evaluation Loop
+
+Target: 2026-06-10
+
+Acceptance:
+
+- Scenario specs, verifier contracts, traces, playbooks, and regression gates
+  are documented and at least one read-only prototype exists.
+- The loop separates observation, proposal, verification, and promotion.
+- Team and individual setups can be scored and improved without blindly
+  mutating configs.
+- RAG/reference-set design covers vetted ECC patterns, team history, CI
+  failures, diffs, review outcomes, and harness config quality.
+
+### 5. AgentShield Enterprise Security Platform
+
+Target: 2026-06-14
+
+Acceptance:
+
+- Formal policy schema exists for org baselines, exceptions, owners,
+  expiration, severity, and audit trails.
+- SARIF/code-scanning output is implemented and tested.
+- GitHub Action policy gates expose organization policy status and violation
+  counts for branch-protection and CI evidence.
+- Policy packs are defined for OSS, team, enterprise, regulated, high-risk
+  hooks/MCP, and CI enforcement.
+- Supply-chain intelligence covers MCP package provenance and has an extension
+  path for npm/pip reputation, CVEs, typosquats, and dependency risk.
+- Prompt-injection corpus and regression benchmark are ready for continuous
+  rule hardening with category-level coverage and regression-gate output.
+- Enterprise reports include JSON plus self-contained HTML executive output
+  with risk posture, priority findings, and category exposure.
+
+### 6. ECC Tools Billing, Deep Analysis, PR Checks, And Linear Sync
+
+Target: 2026-06-21
+
+Acceptance:
+
+- Native GitHub Marketplace billing announcement is backed by verified
+  implementation and docs.
+- Internal billing readiness audit covers plan limits, seats, entitlement
+  mapping, Marketplace plan shape, subscription state, overage hooks, and
+  failure modes.
+- Deep analyzer covers diff patterns, CI/CD workflows, dependency/security
+  surface, PR review behavior, failure history, harness config, skill quality,
+  and reference-set/RAG comparison.
+- PR check suite taxonomy includes Security Evidence, Harness Drift, Install
+  Manifest Integrity, CI/CD Recommendation, Cost/Token Risk, and Agent Config
+  Review.
+- Cost/token-risk predictive follow-ups flag AI routing, model-call, usage,
+  quota, and budget changes when budget evidence is missing.
+- Reference-set validation follow-ups flag analyzer, skill, agent, command, and
+  harness-guidance changes that lack eval, golden trace, benchmark, or
+  maintained reference-set evidence.
+- Linear sync design maps findings to issues/status without flooding the
+  workspace.
+- Follow-up generation caps automatic GitHub object creation and keeps overflow
+  findings in a copy-ready project sync backlog.
+
+### 7. Legacy Audit And Stale-Work Salvage Closure
+
+Target: 2026-06-15
+
+Acceptance:
+
+- Legacy directories and orphaned handoffs are inventoried.
+- Each useful artifact is marked landed, Linear/project-tracked, salvage
+  branch, or archive/no-action.
+- Workspace-level legacy repos are mined only through sanitized maintainer
+  branches; raw context, secrets, personal paths, local settings, and private
+  drafts are never imported wholesale.
+- Stale PR salvage policy stays in force: close stale/conflicted PRs first,
+  record a salvage ledger item, then port useful compatible content on
+  maintainer branches with attribution.
+- #1687 localization leftovers are handled only by translator/manual review,
+  not blind cherry-pick.
+
+## Next Engineering Slices
+
+1. Decide whether AgentShield PDF export adds value beyond the merged HTML
+   executive report and corpus benchmark output.
+2. Extend ECC Tools deep analysis and Linear/project sync without flooding the
+   workspace.

docs/ECC-2.0-REFERENCE-ARCHITECTURE.md

@@ -1,54 +1,238 @@
 # ECC 2.0 Reference Architecture
 
-Research summary from competitor/reference analysis (2026-03-22).
+Current execution mirror:
+[`ECC-2.0-GA-ROADMAP.md`](ECC-2.0-GA-ROADMAP.md).
 
-## Competitive Landscape
+This document turns the May 2026 reference sweep into concrete ECC backlog
+shape. It is not a second strategy memo: every reference pressure below should
+land as an adapter, check, observable signal, security policy, PR review
+surface, or release-readiness gate.
 
-| Project | Stars | Language | Type | Multi-Agent | Worktrees | Terminal-native |
-|---------|-------|----------|------|-------------|-----------|-----------------|
-| **ECC 2.0** | - | Rust | TUI | Yes | Yes | **Yes (SSH)** |
-| superset-sh/superset | 7.7K | TypeScript | Electron | Yes | Yes | No (desktop) |
-| standardagents/dmux | 1.2K | TypeScript | TUI (Ink) | Yes | Yes | Yes |
-| opencode-ai/opencode | 11.5K | Go | TUI | No | No | Yes |
-| smtg-ai/claude-squad | 6.5K | Go | TUI | Yes | Yes | Yes |
+## Reference Baseline
 
-## Three-Layer Architecture
+Snapshot date: 2026-05-12.
 
-```
-┌─────────────────────────────────┐
-│        TUI Layer (ratatui)      │  User-facing dashboard
-│  Panes, diff viewer, hotkeys    │  Communicates via Unix socket
-├─────────────────────────────────┤
-│     Runtime Layer (library)     │  Workspace runtime, agent registry,
-│  State persistence, detection   │  status detection, SQLite
-├─────────────────────────────────┤
-│     Daemon Layer (process)      │  Persistent across TUI restarts
-│  Terminal sessions, git ops,    │  PTY management, heartbeats
-│  agent process supervision      │
-└─────────────────────────────────┘
+| Reference | Primary pressure on ECC 2.0 | Concrete ECC delta |
+| --- | --- | --- |
+| [`stablyai/orca`](https://github.com/stablyai/orca) | Worktree-native multi-agent IDE with terminals, source control, GitHub integration, SSH, notifications, design/browser mode, account switching, and per-worktree context. | Treat worktree lifecycle, review state, notification state, and account/provider identity as first-class adapter signals. |
+| [`superset-sh/superset`](https://github.com/superset-sh/superset) | Desktop AI-agent workspace with parallel execution, worktree isolation, diff review, workspace presets, and broad CLI-agent compatibility. | Add workspace preset taxonomy and make ECC2 session/worktree state exportable enough for external editors to consume. |
+| [`standardagents/dmux`](https://github.com/standardagents/dmux) | Tmux/worktree orchestration, lifecycle hooks, multi-select agent control, smart merging, file browser, notifications, and cleanup. | Add lifecycle-hook coverage to the harness matrix and define merge/conflict queue events. |
+| [`aidenybai/ghast`](https://github.com/aidenybai/ghast) | Native macOS terminal multiplexer with cwd-grouped workspaces, panes, tabs, drag/drop, search, and notifications. | Preserve terminal-native ergonomics while adding cwd/session grouping and searchable handoff/session records. |
+| [`jarrodwatts/claude-hud`](https://github.com/jarrodwatts/claude-hud) | Always-visible Claude Code statusline for context, tools, agents, todos, and transcript-backed activity. | Formalize the ECC HUD/status payload for context, cost, tool calls, active agents, todos, queue state, checks, and risk. |
+| [`stanford-iris-lab/meta-harness`](https://github.com/stanford-iris-lab/meta-harness) | Automated search over task-specific harness design: what to store, retrieve, and show. | Split ECC improvement loops into scenario spec, proposer trace, verifier result, and promoted playbook. |
+| [`greyhaven-ai/autocontext`](https://github.com/greyhaven-ai/autocontext) | Recursive harness improvement using traces, reports, artifacts, datasets, playbooks, and role-separated evaluators. | Store reusable traces and playbooks before mutating installed harness assets. |
+| [`NousResearch/hermes-agent`](https://github.com/NousResearch/hermes-agent) | Self-improving operator shell with memories, skills, scheduler, gateways, subagents, terminal backends, and migration tooling. | Keep ECC portable across local, SSH, container, and hosted terminal backends without hiding the underlying commands. |
+| [`anthropics/claude-code`](https://github.com/anthropics/claude-code), [`sst/opencode`](https://github.com/sst/opencode), Zed, Codex, Cursor, Gemini | Different agent harnesses expose different hooks, plugin surfaces, session stores, config files, and review loops. | Maintain a public adapter compliance matrix instead of treating one harness as the canonical UX. |
+| Local Claude Code source review | Session, tool, permission, hook, remote, analytics, task, and context-suggestion surfaces are more structured than the public CLI UX suggests. | Model status and risk events around session messages, permission requests, tool progress, context pressure, and summary state. |
+
+## Architecture Shape
+
+ECC 2.0 should be a harness operating system, not only a catalog of commands,
+agents, and skills.
+
+```text
+┌──────────────────────────────────────────────────────────────┐
+│ Operator Surface                                             │
+│ CLI, plugin, TUI, HUD/statusline, release gates, PR checks   │
+├──────────────────────────────────────────────────────────────┤
+│ Harness Adapter Layer                                        │
+│ Claude Code, Codex, OpenCode, Cursor, Gemini, Zed, dmux,     │
+│ Orca, Superset, Ghast, terminal-only                         │
+├──────────────────────────────────────────────────────────────┤
+│ Worktree, Session, And Queue Runtime                         │
+│ worktrees, panes, sessions, todos, checks, merge/conflict    │
+│ queues, notification state, ownership, handoff exports       │
+├──────────────────────────────────────────────────────────────┤
+│ Observability And Evaluation Loop                            │
+│ JSONL traces, status snapshots, risk ledger, harness audit,  │
+│ scenario specs, verifiers, promoted playbooks, RAG sets      │
+├──────────────────────────────────────────────────────────────┤
+│ Security And Commercial Platform                             │
+│ AgentShield policies/SARIF, ECC Tools checks, billing,       │
+│ Linear/GitHub sync, enterprise reports                       │
+└──────────────────────────────────────────────────────────────┘
 ```
 
-## Patterns to Adopt
+## Reference-To-Backlog Map
 
-### From Superset (Electron, 7.7K stars)
-- **Workspace Runtime Registry** — trait-based abstraction with capability flags
-- **Persistent daemon terminal** — sessions survive restarts via IPC
-- **Per-project mutex** for git operations (prevents race conditions)
-- **Port allocation** per workspace for dev servers
-- **Cold restore** from serialized terminal scrollback
+### Worktree And Session Orchestration
 
-### From dmux (Ink TUI, 1.2K stars)
-- **Worker-per-pane status detection** — fingerprint terminal output + LLM classification
-- **Agent Registry** — centralized agent definitions (install check, launch cmd, permissions)
-- **Retry strategies** — different policies for destructive vs read-only operations
-- **PaneLifecycleManager** — exclusive locks preventing concurrent pane races
-- **Lifecycle hooks** — worktree_created, pre_merge, post_merge
-- **Background cleanup queue** — async worktree deletion
+Adopt from Orca, Superset, dmux, and Ghast:
 
-## ECC 2.0 Advantages
-- Terminal-native (works over SSH, unlike Superset)
-- Integrates with 116-skill ecosystem
-- AgentShield security scanning
-- Self-improving skill evolution (continuous-learning-v2)
-- Rust single binary (3.4MB, no runtime deps)
-- First Rust-based agentic IDE TUI in open source
+- Worktree lifecycle events: create, resume, pause, stop, diff, review, PR,
+  merge-ready, conflict, stale, close, salvage.
+- Session grouping by repo, branch, cwd, task, owner, and harness.
+- Workspace presets for release lane, PR triage lane, docs lane, security lane,
+  and test-writer lane.
+- Notifications for blocked CI, dirty worktrees, merge conflicts, stale review,
+  and finished autonomous runs.
+- Review loops that can annotate diffs and PRs without taking ownership away
+  from maintainers.
+
+Repo work:
+
+- `everything-claude-code`: extend the adapter compliance matrix and public
+  scorecard onramp.
+- `ecc2`: surface session/worktree state through a stable local payload before
+  adding hosted telemetry.
+- `ECC-Tools`: consume the same lifecycle events for PR checks, issue routing,
+  and Linear sync.
+
+Verification:
+
+- `npm run harness:audit -- --format json`
+- `npm run observability:ready`
+- targeted adapter matrix tests once the matrix moves from docs to data
+
+### HUD, Status, And Observability
+
+Adopt from Claude HUD and the Claude Code source review:
+
+- Context pressure: usage, compaction risk, large-result warnings, and summary
+  state.
+- Tool activity: active tool, recent tools, duration, risky operations, and
+  permission requests.
+- Agent activity: active subagents, delegated task, branch/worktree, and wait
+  state.
+- Queue activity: open PRs/issues, CI state, stale/conflict batches, review
+  state, and closed-stale salvage backlog.
+- Cost/risk: token cost estimate, destructive-operation risk, hook/MCP risk,
+  and security scan state.
+
+Repo work:
+
+- Keep `docs/architecture/observability-readiness.md` as the operator-facing
+  readiness gate.
+- Define a versioned HUD/status JSON contract that both ECC2 and ECC Tools can
+  consume.
+- Add sample exports from `loop-status`, `session-inspect`, harness audit, and
+  risk ledger into a fixture directory before building visual UI.
+
+Verification:
+
+- `npm run observability:ready`
+- fixture validation for every status payload
+- cross-platform smoke test for commands that read session history
+
+### Self-Improving Harness Loop
+
+Adopt from Meta-Harness, Autocontext, and Hermes Agent:
+
+- Separate the loop into observation, proposal, verification, promotion, and
+  rollback.
+- Store every proposed improvement as trace plus artifact, not only as a final
+  changed file.
+- Promote playbooks only after a verifier proves that they improve a scenario
+  without widening blast radius.
+- Use RAG/reference sets for vetted ECC patterns, team history, CI failures,
+  review outcomes, harness config quality, and security decisions.
+
+Repo work:
+
+- `everything-claude-code`: document scenario specs, verifier contracts, and
+  playbook promotion rules.
+- `ECC-Tools`: map analyzer findings to PR comments, check runs, and Linear
+  tasks without flooding the workspace.
+- `agentshield`: feed prompt-injection and config-risk findings into regression
+  suites.
+
+Verification:
+
+- read-only prototype that emits a trace, report, candidate playbook, and
+  verifier result
+- regression fixture proving a bad proposal is rejected
+
+### AgentShield Enterprise Security Platform
+
+AgentShield should move from useful scanner to enterprise security platform.
+
+Backlog shape:
+
+- Policy schema for org baseline, rule severity, owner, exception, expiration,
+  evidence, and audit trail.
+- SARIF output for GitHub code scanning.
+- Policy packs for OSS, team, enterprise, regulated, high-risk hooks/MCP, and
+  CI enforcement.
+- Supply-chain intelligence for MCP packages, npm/pip provenance, CVEs,
+  typosquats, and dependency reputation.
+- Prompt-injection corpus and regression benchmark.
+- JSON plus executive HTML/PDF report output.
+
+Verification:
+
+- schema unit tests
+- SARIF fixture tests
+- policy-pack golden tests
+- false-positive regression tests from the public issue history
+
+### ECC Tools Commercial And Review Platform
+
+ECC Tools should become the GitHub-native layer for billing, deep analysis,
+PR checks, and Linear progress tracking.
+
+Backlog shape:
+
+- Native GitHub Marketplace billing audit before any payments announcement:
+  plans, seats, org/account mapping, subscription state, overage behavior,
+  downgrade/cancel behavior, and failure modes.
+- Deep analyzer comparable in scope to the useful parts of GitGuardian,
+  Dependabot, CodeRabbit, and Greptile: security evidence, dependency risk,
+  CI/CD recommendations, PR review behavior, config quality, token/cost risk,
+  and harness drift.
+- RAG/reference set over vetted ECC patterns, historical PR outcomes,
+  dependency advisories, CI failures, review decisions, and team-specific
+  conventions.
+- Linear sync that maps findings to project status, milestone evidence, and
+  owner-ready issues without exhausting issue limits.
+
+Verification:
+
+- check-run fixture tests
+- billing webhook replay tests
+- analyzer golden PR fixtures
+- Linear sync dry-run fixture
+
+### Closed-Stale Salvage Lane
+
+Closing stale PRs keeps the public queue usable, but useful work should not be
+lost because a contributor no longer has time to rebase.
+
+Execution rule:
+
+1. Close stale, conflicted, or obsolete PRs with a clear courtesy comment.
+2. Record them in a salvage ledger with source PR, author, reason closed,
+   useful files/concepts, risk, and recommended maintainer action.
+3. After the cleanup batch, inspect each closed PR diff manually.
+4. Cherry-pick only when the patch still applies cleanly and preserves current
+   architecture. Otherwise reimplement the useful idea in a fresh maintainer
+   branch.
+5. Preserve attribution in the commit body or PR body.
+6. Comment back on the source PR when useful work lands, linking the maintainer
+   PR or merged commit.
+7. Mark the ledger item as landed, superseded, Linear-tracked, or no-action.
+
+Required safeguards:
+
+- Never blind cherry-pick generated churn, bulk localization, or dependency
+  major-version changes.
+- Prefer small maintainer PRs over one salvage megabranch.
+- Run the same validation gates as normal code, docs, or catalog changes.
+- Keep contributor credit even when the final implementation is rewritten.
+
+## Near-Term Implementation Order
+
+1. Extend the harness adapter matrix and public scorecard onramp.
+2. Add the release/name/plugin publication checklist with evidence fields.
+3. Define the HUD/status JSON contract and fixture directory.
+4. Start AgentShield policy schema plus SARIF fixtures.
+5. Audit ECC Tools billing and check-run surfaces.
+6. Inventory legacy folders and closed-stale PRs into the salvage ledger.
+7. Port useful stale work in small attributed maintainer PRs.
+
+## Non-Goals
+
+- Hosted telemetry before the local event model is useful and testable.
+- Automatic mutation of user harness configs without verifier evidence.
+- Treating any one agent harness as the canonical interface.
+- Release or payments announcements before command, package, marketplace, and
+  billing evidence is fresh.

docs/HERMES-SETUP.md

@@ -83,14 +83,27 @@ These stay local and should be configured per operator:
 ## Suggested Bring-Up Order
 
 0. Run `ecc migrate audit --source ~/.hermes` first to inventory the legacy workspace and see which parts already map onto ECC2.
-0.5. Generate and review artifacts with `ecc migrate plan` / `ecc migrate scaffold`, scaffold reusable legacy skills with `ecc migrate import-skills --output-dir migration-artifacts/skills`, scaffold legacy tool translation templates with `ecc migrate import-tools --output-dir migration-artifacts/tools`, scaffold legacy bridge plugins with `ecc migrate import-plugins --output-dir migration-artifacts/plugins`, preview recurring jobs with `ecc migrate import-schedules --dry-run`, preview gateway dispatch with `ecc migrate import-remote --dry-run`, preview safe env/service context with `ecc migrate import-env --dry-run`, then import sanitized workspace memory with `ecc migrate import-memory`.
-1. Install ECC and verify the baseline harness setup.
+0.5. Plan and scaffold migration artifacts before importing anything:
+   - generate reviewable plans with `ecc migrate plan` and `ecc migrate scaffold`
+   - scaffold reusable legacy skills with `ecc migrate import-skills --output-dir migration-artifacts/skills`
+   - scaffold tool translation templates with `ecc migrate import-tools --output-dir migration-artifacts/tools`
+   - scaffold bridge plugin templates with `ecc migrate import-plugins --output-dir migration-artifacts/plugins`
+   - preview recurring jobs with `ecc migrate import-schedules --dry-run`
+   - preview gateway dispatch with `ecc migrate import-remote --dry-run`
+   - preview safe env/service context with `ecc migrate import-env --dry-run`
+   - import sanitized workspace memory with `ecc migrate import-memory`
+1. Install ECC and verify the baseline harness setup with `node tests/run-all.js`; the expected result is a zero-failure test summary.
 2. Install Hermes and point it at ECC-imported skills.
 3. Register the MCP servers you actually use every day.
 4. Authenticate Google Drive first, then GitHub, then distribution channels.
 5. Start with a small cron surface: readiness check, content accountability, inbox triage, revenue monitor.
 6. Only then add heavier personal workflows like health, relationship graphing, or outbound sequencing.
 
+## Related Docs
+
+- [Hermes/OpenClaw migration guide](HERMES-OPENCLAW-MIGRATION.md)
+- [Cross-harness architecture](architecture/cross-harness.md)
+
 ## Why Hermes x ECC
 
 This stack is useful when you want:

docs/JOYCODE-GUIDE.md

@@ -0,0 +1,55 @@
+# JoyCode Adapter Guide
+
+JoyCode can consume ECC through the selective installer. The adapter installs shared ECC commands, agents, skills, and flattened rules into a project-local `.joycode/` directory.
+
+## Install
+
+Preview the install plan:
+
+```bash
+node scripts/install-plan.js --target joycode --profile full
+```
+
+Apply it to the current project:
+
+```bash
+node scripts/install-apply.js --target joycode --profile full
+```
+
+For a smaller install, select modules explicitly:
+
+```bash
+node scripts/install-apply.js --target joycode --modules rules-core,commands-core,workflow-quality
+```
+
+## Layout
+
+The project adapter writes managed files under:
+
+```text
+.joycode/
+  agents/
+  commands/
+  rules/
+  skills/
+  mcp-configs/
+  scripts/
+  ecc-install-state.json
+```
+
+Rules are flattened into namespaced filenames so a JoyCode project does not receive nested rule directories such as `rules/common/coding-style.md`. Commands, agents, and skills keep the same structure they use elsewhere in ECC.
+The full profile also includes shared MCP and setup helper files that other ECC project-local adapters use.
+
+## Uninstall
+
+Use ECC's managed uninstall path instead of deleting files by hand:
+
+```bash
+node scripts/uninstall.js --target joycode
+```
+
+The uninstall command reads `.joycode/ecc-install-state.json` and removes only files that ECC installed. User-created JoyCode files are preserved.
+
+## Source PR
+
+This adapter salvages the useful project-local JoyCode intent from stale PR #1429 while replacing the standalone shell installer with ECC's current install-state and uninstall machinery.

docs/PLAN-PRD-PATTERN.md

@@ -0,0 +1,154 @@
+# Plan-PRD Pattern: Markdown-Staged Planning Flow
+
+A lightweight, SDLC-aligned planning workflow where each phase of the lifecycle produces a committable markdown **staging file** that the next command consumes.
+
+> Short version: `/plan-prd` writes a PRD, `/plan` writes a plan, the `tdd-workflow` skill implements it, and `/pr` ships it. Each arrow is a file on disk, not a conversation in memory.
+
+## Feature: Markdown Staging Files
+
+Every planning artifact is a plain `.md` file under `.claude/`:
+
+```
+.claude/
+  prds/      # Product Requirements Documents from /plan-prd
+  plans/     # Implementation plans from /plan
+  reviews/   # Code review artifacts from /code-review
+```
+
+These files are:
+
+- **Plain markdown** — readable by humans, diffable in PRs, grep-able at CLI.
+- **Committable** — check them in alongside code so the intent travels with the implementation.
+- **Composable** — each command accepts the previous stage's file as its `$ARGUMENTS`, so the toolchain composes via paths rather than in-context state.
+- **Resumable** — close the session, open a new one tomorrow, pass the file path back in.
+
+## Flow
+
+```
+┌───────────────────────────┐
+│ /plan-prd "<idea>"        │  Requirements phase
+│  → .claude/prds/X.prd.md  │   Problem · Users · Hypothesis · Scope
+└─────────────┬─────────────┘
+              │
+              ▼
+┌───────────────────────────┐
+│ /plan <prd-path>          │  Design phase
+│  → .claude/plans/X.plan.md│   Patterns · Files · Tasks · Validation
+└─────────────┬─────────────┘
+              │
+              ▼
+┌───────────────────────────┐
+│ tdd-workflow skill         │  Implementation phase
+│  → code + tests           │   Test-first, minimal diff
+└─────────────┬─────────────┘
+              │
+              ▼
+┌───────────────────────────┐
+│ /pr                        │  Delivery phase
+│  → GitHub PR               │   Links back to PRD + plan
+└───────────────────────────┘
+```
+
+Each box is a **gate**. You can:
+
+- Stop between gates — the artifact persists.
+- Restart from any gate using the artifact path.
+- Skip gates for small work — feed `/plan` free-form text and ignore `/plan-prd`.
+- Run a gate standalone — `/plan "refactor X"` produces a conversational plan with no artifact.
+
+## Why `/plan-prd` Is Additional to `/plan`
+
+They answer different questions. Mixing them causes scope creep.
+
+| Command | Answers | SDLC Phase | Artifact |
+|---|---|---|---|
+| `/plan-prd` | *What problem? For whom? How do we know we're done?* | Requirements | `.claude/prds/{name}.prd.md` |
+| `/plan` | *What files, patterns, and tasks satisfy the requirement?* | Design + Implementation strategy | `.claude/plans/{name}.plan.md` (PRD mode) or inline (text mode) |
+
+### Why not combine them?
+
+- **Separation of concerns.** PRDs ask *why*; plans ask *how*. Bundling them creates one oversized command that does both poorly, as the old `/prp-prd` → `/prp-plan` pair demonstrated (8-phase interrogation with implementation-phase tables mixed into requirements).
+- **Different audiences.** A stakeholder reviewing a PRD does not care about file paths or type-check commands. An engineer reading a plan does not need the market-research phase.
+- **Different lifespans.** A PRD can remain stable while its plan is rewritten multiple times as implementation assumptions change.
+- **Optional step.** Many changes (bug fixes, small refactors, single-file additions) don't need a PRD. `/plan` alone is enough. Forcing a PRD on every change is bureaucracy.
+
+### When to use each
+
+Use `/plan-prd` when:
+
+- Scope is unclear or contested.
+- Multiple stakeholders need to align on the problem before solutioning.
+- The change is large enough that writing down the hypothesis is cheaper than relitigating scope mid-implementation.
+
+Use `/plan` directly when:
+
+- Requirements are already clear (a bug report, a scoped refactor, a known migration).
+- The work is small enough that a conversational plan + confirmation gate is sufficient.
+- You already have a PRD — pass it to `/plan` and skip `/plan-prd`.
+
+## Usage
+
+### Full flow (feature with unclear scope)
+
+```bash
+# 1. Draft the PRD
+/plan-prd "Per-user rate limits on the public API"
+
+# → .claude/prds/per-user-rate-limits.prd.md created
+# Answer the framing questions, provide evidence, define hypothesis and scope.
+
+# 2. Pick the next pending milestone and produce a plan
+/plan .claude/prds/per-user-rate-limits.prd.md
+
+# → .claude/plans/per-user-rate-limits.plan.md created
+# The plan includes patterns to mirror, files to change, and validation commands.
+# PRD's Delivery Milestones table updates the selected row to `in-progress`.
+
+# 3. Implement test-first
+Use the tdd-workflow skill
+
+# 4. Open the PR
+/pr
+# → PR body auto-references .claude/prds/... and .claude/plans/...
+```
+
+### Quick flow (scope already clear)
+
+```bash
+/plan "Add retry with exponential backoff to the notifier"
+# Conversational planning, no artifact.
+# Confirm, then use the tdd-workflow skill.
+```
+
+### Reference an existing PRD from elsewhere
+
+```bash
+# PRD was written by someone else, lives in your repo
+/plan docs/rfcs/0042-rate-limiting.prd.md
+```
+
+`/plan` detects any `.prd.md` path and switches to artifact mode, parsing the Delivery Milestones table.
+
+## Why staging files beat in-context state
+
+- **Transferable**: drop the PRD path into a fresh session and you're caught up — no replaying a long conversation.
+- **Auditable**: the PR reviewer sees *what you intended* next to *what you built*.
+- **Versioned**: the staging file evolves in git history, same as code.
+- **Machine-parseable**: `/plan` programmatically picks the next pending milestone; `/pr` programmatically links artifacts in the PR body. No prompt engineering required.
+
+## Related commands
+
+- `/plan-prd` — requirements (this pattern entry point).
+- `/plan` — planning (consumes PRDs or free-form text).
+- `tdd-workflow` skill — test-first implementation.
+- `/pr` — open a PR that references PRDs and plans.
+- `/code-review` — reviews local diffs or PRs; auto-detects `.claude/prds/` and `.claude/plans/` as context.
+
+## Compatibility
+
+This pattern adds ECC-native staging-file commands alongside the existing `prp-*` command set. The legacy PRP commands remain available for deeper PRP workflows and for users who already have `.claude/PRPs/` artifacts.
+
+- `/plan-prd` is the lean requirements entry point for `.claude/prds/`.
+- `/plan` can consume `.prd.md` files and produce `.claude/plans/` artifacts without requiring the legacy PRP directory layout.
+- `/pr` is the ECC-native PR creation command and can reference `.claude/prds/` and `.claude/plans/`.
+- `/prp-prd`, `/prp-plan`, `/prp-implement`, `/prp-commit`, and `/prp-pr` remain valid legacy/deep workflow commands.

docs/QWEN-GUIDE.md

@@ -0,0 +1,54 @@
+# Qwen CLI Adapter Guide
+
+ECC can install its managed command, agent, skill, rule, and MCP surfaces into the Qwen CLI home directory.
+
+## Install
+
+From the ECC repository root:
+
+```bash
+./install.sh --target qwen --profile minimal
+```
+
+Preview a larger install before copying files:
+
+```bash
+./install.sh --target qwen --profile full --dry-run
+```
+
+The Qwen adapter writes into `~/.qwen/` and records managed file ownership in `~/.qwen/ecc-install-state.json`.
+
+## Installed Layout
+
+The managed install can populate:
+
+```text
+~/.qwen/
+  QWEN.md
+  agents/
+  commands/
+  mcp-configs/
+  rules/
+  skills/
+  ecc-install-state.json
+```
+
+The installer preserves the source layout for rules, so language rule sets stay under paths such as `~/.qwen/rules/common/` and `~/.qwen/rules/typescript/`.
+
+## Updating
+
+Rerun the same install command after pulling ECC updates. The installer uses the install-state file to update ECC-managed files without claiming unrelated user files in `~/.qwen/`.
+
+## Uninstalling
+
+Use the managed uninstall path rather than deleting the whole Qwen directory:
+
+```bash
+node scripts/uninstall.js --target qwen
+```
+
+That removes files recorded in `~/.qwen/ecc-install-state.json` and leaves unrelated Qwen configuration alone.
+
+## Scope
+
+This target is intentionally narrower than stale PR #1352. It ports the maintainable Qwen install-target intent onto the current selective installer and avoids unverified hook-runtime claims until Qwen's hook/event contract is confirmed.

docs/SELECTIVE-INSTALL-ARCHITECTURE.md

@@ -640,7 +640,7 @@ Suggested operation shape:
   "kind": "copy",
   "moduleId": "rules-core",
   "source": "rules/common/coding-style.md",
-  "destination": "/Users/example/.claude/rules/common/coding-style.md",
+  "destination": "/Users/example/.claude/rules/ecc/common/coding-style.md",
   "ownership": "managed",
   "overwritePolicy": "replace"
 }
@@ -711,7 +711,7 @@ Suggested payload:
     {
       "kind": "copy",
       "moduleId": "rules-core",
-      "destination": "/Users/example/.claude/rules/common/coding-style.md",
+      "destination": "/Users/example/.claude/rules/ecc/common/coding-style.md",
       "digest": "sha256:..."
     }
   ]

docs/architecture/cross-harness.md

@@ -13,6 +13,9 @@ The goal is to keep the durable parts of agentic work in one repo:
 
 Claude Code, Codex, OpenCode, Cursor, Gemini, and future harnesses should adapt those assets at the edge instead of requiring a new workflow model for every tool.
 
+For the operator-facing support matrix and scorecard workflow, see
+[Harness Adapter Compliance Matrix](harness-adapter-compliance.md).
+
 ## Portability Model
 
 | Surface | Shared Source | Harness Adapter | Current Status |
@@ -78,6 +81,25 @@ Do not ship:
 - private datasets
 - local-only automation packs that have not been reviewed
 
+## Worked Example
+
+Use `skills/hermes-imports/SKILL.md` as the same skill source across harnesses.
+
+The workflow is:
+
+1. Author the durable behavior once in `skills/hermes-imports/SKILL.md`.
+2. Keep secrets, local paths, and raw operator memory out of the skill.
+3. Let each harness adapt how the skill is loaded.
+4. Test the source skill and the harness-facing metadata separately.
+
+Claude Code gets the skill through the Claude plugin surface and can enforce related hooks natively.
+
+Codex reads the repo instructions, `.codex-plugin/plugin.json`, and the MCP reference config. The same skill source still describes the workflow, but hook parity is instruction-backed unless Codex adds a native hook surface.
+
+OpenCode gets the skill through the OpenCode package/plugin surface. Event handling can reuse ECC hook logic through the adapter layer, while the skill text stays unchanged.
+
+If a change requires editing three harness copies of the same workflow, the shared source is in the wrong place. Put the workflow back in `skills/`, then adapt only loading, event shape, or command routing at the harness edge.
+
 ## Today vs Later
 
 Supported today:

docs/architecture/harness-adapter-compliance.md

@@ -0,0 +1,105 @@
+# Harness Adapter Compliance Matrix
+
+This matrix is the public onramp for teams that want to use ECC across more
+than one coding harness. It turns the cross-harness architecture into a
+practical scorecard: what works today, what is instruction-only, what needs an
+adapter, and what evidence an operator should collect before trusting a setup.
+
+ECC's durable units stay in shared sources:
+
+- `skills/*/SKILL.md`
+- `rules/`
+- `commands/`
+- `hooks/hooks.json`
+- `scripts/hooks/`
+- MCP reference configs
+- session and observability contracts
+
+Harness-specific files should only adapt loading, event shape, command names,
+or platform limits.
+
+## Compliance States
+
+| State | Meaning |
+| --- | --- |
+| Native | ECC can install or verify the surface directly for this harness. |
+| Adapter-backed | ECC has a thin adapter, plugin, or package surface, but parity differs by harness. |
+| Instruction-backed | ECC can provide the guidance and files, but the harness does not expose the runtime hook/session surface ECC needs for enforcement. |
+| Reference-only | The tool is useful as a design pressure or external runtime, but ECC does not yet ship a direct installer or adapter for it. |
+
+## Matrix
+
+The matrix below is rendered from
+`scripts/lib/harness-adapter-compliance.js` and verified by
+`npm run harness:adapters -- --check`.
+
+<!-- harness-adapter-compliance:matrix-start -->
+| Harness or runtime | State | Supported assets | Unsupported or different surfaces | Install or onramp | Verification command | Risk notes |
+| --- | --- | --- | --- | --- | --- | --- |
+| Claude Code | Native | Claude plugin assets; skills; commands; hooks; MCP config; local rules; statusline-oriented workflows | Claude-native hooks do not imply parity in other harnesses | `./install.sh --profile minimal --target claude`; Claude plugin install | `npm run harness:audit -- --format json`; `node scripts/session-inspect.js --list-adapters` | Avoid loading every skill by default; keep hooks opt-in and inspectable. |
+| Codex | Instruction-backed | `AGENTS.md`; Codex plugin metadata; skills; MCP reference config; command patterns | Native hook enforcement and Claude slash-command semantics are not equivalent | `./install.sh --profile minimal --target codex`; repo-local `AGENTS.md` review | `npm run harness:audit -- --format json` | Treat hooks as policy text unless a native Codex hook surface exists. |
+| OpenCode | Adapter-backed | OpenCode package/plugin metadata; shared skills; MCP config; event adapter patterns | Event names, plugin packaging, and command dispatch differ from Claude Code | OpenCode package or plugin surface from this repo | `node tests/scripts/build-opencode.test.js`; `npm run harness:audit -- --format json` | Keep hook logic in shared scripts and adapt only event shape at the edge. |
+| Cursor | Adapter-backed | Cursor rules; project-local skills; hook adapter; shared scripts | Cursor hook events and rule loading differ from Claude Code | `./install.sh --profile minimal --target cursor` | `node tests/lib/install-targets.test.js`; `npm run harness:audit -- --format json` | Cursor adapters must preserve existing project rules and avoid silent overwrite. |
+| Gemini | Instruction-backed | Gemini project-local instructions; shared skills; rules; compatibility docs | No full ECC hook parity; ecosystem ports must document drift from upstream ECC | `./install.sh --profile minimal --target gemini` | `node tests/lib/install-targets.test.js` | Treat Gemini ports as ecosystem adapters until validated end to end inside Gemini CLI. |
+| Zed-adjacent workflows | Instruction-backed | shared skills; `AGENTS.md` style project instructions; verification loops | Zed agent surfaces vary; no first-party ECC installer is shipped today | Manual copy from shared ECC sources until adapter requirements settle | `npm run harness:audit -- --format json` | Do not claim native Zed support before a real adapter and verification path exist. |
+| dmux | Adapter-backed | session snapshots; tmux/worktree orchestration status; handoff exports | dmux is an orchestration runtime, not an install target for skills/rules | `node scripts/session-inspect.js --list-adapters`; dmux session target inspection | `node tests/lib/session-adapters.test.js` | Treat dmux events as session/runtime signals, not as a replacement for repo validation. |
+| Orca | Reference-only | worktree lifecycle; review state; notification; provider-identity design pressure | No ECC installer or direct adapter today | Use as a comparison target for worktree/session state requirements | `npm run observability:ready` | Do not import product-specific assumptions; convert lessons into ECC event fields. |
+| Superset | Reference-only | workspace presets; parallel-agent review loops; worktree isolation design pressure | No ECC installer or direct adapter today | Use as a comparison target for workspace preset taxonomy | `npm run observability:ready` | Keep ECC portable; do not require a desktop workspace to get basic value. |
+| Ghast | Reference-only | terminal-native pane grouping; cwd grouping; search; notifications | No ECC installer or direct adapter today | Use as a comparison target for terminal-first session grouping | `node scripts/session-inspect.js --list-adapters` | Preserve terminal ergonomics before adding visual UI assumptions. |
+| Terminal-only | Native | skills; rules; commands; scripts; harness audit; observability readiness; handoffs | No external UI, no automatic session control unless scripts are run explicitly | Clone repo; run commands directly; use minimal profile for project installs | `npm run harness:audit -- --format json`; `npm run observability:ready` | This is the fallback contract; every higher-level adapter should degrade to it. |
+<!-- harness-adapter-compliance:matrix-end -->
+
+## Scorecard Onramp
+
+Use this sequence before asking ECC to make a team or repo setup more
+autonomous:
+
+```bash
+npm run harness:adapters -- --check
+npm run harness:audit -- --format json
+npm run observability:ready
+node scripts/session-inspect.js --list-adapters
+node scripts/loop-status.js --json --write-dir .ecc/loop-status
+```
+
+Read the result as a setup scorecard, not a product badge:
+
+- `harness:adapters -- --check` proves this public matrix still matches the
+  adapter source data and required evidence fields.
+- `harness:audit` scores tool coverage, context efficiency, quality gates,
+  memory persistence, eval coverage, security guardrails, and cost efficiency.
+- `observability:ready` proves the repo still exposes the local status,
+  session, tool-activity, risk-ledger, and release-onramp signals.
+- `session-inspect --list-adapters` shows which session surfaces are actually
+  inspectable in the current environment.
+- `loop-status --json` creates a machine-readable handoff/status payload for
+  longer autonomous runs.
+
+## Data-Backed Scorecard Contract
+
+Each adapter record exposes:
+
+- `id`
+- `state`
+- `supported_assets`
+- `unsupported_surfaces`
+- `install_or_onramp`
+- `verification_commands`
+- `risk_notes`
+- `last_verified_at`
+- `owner`
+- `source_docs`
+
+The validator fails if a public adapter claim has no install path,
+verification command, risk note, owner, source doc, or verification date.
+
+## Operating Rules
+
+- Prefer small, additive adapters over harness-specific forks of the same
+  workflow.
+- Do not call a harness native until the adapter has an install path and a
+  verification command.
+- Keep Codex, Gemini, and Zed surfaces honest when enforcement is
+  instruction-backed rather than runtime-backed.
+- Treat reference-only tools as design pressure until ECC has a direct adapter.
+- Keep the terminal-only path healthy; it is the portability floor.

docs/architecture/observability-readiness.md

@@ -0,0 +1,66 @@
+# ECC 2.0 Observability Readiness
+
+ECC 2.0 should be observable before it becomes more autonomous. The local
+default is an opt-in, repo-owned readiness gate that checks whether the core
+signals are present without sending telemetry anywhere.
+
+Run:
+
+```bash
+npm run observability:ready
+node scripts/observability-readiness.js --format json
+```
+
+The gate is deterministic and safe to run in CI. It only checks repository
+files and reports whether the release surface can expose the signals an
+operator needs.
+
+## Signal Model
+
+- Live status: `scripts/loop-status.js` can emit JSON, watch active loops, and
+  write snapshots for dashboards or handoffs.
+- Session traces: `scripts/session-inspect.js` can inspect Claude, dmux, and
+  adapter-backed sessions, then write canonical snapshots.
+- Harness baseline: `scripts/harness-audit.js` provides a repeatable scorecard
+  for tool coverage, context efficiency, quality gates, memory persistence,
+  eval coverage, security guardrails, and cost efficiency.
+- Tool activity: `scripts/hooks/session-activity-tracker.js` records local
+  `tool-usage.jsonl` events that ECC2 can sync.
+- Risk ledger: `ecc2/src/observability/mod.rs` scores tool calls and stores a
+  paginated ledger for review.
+
+## Reference Pressure
+
+The current agent-tooling ecosystem is converging on the same operating needs:
+
+- dmux, Orca, and Superset emphasize isolated worktrees plus one place to see
+  agent state and merge/review work.
+- Claude HUD makes context, tool activity, agent activity, and todo progress
+  visible inside the coding loop.
+- Autocontext records every run as durable traces, reports, artifacts, and
+  reusable improvements.
+- Meta-Harness treats the harness itself as something to evaluate and improve,
+  which requires clean logs of proposer behavior and outcomes.
+- Zed and OpenCode emphasize agent control surfaces, reviewable changes, and
+  harness-specific configuration that should still preserve portable project
+  knowledge.
+
+ECC's answer is not a hosted analytics dependency by default. The first
+release-candidate gate is local and file-backed. Hosted telemetry can come
+later, but only after the local event model is useful enough to trust.
+
+## Operator Workflow
+
+1. Run `npm run observability:ready`.
+2. Run `npm run harness:audit -- --format json` for the broader harness
+   scorecard.
+3. Run `node scripts/loop-status.js --json --write-dir .ecc/loop-status`
+   during longer autonomous batches.
+4. Run `node scripts/session-inspect.js --list-adapters` to confirm which
+   session surfaces are available.
+5. Use ECC2 tool logs for risky operations, conflict analysis, and handoff
+   review before increasing autonomy.
+
+The end-state is practical: before asking ECC to run larger multi-agent loops,
+the operator can prove the system has live status, durable session traces,
+baseline scorecards, and a local risk ledger.

docs/business/social-launch-copy.md

@@ -1,29 +1,34 @@
 # Social Launch Copy (X + LinkedIn)
 
-Use these templates as launch-ready starting points. Replace placeholders before posting.
+Use these templates as launch-ready starting points. Review channel tone before posting.
 
 ## X Post: Release Announcement
 
 ```text
-ECC v1.8.0 is live.
+ECC v2.0.0-rc.1 is live.
 
-We moved from “config pack” to an agent harness performance system:
-- hook reliability fixes
-- new harness commands
-- cross-tool parity (Claude Code, Cursor, OpenCode, Codex)
+The repo is moving from a Claude Code config pack into a cross-harness operating system for agentic work.
 
-Start here: <repo-link>
+What ships:
+- Hermes setup guide
+- release notes and launch collateral
+- cross-harness architecture docs
+- Hermes import guidance for turning local operator workflows into public ECC skills
+
+Start here: https://github.com/affaan-m/everything-claude-code
+Release notes: https://github.com/affaan-m/everything-claude-code/blob/main/docs/releases/2.0.0-rc.1/release-notes.md
 ```
 
 ## X Post: Proof + Metrics
 
 ```text
-If you evaluate agent tooling, use blended distribution metrics:
-- npm installs (`ecc-universal`, `ecc-agentshield`)
-- GitHub App installs
-- repo adoption (stars/forks/contributors)
+ECC v2.0.0-rc.1 keeps the public surface honest:
+- reusable ECC substrate in repo
+- Hermes documented as the operator shell
+- private workspace state left out
+- release metadata and docs covered by tests
 
-We now track this monthly in-repo for sponsor transparency.
+This is the release-candidate line: public system shape now, deeper local integrations only after sanitization.
 ```
 
 ## X Quote Tweet: Eval Skills Article
@@ -36,7 +41,7 @@ In ECC we turned this into production checks via:
 - /quality-gate
 - Stop-phase session summaries
 
-This is where harness performance compounds over time.
+In v2.0.0-rc.1, that discipline extends to the release surface: docs, manifests, launch copy, and public/private boundaries are test-backed.
 ```
 
 ## X Quote Tweet: Plankton / deslop workflow
@@ -44,19 +49,24 @@ This is where harness performance compounds over time.
 ```text
 This workflow direction is right: optimize the harness, not just prompts.
 
-Our v1.8.0 focus was reliability + parity + measurable quality gates across toolchains.
+ECC v2.0.0-rc.1 pushes that further: reusable skills, thin harness adapters, and Hermes as the operator shell on top.
 ```
 
 ## LinkedIn Post: Partner-Friendly Summary
 
 ```text
-We shipped ECC v1.8.0 with one objective: improve agent harness performance in production.
+ECC v2.0.0-rc.1 is live.
 
-Highlights:
-- more reliable hook lifecycle behavior
-- new harness-level quality commands
-- parity across Claude Code, Cursor, OpenCode, and Codex
-- stronger sponsor-facing metrics tracking
+The practical shift: ECC is no longer just a Claude Code config pack. It is becoming a cross-harness operating system for agentic work.
 
-If your team runs AI coding agents daily, this is designed for operational use.
+This release-candidate surface includes:
+- sanitized Hermes setup documentation
+- release notes and launch collateral
+- cross-harness architecture notes
+- Hermes import guidance for turning local operator patterns into public ECC skills
+
+It does not include private workspace state, credentials, raw local exports, or personal datasets.
+
+Repo: https://github.com/affaan-m/everything-claude-code
+Release notes: https://github.com/affaan-m/everything-claude-code/blob/main/docs/releases/2.0.0-rc.1/release-notes.md
 ```

docs/ja-JP/README.md

@@ -1,4 +1,4 @@
-**言語:** [English](../../README.md) | [Português (Brasil)](../pt-BR/README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](README.md) | [한국어](../ko-KR/README.md) | [Türkçe](../tr/README.md)
+**言語:** [English](../../README.md) | [Português (Brasil)](../pt-BR/README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](README.md) | [한국어](../ko-KR/README.md) | [Türkçe](../tr/README.md) | [Русский](../ru/README.md) | [Tiếng Việt](../vi-VN/README.md)
 
 # Everything Claude Code
 
@@ -19,9 +19,9 @@
 
 <div align="center">
 
-**言語 / Language / 語言 / Dil**
+**言語 / Language / 語言 / Dil / Язык / Ngôn ngữ**
 
-[**English**](../../README.md) | [Português (Brasil)](../pt-BR/README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](README.md) | [한국어](../ko-KR/README.md) | [Türkçe](../tr/README.md)
+[**English**](../../README.md) | [Português (Brasil)](../pt-BR/README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](README.md) | [한국어](../ko-KR/README.md) | [Türkçe](../tr/README.md) | [Русский](../ru/README.md) | [Tiếng Việt](../vi-VN/README.md)
 
 </div>
 
@@ -110,7 +110,7 @@
 /plugin marketplace add https://github.com/affaan-m/everything-claude-code
 
 # プラグインをインストール
-/plugin install everything-claude-code
+/plugin install ecc@ecc
 ```
 
 ### ステップ2：ルールをインストール（必須）
@@ -140,7 +140,7 @@ cp -r everything-claude-code/rules/golang/* ~/.claude/rules/
 # /plan "ユーザー認証を追加"
 
 # 利用可能なコマンドを確認
-/plugin list everything-claude-code@everything-claude-code
+/plugin list ecc@ecc
 ```
 
 **完了です！** これで13のエージェント、43のスキル、31のコマンドにアクセスできます。
@@ -427,7 +427,7 @@ Duplicate hook file detected: ./hooks/hooks.json is already resolved to a loaded
 /plugin marketplace add https://github.com/affaan-m/everything-claude-code
 
 # プラグインをインストール
-/plugin install everything-claude-code
+/plugin install ecc@ecc
 ```
 
 または、`~/.claude/settings.json` に直接追加：
@@ -443,7 +443,7 @@ Duplicate hook file detected: ./hooks/hooks.json is already resolved to a loaded
     }
   },
   "enabledPlugins": {
-    "everything-claude-code@everything-claude-code": true
+    "ecc@ecc": true
   }
 }
 ```

docs/ja-JP/commands/sessions.md

@@ -1,6 +1,6 @@
 # Sessionsコマンド
 
-Claude Codeセッション履歴を管理 - `~/.claude/sessions/` に保存されたセッションのリスト表示、読み込み、エイリアス設定、編集を行います。
+Claude Codeセッション履歴を管理 - `~/.claude/session-data/` に保存されたセッションのリスト表示、読み込み、エイリアス設定、編集を行います。旧 `~/.claude/sessions/` のファイルも後方互換のために読み取ります。
 
 ## 使用方法
 
@@ -81,7 +81,7 @@ const size = sm.getSessionSize(session.sessionPath);
 const aliases = aa.getAliasesForSession(session.filename);
 
 console.log('Session: ' + session.filename);
-console.log('Path: ~/.claude/sessions/' + session.filename);
+console.log('Path: ' + session.sessionPath);
 console.log('');
 console.log('Statistics:');
 console.log('  Lines: ' + stats.lineCount);
@@ -299,7 +299,7 @@ $ARGUMENTS:
 
 ## 備考
 
-- セッションは `~/.claude/sessions/` にMarkdownファイルとして保存されます
+- セッションは `~/.claude/session-data/` にMarkdownファイルとして保存され、旧 `~/.claude/sessions/` のファイルも引き続き読み取られます
 - エイリアスは `~/.claude/session-aliases.json` に保存されます
 - セッションIDは短縮できます（通常、最初の4〜8文字で一意になります）
 - 頻繁に参照するセッションにはエイリアスを使用してください

docs/ja-JP/plugins/README.md

@@ -58,7 +58,7 @@ claude plugin install typescript-lsp@claude-plugins-official
 
 **ワークフロー:**
 - `commit-commands` - Gitワークフロー
-- `frontend-design` - UIパターン
+- `frontend-patterns` - UIパターン
 - `feature-dev` - 機能開発
 
 ---

docs/ja-JP/skills/configure-ecc/SKILL.md

@@ -17,7 +17,7 @@ Everything Claude Code プロジェクトのインタラクティブなステッ
 ## 前提条件
 
 このスキルは起動前に Claude Code からアクセス可能である必要があります。ブートストラップには2つの方法があります：
-1. **プラグイン経由**: `/plugin install everything-claude-code@everything-claude-code` — プラグインがこのスキルを自動的にロードします
+1. **プラグイン経由**: `/plugin install ecc@ecc` — プラグインがこのスキルを自動的にロードします
 2. **手動**: このスキルのみを `~/.claude/skills/configure-ecc/SKILL.md` にコピーし、"configure ecc" と言って起動します
 
 ---
@@ -130,9 +130,20 @@ Options:
 
 ### 2c: インストールの実行
 
-選択された各スキルについて、スキルディレクトリ全体をコピーします：
+選択された各スキルについて、正しいソースルートからスキルディレクトリ全体をコピーします：
+
 ```bash
-cp -r $ECC_ROOT/skills/<skill-name> $TARGET/skills/
+# コアスキルは .agents/skills/ 配下にあります
+cp -R "$ECC_ROOT/.agents/skills/<skill-name>" "$TARGET/skills/"
+
+# ニッチスキルは skills/ 配下にあります
+cp -R "$ECC_ROOT/skills/<skill-name>" "$TARGET/skills/"
+```
+
+glob で取得したソースディレクトリを処理するときは、trailing slash 付きのソースをそのまま `cp` に渡さないでください。宛先名にディレクトリ名を明示します：
+
+```bash
+cp -R "${src%/}" "$TARGET/skills/$(basename "${src%/}")"
 ```
 
 注: `continuous-learning` と `continuous-learning-v2` には追加ファイル（config.json、フック、スクリプト）があります — SKILL.md だけでなく、ディレクトリ全体がコピーされることを確認してください。