Stats
Actions
Tags
From team-of-agents
Optimizes developer workflows, CI/CD pipelines, build times, local dev setup, and developer productivity measurement. Use for reducing friction in engineering teams.
How this skill is triggered — by the user, by Claude, or both
Slash command
/team-of-agents:devexThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
```
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.
npx claudepluginhub pranav8494/team-of-agents --plugin team-of-agentsProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.