Facade YARD Documentation Rules

Facade YARD Documentation

Write and verify YARD documentation for facade modules and methods on Git::Repository::*. This skill overrides and extends the general YARD Documentation skill with facade-specific rules.

The facade is the public API surface of the gem. Facade docs describe what the caller passes and what they get back — never the internal command class, parser, or execution context that implements the behavior.

Contents

• Contents
• Related skills
• Input
• Reference
  • Module-level docs
  • Method-level docs
  • Documenting forwarded options with @overload
  • Return type rules
  • @raise rules
  • @note for the failure state
  • Cross-referencing the implementation
  • Common issues
• Workflow
  • 1. Module-level docs
  • 2. Method-level docs (per method)
  • 3. Formatting consistency
• Output
  • When writing new facade YARD docs
  • When reviewing existing facade YARD docs

Related skills

• YARD Documentation — authoritative source for general YARD formatting rules; must be loaded as a prerequisite
• Facade Implementation — facade module structure and orchestration patterns
• Facade Test Conventions — unit and integration test conventions for facade methods
• Command YARD Documentation — sibling skill for the underlying command classes (different rules — facade docs do not mirror command DSL)

Input

Before starting, you MUST load the following skill(s) in their entirety:

• YARD Documentation — authoritative source for YARD formatting rules and writing standards

Then gather:

1. Facade module source — lib/git/repository/<topic>.rb
2. Underlying command class(es) — lib/git/commands/<command>.rb for each command the facade method calls. Use these to confirm option semantics, but do not copy the command's @option docs verbatim — the facade only exposes the options it documents in its public contract.
3. Underlying parser/result class — when the facade returns a structured value, read the parser or result class to confirm the documented return type.

Reference

Module-level docs

Every facade module under lib/git/repository/ requires a module-level YARD block:

module Git
  class Repository
    # Short summary of the topic and the facade methods it provides
    #
    # Included by {Git::Repository}.
    #
    # @api public
    #
    module Topic
      # ...
    end
  end
end

Module-level tags appear in the order required by YARD element rules — Modules: @note, @deprecated, @see, @api. (Facade modules do not use module-level @example — see the override note below.)

Required tags:

• short summary describing the topic (e.g. "Facade methods for staging-area operations: adding and resetting files") — follows the short-description rules in YARD Documentation
• sentence noting "Included by {Git::Repository}." with the YARD link
• @api public — every facade module is part of the public API

Do not add:

• @see Git::Commands::* at the module level — implementation detail
• @see https://git-scm.com/docs/... at the module level — git man-page links belong on the individual facade methods, where the link maps directly to the command being invoked. A module typically groups several facade methods (sometimes spanning multiple git commands), so a single module-level 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 element rules — 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 be redundant. Examples belong on the methods.

Method-level docs

Every facade method requires full YARD docs. Two acceptable forms:

Form A — @overload with anonymous splat in the def (the default for any method that forwards positional args and/or keyword options unchanged to the underlying command). The def uses an anonymous splat — **, *, or ... — to satisfy RuboCop's Style/ArgumentsForwarding cop, and the @overload block introduces named parameters that @param and @option bind to:

# Update the index with the current content found in the working tree
#
# @overload add(paths = '.', **options)
#
#   @example Stage all changed files
#     repo.add
#
#   @example Stage a specific file
#     repo.add('README.md')
#
#   @param paths [String, Array<String>] a file or files to add (relative to
#     the worktree root); defaults to `'.'` (all files)
#
#   @param options [Hash] options for the add command
#
#   @option options [Boolean, nil] :all (nil) add, modify, and remove index
#     entries to match the worktree
#
#   @option options [Boolean, nil] :force (nil) allow adding otherwise ignored
#     files
#
#   @return [String] git's stdout from the add
#
# @raise [ArgumentError] if unsupported options are provided
#
# @raise [Git::FailedError] if `git add` exits with a non-zero status
#
def add(paths = '.', **)
  Git::Repository::Internal.assert_valid_opts!(ADD_ALLOWED_OPTS, **)
  Git::Commands::Add.new(@execution_context).call(*Array(paths), **).stdout
end

See Documenting forwarded options with @overload for the rationale and variations (*, ..., multiple call shapes).

Form B — direct doc comment on a fully named signature (the narrow exception: use only when the method body must inspect or mutate the options hash before forwarding it, or when the signature has no splat at all). When the def has a named parameter for every documented argument, @param and @option bind directly:

# Commit staged changes
#
# @example Commit with a message
#   repo.commit('Initial commit')
#
# @example Amend the previous commit
#   repo.commit('Updated message', amend: true)
#
# @param message [String] the commit message
#
# @param opts [Hash] commit options
#
# @option opts [Boolean, nil] :amend (nil) amend the previous commit
#
# @return [String] git's stdout from the commit
#
# @raise [ArgumentError] if unsupported options are provided
#
# @raise [Git::FailedError] if `git commit` exits with a non-zero status
#
def commit(message, opts = {})
  Git::Repository::Internal.assert_valid_opts!(COMMIT_ALLOWED_OPTS, **opts)
  opts = opts.merge(message: message) if message
  Git::Commands::Commit.new(@execution_context).call(no_edit: true, **opts).stdout
end

Form B is required here because the method body needs a named variable (opts) to build and transform before forwarding — e.g. opts.merge(message: message) returns a new hash that is assigned back, and opts = deprecate_commit_no_gpg_sign_option(opts) reassigns it; an anonymous ** in the def provides no named variable to operate on.

When a method has multiple genuinely distinct call shapes (e.g. commit(message) vs. commit(message, opts) with materially different return types), use one @overload block per shape — see YARD Documentation — Overload template.

Required elements (apply to both forms):

• one-line summary describing what the method does from the caller's perspective (not "calls Git::Commands::Foo")
• at least one @example block with a descriptive title (required on every public facade method; use representative input and show the return value)
• @param for every positional parameter, with type and short description
• @param <name> [Hash] preceding any @option tags — the name comes from the @overload signature (e.g. options or opts) when the actual def uses anonymous ** for Style/ArgumentsForwarding; otherwise it matches the named parameter on the def itself
• @option for every option the facade exposes (the caller-facing contract, not every option the underlying command accepts)
• @return with the documented public return type (see Return type rules)
• @raise for every error the caller can hit (see @raise rules)

Documenting forwarded options with @overload

When a facade method forwards positional args and/or keyword options unchanged to the underlying command, keep the anonymous splat (**, *, or ...) in the def (so Style/ArgumentsForwarding stays satisfied) and document the call shape with an @overload block that names the parameters — Form A in Method-level docs above shows the canonical add example.

Key constraints:

• Do not name the splat — or expand ... into *args, **kwargs, &block — solely to make @param/@option bind. Do not suppress Style/ArgumentsForwarding with # rubocop:disable. The @overload form is the project-standard resolution.
• The @overload signature owns the parameter names; @param, @option, @yield, and @yieldparam tags inside the overload bind to those names.
• When a facade method has multiple distinct call shapes (e.g. commit(message) vs. commit(message, **opts)), write one @overload block per shape.
• Form B (named splat, direct doc comment) is the narrow exception — use only when the body inspects or mutates the options hash before forwarding it.
• The anonymous block parameter (&) is not covered by this rule. @yield/@yieldparam/@yieldreturn describe what is yielded rather than the block parameter itself, so anonymous & is fine. Name the block (&block) only when documenting it as a first-class Proc value.

See the general YARD Documentation — Documenting anonymous splats with @overload for the underlying rule.

Decision rules for facade methods:

• Use @overload when the method uses anonymous *, **, or ...
• Use @overload when call shapes differ meaningfully (different params and/or return contracts)
• Skip @overload only when a single named signature fully describes the API

When using @overload, place tags as follows:

• Put @param, @option, and @return in overload blocks
• Put overload-specific @raise only in the relevant overload block
• Put shared @raise once at top level
• Do not duplicate the same @raise at both levels

Return type rules

The @return annotation must reflect the public contract of the facade method, not the type of the underlying call expression.

Never write @return [Git::Commands::Foo::Result] — command-class result types are internal. Surface Git::CommandLine::Result only when the topic module's documented contract is to expose raw results.

@raise rules

• Always include @raise [Git::FailedError] for any facade method that can cause git to exit non-zero. Use the canonical generic wording matching the command's exit-status range:

  Command's allow_exit_status	Facade @raise wording
  none / 0..0	if git exits with a non-zero exit status
  0..1	if git exits outside the allowed range (exit code > 1)

• When the facade calls assert_valid_opts!, include @raise [ArgumentError] if unsupported options are provided.

• When the facade itself validates arguments and raises (e.g. "you must specify a remote if a branch is specified"), document with a specific @raise [ArgumentError] line that names the constraint.

• Do not enumerate specific git failure causes (no "if the branch doesn't exist", no "if the working tree is dirty"). Use the generic form.

Scope @raise tags by call-shape:

• Shared across all overloads: keep as one top-level @raise
• Specific to one or more overloads: keep only in those overload blocks
• Never duplicate identical @raise tags at both top level and overload level