audit-ci
Skill115 starsChanged 56 days agoApache-2.0View on GitHub
Run and analyze Elements cold CI performance profiles and propose evidence-backed build, test, lint, and dependency-graph improvements. Use whenever asked to profile or benchmark pnpm run ci, rerun ci:profile, create a CI performance audit, compare CI timings, find bottlenecks or the completion path, investigate a CI performance regression, or recommend measured CI/build optimizations.
In this repository46 other files it gives its agents.
- AGENTS.mdAGENTS.md
- projects/starters/angular/AGENTS.mdAGENTS.md
- projects/starters/bundles/AGENTS.mdAGENTS.md
- projects/starters/eleventy/AGENTS.mdAGENTS.md
- projects/starters/eleventy-ssr/AGENTS.mdAGENTS.md
- projects/starters/go/AGENTS.mdAGENTS.md
- projects/starters/go-htmx/AGENTS.mdAGENTS.md
- projects/starters/hugo/AGENTS.mdAGENTS.md
- projects/starters/importmaps/AGENTS.mdAGENTS.md
- projects/starters/lit-library/AGENTS.mdAGENTS.md
- projects/starters/mcp-app/AGENTS.mdAGENTS.md
- projects/starters/mpa/AGENTS.mdAGENTS.md
- projects/starters/nextjs/AGENTS.mdAGENTS.md
- projects/starters/nuxt/AGENTS.mdAGENTS.md
- projects/starters/react/AGENTS.mdAGENTS.md
- projects/starters/solidjs/AGENTS.mdAGENTS.md
- projects/starters/sphinx/AGENTS.mdAGENTS.md
- projects/starters/svelte/AGENTS.mdAGENTS.md
- projects/starters/typescript/AGENTS.mdAGENTS.md
- projects/starters/vue/AGENTS.mdAGENTS.md
- agent-availability-reportSkill
- agent-debug-ciSkill
- agent-dependenciesSkill
- agent-startersSkill
- agent-upkeepSkill
- agent-web-modernizationSkill
- audit-accessibilitySkill
- audit-codeSkill
- audit-consolidationSkill
- audit-simplificationSkill
- authoring-benchmarksSkill
- authoring-componentsSkill
- authoring-documentationSkill
- authoring-examplesSkill
- authoring-patternsSkill
- authoring-projectsSkill
- authoring-testsSkill
- authoring-typescriptSkill
- elementsSkill
- github-dependabotSkill
- guidance-api-designSkill
- guidance-buildSkill
- guidance-webgpu-performanceSkill
- summarize-releasesSkill
- summarize-video-releasesSkill
- troubleshootingSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
26 rules. About 0 are common, 22 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈22
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Read the repository AGENTS.md.
- Very specific: line 15
Read a project's DEVELOPMENT.md before running project-specific commands when that file exists.
- Distinctive: line 17
Do not copy profiling logic into this skill.
- Distinctive: line 21
Run a new profile when the user asks to rerun, benchmark current changes, refresh an audit, or verify an optimization.
- Distinctive: line 23
Create recommendations without implementing them unless the user also asks for the changes.
- Distinctive: line 27
Run all repository commands through mise.
- Very specific: line 31
Stop and ask before profiling if that preview includes user data, local assets, secrets, or other non-reproducible files.
- Distinctive: line 32
Never stash, commit, discard, or clean tracked changes merely to make the profiler accept the worktree.
- Distinctive: line 33
Use the clean command when the worktree is clean:
- Distinctive: line 39
When the dirty changes are the intentional subject of the audit, preserve them and run:
- Distinctive: line 60
all three runs exist;
- Distinctive: line 61
every run has zero incomplete scripts.
- Distinctive: line 63
commit, dirty state, tool versions, CPU, and memory describe the intended environment.
- Distinctive: line 66
Use JSON as the numeric source of truth.
- Distinctive: line 83
Read the optimization playbook when generating recommendations or designing follow-up experiments.
- Very specific: line 87
Create or refresh projects/internals/ci/CI-PERFORMANCE.md.
- Distinctive: line 108
Keep completed work out of the open priority list.
- Distinctive: line 112
Do not add CI-share percentages together.
- Distinctive: line 113
Do not claim a critical path from rankings alone.
- Distinctive: line 114
Do not recommend more concurrency without checking isolation, shared state, ports, output paths, report merging, memory, and machine-wide …
- Distinctive: line 115
Do not remove a quality check unless the same coverage remains in another required workflow.
- Distinctive: line 116
Prefer one-variable experiments and compare at least three samples when variance matters.
- Distinctive: line 118
Treat cache optimization separately from this cold profile because the profiler disables Wireit caching.
- Distinctive: line 120
Keep dependency upgrades separate from performance changes unless the upgrade is the explicit experiment.
- Very specific: line 132
If projects/internals/ci/ci-profile.test.js exists, also run:
- Distinctive: line 138
Do not rerun the full CI merely to validate the report: the profiler already completed it three times.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Audit CI
Produce a repeatable cold-CI profile, explain what controls wall-clock completion, and turn the evidence into prioritized, testable recommendations.
Required context
- Read the repository
AGENTS.md. - Read
projects/internals/BUILD.md. - Inspect the current root
ci:profilescript andprojects/internals/ci/ci-profile.js. Treat the script as the profiling source of truth. - Read a project's
DEVELOPMENT.mdbefore running project-specific commands when that file exists.
Do not copy profiling logic into this skill. Update the repository profiler when its behavior needs to change.
Choose the workflow
- Run a new profile when the user asks to rerun, benchmark current changes, refresh an audit, or verify an optimization.
- Analyze existing
.metrics/ci-profile.{json,md}artifacts without rerunning when the user asks only for interpretation and the artifacts match the intended commit and worktree state. - Create recommendations without implementing them unless the user also asks for the changes.
Profile safely
Run all repository commands through mise.
- Inspect
git status --short. - Preview ignored files that reset would delete with
git clean -ndX. - Stop and ask before profiling if that preview includes user data, local assets, secrets, or other non-reproducible files. The profiler runs
pnpm run ci:reset, which deletes ignored files and reinstalls dependencies before every sample. - Never stash, commit, discard, or clean tracked changes merely to make the profiler accept the worktree.
Use the clean command when the worktree is clean:
mise exec -- pnpm run ci:profileWhen the dirty changes are the intentional subject of the audit, preserve them and run:
CI_PROFILE_ALLOW_DIRTY=1 mise exec -- pnpm run ci:profileRecord the dirty-worktree condition in the report. Do not use this override for unrelated or unexplained changes.
Allow all three cold samples to finish. Dependency installation or browser setup can require network access. If a run fails, inspect the copied .metrics/ci-profile-run-*.log and reset logs, report the incomplete profile, and do not invent missing samples.
Verify the artifacts
The profiler writes ignored artifacts under .metrics/:
ci-profile.json: structured metadata, run durations, and per-script samplesci-profile.md: generated method and top-ten summaryci-profile-run-{1,2,3}.log: complete CI logsci-profile-reset-{1,2,3}.log: reset and install logs
Before analysis, confirm:
- all three runs exist;
- every run has zero incomplete scripts;
- each ranked script has three samples;
- commit, dirty state, tool versions, CPU, and memory describe the intended environment;
- the generated Markdown agrees with the JSON.
Use JSON as the numeric source of truth. Keep full precision during calculations and round only for presentation.
Analyze wall-clock relevance
The slowest command is not automatically the critical path.
- Rank leaf scripts by median duration from
ci-profile.json. - Inspect the end of each run log to identify the scripts that consistently complete last.
- Trace those scripts through their Wireit
dependenciesin the relevantpackage.jsonfiles. - Separate:
- final or near-final dependency branches;
- long parallel work that consumes CPU, memory, filesystem, or browser capacity;
- upstream work that delays a final branch;
- composite commands whose phases need separate timing.
- Inspect each candidate's command, configuration, file count, output, output consumers, and serialization settings before suggesting a change.
- Compare with the existing audit only when its environment and method are compatible. Describe before/after changes as concurrent cold-CI measurements, not isolated causal proof.
Read the optimization playbook when generating recommendations or designing follow-up experiments.
Create the audit
Create or refresh projects/internals/ci/CI-PERFORMANCE.md. Use .metrics/ci-profile.md as generated evidence, not as the finished audit.
Include:
- Frontmatter and generation context
- Executive summary with median CI time and comparison when available
- Method, environment, and all run results
- Current top-ten scripts
- Completion-path analysis
- Numbered open findings
- Verified completed changes when a prior audit exists
- Recommended experiment order
- Raw artifact location
For every finding, provide:
- Evidence: measurements plus current configuration or dependency facts
- Recommendation: one bounded change or experiment
- Validation: output-equivalence checks, metrics to compare, and resource checks
- Confidence: confidence in the diagnosis and in the proposed approach
Keep completed work out of the open priority list. Mark an item verified only when the configuration changed and a comparable full profile confirms the result.
Recommendation guardrails
- Do not add CI-share percentages together; scripts overlap.
- Do not claim a critical path from rankings alone.
- Do not recommend more concurrency without checking isolation, shared state, ports, output paths, report merging, memory, and machine-wide contention.
- Do not remove a quality check unless the same coverage remains in another required workflow.
- Prefer one-variable experiments and compare at least three samples when variance matters.
- Distinguish targeted project benchmarks from full concurrent CI results.
- Treat cache optimization separately from this cold profile because the profiler disables Wireit caching.
- Label estimates and inferred causes. Do not present them as measurements.
- Keep dependency upgrades separate from performance changes unless the upgrade is the explicit experiment.
Check the report
Run:
mise exec -- pnpm exec prettier --write projects/internals/ci/CI-PERFORMANCE.md
mise exec -- pnpm exec vale --config .vale.ini projects/internals/ci/CI-PERFORMANCE.md
git diff --checkIf projects/internals/ci/ci-profile.test.js exists, also run:
mise exec -- node --test projects/internals/ci/ci-profile.test.jsDo not rerun the full CI merely to validate the report: the profiler already completed it three times. Report the median, comparison, top remaining opportunities, artifact paths, and validation results to the user.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

