audit
SolidRead a training/evaluation pipeline and emit ranked, evidence-graded, priced findings on its speed↔quality frontier — across the algorithmic (A), systems (B), and protocol (C) tiers. Use for `/parml:audit`, "why is my training slow", "how do I speed up this training without losing accuracy", "review my training loop for efficiency", "what am I leaving on the table here", "is my pipeline input-bound", or before committing to a round of optimisation. Modality-agnostic — vision, text, audio, tabular, graph, time-series. Prices everything in time-to-target-quality, never throughput. Read-first: writes only ./.parml/findings.md and never edits project code. Do NOT use for a one-line "make this loop faster" on non-ML code, for model-quality debugging with no efficiency question, or to run training.
Install
Quality Score: 79/100
Skill Content
Details
- Author
- emaballarin
- Repository
- emaballarin/ccplugins
- Created
- 3 months ago
- Last Updated
- today
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
review
Adversarially review a proposed or applied efficiency change to a training/evaluation pipeline: did the claimed mechanism actually engage, is the measurement still valid, what did it silently break. Use for `/parml:review`, "I made this training faster, check it", "review this diff before I merge it", "why did throughput improve but accuracy drop", "did this speedup actually work", or on any diff touching a training loop, data pipeline, optimiser, precision, or evaluation path. Walks a pitfall catalogue — score inflation, dead knobs, the throughput fallacy, optimisations that never engaged, stale step-unit hyperparameters, train/eval mismatch, leakage. Read-only; verdicts, not edits. Do NOT use to find new opportunities (that is /parml:audit) or for general code review of non-ML code (that is /code-review).
auditsmith
Use when auditing, reviewing, or assessing an application's codebase — including narrower phrasings like 'review my code', 'is this secure', 'is this production ready', 'why is this slow', 'check my error handling', 'is my LLM integration safe', 'find issues in this repo', or 'what am I missing before launch'. Covers ten areas — UX behavior, code quality, UI, security, LLM/AI usage, performance, testing, dependencies, observability, API contracts. Detects auth/authz gaps, IDOR, injection, secrets, SSRF, prompt injection, race conditions, missing error handling, empty states, N+1 queries, bundle bloat, memory leaks, flaky tests, CVEs, idempotency gaps, missing logging/alerting. Contexts — pre-launch, handover, client delivery, code review, refactor planning. Outputs findings with file:line evidence, severity ranking, and CI/lint rules to prevent regression. Stacks — React, TypeScript, Node, Python, Go, Cloudflare Workers.
product-audit
Periodic, product-wide health check — the CTO's "where do we actually stand?" Sweeps the WHOLE codebase (not a diff, not a PR) across every applicable axis — correctness, architecture, security/cybersecurity, performance, tests, UX/UI, accessibility, SEO, brand, tech debt — PLUS process & docs (incomplete phases, aging issues, solvable known-issues, doc/workflow completeness) and roadmap coherence. Mines accumulated suggestions from feature docs. Output: a severity-ranked report and concrete PROPOSALS — issues to open, roadmap features to add or remove. Every run is persisted to docs/audits/<n>-<YYYY-MM-DD>.md with an incremental audit id and findings numbered F1, F2, … so any finding is addressable later as "triage-issue <audit-id> F<k>". NEVER auto-fixes; the user decides what to act on. On Claude Code and want hand-tuned per-skill model/effort tiers? Install the `#claude` branch instead (`npx skills add gtrabanco/agentic-workflow#claude`) — see the README. This branch is model-agnostic: the skill inherits