codeply-cli 0.1.1 → 0.2.0

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

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

package/skills/messages-ops/SKILL.md

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

package/skills/ml-adoption-playbook/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: ml-adoption-playbook
+description: End-to-end methodology for AI agents and software engineers to add machine learning algorithms to existing non-ML codebases. Covers problem framing, data readiness, architectural decoupling, and baseline model integration.
+origin: ECC
+---
+
+# ML Adoption Playbook
+
+This skill provides an adaptive methodology for implementing machine learning models into existing software engineering projects. It bridges the gap between traditional SWE and MLOps by structuring how ML should be researched, decoupled, trained, and integrated.
+
+## When to Activate
+
+- A user asks to "add ML" or "add an algorithm" to their existing codebase.
+- Planning the integration of a new model (e.g., recommendation, classification, forecasting) into a non-ML application.
+- Structuring a workflow for an agent to build, train, and deploy an ML component adaptively.
+
+## Phase 1: Problem Framing & Feasibility
+
+Before writing model code, establish the "why" and "how".
+- **Heuristic Check:** Ask the user if a simple heuristic (e.g., regex, rule-based sorting) could solve the problem faster. If yes, start there.
+- **Metric Definition:** Define what business metric the ML model is trying to improve (e.g., click-through rate, reduced latency).
+- **Mistake Budget:** Define what a "bad" prediction looks like and how the system should handle it.
+
+## Phase 2: Data Readiness
+
+ML is useless without clean, accessible data.
+- **Audit Data Sources:** Identify where the training data lives. Is it a live database, a static CSV, or an API?
+- **Data Contract:** Establish a schema for the input data. What features are required? What happens if a feature is missing?
+- **Leakage Prevention:** Ensure the user's proposed data split does not accidentally leak future information into the training set (e.g., chronological splitting for time-series data).
+
+## Phase 3: Architectural Integration & Decoupling
+
+Do not tightly couple model inference to core business logic.
+- **API Boundary:** Suggest placing the model behind an API endpoint (e.g., using `fastapi-patterns` or `django-patterns`) or a dedicated service class.
+- **Fallback Mechanisms:** Design a default state. If the model takes too long to respond or throws an error, the system must gracefully fall back to a hardcoded rule.
+- **Feature Flags:** Wrap the new ML inference call in a feature flag so it can be rolled out (or rolled back) safely.
+
+## Phase 4: Model Implementation & Training
+
+Structure the code for reproducibility and iteration.
+- **Start Simple:** Build a baseline model first (e.g., a simple scikit-learn Logistic Regression or a barebones PyTorch linear layer).
+- **Reproducibility:** Apply `pytorch-patterns` or similar best practices: fix random seeds, make code device-agnostic, and explicitly document tensor/array shapes.
+- **Automated Evidence:** Require tests for the data transforms and inference schema. Do not accept a model without an evaluation script comparing it against the baseline.
+
+## Phase 5: Handoff to MLOps
+
+Once the baseline model is integrated, shift focus to continuous operations.
+- **Refer to `mle-workflow`:** Guide the user toward setting up experiment tracking, model registries, and drift detection.
+- **CI/CD:** Add the model evaluation step to the existing CI pipeline to ensure future commits do not degrade model performance.
+
+## Iterative Agent Workflow
+
+When assisting a user via this playbook, agents should:
+1. **Ask clarifying questions** to complete Phase 1 before proposing architectures.
+2. **Draft a data contract** in Phase 2 for user approval.
+3. **Write the decoupling interface** (API/Service) in Phase 3 *before* writing the training loop.
+4. **Deliver a reproducible script** in Phase 4 that trains the model and saves the artifact.

package/skills/mle-workflow/SKILL.md

@@ -0,0 +1,348 @@
+---
+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.
+license: MIT
+metadata:
+  origin: ECC
+---
+
+# 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.