ai-skills-git

Assess a GitHub issue against the current codebase: re-read issue payload, verify references, estimate scope, map skills, record out-of-scope exclusions, comment/label when appropriate. Use during git-issue or git-pipeline after remotes are verified and an issue payload exists (or fetch if missing).

Verify GitHub issue numbers before using Closes or Fixes in commits or pull requests, and avoid wording that still auto-closes (e.g. “Does not close #N”). Use when drafting PR bodies, commit trailers, or any text that would auto-close an issue; when issue numbers come from plans, specs, or memory.

Creates and maintains a .gitignore that protects original files and tracks AI-generated content. On first run generates a baseline; on later runs detects new untracked files and asks whether each should be ignored. Use when setting up AI hygiene for a repo or when git status is noisy with agent output.

Implement an issue plan in an isolated worktree: call git-worktree with base= and branch=, code against the plan, run tests/linters, multi-angle code review, and fix. Use from git-issue or git-pipeline after assess (and plan when required).

Single-issue GitHub workflow: verify remotes, fetch one issue by number or URL, then run assess → plan (if needed) → implement → PR with base on the default branch (no stacking). Use when the user says git-issue 123, passes one issue URL, or wants one focused PR without a multi-issue pipeline.

Multi-issue GitHub pipeline: verify remotes, load foundation/conventions, triage dependency DAG, stacked worktrees/PRs, assess → plan → implement → PR per issue, merge gate and sequential merge. Use for multiple issue numbers, stacks, or full batch processing; prefer git-issue for one standalone issue.

Write and review an implementation plan for a GitHub issue before coding. Use from git-issue or git-pipeline when assess scope is medium or large; skip for trivial/small fast path.

Open and manage one pull request: push to verified push-remote, PR body with git-closes or partial-progress wording, PR review comments, deferred issues, and single-PR merge including merge-via-API. Use from git-issue or git-pipeline after git-implement.

Review branch or PR changes against the project's architecture service contracts. Discovers docs/architecture/service-contracts.md (or architecture.contracts in .git-pipeline.yml), classifies changed files by layer, runs hard/soft checks, and reports a severity-sorted verdict. Use when reviewing architecture, checking layer contracts, or from git-implement / git-pr architecture angles. If contracts are missing, offers to scaffold them before reviewing.

Routes git and forge API operations under restricted sandboxes that block AF_UNIX sockets and keyring access. Use when CLI auth fails, GPG signing fails, git push stalls in sandbox, credential errors appear, or choosing between git CLI and the active forge provider. Does not own worktree creation (see git-worktree) or issue process (see git-issue).

Verify remotes, then detect or create an isolated git worktree and branch, move the agent root into it, and verify pwd/branch before edits. Accepts base= and branch= from callers. Use when starting feature work, git-issue / git-pipeline / git-implement isolation, or when isolation from the primary checkout is required. Standalone; if Superpowers using-git-worktrees is already loaded, defer to it for mechanics after remotes are verified.