Coderbuds
Your team's shipping standards, org map and delivery metrics, inside your coding agent.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноТолько чтение
Что умеет
- Get My Insights Tool: Get active insights for the authenticated user across all their teams. Optionally filter by tab (activity, performance, collaboration, satisfaction) or only show unseen insights.
- Mark Insight Seen Tool: Mark a specific insight as seen by the authenticated user. This helps track which insights have been reviewed and reduces noise in future queries.
- Get Team Insight Summary Tool: Get an aggregate summary of active insights for the authenticated user's team, including counts per tab, unseen count, and personal insight count.
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Your team's shipping standards, org map and delivery metrics, inside your coding agent.
Список инструментов сервера (15)
Технические названия из tools/list. Нужны только разработчикам.
| get-my-insights-tool | Get active insights for the authenticated user across all their teams. Optionally filter by tab (activity, performance, collaboration, satisfaction) or only show unseen insights. |
| mark-insight-seen-tool | Mark a specific insight as seen by the authenticated user. This helps track which insights have been reviewed and reduces noise in future queries. |
| get-team-insight-summary-tool | Get an aggregate summary of active insights for the authenticated user's team, including counts per tab, unseen count, and personal insight count. |
| get-dora-metrics-tool | Get DORA (DevOps Research and Assessment) metrics for the authenticated user's team. Returns deployment frequency, lead time for changes, change failure rate, and mean time to recovery with period-over-period comparison and performance categories (Elite/High/Medium/Low). |
| get-weekly-summary-tool | Get the latest weekly changelog summary for the authenticated user's team. Includes a TL;DR, executive summary, feature highlights, notable fixes, and team highlights. Use weeks_ago to retrieve older summaries. |
| get-pull-request-metrics-tool | Get pull request activity metrics for the authenticated user's team. Returns PR count, code review count, average quality score, active contributors, and PR size distribution with period-over-period comparison. |
| get-agent-activity-tool | Get a summary of autonomous agent activity for the authenticated user's team. Returns which agents are enabled, recent actions, per-agent stats, and pending approval counts. |
| get-team-overview-tool | Get a comprehensive team health overview using the SPACE framework. Returns activity metrics (PRs, deployments, contributors), DORA performance ratings, collaboration metrics (code reviews, participation rate), and efficiency metrics (cycle time, PR size). Use this for a single-call snapshot of team engineering health. |
| get-merged-pull-requests-tool | Count merged pull requests over a recent window (default 30 days), with a human-vs-bot split so you can answer "including dependabot" and "excluding dependabot" from the same result. Returns the total plus per-repository and per-author breakdowns. Optionally scope to specific "owner/name" repositories (e.g. patchstack/saas). Use this when the user asks how many PRs were merged, shipped, or closed on a repo or across the team — including bot/dependabot PRs. |
| get-undeployed-pull-requests-tool | List merged pull requests that have not yet shipped to production, grouped by repository. Returns how long each PR has been waiting and when each repository last deployed — the signal behind deploy-lag and lead-time risk. Use this to spot work that is merged but stuck before deployment. Merged PRs that predate their repository's most recent successful production deploy are assumed shipped (deploys ship the default branch) and reported via `assumed_deployed` instead of being false-positive "undeployed" entries. |
| get-deployments-by-person-tool | List who triggered production deployments over a recent window (default 7 days) and how many each shipped, with failed deploys surfaced per person — e.g. "Bob Marley: 5 deploys (3 failed)". Use this to answer "who has deployed to production this week and how much". Returns each person's deploy count, failed count, and the repositories they shipped to, sorted by deploy count, plus team totals. |
| get-open-pull-requests-tool | List the team's open pull requests grouped by author, with the signal that shows what is blocking each one: whether it is awaiting a reviewer, has changes requested, is approved and ready to merge, is still a draft, is failing CI checks, or is simply too large for anyone to review. Optionally scope to specific "owner/name" repositories (e.g. patchstack/hub). Use this to nudge people to merge — lead with the `headline`. Human authors include their oldest open PRs with age; bot authors (dependabot etc.) are collapsed into count-only summaries so a dependency backlog cannot drown out the PRs a person should act on. `total_oversized` and the per-PR `oversized` flag mark pull requests past the hard review limits — over 100 files, over 5,000 added or deleted lines, or over 8,000 changed in total. These are the ones a reviewer cannot pick up at all, so they are named in the headline and sorted to the front of their author's list. Report them as blocked on being split, not as blocked on a reviewer. The threshold is deliberately the hard limit rather than the team's line target: an open PR gives no file list, so the test/docs discount `assess-change-fit` applies to a numstat cannot be applied here, and judging against the target would flag changes that check would have passed. `size.category` is `unknown` when the counts were never recorded — that is missing data, not a small pull request; do not describe it as small. Set `include_bot_details` when you are working the dependency queue itself — merging dependabot PRs, chasing failing bumps — and each bot author gains the PR numbers, repositories, titles and URLs you need to act, ordered by what can be closed out first: ready to merge, then failing checks, then oldest. Check `status_freshness` before quoting counts: it flags open PRs whose local status may be stale, and repositories that have not synced pull requests recently — whose PRs may be missing from these counts altogether. Archived (decommissioned) repositories are excluded — this is a review queue, and their PRs are nobody's to review. |
| get-my-status-tool | Your personal cross-repo status: your open PRs and what blocks each (awaiting review, changes requested, failing checks, draft, or ready to merge), reviews you could unblock (other people's oldest PRs waiting on a reviewer, bots excluded), your merged-but-undeployed work with hours waiting, and what you shipped recently — standup prep and morning brief in one call. Lead with the `headline` when relaying this result. |
| get-person-activity-tool | What one person on the team has actually been doing, over a recent window (default 8 weeks). Answers "is Dave still shipping?" or "what has Sam been working on?" with three counts read together rather than one in isolation: pull requests opened and merged, reviews given to other people, and production deploys triggered — plus a week-by-week rollup, the busiest days, and the longest quiet run. Lead with the `headline`. A pull request count on its own supports the wrong conclusion: someone who opened 5 pull requests and gave 70 reviews is carrying the team's review load, not coasting. The headline says which of those it is. Identify the person by name or provider login ("dave", "Dave Smith", "@dsmith"). When the reference is ambiguous or unknown the tool returns the team's member names in `candidates` instead of guessing — ask which one rather than reporting activity for the wrong person. `not_captured` lists what this data cannot see (commits, review comment volume, ticket assignment, anything outside git). Repeat those limits when the answer is "this person looks quiet" — never present an absence of pull requests as an absence of work. |
| get-team-context-tool | The team's org map: every repository the team ships to, how alive each one is (merged/open PR activity, top contributors, last merge), how each deploys to production, whether each is ready for a coding agent (a compact `readiness` flag with failing check keys — call `get-repo-readiness` for the full checks and recommendations), how repos relate (taught links plus shared-contributor signals), and the team's confirmed working conventions. Everything is derived from live shipping data, so it never goes stale like a hand-maintained repo list in an agent rules file. Pass `repository` (the repo you are working in) to get a FOCUSED map: that repository's details, the repositories most relevant to it with the reasons they matter, and the rest as names only — the right call at session start in a multi-repo org, instead of pulling the whole atlas. When the map is wrong or incomplete, teach it with `link-repositories`. For size/review norms, use `assess-change-fit`. |