[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HPTY5X8AAMAMYBGKSSRJZE":3,"skill-same:01M6HPTY5X8AAMAMYBGKSSRJZE":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6HPTY5X8AAMAMYBGKSSRJZE","mle-workflow",null,"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.","welflau\u002Fai-dev-system","welflau","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7010385?v=4","01M6HPTDGF18RFY07M229P8CTM","01M6HPTDMRMZCJPYBFEA9XVVYT",3,"MIT","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fconfig_packs\u002Fai-workflow\u002Fshared\u002Fskills\u002Fmle-workflow\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"mle workflow","workflow","learning","when","for","machine","contracts","use","edit","write","read","model","Bash","machine-learning","data","Reproducible","Evaluation","monitoring","deployment","training","ml","2026-11-10 10:12:30",false,"---\nname: mle-workflow\ndescription: 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.\nallowed-tools: Read, Write, Edit, Bash, Grep, Glob\n---\n\n# Machine Learning Engineering Workflow\n\nUse 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.\n\n## When to Activate\n\n- Planning or reviewing a production ML feature, model refresh, ranking system, recommender, classifier, embedding workflow, or forecasting pipeline\n- Converting notebook code into a reusable training, evaluation, batch inference, or online inference pipeline\n- Designing model promotion criteria, offline\u002Fonline evals, experiment tracking, or rollback paths\n- Debugging failures caused by data drift, label leakage, stale features, artifact mismatch, or inconsistent training and serving logic\n- Adding model monitoring, canary rollout, shadow traffic, or post-deploy quality checks\n\n## Scope Calibration\n\nUse 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.\n\n- Do not assume every model has supervised labels, online serving, a feature store, PyTorch, GPUs, human review, A\u002FB tests, or real-time feedback.\n- Do not add heavyweight MLOps machinery when a data contract, baseline, eval script, and rollback note would make the change reviewable.\n- Do make assumptions explicit when the project lacks labels, delayed outcomes, slice definitions, production traffic, or monitoring ownership.\n- Treat examples as interchangeable scaffolds. Replace metrics, serving mode, data stores, and rollout mechanics with the project-native equivalents.\n\n## Related Skills\n\n- `python-patterns` and `python-testing` for Python implementation and pytest coverage\n- `pytorch-patterns` for deep learning models, data loaders, device handling, and training loops\n- `eval-harness` and `ai-regression-testing` for promotion gates and agent-assisted regression checks\n- `database-migrations`, `postgres-patterns`, and `clickhouse-io` for data storage and analytics surfaces\n- `deployment-patterns`, `docker-patterns`, and `security-review` for serving, secrets, containers, and production hardening\n\n## Reuse the SWE Surface\n\nDo not treat MLE as separate from software engineering. Most ECC SWE workflows apply directly to ML systems, often with stricter failure modes:\n\nThe 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.\n\n| SWE surface | MLE use |\n|-------------|---------|\n| `product-capability` \u002F `architecture-decision-records` | Turn model work into explicit product contracts and record irreversible data, model, and rollout choices |\n| `repo-scan` \u002F `codebase-onboarding` \u002F `code-tour` | Find existing training, feature, serving, eval, and monitoring paths before introducing a parallel ML stack |\n| `plan` \u002F `feature-dev` | Scope model changes as product capabilities with data, eval, serving, and rollback phases |\n| `tdd-workflow` \u002F `python-testing` | Test feature transforms, split logic, metric calculations, artifact loading, and inference schemas before implementation |\n| `code-reviewer` \u002F `mle-reviewer` | Review code quality plus ML-specific leakage, reproducibility, promotion, and monitoring risks |\n| `build-fix` \u002F `pr-test-analyzer` | Diagnose broken CI, flaky evals, missing fixtures, and environment-specific model or dependency failures |\n| `quality-gate` \u002F `test-coverage` | Require automated evidence for transforms, metrics, inference contracts, promotion gates, and rollback behavior |\n| `eval-harness` \u002F `verification-loop` | Turn offline metrics, slice checks, latency budgets, and rollback drills into repeatable gates |\n| `ai-regression-testing` | Preserve every production bug as a regression: missing feature, stale label, bad artifact, schema drift, or serving mismatch |\n| `api-design` \u002F `backend-patterns` | Design prediction APIs, batch jobs, idempotent retraining endpoints, and response envelopes |\n| `database-migrations` \u002F `postgres-patterns` \u002F `clickhouse-io` | Version labels, feature snapshots, prediction logs, experiment metrics, and drift analytics |\n| `deployment-patterns` \u002F `docker-patterns` | Package reproducible training and serving images with health checks, resource limits, and rollback |\n| `canary-watch` \u002F `dashboard-builder` | Make rollout health visible with model-version, slice, drift, latency, cost, and delayed-label dashboards |\n| `security-review` \u002F `security-scan` | Check model artifacts, notebooks, prompts, datasets, and logs for secrets, PII, unsafe deserialization, and supply-chain risk |\n| `e2e-testing` \u002F `browser-qa` \u002F `accessibility` | Test critical product flows that consume predictions, including explainability and fallback UI states |\n| `benchmark` \u002F `performance-optimizer` | Measure throughput, p95 latency, memory, GPU utilization, and cost per prediction or retrain |\n| `cost-aware-llm-pipeline` \u002F `token-budget-advisor` | Route LLM\u002Fembedding workloads by quality, latency, and budget instead of defaulting to the largest model |\n| `documentation-lookup` \u002F `search-first` | Verify current library behavior for model serving, feature stores, vector DBs, and eval tooling before coding |\n| `git-workflow` \u002F `github-ops` \u002F `opensource-pipeline` | Package MLE changes for review with crisp scope, generated artifacts excluded, and reproducible test evidence |\n| `strategic-compact` \u002F `dmux-workflows` | Split long ML work into parallel tracks: data contract, eval harness, serving path, monitoring, and docs |\n\n## Ten MLE Task Simulations\n\nUse 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.\n\n| ID | Common MLE task | Streamlined ECC path | Required output | Pipeline lanes covered |\n|----|-----------------|----------------------|-----------------|------------------------|\n| 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 |\n| 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 |\n| 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\u002Fcost estimate, known weaknesses, and tests for score shape and determinism | baseline, scoring, testing, serving parity |\n| 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\u002Fserve equivalence | feature pipeline, leakage, training, artifacts |\n| MLE-05 | Tune thresholds, configs, and model complexity under tradeoffs | `eval-harness`, `ai-regression-testing`, `quality-gate`, `test-coverage` | Threshold\u002Fconfig report comparing precision, recall, F1, AUC, calibration, group slices, latency, cost, complexity, and acceptable error classes | evaluation, threshold, promotion, regression |\n| 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 |\n| 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 |\n| 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 |\n| MLE-09 | Roll out a model with shadow traffic, canary, A\u002FB 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 |\n| 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 |\n\n## Iteration Compact\n\nBefore 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.\n\n```text\nGoal:\nWho cares:\nDecision owner:\nUser or system action changed by the model:\nSuccess metric:\nGuardrail metrics:\nMistake budget:\nUnacceptable mistakes:\nAcceptable mistakes:\nAssumptions:\nConstraints:\nLabels and data snapshot:\nBaseline:\nCandidate signals:\nThreshold or config plan:\nEval slices:\nKnown risks:\nNext experiment:\nRollback or fallback:\n```\n\nThis 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.\n\n## Decision Brain\n\nUse this loop whenever the task is ambiguous, high-impact, or metric-heavy:\n\n1. Start from the decision, not the model. Name the action that changes downstream behavior.\n2. Name who cares and why. Different stakeholders pay different costs for false positives, false negatives, latency, compute spend, opacity, or missed opportunities.\n3. Convert ambiguity into hypotheses. Ask what signal would separate outcomes, what evidence would disprove it, and what simple baseline should be hard to beat.\n4. Research prior art or a nearby known problem before inventing a bespoke system.\n5. Score choices with `(probability, confidence) x (cost, severity, importance, impact)`.\n6. Consider adversarial behavior, incentives, selective disclosure, distribution shift, and feedback loops.\n7. 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.\n8. Capture the decision, evidence, counterargument, and next reversible step.\n\n## Metric and Mistake Economics\n\nChoose metrics from failure costs, not habit:\n\n- Use a confusion matrix early so the team can discuss concrete false positives and false negatives instead of abstract accuracy.\n- Favor precision when the cost of an incorrect positive decision dominates.\n- Favor recall when the cost of a missed positive dominates.\n- Use F1 only when the precision\u002Frecall tradeoff is genuinely balanced and explainable.\n- Use AUC or ranking metrics when ordering quality matters more than a single threshold.\n- Track latency, throughput, memory, and cost as first-class metrics because they shape feasible model complexity.\n- Compare against a baseline and the current production model before celebrating an offline gain.\n- Treat real-world feedback signals as delayed labels with bias, lag, and coverage gaps; do not treat them as ground truth without analysis.\n\nEvery metric choice should state which mistake it makes cheaper, which mistake it makes more likely, and who absorbs that cost.\n\n## Data and Feature Hypotheses\n\nFeatures should come from a theory of separation:\n\n- Text, categorical fields, numeric histories, graph relationships, recency, frequency, and aggregates are candidate signal families, not automatic features.\n- For every feature family, state why it should separate outcomes and how it could leak future information.\n- For noisy labels, consider adjudication, label confidence, soft targets, or confidence weighting.\n- For class imbalance, compare weighted loss, resampling, threshold movement, and calibrated decision rules.\n- For missing values, decide whether absence is informative, imputable, or a reason to abstain.\n- For outliers, decide whether to clip, bucket, investigate, or preserve them as rare but important signal.\n- For correlated features, check whether they are redundant, unstable, or proxies for unavailable future state.\n\nDo not add model complexity until error analysis shows that the baseline is failing for a reason additional signal or capacity can plausibly fix.\n\n## Error Analysis Loop\n\nAfter each baseline, training run, threshold change, or config change:\n\n1. Split mistakes into false positives, false negatives, abstentions, low-confidence cases, and system failures.\n2. Cluster errors by shared traits: language, entity type, source, time, geography, device, sparsity, recency, feature freshness, label source, or model version.\n3. Separate model mistakes from data bugs, label ambiguity, product ambiguity, instrumentation gaps, and serving mismatches.\n4. Trace each major cluster to one of four moves: better labels, better features, better threshold\u002Fconfig, or better product fallback.\n5. Preserve every important mistake as a regression test, eval slice, dashboard panel, or runbook entry.\n6. Write the next iteration as a falsifiable experiment, not a vague \"improve model\" task.\n\nThe strongest MLE loop is not train -> metric -> ship. It is mistake -> cluster -> hypothesis -> experiment -> evidence -> simpler system.\n\n## Observation Ledger\n\nKeep a compact decision and evidence trail beside the code, PR, experiment report, or runbook:\n\n```text\nIteration:\nChange:\nWhy this mattered:\nMetric movement:\nSlice movement:\nFalse positives:\nFalse negatives:\nUnexpected errors:\nDecision:\nTradeoff accepted:\nLesson captured:\nRegression added:\nDebt created:\nNext iteration:\n```\n\nUse 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.\n\n## Core Workflow\n\n### 1. Define the Prediction Contract\n\nCapture the product-level contract before writing model code:\n\n- Prediction target and decision owner\n- Input entity, output schema, confidence\u002Fcalibration fields, and allowed latency\n- Batch, online, streaming, or hybrid serving mode\n- Fallback behavior when the model, feature store, or dependency is unavailable\n- Human review or override path for high-impact decisions\n- Privacy, retention, and audit requirements for inputs, predictions, and labels\n\nDo not accept \"improve the model\" as a requirement. Tie the model to an observable product behavior and a measurable acceptance gate.\n\n### 2. Lock the Data Contract\n\nEvery ML task needs an explicit data contract:\n\n- Entity grain and primary key\n- Label definition, label timestamp, and label availability delay\n- Feature timestamp, freshness SLA, and point-in-time join rules\n- Train, validation, test, and backtest split policy\n- Required columns, allowed nulls, ranges, categories, and units\n- PII or sensitive fields that must not enter training artifacts or logs\n- Dataset version or snapshot ID for reproducibility\n\nGuard 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.\n\n### 3. Build a Reproducible Pipeline\n\nTraining code should be runnable by another engineer without hidden notebook state:\n\n- Use typed config files or dataclasses for all hyperparameters and paths\n- Pin package and model dependencies\n- Set random seeds and document any nondeterministic GPU behavior\n- Record dataset version, code SHA, config hash, metrics, and artifact URI\n- Save preprocessing logic with the model artifact, not separately in a notebook\n- Keep train, eval, and inference transformations shared or generated from one source\n- Make every step idempotent so retries do not corrupt artifacts or metrics\n\nPrefer immutable values and pure transformation functions. Avoid mutating shared data frames or global config during feature generation.\n\n```python\nimport hashlib\nfrom dataclasses import dataclass\nfrom pathlib import Path\n\n\n@dataclass(frozen=True)\nclass TrainingConfig:\n    dataset_uri: str\n    model_dir: Path\n    seed: int\n    learning_rate: float\n    batch_size: int\n\n\ndef artifact_name(config: TrainingConfig, code_sha: str) -> str:\n    config_key = f\"{config.dataset_uri}:{config.seed}:{config.learning_rate}:{config.batch_size}\"\n    config_hash = hashlib.sha256(config_key.encode(\"utf-8\")).hexdigest()[:12]\n    return f\"{code_sha[:12]}-{config_hash}\"\n```\n\n### 4. Evaluate Before Promotion\n\nPromotion criteria should be declared before training finishes:\n\n- Baseline model and current production model comparison\n- Primary metric aligned to product behavior\n- Guardrail metrics for latency, calibration, fairness slices, cost, and error concentration\n- Slice metrics for important cohorts, geographies, devices, languages, or data sources\n- Confidence intervals or repeated-run variance when metrics are noisy\n- Failure examples reviewed by a human for high-impact models\n- Explicit \"do not ship\" thresholds\n\n```python\nPROMOTION_GATES = {\n    \"auc\": (\"min\", 0.82),\n    \"calibration_error\": (\"max\", 0.04),\n    \"p95_latency_ms\": (\"max\", 80),\n}\n\n\ndef assert_promotion_ready(metrics: dict[str, float]) -> None:\n    missing = sorted(name for name in PROMOTION_GATES if name not in metrics)\n    if missing:\n        raise ValueError(f\"Model promotion metrics missing required gates: {missing}\")\n\n    failures = {\n        name: value\n        for name, (direction, threshold) in PROMOTION_GATES.items()\n        for value in [metrics[name]]\n        if (direction == \"min\" and value \u003C threshold)\n        or (direction == \"max\" and value > threshold)\n    }\n    if failures:\n        raise ValueError(f\"Model failed promotion gates: {failures}\")\n```\n\nUse offline metrics as gates, not guarantees. When the model changes product behavior, plan shadow evaluation, canary rollout, or A\u002FB testing before full rollout.\n\n### 5. Package for Serving\n\nAn ML artifact is production-ready only when the serving contract is testable:\n\n- Model artifact includes version, training data reference, config, and preprocessing\n- Input schema rejects invalid, stale, or out-of-range features\n- Output schema includes model version and confidence or explanation fields when useful\n- Serving path has timeout, batching, resource limits, and fallback behavior\n- CPU\u002FGPU requirements are explicit and tested\n- Prediction logs avoid PII and include enough identifiers for debugging and label joins\n- Integration tests cover missing features, stale features, bad types, empty batches, and fallback path\n\nNever let training-only feature code diverge from serving feature code without a test that proves equivalence.\n\n### 6. Operate the Model\n\nModel monitoring needs both system and quality signals:\n\n- Availability, error rate, timeout rate, queue depth, and p50\u002Fp95\u002Fp99 latency\n- Feature null rate, range drift, categorical drift, and freshness drift\n- Prediction distribution drift and confidence distribution drift\n- Label arrival health and delayed quality metrics\n- Business KPI guardrails and rollback triggers\n- Per-version dashboards for canaries and rollbacks\n\nEvery deployment should have a rollback plan that names the previous artifact, config, data dependency, and traffic-switch mechanism.\n\n## Review Checklist\n\n- [ ] Prediction contract is explicit and testable\n- [ ] Data contract defines entity grain, label timing, feature timing, and snapshot\u002Fversion\n- [ ] Leakage risks were checked against prediction-time availability\n- [ ] Training is reproducible from code, config, data version, and seed\n- [ ] Metrics compare against baseline and current production model\n- [ ] Slice metrics and guardrails are included for high-risk cohorts\n- [ ] Promotion gates are automated and fail closed\n- [ ] Training and serving transformations are shared or equivalence-tested\n- [ ] Model artifact carries version, config, dataset reference, and preprocessing\n- [ ] Serving path validates inputs and has timeout, fallback, and rollback behavior\n- [ ] Monitoring covers system health, feature drift, prediction drift, and delayed labels\n- [ ] Sensitive data is excluded from artifacts, logs, prompts, and examples\n\n## Anti-Patterns\n\n- Notebook state is required to reproduce the model\n- Random split leaks future data into validation or test sets\n- Feature joins ignore event time and label availability\n- Offline metric improves while important slices regress\n- Thresholds are tuned on the test set repeatedly\n- Training preprocessing is copied manually into serving code\n- Model version is missing from prediction logs\n- Monitoring only checks service uptime, not data or prediction quality\n- Rollback requires retraining instead of switching to a known-good artifact\n\n## Output Expectations\n\nWhen 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.\n","# Machine Learning Engineering Workflow\n\nUse 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.\n\n## When to Activate\n\n- Planning or reviewing a production ML feature, model refresh, ranking system, recommender, classifier, embedding workflow, or forecasting pipeline\n- Converting notebook code into a reusable training, evaluation, batch inference, or online inference pipeline\n- Designing model promotion criteria, offline\u002Fonline evals, experiment tracking, or rollback paths\n- Debugging failures caused by data drift, label leakage, stale features, artifact mismatch, or inconsistent training and serving logic\n- Adding model monitoring, canary rollout, shadow traffic, or post-deploy quality checks\n\n## Scope Calibration\n\nUse 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.\n\n- Do not assume every model has supervised labels, online serving, a feature store, PyTorch, GPUs, human review, A\u002FB tests, or real-time feedback.\n- Do not add heavyweight MLOps machinery when a data contract, baseline, eval script, and rollback note would make the change reviewable.\n- Do make assumptions explicit when the project lacks labels, delayed outcomes, slice definitions, production traffic, or monitoring ownership.\n- Treat examples as interchangeable scaffolds. Replace metrics, serving mode, data stores, and rollout mechanics with the project-native equivalents.\n\n## Related Skills\n\n- `python-patterns` and `python-testing` for Python implementation and pytest coverage\n- `pytorch-patterns` for deep learning models, data loaders, device handling, and training loops\n- `eval-harness` and `ai-regression-testing` for promotion gates and agent-assisted regression checks\n- `database-migrations`, `postgres-patterns`, and `clickhouse-io` for data storage and analytics surfaces\n- `deployment-patterns`, `docker-patterns`, and `security-review` for serving, secrets, containers, and production hardening\n\n## Reuse the SWE Surface\n\nDo not treat MLE as separate from software engineering. Most ECC SWE workflows apply directly to ML systems, often with stricter failure modes:\n\nThe 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.\n\n| SWE surface | MLE use |\n|-------------|---------|\n| `product-capability` \u002F `architecture-decision-records` | Turn model work into explicit product contracts and record irreversible data, model, and rollout choices |\n| `repo-scan` \u002F `codebase-onboarding` \u002F `code-tour` | Find existing training, feature, serving, eval, and monitoring paths before introducing a parallel ML stack |\n| `plan` \u002F `feature-dev` | Scope model changes as product capabilities with data, eval, serving, and rollback phases |\n| `tdd-workflow` \u002F `python-testing` | Test feature transforms, split logic, metric calculations, artifact loading, and inference schemas before implementation |\n| `code-reviewer` \u002F `mle-reviewer` | Review code quality plus ML-specific leakage, reproducibility, promotion, and monitoring risks |\n| `build-fix` \u002F `pr-test-analyzer` | Diagnose broken CI, flaky evals, missing fixtures, and environment-specific model or dependency failures |\n| `quality-gate` \u002F `test-coverage` | Require automated evidence for transforms, metrics, inference contracts, promotion gates, and rollback behavior |\n| `eval-harness` \u002F `verification-loop` | Turn offline metrics, slice checks, latency budgets, and rollback drills into repeatable gates |\n| `ai-regression-testing` | Preserve every production bug as a regression: missing feature, stale label, bad artifact, schema drift, or serving mismatch |\n| `api-design` \u002F `backend-patterns` | Design prediction APIs, batch jobs, idempotent retraining endpoints, and response envelopes |\n| `database-migrations` \u002F `postgres-patterns` \u002F `clickhouse-io` | Version labels, feature snapshots, prediction logs, experiment metrics, and drift analytics |\n| `deployment-patterns` \u002F `docker-patterns` | Package reproducible training and serving images with health checks, resource limits, and rollback |\n| `canary-watch` \u002F `dashboard-builder` | Make rollout health visible with model-version, slice, drift, latency, cost, and delayed-label dashboards |\n| `security-review` \u002F `security-scan` | Check model artifacts, notebooks, prompts, datasets, and logs for secrets, PII, unsafe deserialization, and supply-chain risk |\n| `e2e-testing` \u002F `browser-qa` \u002F `accessibility` | Test critical product flows that consume predictions, including explainability and fallback UI states |\n| `benchmark` \u002F `performance-optimizer` | Measure throughput, p95 latency, memory, GPU utilization, and cost per prediction or retrain |\n| `cost-aware-llm-pipeline` \u002F `token-budget-advisor` | Route LLM\u002Fembedding workloads by quality, latency, and budget instead of defaulting to the largest model |\n| `documentation-lookup` \u002F `search-first` | Verify current library behavior for model serving, feature stores, vector DBs, and eval tooling before coding |\n| `git-workflow` \u002F `github-ops` \u002F `opensource-pipeline` | Package MLE changes for review with crisp scope, generated artifacts excluded, and reproducible test evidence |\n| `strategic-compact` \u002F `dmux-workflows` | Split long ML work into parallel tracks: data contract, eval harness, serving path, monitoring, and docs |\n\n## Ten MLE Task Simulations\n\nUse 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.\n\n| ID | Common MLE task | Streamlined ECC path | Required output | Pipeline lanes covered |\n|----|-----------------|----------------------|-----------------|------------------------|\n| 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 |\n| 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 |\n| 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\u002Fcost estimate, known weaknesses, and tests for score shape and determinism | baseline, scoring, testing, serving parity |\n| 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\u002Fserve equivalence | feature pipeline, leakage, training, artifacts |\n| MLE-05 | Tune thresholds, configs, and model complexity under tradeoffs | `eval-harness`, `ai-regression-testing`, `quality-gate`, `test-coverage` | Threshold\u002Fconfig report comparing precision, recall, F1, AUC, calibration, group slices, latency, cost, complexity, and acceptable error classes | evaluation, threshold, promotion, regression |\n| 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 |\n| 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 |\n| 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 |\n| MLE-09 | Roll out a model with shadow traffic, canary, A\u002FB 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 |\n| 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 |\n\n## Iteration Compact\n\nBefore 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.\n\n```text\nGoal:\nWho cares:\nDecision owner:\nUser or system action changed by the model:\nSuccess metric:\nGuardrail metrics:\nMistake budget:\nUnacceptable mistakes:\nAcceptable mistakes:\nAssumptions:\nConstraints:\nLabels and data snapshot:\nBaseline:\nCandidate signals:\nThreshold or config plan:\nEval slices:\nKnown risks:\nNext experiment:\nRollback or fallback:\n```\n\nThis 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.\n\n## Decision Brain\n\nUse this loop whenever the task is ambiguous, high-impact, or metric-heavy:\n\n1. Start from the decision, not the model. Name the action that changes downstream behavior.\n2. Name who cares and why. Different stakeholders pay different costs for false positives, false negatives, latency, compute spend, opacity, or missed opportunities.\n3. Convert ambiguity into hypotheses. Ask what signal would separate outcomes, what evidence would disprove it, and what simple baseline should be hard to beat.\n4. Research prior art or a nearby known problem before inventing a bespoke system.\n5. Score choices with `(probability, confidence) x (cost, severity, importance, impact)`.\n6. Consider adversarial behavior, incentives, selective disclosure, distribution shift, and feedback loops.\n7. 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.\n8. Capture the decision, evidence, counterargument, and next reversible step.\n\n## Metric and Mistake Economics\n\nChoose metrics from failure costs, not habit:\n\n- Use a confusion matrix early so the team can discuss concrete false positives and false negatives instead of abstract accuracy.\n- Favor precision when the cost of an incorrect positive decision dominates.\n- Favor recall when the cost of a missed positive dominates.\n- Use F1 only when the precision\u002Frecall tradeoff is genuinely balanced and explainable.\n- Use AUC or ranking metrics when ordering quality matters more than a single threshold.\n- Track latency, throughput, memory, and cost as first-class metrics because they shape feasible model complexity.\n- Compare against a baseline and the current production model before celebrating an offline gain.\n- Treat real-world feedback signals as delayed labels with bias, lag, and coverage gaps; do not treat them as ground truth without analysis.\n\nEvery metric choice should state which mistake it makes cheaper, which mistake it makes more likely, and who absorbs that cost.\n\n## Data and Feature Hypotheses\n\nFeatures should come from a theory of separation:\n\n- Text, categorical fields, numeric histories, graph relationships, recency, frequency, and aggregates are candidate signal families, not automatic features.\n- For every feature family, state why it should separate outcomes and how it could leak future information.\n- For noisy labels, consider adjudication, label confidence, soft targets, or confidence weighting.\n- For class imbalance, compare weighted loss, resampling, threshold movement, and calibrated decision rules.\n- For missing values, decide whether absence is informative, imputable, or a reason to abstain.\n- For outliers, decide whether to clip, bucket, investigate, or preserve them as rare but important signal.\n- For correlated features, check whether they are redundant, unstable, or proxies for unavailable future state.\n\nDo not add model complexity until error analysis shows that the baseline is failing for a reason additional signal or capacity can plausibly fix.\n\n## Error Analysis Loop\n\nAfter each baseline, training run, threshold change, or config change:\n\n1. Split mistakes into false positives, false negatives, abstentions, low-confidence cases, and system failures.\n2. Cluster errors by shared traits: language, entity type, source, time, geography, device, sparsity, recency, feature freshness, label source, or model version.\n3. Separate model mistakes from data bugs, label ambiguity, product ambiguity, instrumentation gaps, and serving mismatches.\n4. Trace each major cluster to one of four moves: better labels, better features, better threshold\u002Fconfig, or better product fallback.\n5. Preserve every important mistake as a regression test, eval slice, dashboard panel, or runbook entry.\n6. Write the next iteration as a falsifiable experiment, not a vague \"improve model\" task.\n\nThe strongest MLE loop is not train -> metric -> ship. It is mistake -> cluster -> hypothesis -> experiment -> evidence -> simpler system.\n\n## Observation Ledger\n\nKeep a compact decision and evidence trail beside the code, PR, experiment report, or runbook:\n\n```text\nIteration:\nChange:\nWhy this mattered:\nMetric movement:\nSlice movement:\nFalse positives:\nFalse negatives:\nUnexpected errors:\nDecision:\nTradeoff accepted:\nLesson captured:\nRegression added:\nDebt created:\nNext iteration:\n```\n\nUse 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.\n\n## Core Workflow\n\n### 1. Define the Prediction Contract\n\nCapture the product-level contract before writing model code:\n\n- Prediction target and decision owner\n- Input entity, output schema, confidence\u002Fcalibration fields, and allowed latency\n- Batch, online, streaming, or hybrid serving mode\n- Fallback behavior when the model, feature store, or dependency is unavailable\n- Human review or override path for high-impact decisions\n- Privacy, retention, and audit requirements for inputs, predictions, and labels\n\nDo not accept \"improve the model\" as a requirement. Tie the model to an observable product behavior and a measurable acceptance gate.\n\n### 2. Lock the Data Contract\n\nEvery ML task needs an explicit data contract:\n\n- Entity grain and primary key\n- Label definition, label timestamp, and label availability delay\n- Feature timestamp, freshness SLA, and point-in-time join rules\n- Train, validation, test, and backtest split policy\n- Required columns, allowed nulls, ranges, categories, and units\n- PII or sensitive fields that must not enter training artifacts or logs\n- Dataset version or snapshot ID for reproducibility\n\nGuard 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.\n\n### 3. Build a Reproducible Pipeline\n\nTraining code should be runnable by another engineer without hidden notebook state:\n\n- Use typed config files or dataclasses for all hyperparameters and paths\n- Pin package and model dependencies\n- Set random seeds and document any nondeterministic GPU behavior\n- Record dataset version, code SHA, config hash, metrics, and artifact URI\n- Save preprocessing logic with the model artifact, not separately in a notebook\n- Keep train, eval, and inference transformations shared or generated from one source\n- Make every step idempotent so retries do not corrupt artifacts or metrics\n\nPrefer immutable values and pure transformation functions. Avoid mutating shared data frames or global config during feature generation.\n\n```python\nimport hashlib\nfrom dataclasses import dataclass\nfrom pathlib import Path\n\n\n@dataclass(frozen=True)\nclass TrainingConfig:\n    dataset_uri: str\n    model_dir: Path\n    seed: int\n    learning_rate: float\n    batch_size: int\n\n\ndef artifact_name(config: TrainingConfig, code_sha: str) -> str:\n    config_key = f\"{config.dataset_uri}:{config.seed}:{config.learning_rate}:{config.batch_size}\"\n    config_hash = hashlib.sha256(config_key.encode(\"utf-8\")).hexdigest()[:12]\n    return f\"{code_sha[:12]}-{config_hash}\"\n```\n\n### 4. Evaluate Before Promotion\n\nPromotion criteria should be declared before training finishes:\n\n- Baseline model and current production model comparison\n- Primary metric aligned to product behavior\n- Guardrail metrics for latency, calibration, fairness slices, cost, and error concentration\n- Slice metrics for important cohorts, geographies, devices, languages, or data sources\n- Confidence intervals or repeated-run variance when metrics are noisy\n- Failure examples reviewed by a human for high-impact models\n- Explicit \"do not ship\" thresholds\n\n```python\nPROMOTION_GATES = {\n    \"auc\": (\"min\", 0.82),\n    \"calibration_error\": (\"max\", 0.04),\n    \"p95_latency_ms\": (\"max\", 80),\n}\n\n\ndef assert_promotion_ready(metrics: dict[str, float]) -> None:\n    missing = sorted(name for name in PROMOTION_GATES if name not in metrics)\n    if missing:\n        raise ValueError(f\"Model promotion metrics missing required gates: {missing}\")\n\n    failures = {\n        name: value\n        for name, (direction, threshold) in PROMOTION_GATES.items()\n        for value in [metrics[name]]\n        if (direction == \"min\" and value \u003C threshold)\n        or (direction == \"max\" and value > threshold)\n    }\n    if failures:\n        raise ValueError(f\"Model failed promotion gates: {failures}\")\n```\n\nUse offline metrics as gates, not guarantees. When the model changes product behavior, plan shadow evaluation, canary rollout, or A\u002FB testing before full rollout.\n\n### 5. Package for Serving\n\nAn ML artifact is production-ready only when the serving contract is testable:\n\n- Model artifact includes version, training data reference, config, and preprocessing\n- Input schema rejects invalid, stale, or out-of-range features\n- Output schema includes model version and confidence or explanation fields when useful\n- Serving path has timeout, batching, resource limits, and fallback behavior\n- CPU\u002FGPU requirements are explicit and tested\n- Prediction logs avoid PII and include enough identifiers for debugging and label joins\n- Integration tests cover missing features, stale features, bad types, empty batches, and fallback path\n\nNever let training-only feature code diverge from serving feature code without a test that proves equivalence.\n\n### 6. Operate the Model\n\nModel monitoring needs both system and quality signals:\n\n- Availability, error rate, timeout rate, queue depth, and p50\u002Fp95\u002Fp99 latency\n- Feature null rate, range drift, categorical drift, and freshness drift\n- Prediction distribution drift and confidence distribution drift\n- Label arrival health and delayed quality metrics\n- Business KPI guardrails and rollback triggers\n- Per-version dashboards for canaries and rollbacks\n\nEvery deployment should have a rollback plan that names the previous artifact, config, data dependency, and traffic-switch mechanism.\n\n## Review Checklist\n\n- [ ] Prediction contract is explicit and testable\n- [ ] Data contract defines entity grain, label timing, feature timing, and snapshot\u002Fversion\n- [ ] Leakage risks were checked against prediction-time availability\n- [ ] Training is reproducible from code, config, data version, and seed\n- [ ] Metrics compare against baseline and current production model\n- [ ] Slice metrics and guardrails are included for high-risk cohorts\n- [ ] Promotion gates are automated and fail closed\n- [ ] Training and serving transformations are shared or equivalence-tested\n- [ ] Model artifact carries version, config, dataset reference, and preprocessing\n- [ ] Serving path validates inputs and has timeout, fallback, and rollback behavior\n- [ ] Monitoring covers system health, feature drift, prediction drift, and delayed labels\n- [ ] Sensitive data is excluded from artifacts, logs, prompts, and examples\n\n## Anti-Patterns\n\n- Notebook state is required to reproduce the model\n- Random split leaks future data into validation or test sets\n- Feature joins ignore event time and label availability\n- Offline metric improves while important slices regress\n- Thresholds are tuned on the test set repeatedly\n- Training preprocessing is copied manually into serving code\n- Model version is missing from prediction logs\n- Monitoring only checks service uptime, not data or prediction quality\n- Rollback requires retraining instead of switching to a known-good artifact\n\n## Output Expectations\n\nWhen 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.\n",{"name":5,"description":7,"allowed-tools":49},"Read, Write, Edit, Bash, Grep, Glob","main","18d0e63d1313ca87098f614aa7c1e2dcf6de79c7","backend\u002Fconfig_packs\u002Fai-workflow\u002Fshared\u002Fskills\u002Fmle-workflow",1,"https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system","https:\u002F\u002Fgithub.com\u002Fwelflau","2026-11-10 11:14:25",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add welflau\u002Fai-dev-system --skill mle-workflow",{"tool":63,"command":64},"bunx","bunx skills add welflau\u002Fai-dev-system --skill mle-workflow",{"tool":66,"command":67},"pnpm","pnpm dlx skills add welflau\u002Fai-dev-system --skill mle-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fconfig_packs\u002Fai-workflow\u002Fshared\u002Fskills\u002Fmle-workflow\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"agents\u002Fopenai.yaml","REFERENCE","参考文档",254,"https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fconfig_packs\u002Fai-workflow\u002Fshared\u002Fskills\u002Fmle-workflow\u002Fagents\u002Fopenai.yaml",[78,109,140,165,191,213],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":82,"licenseFileUrl":83,"sourceHtmlUrl":84,"categories":85,"keywords":89,"publishedAt":44},"01M6HSTDP4M3JFXEBK91VFB4PA","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Fweb-artifacts-builder\u002FSKILL.md",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",[90,91,92,93,94,95,96,97,98,99,100,101,102,103,30,104,105,106,107,27,108],"web artifacts builder","web","artifacts","artifacts builder","builder","frontend","css","components","react","routing","state management","state","file","Tailwind","single-file","simple","ui components","multi","single",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":82,"licenseFileUrl":113,"sourceHtmlUrl":114,"categories":115,"keywords":125,"publishedAt":44},"01M6HSDXH0JSP8R3QTNY9XZ8HN","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Ffrontend-design\u002FSKILL.md",[116,117,120],{"categoryNo":87,"categoryName":88,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":118,"categoryName":119,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[95,126,127,96,91,97,98,128,129,130,92,131,132,133,30,134,135,136,137,138,139,26],"design","frontend design","react components","create","code","examples","applications","landing","ui design","pages","aesthetics","web ui","with","generic",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":82,"licenseFileUrl":144,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":44},"01M6HSA77QYVP7A72HREGTDN2C","algorithmic-art","Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Falgorithmic-art\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Falgorithmic-art\u002FSKILL.md",[147],{"categoryNo":118,"categoryName":119,"taxonomyType":20,"taxonomyTypeDesc":21},[149,150,151,129,130,152,153,154,155,30,156,157,158,159,138,160,161,162,163,164,26],"algorithmic art","Art","algorithmic","flow","js","work","interactive","generative art","exploration","systems","users","Existing","request","generative","copyright","fields",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":82,"licenseFileUrl":169,"sourceHtmlUrl":170,"categories":171,"keywords":173,"publishedAt":44},"01M6HS9HE0X390Y6RQKTY1YNGJ","theme-factory","Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors\u002Ffonts that you can apply to any artifact that has been creating, or can generate a new theme on-the-fly.","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Ftheme-factory\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Ftheme-factory\u002FSKILL.md",[172],{"categoryNo":118,"categoryName":119,"taxonomyType":20,"taxonomyTypeDesc":21},[174,175,176,177,178,179,92,180,181,182,133,183,184,135,185,138,186,187,188,27,189,190],"theme factory","factory","theme","docs","toolkit","generate","SET","fly","slides","styling","artifact","themes","you","fonts","can","apply","new",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":198,"publishedAt":44},"01M6HS74GASM6FJ77F83EY679E","browsing","Use when you need direct browser control - teaches Chrome DevTools Protocol for controlling existing browser sessions, multi-tab management, form automation, and content extraction via use_browser MCP tool","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Fsuperpowers-chrome\u002Fskills\u002Fbrowsing\u002FSKILL.md",[197],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[193,199,200,201,202,203,204,205,206,207,208,30,209,210,211,212,107,186,27,160],"MCP","automation","chrome","sessions","protocol","browser","devtools","chrome devtools","tool","direct","browser control","control","via","form",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":82,"licenseFileUrl":217,"sourceHtmlUrl":218,"categories":219,"keywords":226,"publishedAt":44},"01M6HS6BZT2CKDNQ6YF20DXN4T","slack-gif-creator","Knowledge and utilities for creating animated GIFs optimized for Slack. Provides constraints, validation tools, and animation concepts. Use when users request animated GIFs for Slack like \"make me a GIF of X doing Y for Slack.\"","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Fslack-gif-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Fslack-gif-creator\u002FSKILL.md",[220,223],{"categoryNo":221,"categoryName":222,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":224,"categoryName":225,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",[227,228,229,230,231,232,233,234,235,30,236,159,237,238,239,27,161,26],"slack gif creator","slack","gif","creator","validation","Tools","constraints","Animation","knowledge","me","make","Utilities","concepts"]