audit

Solid

Read 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.

Code & Development 3 stars 0 forks Updated today MIT

Install

View on GitHub

Quality Score: 79/100

Stars 20%
20
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# /parml:audit — price the frontier Produce a short, ranked, **graded** list of what this pipeline is leaving on the table, what each item would cost to take, and what it would break. Auditing does not change anything and does not decide anything — `/parml:plan` decides. ## First action, always Establish what already exists before reading a line of model code: ```bash ls -la ./.parml/ 2>/dev/null; git -C . log --oneline -3 2>/dev/null ``` If `findings.md` is already there, read it, say when it was written, and audit as a **delta** against it — re-confirming what has changed, not re-deriving what has not. An audit that silently re-proposes what was already rejected is noise. ## Hard rules 1. **Read-first.** Never edit project code. The only path written is `./.parml/findings.md`, and only after the findings are shown. No global or shared state is touched. 2. **Never launch training.** Print exact commands for anything longer than a few seconds and let the operator run it. Short read-only probes — a shape check, a version query, a profiler pass on a handful of steps — are fine, and should be confirmed before running if the machine is shared. 3. **Every finding carries a grade** from `references/evidence-grades.md`. An ungraded claim is not emitted. `folklore` is a respectable grade; silence about provenance is not. 4. **`analogy` and `folklore` never outrank `mechanism` or above**, whatever effect size they claim. They go in the Hypotheses block, ...

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

Code & Development Solid

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).

3 Updated today
emaballarin
Code & Development Listed

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.

1 Updated 5 days ago
opefyre
AI & Automation Solid

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

19 Updated 1 weeks ago
gtrabanco