git 5.0.0.beta.2 → 5.0.0.beta.4

data/.github/skills/resolve-feedback/SKILL.md

@@ -0,0 +1,288 @@
+---
+name: resolve-feedback
+description: 'Resolves unresolved pull request review threads on the current branch, folds each fix into the existing commit that last touched the same file, force-pushes with lease, and requests a fresh Copilot review. Use when addressing PR feedback, resolving review comments or threads, amending fixes into prior commits, or asking Copilot to re-review after changes.'
+---
+
+# Resolve Feedback
+
+Address the unresolved review threads on the pull request for the current
+branch, folding each fix into the existing commit that last touched the affected
+file, then force-push and request another Copilot review.
+
+## Contents
+
+- [Contents](#contents)
+- [How to use this skill](#how-to-use-this-skill)
+- [Related skills](#related-skills)
+- [Prerequisites](#prerequisites)
+- [Terms](#terms)
+- [Safety and stop points](#safety-and-stop-points)
+- [Workflow](#workflow)
+- [Step 1: Identify the PR and branch](#step-1-identify-the-pr-and-branch)
+- [Step 2: Fetch unresolved review threads](#step-2-fetch-unresolved-review-threads)
+- [Step 3: Triage each thread](#step-3-triage-each-thread)
+- [Step 4: Implement the changes](#step-4-implement-the-changes)
+- [Step 5: Fold each change into the matching commit](#step-5-fold-each-change-into-the-matching-commit)
+- [Step 6: Force-push the branch](#step-6-force-push-the-branch)
+- [Step 7: Reply to and resolve threads](#step-7-reply-to-and-resolve-threads)
+- [Step 8: Request another Copilot review](#step-8-request-another-copilot-review)
+- [Troubleshooting](#troubleshooting)
+
+## How to use this skill
+
+Attach this file to your Copilot Chat context and invoke it when a PR has review
+feedback to address on the current branch. Work top to bottom. Stop and ask the
+user whenever a thread needs a clarification or decision (Step 3) and before the
+history-rewriting force-push (Step 6).
+
+## Related skills
+
+- [Pull Request Review](../pull-request-review/SKILL.md) — the review workflow
+  that produces the threads this skill resolves
+- [PR Readiness Review](../pr-readiness-review/SKILL.md) — pre-PR quality gate to
+  run before pushing follow-up changes
+- [Development Workflow](../development-workflow/SKILL.md) — TDD process and
+  branch rules that govern the fixes made here
+
+## Prerequisites
+
+- The `gh` CLI is installed and authenticated (`gh auth status`).
+- The current branch has an open PR and is a topic branch (not `main` or `4.x`).
+- The working tree has no unrelated uncommitted changes before starting.
+
+## Terms
+
+- **Unresolved review thread** — a PR review thread whose `isResolved` is
+  `false` in the GitHub GraphQL API.
+- **Base** — the merge-base between the PR base branch and `HEAD`, computed with
+  `git merge-base origin/<base-branch> HEAD`. All commit lookups are scoped to
+  `<base>..HEAD` so only this branch's commits are considered.
+- **Target commit** — the newest commit in `<base>..HEAD` that last touched the
+  file a fix applies to. Each fix is folded into its target commit.
+
+## Safety and stop points
+
+These rules are mandatory:
+
+- Never rewrite history on `main` or `4.x`. Confirm the branch first with
+  `git branch --show-current`.
+- Stop and ask the user whenever a thread requests a clarification or decision
+  (Step 3). Do not guess on ambiguous feedback.
+- Force-push only with `--force-with-lease`, and only after the user confirms
+  (Step 6).
+- Do not resolve a thread until its fix is committed and pushed (Step 7).
+
+## Workflow
+
+1. [Identify the PR and branch](#step-1-identify-the-pr-and-branch)
+2. [Fetch unresolved review threads](#step-2-fetch-unresolved-review-threads)
+3. [Triage each thread](#step-3-triage-each-thread) — ask for clarifications or
+   decisions as needed
+4. [Implement the changes](#step-4-implement-the-changes)
+5. [Fold each change into the matching commit](#step-5-fold-each-change-into-the-matching-commit)
+6. [Force-push the branch](#step-6-force-push-the-branch)
+7. [Reply to and resolve threads](#step-7-reply-to-and-resolve-threads)
+8. [Request another Copilot review](#step-8-request-another-copilot-review)
+
+## Step 1: Identify the PR and branch
+
+Confirm the branch and locate the PR for it:
+
+```bash
+git branch --show-current
+gh pr view --json number,title,headRefName,baseRefName,url,state
+```
+
+Record the PR number, `baseRefName` (the base branch), and URL. If no PR is
+associated with the branch, stop and tell the user.
+
+## Step 2: Fetch unresolved review threads
+
+List the first 100 review threads and keep the ones where `isResolved` is
+`false`. For unusually active PRs with more than 100 review threads, paginate
+before assuming no unresolved threads remain.
+
+```bash
+OWNER=$(gh repo view --json owner --jq '.owner.login')
+REPO=$(gh repo view --json name --jq '.name')
+PR_NUMBER=$(gh pr view --json number --jq '.number')
+
+gh api graphql -f query='
+  query($owner:String!, $repo:String!, $pr:Int!) {
+    repository(owner:$owner, name:$repo) {
+      pullRequest(number:$pr) {
+        reviewThreads(first:100) {
+          nodes {
+            id
+            isResolved
+            isOutdated
+            path
+            line
+            comments(first:30) {
+              nodes { databaseId author { login } body }
+            }
+          }
+        }
+      }
+    }
+  }' -F owner="$OWNER" -F repo="$REPO" -F pr="$PR_NUMBER" \
+  --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false)'
+```
+
+For each unresolved thread, note its `id` (thread ID, needed to resolve it), the
+first comment `databaseId` (needed to reply), the `path`, and the `line`.
+
+## Step 3: Triage each thread
+
+For each unresolved thread, classify it and act:
+
+- **Actionable and unambiguous** → plan the concrete code or doc change.
+- **Needs a clarification or decision** → stop and ask the user. Present the
+  thread's file, line, and comment text, and the specific question or the
+  options you see. Wait for the answer before implementing.
+- **Not applicable / disagree** → do not change code; draft a short, respectful
+  reply explaining why (used in Step 7). Ask the user if you are unsure whether
+  to push back.
+
+Do not proceed to Step 4 for a thread until its resolution is clear.
+
+## Step 4: Implement the changes
+
+Apply the agreed changes in the workspace. Keep edits for each thread minimal and
+scoped to what the feedback asks. If the project has tests or linters, run the
+relevant checks before folding changes into commits:
+
+```bash
+bundle exec rake default
+```
+
+Fix any failures before continuing.
+
+## Step 5: Fold each change into the matching commit
+
+Amend each change into its target commit — the existing commit on this branch
+that last touched the file — instead of adding new follow-up commits.
+
+1. Compute the base once:
+
+   ```bash
+   BASE=$(git merge-base origin/<base-branch> HEAD)
+   ```
+
+2. For each changed file, find its target commit (the topmost line is newest):
+
+   ```bash
+   git log --oneline "$BASE"..HEAD -- <path>
+   ```
+
+3. Stage that file and create a fixup commit aimed at its target SHA:
+
+   ```bash
+   git add <path>
+   git commit --fixup=<target-sha>
+   ```
+
+   Repeat for each changed file. When several files share the same target
+   commit, stage them together for one fixup.
+
+4. Autosquash the fixups into their targets non-interactively:
+
+   ```bash
+   GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash "$BASE"
+   ```
+
+5. Verify the result — the fixup commits should be gone and history should be
+   clean:
+
+   ```bash
+   git --no-pager log --oneline "$BASE"..HEAD
+   git status --short --branch
+   ```
+
+If a change does not correspond to any existing commit (e.g. a brand-new file
+requested in review), ask the user whether to fold it into a related commit or
+add a new, conventionally formatted commit.
+
+## Step 6: Force-push the branch
+
+History was rewritten, so the branch must be force-pushed. This is a
+history-rewriting operation — confirm with the user first, then use a lease to
+avoid clobbering unseen remote commits:
+
+```bash
+git push --force-with-lease
+```
+
+If the push is rejected, someone updated the remote branch. Fetch and reconcile
+before retrying; do not use `--force` to override the lease.
+
+## Step 7: Reply to and resolve threads
+
+For each thread that is now addressed:
+
+1. Reply to the thread, referencing what changed. Keep reply bodies shell-safe:
+   use single quotes for simple one-line replies, or assign a quoted heredoc to a
+   variable for arbitrary text. Do not put human-written reply text directly in a
+   double-quoted shell argument; review comments can contain characters such as
+   `!`, `$`, backticks, or quotes that the shell may expand before `gh` runs.
+
+```bash
+COMMENT_DATABASE_ID=COMMENT_DATABASE_ID_FROM_THREAD
+reply_body='Addressed in the latest push: <short summary>.'
+
+gh api \
+  "repos/$OWNER/$REPO/pulls/$PR_NUMBER/comments/$COMMENT_DATABASE_ID/replies" \
+  -f body="$reply_body"
+```
+
+For multi-line replies or text that may contain shell metacharacters, use a
+single-quoted heredoc delimiter:
+
+```bash
+COMMENT_DATABASE_ID=COMMENT_DATABASE_ID_FROM_THREAD
+reply_body=$(cat <<'EOF'
+Addressed in the latest push: the guidance now covers `@!method` declarations.
+EOF
+)
+
+gh api \
+  "repos/$OWNER/$REPO/pulls/$PR_NUMBER/comments/$COMMENT_DATABASE_ID/replies" \
+  -f body="$reply_body"
+```
+
+2. Resolve the thread:
+
+   ```bash
+   gh api graphql -f query='
+     mutation($threadId:ID!) {
+       resolveReviewThread(input:{threadId:$threadId}) {
+         thread { id isResolved }
+       }
+     }' -F threadId=THREAD_ID
+   ```
+
+Only resolve threads whose feedback was actually addressed (or that the user
+agreed to close after a reply). Leave threads open when the user still owes a
+decision.
+
+## Step 8: Request another Copilot review
+
+Request a fresh Copilot review on the PR so it re-reviews the amended commits.
+
+- Preferred: activate the pull request management tools, then request a Copilot
+  review via the GitHub pull request tooling (`request_copilot_review`).
+- Do **not** create a new Copilot PR task for a re-review; that opens separate
+  work instead of re-reviewing this PR.
+
+Finish by reporting to the user: the threads resolved, any threads left open and
+why, the new commit list, and the PR URL.
+
+## Troubleshooting
+
+| Issue | Solution |
+| ----- | -------- |
+| `git log "$BASE"..HEAD -- <path>` is empty | The file is new on this branch; ask the user whether to fold into a related commit or add a new commit. |
+| Rebase stops with conflicts | Resolve the conflict, `git add` the files, then `git rebase --continue`. |
+| Force-push rejected despite `--force-with-lease` | The remote branch moved; run `git fetch`, review the remote changes, reconcile, and retry. |
+| A thread has no obvious file/line (`path` is null) | It is a PR-level comment; reply at the PR level and resolve only if addressed. |
+| Unsure whether to push back on feedback | Stop and ask the user before replying or resolving. |

data/.github/skills/review-arguments-dsl/CHECKLIST.md

@@ -101,14 +101,14 @@ output-control, editor-suppression, or progress flags. Declare these as
 > `no_edit: true` passed from the facade call site.
 
 **The `--edit` / `--no-edit` pair:** Model as `flag_option :edit, negatable: true`.
-The facade (`Git::Lib`) passes `no_edit: true` at each call site. Do **not** hardcode
+The `Git::Repository::*` facade passes `no_edit: true` at each call site. Do **not** hardcode
 `literal '--no-edit'` — that prevents the facade from controlling the option — and do
 **not** exclude `--edit` from the DSL.
 
 **Output-format options belong at the facade call site, not as `literal` entries:**
 When a parser requires specific output flags (e.g. `--pretty=raw`, `--numstat`),
 declare those flags in the DSL with `flag_option` or `value_option`, and pass them
-explicitly from `Git::Lib`. Never hardcode them as `literal` entries inside the
+explicitly from the `Git::Repository::*` facade. Never hardcode them as `literal` entries inside the
 command class — that hides the parser contract and prevents the facade from choosing
 the format. See Insight 16 in `redesign/3_architecture_implementation.md`.
 
@@ -571,7 +571,7 @@ Values are forwarded as Ruby kwargs to the underlying command runner (e.g.,
 
 The authoritative set of accepted execution option names is defined by
 `COMMAND_CAPTURING_ARG_DEFAULTS` and `COMMAND_STREAMING_ARG_DEFAULTS` in
-`lib/git/lib.rb`. The complete set of accepted names is:
+`lib/git/execution_context.rb`. The complete set of accepted names is:
 
 | Name | Purpose | Capturing | Streaming | Notes |
 | --- | --- | --- | --- | --- |

data/.github/skills/reviewing-skills/SKILL.md

@@ -10,6 +10,7 @@ adherence to the Anthropic skill-authoring best practices.
 
 ## Contents
 
+- [Contents](#contents)
 - [How to use this skill](#how-to-use-this-skill)
 - [Related skills](#related-skills)
 - [Input](#input)
@@ -76,11 +77,16 @@ skill is selected from potentially hundreds of available skills.
 
 ### 3. Body structure and size
 
-- [ ] SKILL.md body is **under 600 lines** (optimal performance threshold)
-- [ ] If approaching the limit, content is split into separate reference files
+- [ ] SKILL.md body targets **under 500 lines** and is reviewed carefully above
+      600 lines
+- [ ] Exceeding the target is justified when splitting always-needed workflow or
+      review rules would make the skill less effective
+- [ ] If approaching the limit, situational content is split into separate
+      reference files before core workflows or checklists are split
 - [ ] Reference files are at most **one level deep** from SKILL.md (no
       deeply-nested chains like SKILL → A.md → B.md → actual content)
 - [ ] Reference files longer than 100 lines include a table of contents
+- [ ] Reference files state their purpose and when the agent should load them
 
 ### 4. Conciseness
 
@@ -108,6 +114,10 @@ Match instruction specificity to task fragility:
 
 - [ ] SKILL.md serves as an overview / table of contents
 - [ ] Detailed materials are in separate files loaded only when needed
+- [ ] Mandatory workflow steps, validation loops, and review checklist items stay
+      in SKILL.md even when detailed examples move to references
+- [ ] Situational, element-specific, type-specific, or platform-specific rules
+      are good candidates for reference files
 - [ ] File names are descriptive (not `doc1.md`, `file2.md`)
 - [ ] Directory structure is organized by domain or feature
 
@@ -119,15 +129,26 @@ Match instruction specificity to task fragility:
       (run validator → fix errors → repeat until clean)
 - [ ] Decision points use conditional workflow patterns (if X → workflow A,
       if Y → workflow B)
+- [ ] For standards and review skills, rules are mandatory unless explicitly
+      marked `Optional`; advisory skills consistently distinguish requirements,
+      recommendations, and examples
 
 ### 8. Content quality
 
 - [ ] No time-sensitive information (dates that will become stale); if legacy
       context is needed, it is in a collapsible "old patterns" section
 - [ ] Consistent terminology throughout (one term per concept, not synonyms)
+- [ ] Named thresholds, modes, phases, or terms are defined before first use and
+      have one authoritative definition
 - [ ] Examples are concrete, not abstract
+- [ ] Examples and domain facts are technically accurate; repo-specific skills
+      use real project patterns where practical
 - [ ] All file paths use forward slashes (no Windows-style backslashes)
 - [ ] No "voodoo constants" — every magic number or config value is justified
+- [ ] Important rule sections use real markdown headings, not bold paragraphs as
+      pseudo-headings
+- [ ] Duplicate rationale and repeated examples are removed, while short
+      normative checklist rules remain self-contained
 
 ### 9. Cross-skill consistency
 
@@ -138,8 +159,12 @@ When reviewing multiple skills in the same repository:
 - [ ] Shared policies (branch rules, commit conventions, quality gates,
       changelog policy) do not contradict each other
 - [ ] Cross-skill links in `## Related skills` resolve to existing files
+- [ ] Intra-skill links, cross-skill deep links, table-of-contents anchors, and
+      referenced files resolve after heading or file moves
 - [ ] Every skill referenced in `.github/copilot-instructions.md`'s routing
       table resolves to an existing `.github/skills/*/SKILL.md` file
+- [ ] Skills that extend other skills clearly state what they inherit, override,
+      or add
 - [ ] Stop/ask checkpoints are used consistently for comparable risk levels
 
 ### 10. Discoverability sections
@@ -182,7 +207,7 @@ Key principles distilled:
 | No time-sensitive info | Avoid dates that will become stale |
 | Consistent terminology | One term per concept throughout |
 | One-level references | No deeply nested file chains |
-| Under 600 lines | Split if approaching the limit |
+| Size targets | Target under 500 lines; review carefully above 600 lines |
 | Test with real usage | Iterate based on observed agent behavior |
 
 > **Branch workflow:** Implement any fixes on a feature branch. Never commit or

data/.github/skills/test-debugging/SKILL.md

@@ -40,17 +40,14 @@ requests unless the user asks for implementation.
 1. **Run the failing test:**
 
    ```bash
-   # TestUnit (legacy tests in tests/units/)
-   bundle exec bin/test <test_file_name>
-
    # RSpec unit test
    bundle exec rspec spec/unit/git/commands/<command>_spec.rb
 
    # RSpec integration test
    bundle exec rspec spec/integration/git/commands/<command>_spec.rb
 
-   # Specific test method (TestUnit)
-   bundle exec ruby -I lib:tests tests/units/test_base.rb -n test_method_name
+   # Specific example, by line number
+   bundle exec rspec spec/unit/git/commands/<command>_spec.rb:42
    ```
 
 2. **For suspected flaky tests, run multiple times:**
@@ -58,15 +55,15 @@ requests unless the user asks for implementation.
    ```bash
    for i in {1..20}; do
      echo "Run $i"
-     bundle exec bin/test <test_file> || break
+     bundle exec rspec <spec_file> || break
    done
    ```
 
 3. **Check test isolation** — run the test alone vs. within the full suite:
 
    ```bash
-   bundle exec bin/test <test_file>   # alone
-   bundle exec rake default           # full suite
+   bundle exec rspec <spec_file>   # alone
+   bundle exec rake default        # full suite
    ```
 
 ## Step 2: Investigate Root Cause
@@ -129,13 +126,12 @@ Present diagnostic findings to the user:
 
 ```bash
 # Run the specific test
-bundle exec bin/test <test_file>        # TestUnit
-bundle exec rspec <spec_file>           # RSpec
+bundle exec rspec <spec_file>
 
 # For flaky test fixes, run many times
 for i in {1..50}; do
   echo "Run $i"
-  bundle exec bin/test <test_file> || break
+  bundle exec rspec <spec_file> || break
 done
 
 # Run full suite
@@ -144,17 +140,22 @@ bundle exec rake default
 
 ## Project-Specific Considerations
 
-**Test frameworks:** This project uses both TestUnit (legacy tests in `tests/units/`)
-and RSpec (new tests in `spec/`). Run both when verifying changes.
+**Test framework:** This project uses RSpec exclusively (`spec/unit/` and
+`spec/integration/`).
 
-**Test helpers:** Use `clone_working_repo`, `create_temp_repo`, `in_temp_dir` from
-test helpers for TestUnit. Use `include_context` shared contexts for RSpec.
+**Test helpers:** Use the `'in an empty repository'` shared context (and other
+`spec/support/contexts/` shared contexts) plus `Git::IntegrationTestHelpers` methods
+(e.g. `write_file`) for integration specs. Use `let`/`let!` and verifying doubles for
+unit specs — see [RSpec Unit Testing Standards](../rspec-unit-testing-standards/SKILL.md).
 
-**Mocking:** The project uses Mocha for TestUnit mocking and RSpec doubles for RSpec.
-Be careful with stubs — they can mask real issues.
+**Mocking:** The project uses RSpec doubles (`instance_double`, `class_double`) for
+unit specs. Be careful with stubs — they can mask real issues.
 
-**Test data:** Fixtures are in `tests/files/`. Use test helpers to create temporary
-repos. Clean up in teardown.
+**Test data:** Integration specs create temporary repos on the fly (e.g. via
+`Dir.mktmpdir` and the shared contexts above). Static fixture files in
+`spec/support/fixtures/` exist for a small number of specs that need pre-built
+content (e.g. `spec/integration/git/command_line_spec.rb`); prefer dynamic helpers
+for new specs. Clean up any state created outside those helpers.
 
 **CI vs. local differences:** If tests pass locally but fail in CI, use the
 ci-cd-troubleshooting skill.