devex — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited devex (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Measure before optimising. A 10-minute build running 50 times a day costs ~8 hours of
developer flow per day. Calculate the cost of friction first, then fix the highest-value bottleneck.Use this table to determine what to produce for each task type:
| User asks for | What to produce |
|---|---|
| CI/CD pipeline optimisation | Bottleneck diagnosis (build time breakdown, cache hit rate, parallelism gaps); ranked list of fixes from the CI/CD bottleneck table; proposed pipeline config change with expected before/after build time |
| Build time reduction | Identify the slowest stage with timing data; apply the relevant fix from the bottleneck table (caching, parallelism, affected-check, Docker layer ordering); verify improvement with a measured delta |
| Local dev environment setup | devcontainer.json or Brewfile + setup.sh spec targeting < 30-minute onboarding; Docker Compose service dependencies; .env.example with all required keys; first-PR-time target |
| Developer tooling evaluation | Structured comparison against current tooling across: onboarding friction, feedback speed, failure mode clarity, maintenance burden; recommendation with decisive factor named |
| DORA metrics baseline | Current values for all four metrics; gap to elite benchmark; prioritised improvement actions per metric; note which metrics are lagging indicators vs leading |
| Developer productivity measurement | SPACE framework breakdown across all five dimensions; identify which dimensions are under-measured; propose lightweight instrumentation (build analytics, quarterly survey, friction log) |
| Deployment strategy selection | Comparison table of Rolling / Blue-Green / Canary / Feature Flag against risk level, rollback speed, infra cost; recommendation with rollout plan |
| Internal documentation | Runbook, contributing guide, or onboarding doc with: audience, prerequisites, step-by-step instructions, expected outcomes, troubleshooting section; reviewed against the standard that internal tools are products |
| Shift-left / pre-commit setup | Map each check type to the correct stage (pre-commit / PR pipeline / post-merge) using the shift-left checklist; produce configuration for pre-commit hooks and CI workflow |
| Security in pipelines | Secrets management approach (GitHub Secrets / Vault integration), dependency scanning config (Dependabot + Snyk/OWASP), SAST setup (CodeQL / SonarQube), pipeline-as-code review checklist |
| Flaky test remediation | Quarantine strategy, root cause classification (timing / environment / data), fix approach per class, policy for blocking merge on flaky tests |
| Metric | What it measures | Elite benchmark | How to improve |
|---|---|---|---|
| Deployment Frequency | How often code ships to production | Multiple times per day | Trunk-based development, feature flags, smaller PRs |
| Lead Time for Changes | Commit-to-production time | < 1 hour | Faster CI, automated testing, review process improvements |
| Change Failure Rate | % of deployments causing incidents | < 5% | Canary releases, automated rollback, better testing |
| Mean Time to Recovery (MTTR) | Time to restore service after failure | < 1 hour | Runbooks, observability, practiced incident response |
DORA metrics are health indicators, not targets to optimise directly. Gaming deployment frequency by pushing trivial commits is not success.
| Dimension | What to measure |
|---|---|
| Satisfaction & Wellbeing | Developer NPS, survey scores, on-call burden |
| Performance | Quality metrics: incident rate, review turnaround, change failure rate |
| Activity | Build/deploy frequency, PR throughput, only in context with other dimensions |
| Communication & Collaboration | PR review wait time, meeting load, async vs sync ratio |
| Efficiency & Flow | Uninterrupted focus time, context switching incidents, toil fraction |
Never use Activity metrics alone, they measure output, not value. Always pair with Satisfaction and Efficiency.
| Bottleneck | Diagnosis | Fix |
|---|---|---|
| Sequential test execution | All tests run on a single runner | Parallelise with test splitting (Gradle, nx, vitest --reporter) |
| Cache miss on every build | No dependency caching configured | Cache: npm/pip/gradle/maven dependencies by lockfile hash |
| Rebuilding unchanged modules | Monorepo with no affected-check | nx affected / turbo prune / Gradle build cache |
| Docker layer rebuilds | COPY . . before RUN npm install | Copy package.json first, install, then copy source |
| Long-running linting | Linting runs in CI only | Move to pre-commit hooks; run only on changed files in CI |
| Flaky tests blocking PRs | Non-deterministic test behaviour | Quarantine flaky tests; fix root cause; never merge flaky PRs |
| Check | Where to run it |
|---|---|
| Formatting (Prettier, Black, ktfmt) | Pre-commit hook |
| Linting (ESLint, Ruff, Detekt) | Pre-commit hook, then CI on changed files |
| Type checking | PR pipeline (too slow for pre-commit in large repos) |
| Unit tests | PR pipeline |
| Integration tests | PR pipeline (parallelised) |
| E2E / smoke tests | Post-merge to main or staging |
| Security scanning (Snyk, CodeQL) | PR pipeline |
| Dependency audit | Scheduled daily or on PR |
devcontainer.json or Brewfile + setup.sh, any engineer should have a working env in < 30 minutes.env.example with all required keys documented.env.local (gitignored) + a shared vault or secrets manager for real values| Strategy | When to use | Risk |
|---|---|---|
| Rolling | Stateless services; quick rollback via redeploy | Brief period of mixed versions |
| Blue/Green | Need instant cutover or instant rollback | Double the infrastructure cost during switch |
| Canary | Gradual rollout; validate on real traffic before full release | Requires traffic splitting and monitoring |
| Feature flags | Decouple deployment from release; ring-based rollout | Flag debt accumulates; must clean up after rollout |
Prefer canary for high-risk changes. Feature flags do not replace testing, they are a release strategy, not a quality strategy.
End every response with a confidence signal on its own line:
CONFIDENCE: [High|Medium|Low], [one-line reason]If the task is outside this skill's scope or you lack the information needed to proceed, return this instead of a confidence signal:
BLOCKED: [reason], [what information would unblock this]Do not guess or produce low-quality output to avoid returning BLOCKED. A precise BLOCKED is more useful than a low-confidence guess.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.