git 5.0.0.beta.3 → 5.0.0.beta.4

data/.github/skills/facade-test-conventions/SKILL.md

@@ -293,17 +293,14 @@ integration grouping. Use a multi-command or post-processing facade method —
 single-command delegators do not warrant integration tests (see [When to skip
 integration tests](#when-to-skip-integration-tests)):
 
-The shared context (e.g. `'in an empty repository'`) provides `repo` and
-`repo_dir` helpers. Facade integration specs must override `execution_context`
-to a `Git::ExecutionContext::Repository` (the shared context's default is
-`repo.lib`, a `Git::Lib`). Stage any required repository state in a `before`
-block inside the spec itself.
+The shared context (e.g. `'in an empty repository'`) provides `repo`,
+`repo_dir`, and `execution_context` helpers. Stage any required repository state
+in a `before` block inside the spec itself.
 
 ```ruby
 RSpec.describe Git::Repository::Stashing, :integration do
-  include_context 'in an empty repository' # provides repo and repo_dir helpers
+  include_context 'in an empty repository' # provides repo, repo_dir, and execution_context helpers
 
-  let(:execution_context) { Git::ExecutionContext::Repository.from_base(repo) }
   let(:described_instance) { Git::Repository.new(execution_context: execution_context) }
 
   before do

data/.github/skills/facade-yard-documentation/SKILL.md

@@ -16,6 +16,7 @@ parser, or execution context that implements the behavior.
 
 ## Contents
 
+- [Contents](#contents)
 - [Related skills](#related-skills)
 - [Input](#input)
 - [Reference](#reference)
@@ -27,7 +28,12 @@ parser, or execution context that implements the behavior.
   - [Cross-referencing the implementation](#cross-referencing-the-implementation)
   - [Common issues](#common-issues)
 - [Workflow](#workflow)
+  - [1. Module-level docs](#1-module-level-docs)
+  - [2. Method-level docs (per method)](#2-method-level-docs-per-method)
+  - [3. Formatting consistency](#3-formatting-consistency)
 - [Output](#output)
+  - [When writing new facade YARD docs](#when-writing-new-facade-yard-docs)
+  - [When reviewing existing facade YARD docs](#when-reviewing-existing-facade-yard-docs)
 
 ## Related skills
 
@@ -82,7 +88,7 @@ end
 ```
 
 Module-level tags appear in the order required by
-[YARD Documentation — Modules](../yard-documentation/SKILL.md#element-specific-rules):
+[YARD element rules — Modules](../yard-documentation/element-rules.md#modules):
 `@note`, `@deprecated`, `@see`, `@api`. (Facade modules do not use module-level
 `@example` — see the override note below.)
 
@@ -104,7 +110,7 @@ Do **not** add:
   link is misleading; for single-command modules it is redundant with the
   method-level link.
 - `@example` blocks at the module level — **facade-specific override of
-  [YARD Documentation — Modules](../yard-documentation/SKILL.md#element-specific-rules)**,
+  [YARD element rules — Modules](../yard-documentation/element-rules.md#modules)**,
   which permits module-level `@example` when a module provides standalone
   methods. Facade modules do provide standalone methods, but every facade
   method already carries its own `@example`, so a module-level example would

data/.github/skills/make-skill-template/SKILL.md

@@ -9,11 +9,19 @@ A meta-skill for creating new Agent Skills. Use this skill when you need to scaf
 
 ## Contents
 
+- [Contents](#contents)
 - [How to use this skill](#how-to-use-this-skill)
 - [Related skills](#related-skills)
 - [When to Use This Skill](#when-to-use-this-skill)
 - [Prerequisites](#prerequisites)
 - [Creating a New Skill](#creating-a-new-skill)
+  - [Step 1: Create the Skill Directory](#step-1-create-the-skill-directory)
+  - [Step 2: Generate SKILL.md with Frontmatter](#step-2-generate-skillmd-with-frontmatter)
+    - [Frontmatter Field Requirements](#frontmatter-field-requirements)
+    - [Description Best Practices](#description-best-practices)
+  - [Step 3: Write the Skill Body](#step-3-write-the-skill-body)
+  - [Step 4: Add Optional Directories (If Needed)](#step-4-add-optional-directories-if-needed)
+- [Skill Body Organization](#skill-body-organization)
 - [Example: Complete Skill Structure](#example-complete-skill-structure)
 - [Quick Start: Duplicate This Template](#quick-start-duplicate-this-template)
 - [Validation Checklist](#validation-checklist)
@@ -54,7 +62,7 @@ check discoverability quality before committing.
 
 Create a new folder with a lowercase, hyphenated name:
 
-```
+```text
 .github/skills/<skill-name>/
 └── SKILL.md          # Required
 ```
@@ -114,6 +122,17 @@ After the frontmatter, add markdown instructions. Recommended sections:
 | `## Troubleshooting` | Common issues and solutions |
 | `## References` | Links to bundled docs |
 
+For standards and review skills, rules are mandatory unless explicitly marked
+`Optional`. For advisory skills, distinguish requirements, recommendations, and
+examples with consistent labels.
+
+Define named thresholds, modes, phases, or terms before first use, and keep one
+authoritative definition for each concept.
+
+Use real markdown headings for durable rule sections. Avoid bold paragraphs as
+pseudo-headings when the section may need a table-of-contents entry, deep link,
+or review reference.
+
 ### Step 4: Add Optional Directories (If Needed)
 
 | Folder | Purpose | When to Use |
@@ -123,9 +142,35 @@ After the frontmatter, add markdown instructions. Recommended sections:
 | `assets/` | Static files used AS-IS | Images, fonts, templates |
 | `templates/` | Starter code agent modifies | Scaffolds to extend |
 
+## Skill Body Organization
+
+Target `SKILL.md` under 500 lines; review carefully above 600 lines. Exceeding
+the target is acceptable when splitting always-needed workflow or review rules
+would make the skill less effective. Split situational references first.
+
+Keep these in `SKILL.md`:
+
+- Routing, prerequisites, and precedence rules
+- The main workflow and required feedback loops
+- Mandatory validation or review checklists
+- Rules needed on nearly every invocation
+
+Move these to reference files:
+
+- Element-specific, type-specific, or platform-specific rules
+- Long examples and templates
+- Rare edge cases and background material
+- Appendices or migration notes
+
+Each reference file should state its purpose and when the agent should load it.
+Keep references one level deep from `SKILL.md`.
+
+When one skill extends another, state what it inherits, overrides, or adds. Link
+to the parent skill or reference file and keep child-skill overrides narrow.
+
 ## Example: Complete Skill Structure
 
-```
+```text
 my-awesome-skill/
 ├── SKILL.md                    # Required instructions
 ├── LICENSE.txt                 # Optional license file
@@ -158,7 +203,12 @@ my-awesome-skill/
 - [ ] `description` is 10-1024 characters
 - [ ] `description` explains WHAT and WHEN
 - [ ] `description` is wrapped in single quotes
-- [ ] Body content is under 500 lines
+- [ ] Body content targets under 500 lines and is reviewed carefully above 600 lines
+- [ ] Always-needed workflow and review rules remain in `SKILL.md`
+- [ ] Situational details are split into reference files with clear load conditions
+- [ ] Named thresholds, modes, phases, or terms are defined before first use
+- [ ] Standards/review rules are mandatory unless explicitly marked `Optional`
+- [ ] Deep links, TOC anchors, and referenced files resolve after heading changes
 - [ ] Bundled assets are under 5MB each
 
 ## Troubleshooting

data/.github/skills/pr-readiness-review/SKILL.md

@@ -5,12 +5,15 @@ description: "Performs a comprehensive pre-PR readiness review covering tests, c
 
 # PR Readiness Review Workflow
 
-Use this at the end of implementation to prepare for PR submission:
+Use this at the end of implementation to prepare for PR submission. Example
+request:
 
-**"I've completed the implementation. Please perform a comprehensive PR readiness review."**
+> I've completed the implementation. Please perform a comprehensive PR readiness
+> review.
 
 ## Contents
 
+- [Contents](#contents)
 - [How to use this skill](#how-to-use-this-skill)
 - [Prerequisites](#prerequisites)
 - [Related skills](#related-skills)
@@ -50,16 +53,21 @@ Before starting, you **MUST** load the following skill(s) in their entirety:
   unit/integration test conventions for `Git::Repository::*` facade methods
 - [Facade YARD Documentation](../facade-yard-documentation/SKILL.md) — verify
   facade module/method documentation completeness and consistency
+- [Reviewing Skills](../reviewing-skills/SKILL.md) — audit skill quality,
+  discoverability, reference structure, and cross-skill links when skill files
+  change
 
 ## 1. Run Final Validation
 
 Execute and report results for:
+
 - `bundle exec rake default` - all tests and linters must pass
 - Check test output for any Ruby warnings
 
 ## 2. Verify Testing Quality
 
 **Unit Tests (Critical):**
+
 - [ ] **100% coverage of all changed code** - every branch, edge case, error condition
 - [ ] All external dependencies properly mocked (execution_context, git commands)
 - [ ] Each test verifies one specific behavior
@@ -67,6 +75,7 @@ Execute and report results for:
 - [ ] Test only through public interfaces (see RSpec Unit Testing Standards Rule 6)
 
 **Integration Tests (Essential Only):**
+
 - [ ] **Minimal and purposeful** - only test what unit tests cannot verify
 - [ ] Each test validates one specific git interaction pattern
 - [ ] Tests verify mocked assumptions match real git behavior
@@ -74,6 +83,7 @@ Execute and report results for:
 - [ ] Follow CONTRIBUTING.md guidelines: test gem's interaction with git, not git itself
 
 **Command Tests (if any `Git::Commands::*` specs are included):**
+
 - [ ] Apply the [Command Test Conventions](../command-test-conventions/SKILL.md) skill to
   every new or modified unit and integration spec file for command classes. Resolve
   all findings before proceeding.
@@ -123,6 +133,10 @@ Execute and report results for:
 - [ ] README.md updated if public API changed
 - [ ] Examples are clear and demonstrate common use cases
 - [ ] All `@param`, `@return`, `@raise` tags are accurate
+- [ ] **Skill docs (if any `.github/skills/**` files are included):** Apply the
+  [Reviewing Skills](../reviewing-skills/SKILL.md) skill to every new or
+  modified skill. Verify TOC anchors, relative links, cross-skill deep links,
+  referenced files, and any stated inheritance/override relationships.
 
 ## 7. Verify Branch Placement
 
@@ -143,22 +157,26 @@ history), or recommit (uncommitted changes) — based on the situation.
 Provide a comprehensive report with:
 
 **Implementation Summary:**
+
 - What was implemented and why
 - Key design decisions made
 - Any trade-offs or limitations
 
 **Test Coverage:**
+
 - Unit tests: X examples covering Y scenarios
 - Integration tests: Z examples validating specific git interactions
 - Coverage: 100% of changed lines (or explain gaps)
 - Edge cases tested: [list critical ones]
 
 **Quality Verification:**
+
 - ✅ Items that passed all checks
 - ⚠️ Items that need attention (if any)
 - Reference to relevant documentation verified
 
 **Suggested PR Materials:**
+
 - PR Title: `type: clear description of change`
 - PR Description draft including:
   - Summary of changes
@@ -168,6 +186,7 @@ Provide a comprehensive report with:
   - Checklist from .github/pull_request_template.md
 
 **PR Body Editing Safety:**
+
 - The terminal tool mangles multi-line markdown (backticks, asterisks, newlines) in
   any shell command, including heredocs. Always write the PR body using the
   **`create_file` tool** (the VS Code Copilot agent tool that writes file content
@@ -180,6 +199,7 @@ Provide a comprehensive report with:
 - If the body is garbled, rewrite the file with `create_file` and re-run `gh pr edit`
 
 **Next Steps:**
+
 - Any remaining items to address before PR submission
 - Confirmation that all checklist items are complete
 - Make sure to create a feature branch for the PR -- never push directly to main

data/.github/skills/project-context/SKILL.md

@@ -34,12 +34,7 @@ coding standard details, or implementation constraints.
 - [Command Implementation](../command-implementation/SKILL.md) — generating and
   reviewing command classes in the layered architecture
 - [Facade Implementation](../facade-implementation/SKILL.md) — generating and
-  reviewing `Git::Repository::*` facade methods (the planned v5.0.0 facade
-  layer is being introduced incrementally during the architectural redesign;
-  `Git::Base` / `Git::Lib` remain the current public API until the migration
-  completes)
-- [Extract Facade from Base/Lib](../extract-facade-from-base-lib/SKILL.md) —
-  migrating public methods from `Git::Base` / `Git::Lib` into facade methods
+  reviewing `Git::Repository::*` facade methods, the gem's public API layer
 - [YARD Documentation](../yard-documentation/SKILL.md) — documentation
   standards
 
@@ -49,8 +44,8 @@ coding standard details, or implementation constraints.
 
 | Class | Role |
 | --- | --- |
-| `Git::Base` | Main facade — entry point for all user-facing operations |
-| `Git::Lib` | Low-level adapter/facade; calls `Git::Commands::*`, builds rich objects via parsers |
+| `Git::Repository` | Main facade — entry point for all user-facing operations; methods live in `Git::Repository::*` topic modules under `lib/git/repository/`, included into the class |
+| `Git::ExecutionContext::*` | Configured subprocess runner; holds binary path, env vars, and global opts; provides `#command_capturing`/`#command_streaming` to command classes |
 | `Git::Commands::*` | Command classes: define CLI API, bind args, execute → return `CommandLineResult` |
 | `Git::CommandLine` | Subprocess execution: escaping, timeout, stdout/stderr capture |
 | `Git::Parsers::*` | Transform raw stdout into structured data |
@@ -67,7 +62,7 @@ coding standard details, or implementation constraints.
 
 - `lib/git/` — Core library code
 - `lib/git/commands/` — Command classes (new architecture)
-- `tests/units/` — Legacy Test::Unit suite
+- `lib/git/repository/` — Facade topic modules (`Git::Repository::*`)
 - `spec/unit/` — RSpec unit tests (mocked execution context)
 - `spec/integration/` — RSpec integration tests (real git repositories)
 - `spec/support/` — Shared test contexts and helpers
@@ -81,9 +76,9 @@ coding standard details, or implementation constraints.
 The three-layer architecture separates concerns cleanly:
 
 ```
-Git::Base (facade)
-  └── Git::Lib (adapter — pre-processes args, builds rich objects)
-        └── Git::Commands::* (defines CLI API, binds args, executes)
+Git::Repository (facade — topic modules under lib/git/repository/)
+  └── Git::Commands::* (defines CLI API, binds args, executes via execution_context)
+        └── Git::ExecutionContext::* (configured subprocess runner: env, binary, global opts)
               └── Git::CommandLine (subprocess execution)
 ```
 
@@ -99,13 +94,11 @@ Git::Base (facade)
     for the same operation with different output modes are an anti-pattern.
 - **Parser layer** (`Git::Parsers::*`): Transforms raw stdout/stderr into structured
   Ruby data. No execution.
-- **Facade layer** (`Git::Lib`): Pre-processes caller arguments, invokes the right
-  command class, calls parsers, constructs rich response objects. **Parser-contract
-  options** (e.g. `no_color: true`, `pretty: 'raw'`, `format: FORMAT_STRING`) are
-  passed explicitly at the facade call site — this makes the parser contract
-  auditable by reading `Git::Lib`. Being incrementally migrated to `Git::Repository`.
-- **Interface layer** (`Git::Base`): User-facing API. Delegates to `Git::Lib`.
-  Returns domain objects.
+- **Facade layer** (`Git::Repository::*`): Pre-processes caller arguments, invokes
+  the right command class, calls parsers, constructs rich response objects.
+  **Parser-contract options** (e.g. `no_color: true`, `pretty: 'raw'`,
+  `format: FORMAT_STRING`) are passed explicitly at the facade call site — this makes
+  the parser contract auditable by reading the topic module method.
 
 `Git::Commands::Base` provides default `#initialize(execution_context)` and `#call`.
 Command classes that need non-zero successful exits declare
@@ -115,7 +108,7 @@ Command classes that need non-zero successful exits declare
 
 Command classes are neutral, faithful representations of the git CLI. They declare
 options via the DSL but never embed policy choices (output-control flags, editor
-suppression, progress, verbose mode). The facade (`Git::Lib`) sets safe defaults
+suppression, progress, verbose mode). The facade (`Git::Repository::*`) sets safe defaults
 at each call site. Some defaults are **fixed** (not in `ALLOWED_OPTS` — rejected by
 `assert_valid_opts!` before reaching the command); others are **overridable** (in
 `ALLOWED_OPTS`, placed before the caller's `**opts` so the caller's value wins).
@@ -209,7 +202,7 @@ See [CONTRIBUTING.md](../../CONTRIBUTING.md) for authoritative, complete guideli
 
 - **Lightweight wrapper** — minimal abstraction over `git` CLI
 - **Principle of least surprise** — predictable, follows git conventions
-- **Direct CLI mapping** — `git add` → `Git::Base#add`; use prefix + suffix for
+- **Direct CLI mapping** — `git add` → `Git::Repository#add`; use prefix + suffix for
   multi-purpose commands (`#ls_files_untracked`, `#ls_files_staged`)
 - **Parameter naming** mirrors long CLI options
 - **Rich output objects** — translate git output to Ruby objects when useful to
@@ -233,7 +226,7 @@ swallow exceptions silently.
 ### Path Handling
 
 - Working-directory paths: relative to repo working directory
-- Paths stored as `Pathname` objects on `Git::Base`
+- Paths stored as `Pathname` objects on `Git::Repository`
 - `Git::EscapedPath` for paths with special characters
 - Handle Windows path separators; test with Unicode filenames
 
@@ -292,7 +285,7 @@ swallow exceptions silently.
 ### Adding new commands
 
 Follow the three-layer pattern: command class (CLI contract) → parser (output
-transform) → `Git::Lib` method (orchestration + rich object). See
+transform) → `Git::Repository::*` facade method (orchestration + rich object). See
 [Command Implementation](../command-implementation/SKILL.md).
 
 ### Working with paths

data/.github/skills/pull-request-review/SKILL.md

@@ -48,9 +48,9 @@ confirms.
 
 Evaluate the PR against these criteria:
 
-**Code Quality:** Ruby style (Rubocop-compliant), `frozen_string_literal: true`, proper naming (snake_case/PascalCase), single-responsibility, no duplication, Ruby 3.2+ idioms.
+**Code Quality:** Ruby style (RuboCop-compliant), `frozen_string_literal: true`, proper naming (snake_case/PascalCase), single-responsibility, no duplication, Ruby 3.2+ idioms.
 
-**Testing:** Changes are covered by atomic RSpec specs (`spec/`), well-named, and passing CI. Legacy Test::Unit tests (`tests/units/`) require justification to modify.
+**Testing:** Changes are covered by atomic RSpec specs (`spec/`), well-named, and passing CI.
 
 **Documentation:** YARD docs on public methods with `@param`, `@return`, `@raise`, `@example`. README updated for user-facing changes. Platform differences and security documented. For `Git::Commands::*` classes, `@raise [Git::FailedError]` must use the canonical generic wording — **never** enumerate failure causes; see the `@raise` wording table in [Command YARD Documentation](../command-yard-documentation/SKILL.md#3-return-and-raise-tags).
 

data/.github/skills/rebase/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: rebase
+description: 'Rebases the current branch onto origin/main, resolves rebase conflicts, and force-pushes with lease using non-interactive Git commands that never open an editor. Use when updating a feature branch from main, handling rebase conflicts, or rewriting branch history before updating a pull request.'
+---
+
+# Rebase
+
+Rebase the current branch on `origin/main`, resolve conflicts, and force-push
+the rewritten history without opening an editor.
+
+## Contents
+
+- [Contents](#contents)
+- [How to use this skill](#how-to-use-this-skill)
+- [Related skills](#related-skills)
+- [Prerequisites](#prerequisites)
+- [Safety rules](#safety-rules)
+- [Workflow](#workflow)
+- [Step 1: Preflight checks and fetch](#step-1-preflight-checks-and-fetch)
+- [Step 2: Start rebase on origin/main](#step-2-start-rebase-on-originmain)
+- [Step 3: Resolve conflicts and continue](#step-3-resolve-conflicts-and-continue)
+- [Step 4: Verify the rebased branch](#step-4-verify-the-rebased-branch)
+- [Step 5: Force-push with lease](#step-5-force-push-with-lease)
+- [Troubleshooting](#troubleshooting)
+
+## How to use this skill
+
+Attach this file to your Copilot Chat context, then invoke it when the current
+branch needs to be rebased onto `origin/main` and pushed.
+
+## Related skills
+
+- [Resolve Feedback](../resolve-feedback/SKILL.md) — follow-up workflow for
+  addressing PR review comments after rebasing
+- [PR Readiness Review](../pr-readiness-review/SKILL.md) — final validation
+  before opening or updating a pull request
+
+## Prerequisites
+
+- `git` is installed and authenticated for the remote.
+- The branch is a topic branch with an upstream on `origin`.
+- The working tree is clean before rebasing.
+
+## Safety rules
+
+These rules are mandatory:
+
+- Never run this workflow on `main` or `4.x`.
+- Always fetch `origin` immediately before rebasing.
+- Always run rebase commands with `GIT_EDITOR=:` and `GIT_SEQUENCE_EDITOR=:` so
+  no editor opens.
+- Force-push only with `--force-with-lease`.
+
+## Workflow
+
+1. [Preflight checks and fetch](#step-1-preflight-checks-and-fetch)
+2. [Start rebase on origin/main](#step-2-start-rebase-on-originmain)
+3. [Resolve conflicts and continue](#step-3-resolve-conflicts-and-continue)
+4. [Verify the rebased branch](#step-4-verify-the-rebased-branch)
+5. [Force-push with lease](#step-5-force-push-with-lease)
+
+## Step 1: Preflight checks and fetch
+
+```bash
+git branch --show-current
+git status --short --branch
+git fetch --prune origin
+```
+
+If the current branch is `main` or `4.x`, stop and ask the user to switch to a
+topic branch first.
+
+If `git status --short --branch` shows uncommitted changes, stop and ask the
+user whether to commit or stash before continuing.
+
+## Step 2: Start rebase on origin/main
+
+```bash
+GIT_EDITOR=: GIT_SEQUENCE_EDITOR=: git rebase origin/main
+```
+
+If the command succeeds, continue to Step 4. If it stops with conflicts, go to
+Step 3.
+
+## Step 3: Resolve conflicts and continue
+
+Repeat until the rebase completes:
+
+1. Inspect conflicted files:
+
+   ```bash
+   git status --short
+   ```
+
+2. Edit conflicted files, remove conflict markers, and keep the intended final
+   content.
+
+3. Stage resolved files:
+
+   ```bash
+   git add <resolved-path> [<resolved-path>...]
+   ```
+
+4. Continue the rebase without opening an editor:
+
+   ```bash
+   GIT_EDITOR=: GIT_SEQUENCE_EDITOR=: git rebase --continue
+   ```
+
+5. If Git reports an empty patch after conflict resolution, skip that commit:
+
+   ```bash
+   GIT_EDITOR=: GIT_SEQUENCE_EDITOR=: git rebase --skip
+   ```
+
+If the rebase cannot be completed safely, abort and report back:
+
+```bash
+git rebase --abort
+```
+
+## Step 4: Verify the rebased branch
+
+```bash
+git status --short --branch
+git merge-base --is-ancestor origin/main HEAD
+git --no-pager log --oneline --decorate --max-count=15
+```
+
+`git merge-base --is-ancestor origin/main HEAD` must exit successfully.
+
+## Step 5: Force-push with lease
+
+```bash
+git push --force-with-lease
+```
+
+If push is rejected, fetch and reconcile remote updates before retrying. Never
+replace this with plain `--force`.
+
+## Troubleshooting
+
+| Issue | Solution |
+| ----- | -------- |
+| Rebase stops with conflicts | Resolve files, `git add`, then run `GIT_EDITOR=: GIT_SEQUENCE_EDITOR=: git rebase --continue`. |
+| Rebase continue opens an editor | Re-run with both `GIT_EDITOR=:` and `GIT_SEQUENCE_EDITOR=:` prefixes. |
+| `--force-with-lease` push rejected | Run `git fetch origin`, inspect divergence, reconcile, and retry `--force-with-lease`. |
+| Need to abandon rebasing attempt | Run `git rebase --abort` and report the reason to the user. |

data/.github/skills/refactor-command-to-commandlineresult/SKILL.md

@@ -51,7 +51,7 @@ Before starting, you **MUST** load the following skill(s) in their entirety:
   rollout gates, and internal compatibility contracts
 - [Review Arguments DSL](../review-arguments-dsl/SKILL.md) — verifying DSL entries match git CLI
 - [Command Test Conventions](../command-test-conventions/SKILL.md) — unit/integration test conventions for command classes
-- [Review Backward Compatibility](../review-backward-compatibility/SKILL.md) — preserving `Git::Lib` return-value contracts
+- [Facade Implementation](../facade-implementation/SKILL.md) — preserving `Git::Repository::*` return-value contracts
 
 ## Target end state