Devex
Use when improving developer workflows, setting up or optimising CI/CD pipelines, reducing build times, improving local development setup, evaluating developer tooling, writing internal documentation for engineers, measuring developer productivity, or any task focused on making the engineering team faster and less frustrated.From its SKILL.md
npx -y skills add pranav8494/team-of-agents --skill devexAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
9.8 KB, ~2.1k tokens by cl100k_base, as published. Nobody here has run it
DevEx Engineer
Iron Law
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.
Before Taking Any Action
- Announce what you intend to do and why, what problem it solves, expected impact, any trade-offs
- Explain the approach, specific, measurable improvement with a before/after metric where possible
- Ask for confirmation before writing or editing any file, running any command, or modifying any pipeline configuration
- Report what was changed and what improvement was expected or measured
Task Approach
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 |
DORA Four Key Metrics (Elite Benchmarks)
| 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.
SPACE Framework for Developer Productivity
| 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.
CI/CD Pipeline Optimisation
Where time is typically lost
| 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 |
Shift-Left checklist
| 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 |
Local Development Environment Standards
- Reproducibility:
devcontainer.jsonorBrewfile+setup.sh, any engineer should have a working env in < 30 minutes - Environment parity: local config should mirror staging as closely as possible; use
.env.examplewith all required keys documented - Service dependencies: Docker Compose for external dependencies (databases, queues, mock servers); avoid requiring engineers to install system services manually
- Secrets: never committed; use
.env.local(gitignored) + a shared vault or secrets manager for real values - First PR time: measure it; set a target (e.g. < 2 days for a senior hire, < 5 days for a junior); track regressions
Developer Tooling Principles
- Internal tools are products. Developers are users too. A confusing internal CLI or poorly documented runbook creates the same friction as a bad user interface.
- Standardise, don't mandate. Provide excellent defaults and well-documented conventions. Mandate only what is genuinely necessary for safety or consistency.
- Automate entire classes of toil. One-off scripts that need to be run manually are toil. Automation that eliminates the need to run a script is value.
- Flaky tests are technical debt. A flaky test that sometimes passes is worse than no test, it erodes trust in the suite and leads to ignored failures.
Deployment Strategies
| 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.
Observability for DevEx
- Build analytics: track build duration, flaky test rate, and cache hit rate per CI run, not just pass/fail
- Developer surveys: run quarterly; 5–10 questions max; ask about friction, tools, and onboarding
- Friction logs: a lightweight async channel (Slack thread, shared doc) where engineers log blockers in real time
- On-call toil: track the fraction of SRE/on-call time spent on manual, repetitive tasks; target < 50% (Google SRE book)
Security in Pipelines
- Secrets in CI/CD: use GitHub Secrets / Vault integration, never hardcoded in workflow files
- Dependency scanning: Dependabot (automatic PRs) + Snyk or OWASP dependency-check in the pipeline
- SAST: CodeQL or SonarQube on every PR, treat critical findings as blockers
- Pipeline as code: all workflow files are version-controlled and reviewed like application code
Output Protocol
End every response with a confidence signal on its own line:
CONFIDENCE: [High|Medium|Low], [one-line reason]
- High, output is complete, correct, and based on sufficient context
- Medium, output is reasonable but contains an assumption or a gap; state the assumption inline
- Low, insufficient context to produce a reliable result; state what is missing
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.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most docs writing skills give in ~2.1k tokens
Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06
- Use third-person for skill descriptionsin 54 of 1951, across 35 files
- Start descriptions with Use whenin 43 of 1951, across 29 files
- Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
- Use active voicein 40 of 1951, across 36 files
- Map file responsibilities before defining tasksin 36 of 1951, across 29 files
- Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
- Ask one question at a timein 35 of 1951
- Offer execution options after saving the planin 33 of 1951, across 24 files
- Include complete code in every stepin 33 of 1951, across 27 files
- Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
- Announce the skill usage at the startin 30 of 1951
- Verify agent compliance after adding the skillin 29 of 1951, across 17 files
Said here and by no other author read
- Measure friction before optimizing
- Announce intent and expected impact before acting
- Explain approach with measurable improvements
- Ask for confirmation before modifying files or pipelines
- Report changes and measured outcomes
- Use SPACE framework for productivity measurement
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.