Engineering Manager

Start here

Widely used and core to this role

• GitHub Copilot(opens in new tab)

  · AI coding assistant

  AI coding assistant with usage metrics for admins, including daily active users, acceptance rate, lines of code and pull request lifecycle.

Also worth a look

Depends on your team and stack

Written from the changes above. Read and adapt one before you use it.

• AI impact metrics reviewCompares team AI use with delivery and quality metrics and drafts a balanced summaryai-impact-metrics-reviewView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named ai-impact-metrics-review. When to use it: Reviews team-level data on AI tool use together with delivery, quality and stability metrics against a baseline, using metrics that keep each other in check, and drafts a balanced summary for leadership. Never uses code volume or individual data as a productivity measure. Use when asked "is AI making the team faster?", when preparing an AI adoption or impact update, setting a baseline before rolling out a tool, or reviewing an AI usage dashboard.

  ---
  name: ai-impact-metrics-review
  description: Reviews team-level data on AI tool use together with delivery, quality and stability metrics against a baseline, using metrics that keep each other in check, and drafts a balanced summary for leadership. Never uses code volume or individual data as a productivity measure. Use when asked "is AI making the team faster?", when preparing an AI adoption or impact update, setting a baseline before rolling out a tool, or reviewing an AI usage dashboard.
  metadata:
    title: "AI impact metrics review"
    summary: "Compares team AI use with delivery and quality metrics and drafts a balanced summary"
  ---
  
  # AI Impact Metrics Review
  
  Give an honest, team-level picture of how AI tools are affecting delivery, quality and stability, compared with a baseline, without turning output counts into a productivity score.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The question leadership is asking, and the decision it feeds (for example renewing licences or expanding a rollout).
  - Team-level AI usage data for the period (for example active users and frequency), aggregated, not per person.
  - Delivery metrics for the same period and a baseline period before the change: for example PR throughput, cycle time and deployment frequency.
  - Quality and stability metrics for both periods: for example change failure rate, incidents, reverted changes and review time.
  - Developer experience input, such as survey results or themes from team discussions.
  - Context that affects the numbers: team size changes, holidays, big launches, reorganisations, other process changes.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Confirm the data is aggregated at team level. If per-person data is provided, stop and ask for a team-level export; do not analyse or keep the individual rows.
  2. Check that the baseline and current periods are comparable in length, team size and type of work. List every difference.
  3. Organise metrics into groups: utilisation (how much the tools are used), impact (delivery, quality, stability, developer experience) and cost (if provided).
  4. For each metric, show baseline, current value and direction of change.
  5. Pair metrics that keep each other in check: throughput with change failure rate, cycle time with incidents, review time with pull request size.
  6. Note where throughput went up while stability or quality went down, and flag it prominently.
  7. Mark any metric based on code volume, lines of code, acceptance rate or commit counts as weak evidence and do not use it as a productivity measure.
  8. Separate correlation from cause. List other changes that could explain the movement.
  9. Note if the period includes ramp-up time, and what longer data would show.
  10. Draft a summary with findings, uncertainties, and options for leadership. Do not recommend decisions about individuals.
  
  ## Output format
  
  ```markdown
  # AI impact review: <team or group> — <period> vs <baseline period>
  
  **Question:** <what leadership asked>
  **Overall reading:** <one or two sentences, including uncertainty>
  
  ## Comparability of periods
  
  - <differences in team size, work type, events>
  
  ## Metrics
  
  | Group | Metric | Baseline | Current | Change | Paired with | Evidence strength |
  | ----- | ------ | -------- | ------- | ------ | ----------- | ----------------- |
  
  ## What the data suggests
  
  1. <finding> — supported by <metrics>
  
  ## Warning signs
  
  - <e.g. throughput up while change failure rate up>
  
  ## Other explanations to rule out
  
  - <item>
  
  ## What we cannot tell yet
  
  - <item and data that would help>
  
  ## Options for leadership
  
  | Option | Supports | Risks |
  | ------ | -------- | ----- |
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Code generation volume, lines of code and acceptance rate are easy to measure and easy to game. They do not show whether code is maintainable or later reverted.
  - Never use these metrics in individual performance evaluations, and say so if the review is shared with the team.
  - Check whether stability metrics moved with throughput.
  - Note if the period includes ramp-up time, and what longer data would show, before presenting any change as success or failure.
  - Never reproduce secrets, credentials or personal data in the output unless the user needs them.
  - Small teams produce noisy metrics. A few incidents can swing a rate.
  - Do not attribute all change to AI when other process or team changes happened in the same period.
  
  ## Before you finish
  
  - [ ] All data in the output is team-level; no individual appears.
  - [ ] Every impact metric has a baseline and a paired counter-metric.
  - [ ] Volume-based metrics are marked as weak evidence, not productivity.
  - [ ] Other explanations and uncertainties are listed.
  - [ ] Options are presented without deciding for leadership.
  - [ ] Clearly flag every assumption, and anything the engineering manager or leadership must review or decide.
  

• AI tool spend reviewBreaks down AI tool spend, spots unused seats and cost spikes, and drafts a forecastai-tool-spend-reviewView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named ai-tool-spend-review. When to use it: Reviews a team's AI tool spend from invoices or usage exports, breaking it down by tool, seat and usage-based charges, calculating spend per developer, spotting unused seats and cost spikes, and drafting a forecast and budget note with options. Use when preparing a tooling budget, checking a surprise AI bill, planning licence renewals, or when asked "what are we spending on AI tools?" or "forecast our AI costs".

  ---
  name: ai-tool-spend-review
  description: Reviews a team's AI tool spend from invoices or usage exports, breaking it down by tool, seat and usage-based charges, calculating spend per developer, spotting unused seats and cost spikes, and drafting a forecast and budget note with options. Use when preparing a tooling budget, checking a surprise AI bill, planning licence renewals, or when asked "what are we spending on AI tools?" or "forecast our AI costs".
  metadata:
    title: "AI tool spend review"
    summary: "Breaks down AI tool spend, spots unused seats and cost spikes, and drafts a forecast"
  ---
  
  # AI Tool Spend Review
  
  Produce a clear, team-level view of what AI tools cost, where the money goes and what spend is likely next, so the manager can make budget decisions with facts.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - Invoices, billing exports or admin usage reports for each AI tool, for at least the last few months.
  - The pricing model for each tool: per seat, usage-based credits or tokens, or both, and any spend limits already set.
  - The number of developers on the team for each month in the period.
  - Team-level usage data (active users per tool), if available.
  - The current budget and the budget period.
  - Known upcoming changes: new hires, new tools, planned rollouts or contract renewals.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Build a month-by-month table of spend per tool, separating seat charges from usage-based charges.
  2. Calculate total spend and spend per developer for each month, using the team size for that month.
  3. Compare seats paid for with active users per tool. List seats that appear unused, as counts per tool, not names.
  4. Identify spikes in usage-based charges and note what else happened that month, such as a new agent workflow or a large migration.
  5. Check for overlap: several tools paid for the same job.
  6. Note whether spend limits or alerts exist for usage-based tools, and who can see and change them.
  7. Draft a forecast for the next budget period with low, expected and high cases. State every assumption behind each case.
  8. List options: adjusting seats, setting or changing spend limits, consolidating tools, or keeping spend steady during a learning period. Give trade-offs for each.
  9. Where impact data exists, point to it; do not claim a return on investment the data does not show.
  10. Produce the draft. Do not change seats, limits, plans or contracts.
  
  ## Output format
  
  ```markdown
  # AI tool spend review: <team> — <period>
  
  **Budget for period:** <amount> | **Spend to date:** <amount>
  
  ## Monthly spend
  
  | Month | Tool | Seat charges | Usage charges | Total | Team size | Spend per developer |
  | ----- | ---- | ------------ | ------------- | ----- | --------- | ------------------- |
  
  ## Seats and usage
  
  | Tool | Seats paid | Active users | Apparently unused seats |
  | ---- | ---------- | ------------ | ----------------------- |
  
  ## Spikes and overlaps
  
  - <month / tool — amount — possible cause>
  
  ## Spend controls
  
  | Tool | Limit or alert in place? | Who can change it |
  | ---- | ------------------------ | ----------------- |
  
  ## Forecast: <next period>
  
  | Case     | Total | Assumptions |
  | -------- | ----- | ----------- |
  | Low      |       |             |
  | Expected |       |             |
  | High     |       |             |
  
  ## Options
  
  | Option | Expected effect | Trade-offs |
  | ------ | --------------- | ---------- |
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Check usage-based charges separately; seat counts alone may understate cost.
  - A seat with low use is not necessarily wasted; the person may be on leave or new. Present unused seats as a question, not a cut list.
  - Do not use per-person spend or usage as a measure of anyone's productivity or performance.
  - Present cutting tools as a trade-off to discuss.
  - Currency, tax and discount differences between invoices can distort comparisons. Normalise and say how.
  - Keep contract terms and pricing confidential to the intended audience.
  - Never reproduce secrets, credentials or personal data in the output unless the user needs them.
  
  ## Before you finish
  
  - [ ] Seat and usage-based charges are separated.
  - [ ] Spend per developer uses the correct team size for each month.
  - [ ] Unused seats are shown as counts, with no individual named.
  - [ ] Each forecast case lists its assumptions.
  - [ ] No seats, limits, plans or contracts were changed.
  - [ ] Clearly flag every assumption, and anything the engineering manager or finance must review or decide.
  

• Team AI policy draftDrafts a team policy on approved AI tools, data, agent permissions and spend, for approvalteam-ai-policy-draftView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named team-ai-policy-draft. When to use it: Drafts a manager-owned team AI tool policy for approval, within the organisation's rules, covering approved tools, what code and data may go into them, agent permissions, spend limits, minimum review and testing requirements, how usage data will and will not be used, and a plan to walk the team through it. Day-to-day team norms (Definition of Done for AI-assisted work, review pairing, retrospective questions) belong in a team-authored working agreement instead. Use when a team adopts AI coding tools or agents, when policy is unclear or out of date, or when asked to "write our AI policy", "which AI tools are we allowed to use" or "set rules for AI agents and data".

  ---
  name: team-ai-policy-draft
  description: Drafts a manager-owned team AI tool policy for approval, within the organisation's rules, covering approved tools, what code and data may go into them, agent permissions, spend limits, minimum review and testing requirements, how usage data will and will not be used, and a plan to walk the team through it. Day-to-day team norms (Definition of Done for AI-assisted work, review pairing, retrospective questions) belong in a team-authored working agreement instead. Use when a team adopts AI coding tools or agents, when policy is unclear or out of date, or when asked to "write our AI policy", "which AI tools are we allowed to use" or "set rules for AI agents and data".
  metadata:
    title: "Team AI policy draft"
    summary: "Drafts a team policy on approved AI tools, data, agent permissions and spend, for approval"
  ---
  
  # Team AI Policy Draft
  
  Draft a short, practical AI tool policy for an engineering team that fits the organisation's rules. The engineering manager owns it and it needs approval before it applies. It sets the boundaries; the team then agrees its own working norms inside them.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The organisation's existing AI, security, data protection and procurement policies.
  - The AI tools the team uses or wants to use, and whether each is approved or licensed.
  - The kinds of code and data the team handles (for example customer data, credentials, regulated data, open-source code).
  - Current review, testing and release practices.
  - Whether agents can act on their own (open pull requests, run commands, access environments).
  - Budget limits and who owns AI tool spend.
  - Who must approve the policy (for example security, legal or the engineering leadership).
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Summarise the organisation-level rules that apply. If a rule is missing or unclear, list it as a question for the approvers.
  2. List approved tools and what each may be used for. Mark tools the team wants but that are not approved as "pending approval".
  3. Define data rules: what may go into each tool, and what must never go in (for example secrets, customer personal data, or code under restrictive licences).
  4. Set minimum review and testing requirements: AI-generated code is reviewed like any other code, the author is accountable for it, and tests are not skipped. Leave how the team meets them (Definition of Done details, review pairing, change size) to the team's working agreement.
  5. Define agent permissions: what agents may do without a human (for example draft a pull request) and what always needs a human (for example merging, deploying, or touching production data).
  6. Set spend limits and who owns them, describe how usage and spend are tracked, who can see the data, and state that usage metrics will not be used for individual performance evaluation.
  7. Describe how people ask for a new tool or an exception, and who decides.
  8. Draft a short plan to walk the team through the policy, collect questions, invite the team to agree its own working norms within it, and set a review date.
  9. List who must approve the policy and what each approver needs to confirm.
  10. Produce the draft for approval. Do not publish it, change tool settings or grant access.
  
  ## Output format
  
  ```markdown
  # AI tool policy (draft): <team>
  
  **Owner:** <engineering manager> | **Approvers:** <roles> | **Status:** Draft, not in force until approved | **Review date:** <date>
  
  ## Purpose
  
  <two sentences>
  
  ## Approved tools
  
  | Tool | Approved for | Not approved for | Status |
  | ---- | ------------ | ---------------- | ------ |
  
  ## Data rules
  
  - May go into approved tools: <list>
  - Must never go into AI tools: <list>
  
  ## Minimum review and testing requirements
  
  - <requirement>
  - Team norms for meeting these live in the team's AI working agreement.
  
  ## Agent permissions
  
  | Action | Agent may do alone | Needs a human |
  | ------ | ------------------ | ------------- |
  
  ## Usage and spend
  
  - What is tracked: <…>
  - Who can see it: <…>
  - Usage data is not used for individual performance evaluation.
  - Spend limits: <…>
  
  ## Requests and exceptions
  
  - <process and decision owner>
  
  ## Rollout plan
  
  - <walkthrough session, Q&A, team working agreement session, review date>
  
  ## Assumptions and open questions
  
  - <assumption or question for approvers, and who can confirm>
  ```
  
  ## Watch out for
  
  - A team policy cannot loosen organisation policy. Flag conflicts instead of resolving them.
  - Vague rules ("be careful with data") do not help. Give concrete examples of allowed and forbidden inputs.
  - Keep review and testing expectations firm regardless of change volume.
  - Keep day-to-day team norms out of the policy. The team owns those in its working agreement.
  - Output metrics such as code volume are easy to game. Do not set targets based on them.
  - Tool choice may be constrained by procurement. Note this rather than recommending unapproved tools.
  - Agents with broad permissions can take irreversible actions. Default to requiring a human for anything that merges, deploys, deletes or touches production.
  - A policy nobody has read has no effect. Include the walkthrough plan.
  
  ## Before you finish
  
  - [ ] Every rule is consistent with the organisation policies provided, or the conflict is flagged.
  - [ ] Data rules include concrete examples.
  - [ ] Irreversible agent actions require a human.
  - [ ] The policy states usage data is not used for individual performance evaluation.
  - [ ] Nothing was published, configured or granted.
  - [ ] Clearly flag every assumption, and anything the engineering manager or approvers must review or decide.