Pull Request

Use this skill for the whole PR lifecycle, not only the moment of opening or merging.

Runtime Setup

For Basic Memory Python tooling, use the project environment first:

source .venv/bin/activate

After activation, run Python scripts as python .... For one-off commands where activation is awkward, prefer ./.venv/bin/python ... or the repo's uv run ... patterns. Do not fall back to system python, python3, or global packages just because a command is missing.

Flow

1. Inspect the live artifact first.

   • Use gh pr view, gh issue view, linked review comments, CI status, and current branch state before deciding what to change.
   • If the user links a specific PR discussion, inspect that exact discussion before broad edits.

2. Keep branch scope clean.

   • Base product-fix PRs on the intended remote base.
   • Avoid mixing workflow/skill/doc commits into unrelated product branches.
   • In basic-memory, prefer local branches in the main workspace unless the user asks for a worktree.

3. Implement and validate.

   • Read files fully before editing.
   • Make the smallest behaviorally complete change.
   • Run focused tests for the changed surface.
   • Run the repo's required gate, such as just fast-check for source changes or just package-check for agent/package changes, before calling the branch ready.

4. Write or update the PR description.

   • A PR without a useful description is not done.
   • Use the existing pr-description skill when available.
   • Make the body explain the change to a reviewer who did not watch the chat.

5. Open or update the PR.

   • Include linked issues, review comments, or specs.
   • Include exact validation commands and outcomes.
   • Mark draft only when the PR is intentionally not ready for review.