Software Developer / Engineer

Start here

Widely used and core to this role

• GitHub Copilot(opens in new tab)

  · AI coding assistant

  Inline completions, chat, agent mode in the IDE, and assigning issues to a cloud agent that opens a pull request for review.

Also worth a look

Depends on your team and stack

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

• AI diff reviewReviews AI-written code changes for correctness, security and tests, and drafts commentsai-diff-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-diff-review. When to use it: Reviews a diff or pull request written by an AI assistant or coding agent for correctness, security, test integrity and fit with the codebase, and drafts review comments. Use when asked to review AI-generated code, an agent's pull request, a large machine-generated diff, or your own agent's changes before merge; triggers include "review this diff", "check the agent's PR", "is this AI change safe to merge". For infrastructure, data-model, security-fix or test-only changes, a more specific review skill fits better.

  ---
  name: ai-diff-review
  description: Reviews a diff or pull request written by an AI assistant or coding agent for correctness, security, test integrity and fit with the codebase, and drafts review comments. Use when asked to review AI-generated code, an agent's pull request, a large machine-generated diff, or your own agent's changes before merge; triggers include "review this diff", "check the agent's PR", "is this AI change safe to merge". For infrastructure, data-model, security-fix or test-only changes, a more specific review skill fits better.
  metadata:
    title: "AI diff review"
    summary: "Reviews AI-written code changes for correctness, security and tests, and drafts comments"
  ---
  
  # AI Diff Review
  
  Review a change drafted by an AI assistant or agent as carefully as a colleague's, and draft findings a human reviewer can act on.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The diff, branch or pull request to review, and the base it is compared against.
  - The task, ticket or spec the change was meant to implement.
  - How to build and run the tests locally, if you are allowed to run them.
  - Any areas the author is unsure about, and any parts of the codebase that are off limits.
  - The team's coding and security conventions (instruction file, style guide, lint rules).
  
  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. Restate the intended change in two or three sentences from the ticket or spec. If there is no ticket, say so and infer intent from the diff, marking it as an assumption.
  2. Read the whole diff once without commenting. List every file touched and group them: feature code, tests, configuration, dependencies, generated files.
  3. Check scope. Flag changes that the task did not ask for, such as unrelated refactors, renamed files, reformatting or edits to shared configuration.
  4. Check correctness line by line against the intent. Look for code that is almost right: off-by-one boundaries, wrong defaults, swallowed errors, missing null or empty handling, incorrect assumptions about existing APIs, and logic that only works for the happy path.
  5. Verify that every function, method, library and configuration key the diff uses actually exists in this codebase or its declared dependencies. Search the repository rather than trusting names that look plausible.
  6. Run a security pass on every changed line, treating AI-written code as untrusted until checked:
     - input validation and output encoding (injection, cross-site scripting, log injection);
     - authentication and authorisation checks on new or changed entry points;
     - secrets, tokens or credentials in code, tests, logs or fixtures;
     - unsafe use of cryptography, randomness, file paths, deserialisation or shell calls;
     - new or changed dependencies: confirm each package name is real, intended and pinned the way the project expects.
  7. Check test integrity. Flag any test that was deleted, skipped, disabled, loosened (weaker assertions, broader matchers, added retries) or rewritten to match new behaviour without explanation.
  8. Check that new behaviour has tests, including at least one failure or edge case, not only the happy path.
  9. If you are allowed to, run the existing build, linters and tests in an isolated environment without production credentials, and record the results. Do not push, merge, deploy or change the branch.
  10. Check fit: duplicated helpers that already exist elsewhere, naming and structure that break local conventions, and missing or stale documentation.
  11. Sort findings by severity and write each one as a concrete comment with file, line and a suggested fix or question.
  
  ## Output format
  
  ```markdown
  ## Review summary
  
  - **Change:** <one-sentence restatement of intent>
  - **Recommendation:** Approve / Approve with changes / Request changes / Needs discussion
  - **Tests run:** <commands and results, or "not run" with reason>
  
  ## Findings
  
  | #   | Severity                      | File:line | Category                                                 | Finding | Suggested fix or question |
  | --- | ----------------------------- | --------- | -------------------------------------------------------- | ------- | ------------------------- |
  | 1   | Blocker / Major / Minor / Nit |           | Correctness / Security / Tests / Scope / Maintainability |         |                           |
  
  ## Security pass
  
  - Input handling: <ok / issues, with references>
  - Auth and access control: <...>
  - Secrets and sensitive data: <...>
  - Dependencies: <new packages and whether each was confirmed>
  
  ## Test integrity
  
  - Tests added: <list>
  - Tests removed, skipped or weakened: <list, or "none found">
  
  ## Out of scope changes
  
  - <list, or "none">
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Output that is almost right. It compiles and reads well but handles one case wrongly; trace the unusual inputs, not just the obvious ones.
  - Clean syntax is not evidence of secure code. Always do the security pass, even for small diffs.
  - An agent claiming it ran or passed tests. Only report test results you ran yourself or can see in CI output.
  - Plausible but invented APIs, configuration options or package names.
  - Tests changed in the same diff as the code they test, which can hide a behaviour change.
  - Very large diffs. Say which parts you reviewed in depth and which you only skimmed.
  - Fixes that silence a symptom (catching and ignoring an exception, widening a type) instead of fixing the cause.
  - Never reproduce secrets, tokens, credentials or personal data in the output; refer to them by location and type, and tell the user to rotate anything exposed.
  - For infrastructure, data-model, security-fix or test-only changes, a more specific review skill fits better.
  
  ## Before you finish
  
  - [ ] Every finding points to a file and line and says what to change or ask.
  - [ ] The security pass covers every changed entry point and dependency.
  - [ ] Deleted, skipped or weakened tests are listed explicitly.
  - [ ] Test results are ones you observed, or are marked "not run".
  - [ ] You made no commits, pushes, merges or deployments.
  - [ ] No secret, token, credential or personal data value appears in the output; any found is referred to by location and type, with advice to rotate it.
  - [ ] Clearly flag your assumptions, the parts you did not review in depth, and every decision a human reviewer must make before merge.
  

• Change spec for an agentTurns a ticket into a short spec, plan and task list that a coding agent can followchange-spec-for-agentView · 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 change-spec-for-agent. When to use it: Turns a ticket or feature request into a short spec, technical plan and ordered task list that a coding agent can follow, with acceptance checks and a security and testing plan for each task. Use when planning a medium or large code change before delegating it to an AI agent, breaking down a ticket, writing a spec or implementation plan, or deciding what to hand to an agent and what to do by hand.

  ---
  name: change-spec-for-agent
  description: Turns a ticket or feature request into a short spec, technical plan and ordered task list that a coding agent can follow, with acceptance checks and a security and testing plan for each task. Use when planning a medium or large code change before delegating it to an AI agent, breaking down a ticket, writing a spec or implementation plan, or deciding what to hand to an agent and what to do by hand.
  metadata:
    title: "Change spec for an agent"
    summary: "Turns a ticket into a short spec, plan and task list that a coding agent can follow"
  ---
  
  # Change Spec for an Agent
  
  Write a concise spec, plan and task list for a code change so an agent can implement it in small, reviewable steps.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The ticket, feature request or bug report, including acceptance criteria if any.
  - The repository and the area of code involved.
  - Constraints: deadlines, performance or compatibility needs, APIs that must not change.
  - The project's build, test and lint commands, and any agent instruction file.
  - Who will review the agent's work, and how large a pull request they are comfortable reviewing.
  
  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. Decide whether a spec is worth it. If the change is a small, well-understood fix, say so and propose a two-line prompt instead of a full spec.
  2. Read the relevant code before writing. Note the files, functions and existing patterns the change should follow. Do not describe code you have not looked at.
  3. Write the problem statement and the intended behaviour in plain language, from the user's or caller's point of view.
  4. List what is explicitly out of scope, so the agent does not wander into unrelated refactors.
  5. Write acceptance criteria as checkable statements. Include error cases, empty or boundary inputs, and any non-functional needs such as performance, accessibility or backwards compatibility.
  6. Draft the technical plan: components to change, data or schema changes, new interfaces, and how the change will be rolled out or reversed.
  7. Add a security section: new inputs and where they are validated, permission checks, sensitive data touched, and new dependencies (each must be named and justified).
  8. Break the plan into ordered tasks. Each task should be small enough for one reviewable commit, name the files it expects to touch, and say which tests prove it is done.
  9. For each task, mark whether it suits an agent, needs a human, or needs a human decision first (for example, a design choice or a migration on real data).
  10. Add stop conditions: situations where the agent must stop and ask rather than guess, such as failing unrelated tests, missing credentials or ambiguous requirements.
  11. Keep the whole document short. Cut anything a reviewer would skim past.
  12. Produce the spec only; do not start implementing it or hand it to an agent.
  
  ## Output format
  
  ```markdown
  # Spec: <change title>
  
  ## Problem
  
  <2–4 sentences>
  
  ## Intended behaviour
  
  - <bullet per behaviour>
  
  ## Out of scope
  
  - <bullet>
  
  ## Acceptance criteria
  
  - [ ] <checkable statement>
  - [ ] <error or edge case>
  - [ ] <non-functional need, if any>
  
  ## Technical plan
  
  - **Components:** <files, modules>
  - **Data changes:** <or "none">
  - **Rollout and rollback:** <how>
  
  ## Security considerations
  
  - <inputs, permissions, sensitive data, new dependencies>
  
  ## Tasks
  
  | #   | Task | Files | Done when (tests) | Owner                                |
  | --- | ---- | ----- | ----------------- | ------------------------------------ |
  | 1   |      |       |                   | Agent / Human / Human decision first |
  
  ## Stop and ask if
  
  - <condition>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Over-specifying small changes. A long spec can take longer to review than the change itself.
  - Long documents the agent will not follow closely. Prefer short, concrete tasks with checks over prose.
  - Acceptance criteria that only cover the happy path.
  - Plans that assume a library, endpoint or table exists without checking.
  - Tasks that mix a refactor with a behaviour change, which makes review harder.
  - Leaving the security and test sections empty because the change "looks simple".
  - No secrets, credentials or customer data in the spec. Never reproduce secrets, tokens, credentials or personal data found in code, configs or tickets; refer to them by location and type, and tell the user to rotate anything exposed.
  
  ## Before you finish
  
  - [ ] Every task has a test or check that proves it is done.
  - [ ] Out of scope items and stop conditions are written down.
  - [ ] Security considerations are filled in or explicitly marked "none identified" with a reason.
  - [ ] File and function names in the plan were confirmed in the repository.
  - [ ] The document is short enough to review in a few minutes.
  - [ ] You produced the spec only; nothing was implemented or handed to an agent.
  - [ ] Clearly flag your assumptions, open questions, and every decision a human must make before the agent starts.
  

• Agent context fileDrafts or updates a file telling AI coding agents a repo's commands and conventionsagent-context-fileView · 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 agent-context-file. When to use it: Drafts or updates a repository instruction file for coding agents, covering build and test commands, conventions, architecture notes, internal APIs and lessons learned from past agent mistakes. Use when setting up a repository for AI coding agents, when an agent keeps making the same mistake, when onboarding an agent to an unfamiliar codebase, or when asked to write or refresh an agent instructions, context or conventions file.

  ---
  name: agent-context-file
  description: Drafts or updates a repository instruction file for coding agents, covering build and test commands, conventions, architecture notes, internal APIs and lessons learned from past agent mistakes. Use when setting up a repository for AI coding agents, when an agent keeps making the same mistake, when onboarding an agent to an unfamiliar codebase, or when asked to write or refresh an agent instructions, context or conventions file.
  metadata:
    title: "Agent context file"
    summary: "Drafts or updates a file telling AI coding agents a repo's commands and conventions"
  ---
  
  # Agent Context File
  
  Draft a short, accurate instruction file that gives a coding agent the context it needs to work in this repository.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The repository, and whether an instruction file already exists (and its expected file name).
  - The commands the team uses to install, build, test, lint and run the project.
  - Recent examples of agent mistakes the team wants to prevent.
  - Areas of the codebase that are sensitive, generated, or must not be edited.
  - Team conventions that are not obvious from the code (branching, commit style, review rules).
  
  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. If a file exists, read it fully first. Plan to edit it, not replace it, and keep content the team wrote unless it is wrong.
  2. Explore the repository read-only: package manifests, build scripts, CI configuration, directory layout, and a few representative modules.
  3. Record the exact commands for install, build, test (all and single test), lint and format. Confirm each command appears in a manifest, script or CI file. Do not run commands that change state beyond a local build or test.
  4. Write a short architecture overview: main components, how they talk to each other, and where new code of each kind should go.
  5. Document internal APIs and helpers an agent should reuse instead of re-creating, with the module path for each.
  6. Write conventions as concrete rules, each with a short example where it helps: naming, error handling, logging, test placement.
  7. Add a security section: where secrets live and that they must never be committed, input validation expectations, and any code that needs human security review.
  8. Add a testing rule: new behaviour needs tests, and tests must not be deleted, skipped or weakened without explaining why in the pull request.
  9. List files and directories the agent must not edit (generated code, vendored code, migrations already applied).
  10. Add a "Lessons learned" section and turn each reported agent mistake into one short rule.
  11. Keep the file short. Link to longer docs instead of copying them.
  12. Return the file content. Write or overwrite the file only if the user asks, and never commit.
  
  ## Output format
  
  Return the file content, then a change note. Do not write the file unless the user asks, and never commit.
  
  ```markdown
  # <Project name> — agent instructions
  
  ## Commands
  
  - Install: `<command>`
  - Build: `<command>`
  - Test (all / single): `<command>` / `<command>`
  - Lint and format: `<command>`
  
  ## Architecture
  
  <short overview, where new code goes>
  
  ## Reuse these
  
  - `<module path>` — <what it does>
  
  ## Conventions
  
  - <rule>
  
  ## Security
  
  - <rule>
  
  ## Testing
  
  - <rule>
  
  ## Do not edit
  
  - `<path>` — <reason>
  
  ## Lessons learned
  
  - <rule from a past mistake>
  ```
  
  ```markdown
  ## Change note
  
  - Added: <sections or rules>
  - Changed: <what and why>
  - Unverified: <commands or facts you could not confirm>
  
  ### Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Commands copied from a README that no longer match the build scripts or CI.
  - Describing the architecture the team wants rather than the one that exists. Write what the code shows and flag differences.
  - Long files that bury the important rules. Commands and "do not" rules should be near the top.
  - Rules that are vague ("write clean code"). Each rule should be something a reviewer can check.
  - Internal hostnames copied into the file from configuration.
  - Never reproduce secrets, tokens, credentials or personal data in the output; refer to them by location and type, and tell the user to rotate anything exposed.
  - Deleting team-written rules because you cannot see why they exist; ask instead.
  
  ## Before you finish
  
  - [ ] Every command was confirmed in a script, manifest or CI file, or is marked unverified.
  - [ ] Every module path in "Reuse these" exists.
  - [ ] Security and testing rules are present.
  - [ ] No secrets or sensitive values appear in the file.
  - [ ] Existing team content was kept or its removal is explained in the change note.
  - [ ] The file was written only if the user asked, and nothing was committed.
  - [ ] Clearly flag your assumptions, unverified facts, and any rule a human must confirm before the file is committed.