Team (team-*)v1.1.0

team-eo-dm

Skills and tools for the Document Management team

by Document ManagementView on GitHub ↗
eodocument-managementDM

team-eo-dm

Skills and tools for the Document Management team.

Installation

claude plugin install ./plugins/team-eo-dm

What does this plugin do?

Provides cross-repository analysis skills for the Document Management team, enabling Claude to gather and synthesise information that spans multiple repositories — helping engineers quickly understand how a feature, entity, or concern is implemented across the codebase.

Skills

  • birds-eye-analysis — cross-repository analysis of a domain concept, entity, or concern.
  • api-change-impact — read-only impact/suitability report for an API change: who consumes the API across the org and who breaks.

birds-eye-analysis

Cross-repository analysis. Use when you need information that is spread across different repositories — for example, tracing how a document entity is handled end-to-end, comparing implementations of the same concept across services, or auditing usage of a shared interface across the estate.

What you need

  • Access to the relevant repositories cloned locally, or read access via GitHub search tools
  • A clear question or topic to investigate (e.g. a domain concept, a data model, a shared API contract)

Quick Start

/birds-eye-analysis "Your context goes here" "Your task goes here"

/birds-eye-analysis "We want to know if we adopted EDM and how" "Analyse the existing projects and describe if we adopted it and how"

Example

Scenario: You are required to analyse if your area has adopted EDM and in case it was, understand how.

/birds-eye-analysis "We want to know if we adopted EDM and how" "Analyse the existing projects and describe if we adopted it and how"

Claude will produce a report with the information required.

Why would you want this?

  • Onboarding: quickly understand how a domain concept is spread across the estate without reading dozens of files manually
  • Cross-cutting changes: assess the blast radius of a change before making it
  • Consistency audits: spot divergent implementations of the same concept across services
  • Architecture reviews: build a map of ownership and data flow for a given domain
  • Bug triaging: gather context quickly during a bug triage.
  • Refinements: gather context quickly about existing logic and how it is implemented.

api-change-impact

Read-only cross-repo impact analysis for an API change. Given a repo and branch, it diffs the change against its base, finds which other repositories in the org consume that API, checks whether each consumer is still compatible, and prints a risk report (🔴 HIGH / 🟡 MEDIUM / 🟢 LOW/info) with file:line evidence and the owning team.

It handles two change shapes:

  • Mode A — declared contract changes: proto / OpenAPI / GraphQL (add/remove/rename a field, make a field required, change a type, etc.).
  • Mode B — server-side behavioral / validation changes: a new precondition enforced in handler/mapper code with no contract-file change (e.g. "the namespace filter is now mandatory"). Proto linters miss these; this skill catches them.

What you need

  • gh CLI authenticated with repo + read:org access to Personio-Internal
  • A branch containing the API change you want to assess (optionally the base branch to diff against)

Quick Start

Run an API change impact report for this branch

I made the namespace field required on ListDocumentsRequest — who breaks?

Example

Scenario: You are about to make a field mandatory on a gRPC endpoint and want to know which clients would break before you merge.

Is this change safe? I made the namespace field required on ListDocuments. Which repositories are affected?

Claude discovers the consumers across the org, inspects each caller's code, and returns a risk report naming the repositories that don't provide the field (HIGH risk) and those that use the endpoint but are unaffected.

Why would you want this?

  • Pre-merge safety: catch breaking API changes before they reach production
  • Blast radius: see every repository that consumes an endpoint and how it's affected
  • Incident prevention: surface clients that don't satisfy a newly-tightened requirement
  • Migration planning: know exactly which consumers must change and who owns them

Limitations

  • Read-only — never comments on PRs, messages teams, or edits code; the only output is a report.
  • Consumer discovery is a lower bound — gh search code is substring-based, rate-limited, and lags recent pushes, and it can miss dynamic/reflection-based or indirect callers (e.g. behind a BFF or the monolith).
  • Static, not runtime — a field "set" in code may still be null at runtime; confirm the full call chain with runtime traces where it matters.
  • Pin the version — api.v1 also matches api.v1alpha1 in code search; treat this as a first-pass report for human review, not a merge gate.