agentleFS
oocxoocx/tfplan2md/.agents/skills/create-pr-azdo/SKILL.md

create-pr-azdo

Skill174 starsChanged 2 months agoMITView on GitHub

Create an Azure DevOps pull request using az devops tooling; include the repo’s linear-history merge preference and ask the Maintainer if merge options differ.

  • Commits and pushes

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create an Azure DevOps pull request in a consistent way, while still encoding the repository’s preference for a linear history.

    line 11
  2. Distinctive:

    Ensure the working tree is clean before creating a PR.

    line 26
  3. Distinctive:

    Keep PR title and description conventional and review-friendly.

    line 28
  4. Distinctive:

    Before creating the PR, post the exact Title and Description in chat.

    line 29
  5. Distinctive:

    Use the standard description template (Problem / Change / Verification).

    line 30
  6. Distinctive:

    Before running any PR creation command, provide in chat:

    line 40
  7. Distinctive:

    If you need to merge the PR, confirm the exact merge option with the Maintainer first.

    line 95
  8. Distinctive:

    Prefer a rebase/linear-history option when available.

    line 96

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Create PR (Azure DevOps)

Purpose

Create an Azure DevOps pull request in a consistent way, while still encoding the repository’s preference for a linear history.

This skill prefers using the repo wrapper script scripts/pr-azdo.sh to minimize Maintainer approval interruptions (single terminal invocation).

Notes on Merge Policy

docs/development.md specifies Rebase and merge as the required merge strategy for this repo.

Azure DevOps UI/merge options differ by project settings. When merging an Azure DevOps PR, choose the most “rebase/linear-history” option available (often called Rebase and fast-forward) when available; otherwise, ask the Maintainer what to use.

Hard Rules

Must

  • Work on a non-main branch.
  • Ensure the working tree is clean before creating a PR.
  • Push the branch before creating the PR.
  • Keep PR title and description conventional and review-friendly.
  • Before creating the PR, post the exact Title and Description in chat.
  • Use the standard description template (Problem / Change / Verification).

Must Not

  • Merge using a strategy that introduces merge commits unless the Maintainer explicitly requests it.

Actions

0. Title + Description (Required)

Before running any PR creation command, provide in chat:

  • PR title (exact)
  • PR description (exact), using this template:
## Problem
<why is this change needed?>

## Change
<what changed?>

## Verification
<how was it validated?>

Recommended: One-Command Wrapper

scripts/pr-azdo.sh create --title "<type(scope): summary>" --description "<why + what + testing notes>"

Abandon a test PR (cleanup):

scripts/pr-azdo.sh abandon --id <pr-id>

1. Pre-flight Checks

git branch --show-current
git status --short

2. Push the Branch

git push -u origin HEAD

3. Create the PR

This is a minimal example; set --organization/--project appropriately for the target repo.

az repos pr create \
  --title "<type(scope): summary>" \
  --description "<why + what + testing notes>" \
  --source-branch "$(git branch --show-current)" \
  --target-branch main

4. Merging

  • If you need to merge the PR, confirm the exact merge option with the Maintainer first.
  • Prefer a rebase/linear-history option when available.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.