Files

Defame1297 2c6ce438b6 refactor(git): normalize rtk-prefix usage, add metadata.version

Two bundled fixes across the same nine skills, since both touch the
same files.

Issue #113: skill prose used rtk git and bare git inconsistently for
the same operations, with no stated rule for which applied where.
Executable instructed commands (a dispatch-table "Run" cell, a fenced
code-block procedure, an imperative step) now consistently use rtk
git; illustrative or referential mentions -- naming a flag's behavior,
quoting a doc heading, warning against an anti-pattern -- stay bare
git. Documented in the new plugins/git/README.md, scoped to this
plugin only: gitea-* skills talk to the server over MCP tools and
carry no git/rtk mentions at all.

Also the git-plugin slice of #127: metadata.version added to the
eight skills that lacked it. git-commits already had one and is
untouched.

Fixes: #113
Fixes: #127
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP

2026-09-07 20:36:49 +00:00

2.9 KiB

Raw Blame History

source_keys

context7-pre-commit-com

pre-commit-com

Modifying an existing `.pre-commit-config.yaml`

Reached from SKILL.md's Route table when the repo already has a config. Self-contained — the create flow's file is not needed here. SKILL.md's three common gates still apply.

Read the existing .pre-commit-config.yaml before editing. Note any stale rev values (see Rev staleness below) but do not change them.

Adding a hook

Run a shallow extension scan, so the addition is judged against the languages actually present:
```
rtk git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
```
Read references/hooks-by-language.md for the correct repo URL, rev and recommended args before writing anything.
Check for duplicates. If the same hook ID, or an equivalent tool, is already configured, say so and stop rather than adding a second one.
To sanity-check a hook against the repo's real files before committing to it, smoke-test it:
```
pre-commit try-repo <repo-url> <hook-id> --verbose
```
Use a local path in place of the URL for a hook under development. This runs the hook without writing anything.
If the hook's source repo is already a block in the config, add the hook under that block. Otherwise append a new repo block.
State the proposed addition, wait for confirmation, write, and run pre-commit validate-config. On a non-zero exit, show the error, fix it, and re-validate.

Removing a hook

Identify the hook entry and its parent repo block.
State what will be removed — the hook ID, and whether the parent repo block goes with it because it would be left with zero hooks. Wait for confirmation.
Remove the hook entry. If the repo block now has no hooks left, remove the whole block: an empty hooks: [] fails validate-config.
Write, then run pre-commit validate-config. On a non-zero exit, revert the edit, show the error, and stop. A removal is not safely fixable in place the way a malformed new hook block is, so recovering the prior state beats patching forward.

Configuring top-level keys

Only when the user explicitly asks. Valid keys: fail_fast, default_stages, default_language_version, minimum_pre_commit_version, exclude, files, default_install_hook_types.

State the proposed change and wait for confirmation before writing.

Rev staleness

For each repo in the config that also appears in references/hooks-by-language.md, compare the two rev values. Flag a mismatch as potentially outdated and tell the user to run pc-run to autoupdate. Repos absent from the reference cannot be checked — skip them silently. Do not modify any rev yourself.

The reference table's own pins go stale between updates, so treat a mismatch as a prompt to check rather than proof of staleness. pre-commit autoupdate, via pc-run, is the authoritative answer to what the current rev actually is.

2.9 KiB Raw Blame History

Modifying an existing .pre-commit-config.yaml