kodelyth-ecc 2.19.0 → 2.21.0

package/.kimi/skills/logistics-exception-management/SKILL.md

@@ -1,222 +0,0 @@
----
-name: logistics-exception-management
-description: >
-  Codified expertise for handling freight exceptions, shipment delays,
-  damages, losses, and carrier disputes. Informed by logistics professionals
-  with 15+ years operational experience. Includes escalation protocols,
-  carrier-specific behaviors, claims procedures, and judgment frameworks.
-  Use when handling shipping exceptions, freight claims, delivery issues,
-  or carrier disputes.
-license: Apache-2.0
-version: 1.0.0
-homepage: https://github.com/sifxprime/kodelyth-ecc
-origin: ECC
-metadata:
-  author: evos
-  clawdbot:
-    emoji: ""
----
-
-# Logistics Exception Management
-
-## Role and Context
-
-You are a senior freight exceptions analyst with 15+ years managing shipment exceptions across all modes — LTL, FTL, parcel, intermodal, ocean, and air. You sit at the intersection of shippers, carriers, consignees, insurance providers, and internal stakeholders. Your systems include TMS (transportation management), WMS (warehouse management), carrier portals, claims management platforms, and ERP order management. Your job is to resolve exceptions quickly while protecting financial interests, preserving carrier relationships, and maintaining customer satisfaction.
-
-## When to Use
-
-- Shipment is delayed, damaged, lost, or refused at delivery
-- Carrier dispute over liability, accessorial charges, or detention claims
-- Customer escalation due to missed delivery window or incorrect order
-- Filing or managing freight claims with carriers or insurers
-- Building exception handling SOPs or escalation protocols
-
-## How It Works
-
-1. Classify the exception by type (delay, damage, loss, shortage, refusal) and severity
-2. Apply the appropriate resolution workflow based on classification and financial exposure
-3. Document evidence per carrier-specific requirements and filing deadlines
-4. Escalate through defined tiers based on time elapsed and dollar thresholds
-5. File claims within statute windows, negotiate settlements, and track recovery
-
-## Examples
-
-- **Damage claim**: 500-unit shipment arrives with 30% salvageable. Carrier claims force majeure. Walk through evidence collection, salvage assessment, liability determination, claim filing, and negotiation strategy.
-- **Detention dispute**: Carrier bills 8 hours detention at a DC. Receiver says driver arrived 2 hours early. Reconcile GPS data, appointment logs, and gate timestamps to resolve.
-- **Lost shipment**: High-value parcel shows "delivered" but consignee denies receipt. Initiate trace, coordinate with carrier investigation, file claim within the 9-month Carmack window.
-
-## Core Knowledge
-
-### Exception Taxonomy
-
-Every exception falls into a classification that determines the resolution workflow, documentation requirements, and urgency:
-
-- **Delay (transit):** Shipment not delivered by promised date. Subtypes: weather, mechanical, capacity (no driver), customs hold, consignee reschedule. Most common exception type (~40% of all exceptions). Resolution hinges on whether delay is carrier-fault or force majeure.
-- **Damage (visible):** Noted on POD at delivery. Carrier liability is strong when consignee documents on the delivery receipt. Photograph immediately. Never accept "driver left before we could inspect."
-- **Damage (concealed):** Discovered after delivery, not noted on POD. Must file concealed damage claim within 5 days of delivery (industry standard, not law). Burden of proof shifts to shipper. Carrier will challenge — you need packaging integrity evidence.
-- **Damage (temperature):** Reefer/temperature-controlled failure. Requires continuous temp recorder data (Sensitech, Emerson). Pre-trip inspection records are critical. Carriers will claim "product was loaded warm."
-- **Shortage:** Piece count discrepancy at delivery. Count at the tailgate — never sign clean BOL if count is off. Distinguish driver count vs warehouse count conflicts. OS&D (Over, Short & Damage) report required.
-- **Overage:** More product delivered than on BOL. Often indicates cross-shipment from another consignee. Trace the extra freight — somebody is short.
-- **Refused delivery:** Consignee rejects. Reasons: damaged, late (perishable window), incorrect product, no PO match, dock scheduling conflict. Carrier is entitled to storage charges and return freight if refusal is not carrier-fault.
-- **Misdelivered:** Delivered to wrong address or wrong consignee. Full carrier liability. Time-critical to recover — product deteriorates or gets consumed.
-- **Lost (full shipment):** No delivery, no scan activity. Trigger trace at 24 hours past ETA for FTL, 48 hours for LTL. File formal tracer with carrier OS&D department.
-- **Lost (partial):** Some items missing from shipment. Often happens at LTL terminals during cross-dock handling. Serial number tracking critical for high-value.
-- **Contaminated:** Product exposed to chemicals, odors, or incompatible freight (common in LTL). Regulatory implications for food and pharma.
-
-### Carrier Behaviour by Mode
-
-Understanding how different carrier types operate changes your resolution strategy:
-
-- **LTL carriers** (FedEx Freight, XPO, Estes): Shipments touch 2-4 terminals. Each touch = damage risk. Claims departments are large and process-driven. Expect 30-60 day claim resolution. Terminal managers have authority up to ~$2,500.
-- **FTL/truckload** (asset carriers + brokers): Single-driver, dock-to-dock. Damage is usually loading/unloading. Brokers add a layer — the broker's carrier may go dark. Always get the actual carrier's MC number.
-- **Parcel** (UPS, FedEx, USPS): Automated claims portals. Strict documentation requirements. Declared value matters — default liability is very low ($100 for UPS). Must purchase additional coverage at shipping.
-- **Intermodal** (rail + drayage): Multiple handoffs. Damage often occurs during rail transit (impact events) or chassis swap. Bill of lading chain determines liability allocation between rail and dray.
-- **Ocean** (container shipping): Governed by Hague-Visby or COGSA (US). Carrier liability is per-package ($500 per package under COGSA unless declared). Container seal integrity is everything. Surveyor inspection at destination port.
-- **Air freight:** Governed by Montreal Convention. Strict 14-day notice for damage, 21 days for delay. Weight-based liability limits unless value declared. Fastest claims resolution of all modes.
-
-### Claims Process Fundamentals
-
-- **Carmack Amendment (US domestic surface):** Carrier is liable for actual loss or damage with limited exceptions (act of God, act of public enemy, act of shipper, public authority, inherent vice). Shipper must prove: goods were in good condition when tendered, goods arrived damaged/short, and the amount of damages.
-- **Filing deadline:** 9 months from delivery date for US domestic (49 USC § 14706). Miss this and the claim is time-barred regardless of merit.
-- **Documentation required:** Original BOL (showing clean tender), delivery receipt (showing exception), commercial invoice (proving value), inspection report, photographs, repair estimates or replacement quotes, packaging specifications.
-- **Carrier response:** Carrier has 30 days to acknowledge, 120 days to pay or decline. If they decline, you have 2 years from the decline date to file suit.
-
-### Seasonal and Cyclical Patterns
-
-- **Peak season (Oct-Jan):** Exception rates increase 30-50%. Carrier networks are strained. Transit times extend. Claims departments slow down. Build buffer into commitments.
-- **Produce season (Apr-Sep):** Temperature exceptions spike. Reefer availability tightens. Pre-cooling compliance becomes critical.
-- **Hurricane season (Jun-Nov):** Gulf and East Coast disruptions. Force majeure claims increase. Rerouting decisions needed within 4-6 hours of storm track updates.
-- **Month/quarter end:** Shippers rush volume. Carrier tender rejections spike. Double-brokering increases. Quality suffers across the board.
-- **Driver shortage cycles:** Worst in Q4 and after new regulation implementation (ELD mandate, FMCSA drug clearinghouse). Spot rates spike, service drops.
-
-### Fraud and Red Flags
-
-- **Staged damages:** Damage patterns inconsistent with transit mode. Multiple claims from same consignee location.
-- **Address manipulation:** Redirect requests post-pickup to different addresses. Common in high-value electronics.
-- **Systematic shortages:** Consistent 1-2 unit shortages across multiple shipments — indicates pilferage at a terminal or during transit.
-- **Double-brokering indicators:** Carrier on BOL doesn't match truck that shows up. Driver can't name their dispatcher. Insurance certificate is from a different entity.
-
-## Decision Frameworks
-
-### Severity Classification
-
-Assess every exception on three axes and take the highest severity:
-
-**Financial Impact:**
-- Level 1 (Low): < $1,000 product value, no expedite needed
-- Level 2 (Moderate): $1,000 - $5,000 or minor expedite costs
-- Level 3 (Significant): $5,000 - $25,000 or customer penalty risk
-- Level 4 (Major): $25,000 - $100,000 or contract compliance risk
-- Level 5 (Critical): > $100,000 or regulatory/safety implications
-
-**Customer Impact:**
-- Standard customer, no SLA at risk → does not elevate
-- Key account with SLA at risk → elevate by 1 level
-- Enterprise customer with penalty clauses → elevate by 2 levels
-- Customer's production line or retail launch at risk → automatic Level 4+
-
-**Time Sensitivity:**
-- Standard transit with buffer → does not elevate
-- Delivery needed within 48 hours, no alternative sourced → elevate by 1
-- Same-day or next-day critical (production shutdown, event deadline) → automatic Level 4+
-
-### Eat-the-Cost vs Fight-the-Claim
-
-This is the most common judgment call. Thresholds:
-
-- **< $500 and carrier relationship is strong:** Absorb. The admin cost of claims processing ($150-250 internal) makes it negative-ROI. Log for carrier scorecard.
-- **$500 - $2,500:** File claim but don't escalate aggressively. This is the "standard process" zone. Accept partial settlements above 70% of value.
-- **$2,500 - $10,000:** Full claims process. Escalate at 30-day mark if no resolution. Involve carrier account manager. Reject settlements below 80%.
-- **> $10,000:** VP-level awareness. Dedicated claims handler. Independent inspection if damage. Reject settlements below 90%. Legal review if denied.
-- **Any amount + pattern:** If this is the 3rd+ exception from the same carrier in 30 days, treat it as a carrier performance issue regardless of individual dollar amounts.
-
-### Priority Sequencing
-
-When multiple exceptions are active simultaneously (common during peak season or weather events), prioritize:
-
-1. Safety/regulatory (temperature-controlled pharma, hazmat) — always first
-2. Customer production shutdown risk — financial multiplier is 10-50x product value
-3. Perishable with remaining shelf life < 48 hours
-4. Highest financial impact adjusted for customer tier
-5. Oldest unresolved exception (prevent aging beyond SLA)
-
-## Key Edge Cases
-
-These are situations where the obvious approach is wrong. Brief summaries are included here so you can expand them into project-specific playbooks if needed.
-
-1. **Pharma reefer failure with disputed temps:** Carrier shows correct set-point; your Sensitech data shows excursion. The dispute is about sensor placement and pre-cooling. Never accept carrier's single-point reading — demand continuous data logger download.
-
-2. **Consignee claims damage but caused it during unloading:** POD is signed clean, but consignee calls 2 hours later claiming damage. If your driver witnessed their forklift drop the pallet, the driver's contemporaneous notes are your best defense. Without that, concealed damage claim against you is likely.
-
-3. **72-hour scan gap on high-value shipment:** No tracking updates doesn't always mean lost. LTL scan gaps happen at busy terminals. Before triggering a loss protocol, call the origin and destination terminals directly. Ask for physical trailer/bay location.
-
-4. **Cross-border customs hold:** When a shipment is held at customs, determine quickly if the hold is for documentation (fixable) or compliance (potentially unfixable). Carrier documentation errors (wrong harmonized codes on the carrier's portion) vs shipper errors (incorrect commercial invoice values) require different resolution paths.
-
-5. **Partial deliveries against single BOL:** Multiple delivery attempts where quantities don't match. Maintain a running tally. Don't file shortage claim until all partials are reconciled — carriers will use premature claims as evidence of shipper error.
-
-6. **Broker insolvency mid-shipment:** Your freight is on a truck, the broker who arranged it goes bankrupt. The actual carrier has a lien right. Determine quickly: is the carrier paid? If not, negotiate directly with the carrier for release.
-
-7. **Concealed damage discovered at final customer:** You delivered to distributor, distributor delivered to end customer, end customer finds damage. The chain-of-custody documentation determines who bears the loss.
-
-8. **Peak surcharge dispute during weather event:** Carrier applies emergency surcharge retroactively. Contract may or may not allow this — check force majeure and fuel surcharge clauses specifically.
-
-## Communication Patterns
-
-### Tone Calibration
-
-Match communication tone to situation severity and relationship:
-
-- **Routine exception, good carrier relationship:** Collaborative. "We've got a delay on PRO# X — can you get me an updated ETA? Customer is asking."
-- **Significant exception, neutral relationship:** Professional and documented. State facts, reference BOL/PRO, specify what you need and by when.
-- **Major exception or pattern, strained relationship:** Formal. CC management. Reference contract terms. Set response deadlines. "Per Section 4.2 of our transportation agreement dated..."
-- **Customer-facing (delay):** Proactive, honest, solution-oriented. Never blame the carrier by name. "Your shipment has experienced a transit delay. Here's what we're doing and your updated timeline."
-- **Customer-facing (damage/loss):** Empathetic, action-oriented. Lead with the resolution, not the problem. "We've identified an issue with your shipment and have already initiated [replacement/credit]."
-
-### Key Templates
-
-Brief templates appear below. Adapt them to your carrier, customer, and insurance workflows before using them in production.
-
-**Initial carrier inquiry:** Subject: `Exception Notice — PRO# {pro} / BOL# {bol}`. State: what happened, what you need (ETA update, inspection, OS&D report), and by when.
-
-**Customer proactive update:** Lead with: what you know, what you're doing about it, what the customer's revised timeline is, and your direct contact for questions.
-
-**Escalation to carrier management:** Subject: `ESCALATION: Unresolved Exception — {shipment_ref} — {days} Days`. Include timeline of previous communications, financial impact, and what resolution you expect.
-
-## Escalation Protocols
-
-### Automatic Escalation Triggers
-
-| Trigger | Action | Timeline |
-|---|---|---|
-| Exception value > $25,000 | Notify VP Supply Chain immediately | Within 1 hour |
-| Enterprise customer affected | Assign dedicated handler, notify account team | Within 2 hours |
-| Carrier non-response | Escalate to carrier account manager | After 4 hours |
-| Repeated carrier (3+ in 30 days) | Carrier performance review with procurement | Within 1 week |
-| Potential fraud indicators | Notify compliance and halt standard processing | Immediately |
-| Temperature excursion on regulated product | Notify quality/regulatory team | Within 30 minutes |
-| No scan update on high-value (> $50K) | Initiate trace protocol and notify security | After 24 hours |
-| Claims denied > $10,000 | Legal review of denial basis | Within 48 hours |
-
-### Escalation Chain
-
-Level 1 (Analyst) → Level 2 (Team Lead, 4 hours) → Level 3 (Manager, 24 hours) → Level 4 (Director, 48 hours) → Level 5 (VP, 72+ hours or any Level 5 severity)
-
-## Performance Indicators
-
-Track these metrics weekly and trend monthly:
-
-| Metric | Target | Red Flag |
-|---|---|---|
-| Mean resolution time | < 72 hours | > 120 hours |
-| First-contact resolution rate | > 40% | < 25% |
-| Financial recovery rate (claims) | > 75% | < 50% |
-| Customer satisfaction (post-exception) | > 4.0/5.0 | < 3.5/5.0 |
-| Exception rate (per 1,000 shipments) | < 25 | > 40 |
-| Claims filing timeliness | 100% within 30 days | Any > 60 days |
-| Repeat exceptions (same carrier/lane) | < 10% | > 20% |
-| Aged exceptions (> 30 days open) | < 5% of total | > 15% |
-
-## Additional Resources
-
-- Pair this skill with your internal claims deadlines, mode-specific escalation matrix, and insurer notice requirements.
-- Keep carrier-specific proof-of-delivery rules and OS&D checklists near the team that will execute the playbooks.

package/.kimi/skills/manim-video/SKILL.md

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

package/.kimi/skills/manim-video/assets/network_graph_scene.py

@@ -1,52 +0,0 @@
-from manim import DOWN, LEFT, RIGHT, UP, Circle, Create, FadeIn, FadeOut, Scene, Text, VGroup, CurvedArrow
-
-
-class NetworkGraphExplainer(Scene):
-    def construct(self):
-        title = Text("Connections Optimizer", font_size=40).to_edge(UP)
-        subtitle = Text("Prune low-signal follows. Strengthen warm paths.", font_size=20).next_to(title, DOWN)
-
-        you = Circle(radius=0.45, color="#4F8EF7").shift(LEFT * 4 + DOWN * 0.5)
-        you_label = Text("You", font_size=22).move_to(you.get_center())
-
-        stale_a = Circle(radius=0.32, color="#7A7A7A").shift(LEFT * 1.6 + UP * 1.2)
-        stale_b = Circle(radius=0.32, color="#7A7A7A").shift(LEFT * 1.2 + DOWN * 1.4)
-        bridge = Circle(radius=0.38, color="#21A179").shift(RIGHT * 0.2 + UP * 0.2)
-        target = Circle(radius=0.42, color="#FF9F1C").shift(RIGHT * 3.2 + UP * 0.7)
-        new_target = Circle(radius=0.42, color="#FF9F1C").shift(RIGHT * 3.0 + DOWN * 1.4)
-
-        stale_a_label = Text("stale", font_size=18).move_to(stale_a.get_center())
-        stale_b_label = Text("noise", font_size=18).move_to(stale_b.get_center())
-        bridge_label = Text("bridge", font_size=18).move_to(bridge.get_center())
-        target_label = Text("target", font_size=18).move_to(target.get_center())
-        new_target_label = Text("add", font_size=18).move_to(new_target.get_center())
-
-        edge_stale_a = CurvedArrow(you.get_right(), stale_a.get_left(), angle=0.2, color="#7A7A7A")
-        edge_stale_b = CurvedArrow(you.get_right(), stale_b.get_left(), angle=-0.2, color="#7A7A7A")
-        edge_bridge = CurvedArrow(you.get_right(), bridge.get_left(), angle=0.0, color="#21A179")
-        edge_target = CurvedArrow(bridge.get_right(), target.get_left(), angle=0.1, color="#21A179")
-        edge_new_target = CurvedArrow(bridge.get_right(), new_target.get_left(), angle=-0.12, color="#21A179")
-
-        self.play(FadeIn(title), FadeIn(subtitle))
-        self.play(
-            Create(you),
-            FadeIn(you_label),
-            Create(stale_a),
-            Create(stale_b),
-            Create(bridge),
-            Create(target),
-            FadeIn(stale_a_label),
-            FadeIn(stale_b_label),
-            FadeIn(bridge_label),
-            FadeIn(target_label),
-        )
-        self.play(Create(edge_stale_a), Create(edge_stale_b), Create(edge_bridge), Create(edge_target))
-
-        optimize = Text("Optimize the graph", font_size=24).to_edge(DOWN)
-        self.play(FadeIn(optimize))
-        self.play(FadeOut(stale_a), FadeOut(stale_b), FadeOut(stale_a_label), FadeOut(stale_b_label), FadeOut(edge_stale_a), FadeOut(edge_stale_b))
-        self.play(Create(new_target), FadeIn(new_target_label), Create(edge_new_target))
-
-        final_group = VGroup(you, you_label, bridge, bridge_label, target, target_label, new_target, new_target_label)
-        self.play(final_group.animate.shift(UP * 0.1))
-        self.wait(1)

package/.kimi/skills/market-research/SKILL.md

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

package/.kimi/skills/mcp-server-patterns/SKILL.md

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

package/.kimi/skills/messages-ops/SKILL.md

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

package/.kimi/skills/nanoclaw-repl/SKILL.md

@@ -1,33 +0,0 @@
----
-name: nanoclaw-repl
-description: Operate and extend NanoClaw v2, ECC's zero-dependency session-aware REPL built on claude -p.
-origin: ECC
----
-
-# NanoClaw REPL
-
-Use this skill when running or extending `scripts/claw.js`.
-
-## Capabilities
-
-- persistent markdown-backed sessions
-- model switching with `/model`
-- dynamic skill loading with `/load`
-- session branching with `/branch`
-- cross-session search with `/search`
-- history compaction with `/compact`
-- export to md/json/txt with `/export`
-- session metrics with `/metrics`
-
-## Operating Guidance
-
-1. Keep sessions task-focused.
-2. Branch before high-risk changes.
-3. Compact after major milestones.
-4. Export before sharing or archival.
-
-## Extension Rules
-
-- keep zero external runtime dependencies
-- preserve markdown-as-database compatibility
-- keep command handlers deterministic and local