git 5.1.0 → 5.2.0

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

@@ -1,214 +0,0 @@
----
-name: review-arguments-dsl
-description: "Audits a command class's arguments DSL definition to verify it accurately maps Ruby call arguments to git CLI arguments in the correct order with correct DSL methods and modifiers."
----
-
-# Review Arguments DSL
-
-Verify that a command class's `arguments do ... end` definition accurately maps Ruby
-call arguments to git CLI arguments, in the correct order, with the correct DSL
-methods and modifiers.
-
-## Contents
-
-- [Contents](#contents)
-- [Related skills](#related-skills)
-- [Input](#input)
-  - [Command source code](#command-source-code)
-  - [Command test code](#command-test-code)
-  - [Git documentation for the git command](#git-documentation-for-the-git-command)
-- [Reference](#reference)
-  - [Architecture Context (Base Pattern)](#architecture-context-base-pattern)
-  - [DSL to CLI Mapping](#dsl-to-cli-mapping)
-- [Workflow](#workflow)
-- [Output](#output)
-
-## Related skills
-
-- [Command Implementation](../command-implementation/SKILL.md) — class structure, phased rollout gates, and
-  internal compatibility contracts
-- [Command Test Conventions](../command-test-conventions/SKILL.md) — unit/integration test conventions for command classes
-- [Command YARD Documentation](../command-yard-documentation/SKILL.md) — documentation completeness for command classes
-
-## Input
-
-What the agent requires to run this skill and where to get it.
-
-### Command source code
-
-Read the command class from `lib/git/commands/{command}.rb` or, for subcommands,
-`lib/git/commands/{command}/{subcommand}.rb`. For subcommands, also read the
-namespace module at `lib/git/commands/{command}.rb` which should list all sibling
-subcommands and provide the module-level documentation.
-
-### Command test code
-
-Read unit tests matching `spec/unit/git/commands/{command}/**/*_spec.rb`. Use these as
-supplemental evidence when tracing the verification chain (Ruby call → bound
-argument → expected git CLI). Coverage completeness is assessed by the
-[Command Test Conventions](../command-test-conventions/SKILL.md) skill.
-
-### Git documentation for the git command
-
-- **Latest-version online command documentation**
-
-  Read the **entire** official git documentation online man page for the command
-  for the latest version of git. This version will be used as the primary
-  authority for DSL completeness, including the options to include in the
-  DSL, argument names, aliases, ordering, etc.
-  Fetch this version from the URL `https://git-scm.com/docs/git-{command}`
-  (this URL always serves the latest release).
-
-- **Minimum-version online command documentation**
-
-  Read the **entire** official git documentation online man page for the command for
-  the `Git::MINIMUM_GIT_VERSION` version of git. This will be used only for
-  command-introduction and `requires_git_version` decisions. Fetch this version from
-  URL `https://git-scm.com/docs/git-{command}/{version}`.
-
-Do **not** scaffold from local `git <command> -h` output alone — the installed Git
-version is unknown and may differ from the latest supported version. Local help should
-NOT be used even as a supplemental check.
-
-## Reference
-
-### Architecture Context (Base Pattern)
-
-Command classes follow this structure:
-
-- `class < Git::Commands::Base`
-- class-level `arguments do ... end`
-- optional class-level macros such as `allow_exit_status <range>` and
-  `requires_git_version <version>`
-- YARD documentation with `@overload` blocks containing `@param`, `@option`,
-  `@return`, and `@raise` tags, in one of two forms:
-  - **when `#call` is overridden:** standard YARD comments directly above `def call`
-  - **when `#call` is not overridden:** a `# @!method call(*, **)` directive with
-    nested standard YARD comments
-
-The CLI argument mapping is still defined exclusively by the Arguments DSL. The
-`Base` class handles binding and execution.
-
-### DSL to CLI Mapping
-
-<!--
-Purpose: gives the agent the mental model for predicting CLI output from a
-DSL definition — the mapping rules needed to execute the verification chain
-(Ruby call → bound argument → expected git CLI).
-
-CHECKLIST.md works in the reverse direction: given git man-page behavior,
-which DSL method and modifiers to use.
--->
-
-The Arguments DSL (`arguments do ... end`) declares how Ruby keyword and positional
-arguments map to git CLI flags, options, and operands. See [CHECKLIST.md §
-Verify DSL method per option type](CHECKLIST.md#2-verify-dsl-method-per-option-type)
-for the full DSL method mapping table.
-
-Key behaviors:
-
-- **Basic emit** — `flag_option :verbose` → `--verbose`; `value_option :message` →
-  `--message <value>`; `operand :commit` → bare `<value>` in positional slot.
-- **`flag_or_value_option`** — hybrid: `true` → `--flag`; string → `--flag value`
-  (or `--flag=value` with `inline:`); `false`/`nil` → nothing. Supports `negatable:`.
-- **`key_value_option`** — accepts a Hash or Array of pairs; emits `--flag key=value`
-  per pair. `key_separator:` overrides `=`; `inline:` joins as `--flag=key=value`.
-- **`custom_option`** — block receives the raw value and returns CLI strings; String
-  is appended, Array is concatenated, `nil`/empty emits nothing.
-- **nil / false suppression** — for boolean-style options (`flag_option`,
-  `flag_or_value_option` in boolean mode), `false` or `nil` suppresses emission.
-  For `value_option` / `inline_value` options, `false` is treated as a value
-  (stringified to `"false"`) unless a type constraint rejects it. `nil` suppresses
-  emission for all option types (including negatable options — `false` is absent,
-  not `--no-*`).
-- **Output order matches definition order** — bound arguments are emitted in the
-  order entries appear in `arguments do`.
-- **Name-to-flag mapping** — underscores become hyphens, single-char names map to
-  `-x`, multi-char names map to `--name`. **Case is preserved**: `:A` → `-A`, `:N` →
-  `-N`. Uppercase short flags do not require `as:`.
-- **`as:` override** — emits a verbatim string instead of deriving the flag from the
-  symbol name. See [CHECKLIST.md § The `as:` escape
-  hatch](CHECKLIST.md#the-as-escape-hatch) for when use is justified.
-- **Aliases** — first alias is canonical and determines the generated flag; remaining
-  aliases are accepted as caller-side synonyms. Long name first:
-  `%i[force f]`, not `%i[f force]`.
-- **`negatable:`** — registers two entries: the positive key and a `no_` companion.
-  Both follow standard boolean semantics: `true` emits the flag, `false`/`nil` omits
-  it. Pass `no_edit: true` to emit `--no-edit`.
-  - `flag_option :edit, negatable: true` → `:edit` `[Boolean]` and `:no_edit`
-    `[Boolean]`
-  - `flag_or_value_option :track, negatable: true` → `:track` `[Boolean, String]`
-    (positive or value form) and `:no_track` `[Boolean]` (boolean only; the negated
-    form never takes a value)
-- **`inline:`** — `value_option :format, inline: true` emits `--format=value` as one
-  token; without it, `--format value` as two tokens.
-- **`max_times:`** — `flag_option :force, max_times: 2` with `force: 2` emits
-  `--force --force`.
-- **`repeatable:`** — accepts an array; emits the flag once per value
-  (e.g., `--include a --include b`).
-- **`as_operand:`** — `value_option :pathspec, as_operand: true` is passed as a
-  keyword but emitted in the operand position after `end_of_options`.
-- **`literal`** — always emits its string unconditionally; the caller has no control.
-- **`execution_option`** — never emits anything to argv; forwarded as Ruby kwargs to
-  the subprocess runner.
-- **`skip_cli:` on operands** — `operand ..., skip_cli: true` binds and validates
-  like any other operand and remains accessible on `Bound`, but is excluded from argv
-  emission.
-- **`end_of_options`** — signals end of options in the emitted argv; only operands
-  may follow (though operands may also appear before it). Emits `--` by default.
-  Override with `as:` when the command uses a different token. See [CHECKLIST.md §
-  Choosing the `as:` token](CHECKLIST.md#choosing-the-as-token) for the decision
-  rule.
-- **Operand/option name collision** — if a positional operand and a keyword option
-  share the same name, the **option keeps its name** and the **operand is renamed**.
-  For repeatable operands, prefer the plural form (`:commit` → `:commits`). See
-  [CHECKLIST.md § Operand naming](CHECKLIST.md#operand-naming) for details.
-
-## Workflow
-
-1. **Determine scope and exclusions** — using the git documentation loaded during
-   [Input](#input), identify which options are in scope for the DSL. See
-   [CHECKLIST.md §1](CHECKLIST.md#1-determine-scope-and-exclusions).
-
-2. **Audit each DSL entry** — for each entry in `arguments do`, walk through
-   [CHECKLIST.md](CHECKLIST.md) §2–§5:
-   1. Verify DSL method per option type
-   2. Verify alias and `as:` usage
-   3. Verify ordering
-   4. Verify modifiers
-
-   For each entry, also trace the verification chain — confirm the full mapping:
-
-   `Ruby call → bound argument → expected git CLI`
-
-   Compare the expected CLI output against the git man-page documentation.
-
-3. **Check completeness** — verify the DSL as a whole against the git man page per
-   [CHECKLIST.md §6](CHECKLIST.md#6-check-completeness): YARD↔DSL parity, missing
-   options, repeatable flags, operand naming, and per-argument validation.
-
-4. **Check class-level declarations** — verify `allow_exit_status` and
-   `requires_git_version` per
-   [CHECKLIST.md §7](CHECKLIST.md#7-check-class-level-declarations).
-
-5. **Check the validation delegation policy** — verify that cross-argument
-   constraint methods (`conflicts`, `requires`, etc.) are used only when
-   justified. See the constraint policy in
-   [CHECKLIST.md §6 Per-argument validation completeness](CHECKLIST.md#per-argument-validation-completeness).
-
-6. **Collect issues** — record all findings for the [Output](#output).
-
-## Output
-
-Produce:
-
-1. A per-entry table:
-
-   | # | DSL method | Definition | CLI output | Correct? | Issue |
-   | --- | --- | --- | --- | --- | --- |
-
-2. A list of missing options/modifier/order/conflict issues
-3. Any class-level declaration mismatches: `allow_exit_status` not present with
-   a `Range` and rationale comment when the command has non-zero successful
-   exits; `requires_git_version` not present only when the command was
-   introduced after `Git::MINIMUM_GIT_VERSION`

data/.github/skills/review-cross-command-consistency/SKILL.md

@@ -1,139 +0,0 @@
----
-name: review-cross-command-consistency
-description: "Compares sibling command classes for consistent structure, documentation, testing, and exit-status conventions under the Base architecture. Use for cross-command audits."
----
-
-# Review Cross-Command Consistency
-
-Review sibling command classes (same module/family) for consistent structure,
-documentation, testing, and exit-status conventions under the `Base` architecture.
-
-## Contents
-
-- [How to use this skill](#how-to-use-this-skill)
-- [Prerequisites](#prerequisites)
-- [Related skills](#related-skills)
-- [Version-Aware Comparison Scope](#version-aware-comparison-scope)
-- [What to Check](#what-to-check)
-  - [1. Class structure consistency](#1-class-structure-consistency)
-  - [2. Arguments DSL consistency](#2-arguments-dsl-consistency)
-  - [3. Exit-status consistency](#3-exit-status-consistency)
-  - [4. YARD consistency](#4-yard-consistency)
-  - [5. Unit spec consistency](#5-unit-spec-consistency)
-  - [6. Integration spec consistency](#6-integration-spec-consistency)
-  - [7. Migration process consistency](#7-migration-process-consistency)
-- [Output](#output)
-
-## How to use this skill
-
-Attach this file to your Copilot Chat context, then invoke it with the sibling
-command files (same module/family) to compare. Examples:
-
-```text
-Using the Review Cross-Command Consistency skill, review the
-Git::Commands::Diff family: lib/git/commands/diff/patch.rb,
-lib/git/commands/diff/numstat.rb, lib/git/commands/diff/raw.rb.
-```
-
-```text
-Review Cross-Command Consistency: all files under lib/git/commands/stash/
-```
-
-The invocation needs two or more sibling command files from the same family.
-
-## Prerequisites
-
-Before starting, you **MUST** load the following skill(s) in their entirety:
-
-- [YARD Documentation](../yard-documentation/SKILL.md) — authoritative
-  source for YARD formatting rules and writing standards;
-
-## Related skills
-
-- [Command Implementation](../command-implementation/REFERENCE.md#phased-rollout-requirements) — canonical class-shape checklist, phased
-  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
-- [Command YARD Documentation](../command-yard-documentation/SKILL.md) — documentation completeness for command classes
-
-## Version-Aware Comparison Scope
-
-Before flagging siblings as inconsistent for option names, aliases, negated
-forms, or documented values, determine the repository's minimum supported Git
-version from project metadata. In this repository, `git.gemspec` declares
-`git 2.28.0 or greater`.
-
-Consistency judgments for CLI surface area must be based on the minimum
-supported Git version, not only on the locally installed Git. Use
-version-matched upstream documentation first, version-matched upstream source
-when exact parser behavior is ambiguous, and local `git <command> -h` output
-only as a supplemental check.
-
-## What to Check
-
-### 1. Class structure consistency
-
-- [ ] all classes use `class < Git::Commands::Base`
-- [ ] all require `git/commands/base`
-- [ ] all use `arguments do ... end` (no legacy `ARGS =` constants)
-- [ ] simple commands carry YARD directive `# @!method call(*, **)` with nested `@overload` blocks and have no explicit `def call` definition
-- [ ] commands with legitimate `call` overrides (stdin protocol, input validation, non-trivial option routing) use explicit YARD docs instead and do **not** carry the `# @!method` directive
-- [ ] commands with `call` overrides use `Base#with_stdin` for stdin feeding and delegate exit-status validation to `validate_exit_status!`
-
-### 2. Arguments DSL consistency
-
-- [ ] shared options use same alias/modifier patterns
-- [ ] shared entries appear in same relative order
-- [ ] command-specific differences are intentional and documented
-- [ ] no `literal` entries for policy/output-control flags (`--no-edit`, `--verbose`,
-      `--no-progress`, `--no-color`, etc.) — command classes are neutral, faithful
-      representations of the git CLI; all siblings use `flag_option` /
-      `value_option` for these, leaving policy decisions to the facade. See
-      "Command-layer neutrality" in CONTRIBUTING.md.
-
-### 3. Exit-status consistency
-
-- [ ] siblings with same git exit semantics use same `allow_exit_status` range
-- [ ] rationale comments are present and consistent in tone
-- [ ] commands without non-zero successful exits do not declare custom ranges
-
-### 4. YARD consistency
-
-- [ ] consistent class summaries and `@api private`
-- [ ] `@overload` coverage consistent for equivalent call shapes
-- [ ] `@return` and `@raise` wording consistent across siblings — `@raise [Git::FailedError]` uses the canonical generic form ("if git exits with a non-zero exit status" for default range; "if git exits outside the allowed range (exit code > N)" for non-default); never enumerates specific failure causes
-- [ ] tag short descriptions do not end with punctuation
-- [ ] multi-paragraph tag descriptions have a blank comment line between the short
-      description and each continuation paragraph
-
-### 5. Unit spec consistency
-
-- [ ] expectations include `raise_on_failure: false` where command invocation is asserted
-- [ ] similar option paths use similar context naming
-- [ ] exit-status tests are parallel where ranges are shared
-
-### 6. Integration spec consistency
-
-- [ ] success/failure grouping uses same structure
-- [ ] no output-format assertions (smoke + error handling only)
-
-### 7. Migration process consistency
-
-See **[Command Implementation § Phased rollout requirements](../command-implementation/REFERENCE.md#phased-rollout-requirements)** for
-the canonical checklist. During a cross-command audit, verify that sibling commands
-were migrated in the same slice and that the same quality gates were applied.
-
-## Output
-
-1. Summary table:
-
-   | Aspect | File A | File B | File C | Status |
-   | --- | --- | --- | --- | --- |
-
-2. Inconsistency list with canonical recommendation:
-
-   | Issue | Files | Recommended canonical form |
-   | --- | --- | --- |
-
-> **Branch workflow:** Implement any fixes on a feature branch. Never commit or
-> push directly to `main` — open a pull request when changes are ready to merge.

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

@@ -1,214 +0,0 @@
----
-name: reviewing-skills
-description: 'Audits Agent Skills for quality, discoverability, and adherence to best practices. Use when reviewing a skill, checking skill quality, auditing skill descriptions, or validating skill structure before committing.'
----
-
-# Reviewing Skills
-
-Audit one or more Agent Skills for quality, discoverability, consistency, and
-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)
-- [Review checklist](#review-checklist)
-  - [1. Frontmatter](#1-frontmatter)
-  - [2. Description quality](#2-description-quality)
-  - [3. Body structure and size](#3-body-structure-and-size)
-  - [4. Conciseness](#4-conciseness)
-  - [5. Degrees of freedom](#5-degrees-of-freedom)
-  - [6. Progressive disclosure](#6-progressive-disclosure)
-  - [7. Workflows and feedback loops](#7-workflows-and-feedback-loops)
-  - [8. Content quality](#8-content-quality)
-  - [9. Cross-skill consistency](#9-cross-skill-consistency)
-  - [10. Discoverability sections](#10-discoverability-sections)
-- [Output](#output)
-- [Reference: Anthropic best-practices summary](#reference-anthropic-best-practices-summary)
-
-## How to use this skill
-
-Attach this file to your Copilot Chat context, then invoke it with the skill
-folder or SKILL.md file(s) to review. Examples:
-
-```text
-Using the Reviewing Skills skill, review .github/skills/command-implementation/.
-```
-
-```text
-Review all skills under .github/skills/ for best-practice compliance.
-```
-
-## Related skills
-
-- [Make Skill Template](../make-skill-template/SKILL.md) — scaffold new skills;
-  use this reviewing skill afterward to validate quality
-- [PR Readiness Review](../pr-readiness-review/SKILL.md) — final pre-PR quality
-  gate (broader than skill-specific review)
-
-## Input
-
-One or more skill directories or SKILL.md files from `.github/skills/`.
-
-## Review checklist
-
-Work through each section below for every skill under review.
-
-### 1. Frontmatter
-
-- [ ] `name` is present, 1-64 chars, lowercase letters/numbers/hyphens only
-- [ ] `name` matches the folder name exactly
-- [ ] `name` does not contain reserved words (`anthropic`, `claude`)
-- [ ] `description` is present, 1-1024 chars
-- [ ] `description` does not contain XML tags
-
-### 2. Description quality
-
-The description is the **primary discovery mechanism** — it determines whether the
-skill is selected from potentially hundreds of available skills.
-
-- [ ] Written in **third person** (not "I can…" or "You can…")
-- [ ] Describes **what** the skill does (capabilities)
-- [ ] Describes **when** to use it (triggers, scenarios, keywords)
-- [ ] Includes specific key terms users are likely to mention
-- [ ] Is not vague (e.g. "Helps with documents" is too vague)
-
-### 3. Body structure and size
-
-- [ ] 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
-
-Every token in a loaded skill competes with conversation history and other
-context. Challenge each piece of information:
-
-- [ ] Only includes context the model does not already have
-- [ ] Does not over-explain concepts the model already knows
-- [ ] Avoids redundant paragraphs or verbose preambles
-- [ ] Uses code examples instead of lengthy prose where possible
-
-### 5. Degrees of freedom
-
-Match instruction specificity to task fragility:
-
-- [ ] **High freedom** (general text guidance) for tasks where multiple
-      approaches are valid and context determines the best route
-- [ ] **Medium freedom** (pseudocode / parameterized templates) for tasks with a
-      preferred pattern but acceptable variation
-- [ ] **Low freedom** (exact scripts, no parameters) for fragile or
-      error-prone operations where consistency is critical
-- [ ] The chosen level is appropriate for the skill's domain
-
-### 6. Progressive disclosure
-
-- [ ] 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
-
-### 7. Workflows and feedback loops
-
-- [ ] Complex multi-step operations are broken into clear, sequential steps
-- [ ] Long workflows include a progress checklist the agent can track
-- [ ] Validation / feedback loops are present for quality-critical tasks
-      (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
-
-When reviewing multiple skills in the same repository:
-
-- [ ] Naming convention is consistent (all gerund, all noun-phrase, or all
-      action-oriented — not a mix)
-- [ ] 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
-
-Every skill in this repository must include these standard sections:
-
-- [ ] `## Contents` — table of contents with anchor links
-- [ ] `## How to use this skill` — brief invocation guidance
-- [ ] `## Related skills` — cross-links to related skills with one-line
-      descriptions
-
-## Output
-
-For each reviewed skill, produce:
-
-1. A per-check result table:
-
-   |  #  | Check | Status | Issue |
-   | --- | ----- | ------ | ----- |
-
-2. A summary of required fixes (if any)
-
-3. A list of suggestions for improvement (optional, lower priority)
-
-## Reference: Anthropic best-practices summary
-
-This checklist is derived from the official Anthropic skill-authoring best
-practices at
-<https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices>.
-
-Key principles distilled:
-
-| Principle | One-liner |
-| --------- | --------- |
-| Concise is key | Only add context the model does not already have |
-| Degrees of freedom | Match specificity to task fragility |
-| Progressive disclosure | SKILL.md is an overview; details in separate files |
-| Effective descriptions | Third-person, specific, includes triggers and keywords |
-| Workflows | Sequential steps with checklists and feedback loops |
-| 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 |
-| 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
-> push directly to `main` — open a pull request when changes are ready to merge.