pull-request

Files (1)

• SKILL.md

SKILL.md (first lines)

# Pull-request workflow

## Before editing

- Resolve the exact allowed repository with `list_working_repos`.
- Materialize it with `add_source`; use only the returned source path.
- Read repository instructions, the affected code, and nearby tests.
- Restate the requested outcome in one sentence. Ask when acceptance criteria
  are genuinely unclear.

## Implement and verify

- Keep the patch narrow. Do not reformat or refactor unrelated code.
- Add or update a test that would fail before the change when practical.
- Run the smallest relevant test command, then inspect the complete diff.
- Never edit generated dependencies or commit build output unless the
  repository explicitly requires it.

## Publish

- Summarize the exact behavior change and tests.
- Call `github_publish_pull_request` once with the source name from
  `add_source`, a concrete title, and a body that explains what changed and how
  it was verified.
- Return the tool-authored PR URL. If the tool reports no changes or a recovery
  error, relay that result accurately instead of inventing success.

From diggerhq/oc-flue-slack-pr-agent, MIT.

More from diggerhq/oc-flue-slack-pr-agent