mirror of
https://github.com/davila7/claude-code-templates.git
synced 2026-09-19 01:30:23 +08:00
Daniel Avila
9b2432237b
* improve: enhance ml-engineer based on automated review - Modernize tooling ecosystem with named, current tools (KServe, vLLM/Triton, Feast/Tecton/Hopsworks, Evidently/WhyLabs/Arize) and note Seldon Core v2's BSL license - Ground bare "Data validation" bullets in named tools (Great Expectations, Pandera) - Add scope-clarifying sentence distinguishing this agent from machine-learning-engineer and mlops-engineer - Reframe hardcoded performance targets as illustrative/configurable SLAs - Name fairness/explainability tooling (Fairlearn, Aequitas, SHAP, LIME) and add model card/regulatory awareness note - Add ML-specific security bullets: artifact integrity, training data PII/leakage checks, adversarial robustness testing Automated review cycle | Co-Authored-By: Claude Code <noreply@anthropic.com> * fix: move ml-engineer scope boundaries into frontmatter description Agent auto-selection reads the frontmatter description, not the body prompt text, so the scope-clarifying sentence added in the previous commit had no effect on delegation. Move it into the description field where it can actually reduce ambiguity with machine-learning- engineer, mlops-engineer, and ai-engineer. Addresses review feedback from greptile-apps[bot] on PR #787. * fix: route prompt-text optimization to prompt-engineer, not ai-engineer ai-engineer's own description explicitly hands off prompt-text-only optimization on an already-chosen model to prompt-engineer (ai-specialists category). ml-engineer's scope note was steering all "prompting work" to the generalist ai-engineer instead, which could reintroduce the routing ambiguity this review is meant to reduce. Addresses review feedback from cubic-dev-ai[bot] on PR #787. * fix: resolve contradiction between ml-engineer's example and its own delegation boundary Example 2 in the frontmatter description depicted ml-engineer handling pure inference-serving optimization (quantization, serving-strategy comparison, canary rollout) - exactly the work the new scope note says to delegate to machine-learning-engineer. Rewrote the example so ml-engineer owns the training-pipeline root cause (feature drift, retraining) and explicitly hands off the serving-side optimization, following the same hand-off pattern already used in ai-engineer.md's examples. Addresses review feedback from greptile-apps[bot] on PR #787. * clarify: distinguish model-level lifecycle work from platform infra in Example 3 Sharpens Example 3's commentary to explicitly frame deployment/ monitoring/retraining as model-level lifecycle ownership (a specific model's own rollout and retraining loop), distinct from the underlying platform/infrastructure automation (CI/CD, GPU orchestration, cross-model versioning) that mlops-engineer.md's own description already claims. Full disambiguation between the three sibling agents' descriptions would require editing mlops-engineer.md and machine-learning-engineer.md too, which is out of scope for this single-file review. Addresses review feedback from greptile-apps[bot] on PR #787. * fix: remove ambiguous "performance optimization" from opening invocation trigger The opening sentence of the frontmatter description is the first thing agent selection matches against, and it still claimed raw "performance optimization" as ml-engineer's trigger even though the same description delegates deep inference-serving optimization to machine-learning-engineer later on. Reworded the opening trigger to fold the redirect in directly, so a pure serving-latency-optimization request no longer matches ml-engineer's own invocation criteria. Addresses review feedback from greptile-apps[bot] on PR #787. --------- Co-authored-by: Claude <noreply@anthropic.com>