refactor(git-commits): retrofit to the ADR-0020 context contract
Description 724 -> 214 chars, body 1102 -> 343 words, Gotchas 12 -> 3. Create, rewrite, and cherry-pick flows move to self-contained references/ files behind a dispatch table. The audit caught that moving the secret scan into the create flow left the amend/squash path with no check in its loaded context; it is now a gate common to every flow. Also re-homes the interactive-rebase reflog warning git-history dropped, since this skill owns rebase.
This commit is contained in:
@@ -16,9 +16,16 @@ Describe your commit task: create a new commit, amend, squash, or cherry-pick. T
|
||||
|
||||
## Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `SKILL.md` | Skill instructions for agents |
|
||||
| `references/conventional-commits-spec.md` | Full Conventional Commits specification |
|
||||
| `references/commit-template.md` | Why / Implementation Notes / Impact body structure and full trailer list |
|
||||
| File | Loaded when |
|
||||
|------|-------------|
|
||||
| `SKILL.md` | Always — gotchas, the flow dispatch table, the gates common to every flow, and the output shape |
|
||||
| `references/create-commit.md` | Composing a new commit from staged changes |
|
||||
| `references/rewrite-history.md` | Amending, squashing, or folding a `fixup!`/`squash!` commit into an earlier one |
|
||||
| `references/cherry-pick.md` | Replaying an existing commit onto the current branch |
|
||||
| `references/conventional-commits-spec.md` | A type, footer, or breaking-change edge case is not obvious — full spec, 11-type set, commitlint constraint table |
|
||||
| `references/commit-template.md` | Writing a body for a non-trivial commit — Why / Implementation Notes / Impact structure and the full trailer list |
|
||||
| `references/sources.md` | Research sources and provenance |
|
||||
|
||||
## Composition
|
||||
|
||||
Part of the git plugin's domain suite. This skill owns commit authoring and history-rewriting operations only; `git-history` inspects history, `git-branches` owns branch lifecycle, and `git-workflow` is the conversational entry point that routes between them.
|
||||
|
||||
@@ -2,16 +2,13 @@
|
||||
name: git-commits
|
||||
|
||||
description: >
|
||||
Use when creating, amending, squashing, or cherry-picking commits.
|
||||
Generates well-formatted commit messages following Conventional Commits spec (type, scope, description, body, footers).
|
||||
Validates against commitlint config-conventional constraints (header max 100 chars, lowercase subject, no trailing periods, type must be one of 11 standard types).
|
||||
Communicates SemVer impact (MAJOR for breaking changes, MINOR for features, PATCH for fixes).
|
||||
Handles confirmation gates for history-altering operations (amend, rebase, squash).
|
||||
Provides interactive guidance for humans, structured JSON output for agents.
|
||||
Do not use for: inspecting git history, branch management, or repository state inspection — those are separate skills.
|
||||
Use when creating, amending, squashing, or cherry-picking commits, including
|
||||
writing and validating the Conventional Commits message.
|
||||
Not history inspection -> `git-history`.
|
||||
Not branch lifecycle -> `git-branches`.
|
||||
|
||||
metadata:
|
||||
version: "0.1.2"
|
||||
version: "0.1.3"
|
||||
category: git
|
||||
source_keys:
|
||||
- conventional-commits-spec
|
||||
@@ -24,92 +21,45 @@ allowed-tools: Bash
|
||||
|
||||
## Gotchas
|
||||
|
||||
- **Type must be one of 11 standard types** — `feat`, `fix`, `perf`, `revert`, `docs`, `style`, `refactor`, `test`, `build`, `ci`, `chore`. Non-standard types will fail commitlint validation. Note: the Conventional Commits spec itself only mandates `feat`/`fix` — the 11-type set is a commitlint/Angular convention this skill validates against, not a spec requirement.
|
||||
- **Scope is optional but should be used** — helps identify which part of the system changed. Examples: `api`, `db`, `cli`, `config`.
|
||||
- **Header max 100 characters** — type + scope + colon + description must fit. If longer, move detail to body.
|
||||
- **BREAKING CHANGE notation** — use `!` before the colon (`feat!: drop Node 6`) for visibility in `git log --oneline`. Footer notation (`BREAKING CHANGE: ...`) is machine-readable but hidden in log.
|
||||
- **SemVer mapping is not optional** — agents must communicate: `feat` → MINOR bump, `fix`/`perf`/`revert` → PATCH, any with breaking change → MAJOR.
|
||||
- **Confirmation gates are mandatory for destructive operations** — amend, rebase, squash require explicit user/agent approval before execution.
|
||||
- **Never skip hooks with `--no-verify`** — hooks are the automated QA gate; bypassing them breaks the pipeline. Do not add this flag to any commit command unless the user explicitly demands it, and warn them if they do.
|
||||
- **Never force-push `main`/`master`** — even after an amend or interactive rebase, refuse to force-push a protected branch (`main`, `master`) and explain why; force-push is only safe on branches no one else has based work on.
|
||||
- **Command examples use the `rtk git` wrapper** — this org's convention routes all git invocations through `rtk git <subcommand>` instead of bare `git <subcommand>`. Follow this prefix in any command you actually run.
|
||||
- **Never commit secrets, credentials, or environment-specific config** — if staged changes contain what looks like an API key, token, password, or connection string, stop and flag it before committing rather than committing it.
|
||||
- **Commits must be atomic and leave the repo working** — each commit should be one logical, independently reviewable and reversible change, and should leave the repository in a buildable/testable state. If staged changes bundle unrelated work, suggest splitting before committing.
|
||||
- **Commit messages explain why, not what** — the diff already shows what changed; the message's job is to capture context the diff can't (motivation, root cause, tradeoffs). See `references/commit-template.md` for the structure this maps to.
|
||||
- **Run git as `rtk git <subcommand>`, never bare `git`** — org convention, in `&&` chains too.
|
||||
- **Refuse to force-push `main`/`master`** — a rewrite leaves the branch diverged and the reflex is to force it back; safe only where nobody else has based work on it.
|
||||
- **Never add `--no-verify`** — using it when a hook fails bypasses the QA gate the pipeline depends on. Only on the user's explicit demand, with a warning.
|
||||
|
||||
## Workflow
|
||||
## Dispatch
|
||||
|
||||
### For creating a new commit:
|
||||
Read exactly one flow file. Each is self-contained.
|
||||
|
||||
1. **Gather context** — what changed and why? (from staged changes, PR description, issue context). Verify the staged diff is one logical, atomic change and that the repo would still build/test at this commit — if not, suggest splitting before proceeding.
|
||||
2. **Check for secrets** — scan the staged diff for anything that looks like a credential, API key, token, or environment-specific config. Stop and flag it rather than committing.
|
||||
3. **Determine type** — is this a feature (`feat`), bug fix (`fix`), or other? Default: check the change itself.
|
||||
4. **Determine scope** — which system/module? Use scope from plugin config if set, otherwise infer from files changed.
|
||||
5. **Write description** — imperative mood, no period. Neither source spec sets a length target below the 100-char header max, but convention favors keeping it to ~50 characters where possible for `git log --oneline` readability. Examples: "add user authentication", "fix race condition in cache".
|
||||
6. **Add body if needed** — explain why (not what). Blank line before body, wrap at 100 chars. For non-trivial changes, follow the Why / Implementation Notes / Impact structure in `references/commit-template.md`.
|
||||
7. **Add footers if needed** — `Fixes: #123`, `Refs: #123`, `ADR: 0012`, `RFC: 0003`, `Design: <link>`, `Reviewed-by: Name`, `Co-authored-by: Name <email>`, `Signed-off-by: Name <email>`, `BREAKING CHANGE: description`. See `references/commit-template.md` for the full trailer list.
|
||||
8. **Validate** — check header length, type correctness, no trailing periods, lowercase.
|
||||
9. **Confirm and execute** — for agents, require explicit approval; for humans, show preview and ask. Never add `--no-verify` to skip hooks.
|
||||
| Condition | Flow | Read |
|
||||
|---|---|---|
|
||||
| Composing a new commit from staged changes | create | `references/create-commit.md` |
|
||||
| Amending, squashing, or folding a fixup into an earlier commit | rewrite | `references/rewrite-history.md` |
|
||||
| Replaying an existing commit onto the current branch | cherry-pick | `references/cherry-pick.md` |
|
||||
|
||||
### For amending a commit:
|
||||
## Gates on every flow
|
||||
|
||||
1. **Stage new changes** (or changes to undo)
|
||||
2. **Run amend operation** — executes `rtk git commit --amend [--no-edit]` based on user intent
|
||||
3. **Offer message edit** — if user wants to change commit message, show current message and prompt for new one
|
||||
4. **Confirm before force-push** — amending is only safe on non-shared branches; if the current branch is `main`/`master`, refuse to force-push and explain why rather than warning and proceeding
|
||||
1. **Confirmation.** No history rewrite executes without explicit approval from the user or the calling agent. Cherry-pick needs the destination branch confirmed first.
|
||||
2. **Secrets.** Before any commit or amend, scan the staged diff for anything resembling an API key,
|
||||
token, password, connection string, or environment-specific config. Stop and flag it rather than
|
||||
committing it.
|
||||
3. **Validation.** Check the message against commitlint `config-conventional` before committing. If a type, footer, or breaking-change edge case is not obvious, read `references/conventional-commits-spec.md` — it carries the constraint table, the 11-type set, and the footer token rules.
|
||||
4. **SemVer impact.** Report the bump the commit implies: `feat` → MINOR, `fix`/`perf`/`revert` → PATCH, any breaking change → MAJOR, everything else → none. Callers decide releases from this, so never omit it.
|
||||
5. **Conflicts.** If a rebase or cherry-pick halts, offer resolution or an abort. Do not resolve automatically without confirmation.
|
||||
|
||||
### For squashing commits (interactive rebase):
|
||||
## Output
|
||||
|
||||
1. **Identify commits to squash** — typically the last N commits on current branch
|
||||
2. **Confirm operation** — squashing rewrites history; get explicit approval
|
||||
3. **Execute rebase** — `rtk git rebase -i HEAD~N`, mark older commits as `squash` or `fixup`
|
||||
4. **Handle merge conflicts** — if rebase halts, offer conflict resolution options or abort; do not resolve automatically without confirmation
|
||||
5. **Offer message composition** — if squashing interactive, allow message editing
|
||||
|
||||
### For squashing commits (autosquash — preferred when tagging at commit time):
|
||||
|
||||
Prefer this over manual interactive rebase when a commit is written to be folded into an earlier one, since it removes the manual "mark as squash/fixup" step and the risk of reordering the wrong line:
|
||||
|
||||
1. **Create the fixup/squash commit** — `rtk git commit --fixup=<commit>` (keeps target's message) or `rtk git commit --squash=<commit>` (lets you edit the combined message later). Both prefix the message with `fixup!`/`squash!` and target `<commit>`.
|
||||
2. **Confirm operation** — rewriting history still requires explicit approval before the rebase runs.
|
||||
3. **Execute** — `rtk git rebase --autosquash HEAD~N` (or `-i --autosquash` to review the plan first); git reorders and marks the `fixup!`/`squash!` commits against their targets automatically.
|
||||
4. **Handle merge conflicts** — same as manual rebase: offer resolution or abort, never resolve automatically without confirmation.
|
||||
|
||||
### For cherry-picking:
|
||||
|
||||
1. **Identify source commit(s)** — hash or branch reference
|
||||
2. **Confirm destination branch** — cherry-pick will replay commits on current branch
|
||||
3. **Execute cherry-pick** — `rtk git cherry-pick <commit-hash>`
|
||||
4. **Handle conflicts** — offer conflict resolution or abort
|
||||
5. **Report outcome** — successful replays, conflicts, or rejected commits
|
||||
|
||||
## Output format (for agent consumption)
|
||||
|
||||
Return structured JSON:
|
||||
For an agent caller, return:
|
||||
|
||||
```json
|
||||
{
|
||||
"operation": "create|amend|squash|cherry-pick",
|
||||
"status": "success|conflict|rejected",
|
||||
"message": "Commit message or error description",
|
||||
"message": "commit message or error description",
|
||||
"commit_hash": "abc1234",
|
||||
"semver_impact": "MAJOR|MINOR|PATCH|none",
|
||||
"breaking_change": true|false,
|
||||
"confirmation_required": true|false,
|
||||
"details": {
|
||||
"type": "feat",
|
||||
"scope": "api",
|
||||
"description": "add user authentication",
|
||||
"body": "optional body text",
|
||||
"footers": ["Fixes: #123", "Refs: #456", "ADR: 0012", "Reviewed-by: Alice", "Co-authored-by: Bob <bob@example.com>", "Signed-off-by: Alice <alice@example.com>"]
|
||||
}
|
||||
"breaking_change": false,
|
||||
"confirmation_required": false,
|
||||
"details": { "type": "feat", "scope": "api", "description": "add user authentication" }
|
||||
}
|
||||
```
|
||||
|
||||
For interactive human use, format as readable prose with clear prompts and previews.
|
||||
|
||||
## Reference
|
||||
|
||||
If a footer or type/scope edge case isn't covered above, read `references/conventional-commits-spec.md` for the full specification.
|
||||
|
||||
For the Why / Implementation Notes / Impact body structure and the full trailer list, read `references/commit-template.md`.
|
||||
For a human caller, show the same fields as a prose preview with a confirmation prompt.
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
source_keys:
|
||||
- context7-git-htmldocs
|
||||
---
|
||||
|
||||
# Cherry-picking a commit
|
||||
|
||||
1. **Identify the source commit** — a hash or a branch reference.
|
||||
2. **Confirm the destination** — cherry-pick replays onto the branch currently checked out, so verify that is the intended branch before running anything.
|
||||
3. **Execute** — `rtk git cherry-pick <commit-hash>`. A range is `<a>..<b>` (exclusive of `<a>`) or `<a>^..<b>` (inclusive); `-n` stages without committing, for when the replay needs editing first.
|
||||
4. **Handle conflicts** — if the replay halts, offer resolution or `rtk git cherry-pick --abort`. Never resolve automatically without confirmation.
|
||||
5. **Report the outcome** — which commits replayed, which conflicted, and which were rejected.
|
||||
@@ -7,7 +7,7 @@ source_keys:
|
||||
|
||||
Use this structure for the body/footer of any non-trivial commit (skip sections that don't apply — do not leave placeholders in the actual commit).
|
||||
|
||||
```
|
||||
```text
|
||||
<type>(<scope>): <concise summary>
|
||||
```
|
||||
The header is required. Describe the intended outcome, not the implementation.
|
||||
@@ -53,7 +53,7 @@ Omit if there are no noteworthy impacts.
|
||||
|
||||
Structured metadata for traceability and tooling. Use only the trailers that apply:
|
||||
|
||||
```
|
||||
```text
|
||||
Fixes:
|
||||
Refs:
|
||||
ADR:
|
||||
|
||||
@@ -10,7 +10,7 @@ Conventional Commits is a lightweight convention on top of commit messages that
|
||||
|
||||
## Message Format
|
||||
|
||||
```
|
||||
```text
|
||||
<type>[optional scope]: <description>
|
||||
|
||||
[optional body]
|
||||
@@ -58,20 +58,20 @@ A `BREAKING CHANGE` footer or `!` on **any** type always triggers a MAJOR bump.
|
||||
Two equivalent notations:
|
||||
|
||||
**`!` in header** (preferred — visible in `git log --oneline`):
|
||||
```
|
||||
```text
|
||||
feat!: drop support for Node 6
|
||||
feat(api)!: remove deprecated endpoint
|
||||
```
|
||||
|
||||
**`BREAKING CHANGE` footer** (machine-readable body):
|
||||
```
|
||||
```text
|
||||
feat: allow config to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key now used for extending config files
|
||||
```
|
||||
|
||||
**Both together** (most explicit):
|
||||
```
|
||||
```text
|
||||
feat!: drop support for Node 6
|
||||
|
||||
BREAKING CHANGE: use JavaScript features not available in Node 6.
|
||||
@@ -85,7 +85,7 @@ Rules:
|
||||
|
||||
## Footer Token Rules
|
||||
|
||||
```
|
||||
```text
|
||||
<token>: <value>
|
||||
<token> #<value> # for issue references
|
||||
```
|
||||
@@ -96,7 +96,7 @@ Rules:
|
||||
- Blank line required before the footer block.
|
||||
|
||||
Valid footer examples:
|
||||
```
|
||||
```text
|
||||
Reviewed-by: Z
|
||||
Refs: #123
|
||||
Co-authored-by: Alice <alice@example.com>
|
||||
@@ -106,29 +106,29 @@ BREAKING CHANGE: the `--format` flag now requires a value
|
||||
## Examples
|
||||
|
||||
Minimal — no body, no footer:
|
||||
```
|
||||
```text
|
||||
docs: correct spelling of CHANGELOG
|
||||
```
|
||||
|
||||
With scope:
|
||||
```
|
||||
```text
|
||||
feat(lang): add Polish language
|
||||
```
|
||||
|
||||
Breaking change via `!`:
|
||||
```
|
||||
```text
|
||||
feat!: send an email to the customer when a product is shipped
|
||||
```
|
||||
|
||||
Breaking change via footer:
|
||||
```
|
||||
```text
|
||||
feat: allow provided config object to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||
```
|
||||
|
||||
Multi-paragraph body with multiple footers:
|
||||
```
|
||||
```text
|
||||
fix: prevent racing of requests
|
||||
|
||||
Introduce a request id and a reference to latest request. Dismiss
|
||||
@@ -142,7 +142,7 @@ Refs: #123
|
||||
```
|
||||
|
||||
Revert:
|
||||
```
|
||||
```text
|
||||
revert: let us never again speak of the noodle incident
|
||||
|
||||
Refs: 676104e, a215868
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
source_keys:
|
||||
- conventional-commits-spec
|
||||
- commitlint-config-conventional
|
||||
- org-commit-conventions
|
||||
---
|
||||
|
||||
# Creating a new commit
|
||||
|
||||
1. **Gather context** — what changed and why, from the staged diff, the PR description, or the issue. Confirm the staged diff is one logical, independently reviewable and reversible change that leaves the repository buildable and testable. If it bundles unrelated work, suggest splitting it before going further.
|
||||
2. **Determine the type** — read it off the change itself: a new user-visible feature is `feat`, a bug fix is `fix`. For the full 11-type set and each type's SemVer impact, read `references/conventional-commits-spec.md`.
|
||||
3. **Determine the scope** — use the scope from plugin config where one is set, otherwise infer it from the files changed (`api`, `db`, `cli`, `config`). Scope is optional, but it identifies which part of the system moved and is worth setting.
|
||||
4. **Write the description** — imperative mood, no trailing period: "add user authentication", "fix race condition in cache". Neither source spec sets a target below the 100-character header maximum, but convention favours roughly 50 characters so `git log --oneline` stays readable.
|
||||
5. **Add a body when the change is non-trivial** — blank line first, wrapped at 100 characters. Explain *why*, not what: the diff already shows what changed, and the message's job is the context the diff cannot carry — motivation, root cause, tradeoffs. Follow the Why / Implementation Notes / Impact structure in `references/commit-template.md`.
|
||||
6. **Add footers where they apply** — `Fixes: #123`, `Refs: #123`, `ADR: 0012`, `Co-authored-by: Name <email>`, `BREAKING CHANGE: description`. For the full trailer list, read `references/commit-template.md`.
|
||||
7. **Signal a breaking change with `!` before the colon** — `feat!: drop Node 6` is visible in `git log --oneline`, where the `BREAKING CHANGE:` footer alone is machine-readable but hidden. Use both when the break needs describing.
|
||||
8. **Validate, confirm, execute** — check header length, type, lowercase subject and trailing period against commitlint, show the message, and commit only once the caller has approved. Never add `--no-verify`.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
source_keys:
|
||||
- org-commit-conventions
|
||||
- context7-git-htmldocs
|
||||
---
|
||||
|
||||
# Rewriting existing commits
|
||||
|
||||
Every flow on this page rewrites history. None of them runs before the caller has explicitly approved it, and none is followed by a force-push to `main`/`master` — refuse that and explain why instead.
|
||||
|
||||
## Amend the last commit
|
||||
|
||||
1. Stage the new changes, or the changes that undo something.
|
||||
2. Run `rtk git commit --amend`, adding `--no-edit` when the message stays as it is.
|
||||
3. If the message should change, show the current one and prompt for the replacement.
|
||||
4. The branch has now diverged from its remote. Amending is safe only on a branch nobody else has based work on; on `main`/`master`, refuse the force-push and explain, rather than warning and proceeding.
|
||||
|
||||
## Fold a commit into an earlier one (autosquash — preferred)
|
||||
|
||||
Prefer this whenever a commit is written to be folded, because git does the marking:
|
||||
|
||||
1. `rtk git commit --fixup=<commit>` keeps the target's message; `rtk git commit --squash=<commit>` lets you edit the combined message later. Both prefix the message with `fixup!`/`squash!` and name the target commit.
|
||||
2. Get explicit approval — the rebase still rewrites history.
|
||||
3. Run `rtk git rebase --autosquash HEAD~N`, or `-i --autosquash` to review the plan first. Git reorders the tagged commits against their targets automatically.
|
||||
|
||||
## Squash by hand (interactive rebase)
|
||||
|
||||
Use this when the commits were not tagged at commit time. **Interactive rebase has no undo once `rebase -i` starts — `git reflog` is the recovery path.**
|
||||
|
||||
1. Identify the commits to squash — typically the last N on the current branch.
|
||||
2. Get explicit approval.
|
||||
3. Run `rtk git rebase -i HEAD~N`, marking the older commits `squash` to keep their messages for editing, or `fixup` to discard them.
|
||||
4. Compose the combined message when the rebase stops to ask. For a non-trivial combined message, follow the structure in `references/commit-template.md`.
|
||||
|
||||
## When a rebase halts on a conflict
|
||||
|
||||
Offer conflict resolution or `rtk git rebase --abort`. Do not resolve conflicts automatically without confirmation.
|
||||
@@ -7,34 +7,34 @@ source_keys:
|
||||
- context7-git-htmldocs
|
||||
---
|
||||
|
||||
# Research Sources for git:commits Skill
|
||||
# Research Sources for git-commits Skill
|
||||
|
||||
Sources extracted from the git plugin research phase. Only sources that directly informed this skill are listed; sibling skills (git:branches, git:history, git:remotes, etc.) have their own sources.md.
|
||||
Sources extracted from the git plugin research phase. Only sources that directly informed this skill are listed; sibling skills (git-branches, git-history, git-remotes, etc.) have their own sources.md.
|
||||
|
||||
## conventional-commits-spec
|
||||
|
||||
- **Description:** Conventional Commits Specification (v1.0.0) — message format, types, breaking changes, footer rules
|
||||
- **Research doc:** plugins/git/docs/research/docs/git/commits.md § "Conventional Commits Specification (v1.0.0)"
|
||||
- **Contributing files:** SKILL.md, references/conventional-commits-spec.md
|
||||
- **Contributing files:** SKILL.md, references/conventional-commits-spec.md, references/create-commit.md
|
||||
- **Status:** extracted
|
||||
|
||||
## commitlint-config-conventional
|
||||
|
||||
- **Description:** commitlint config-conventional preset — validation constraints (max 100 chars header, no trailing periods, lowercase type, 11-type set enforcement)
|
||||
- **Research doc:** plugins/git/docs/research/docs/git/commits.md § "commitlint Constraints (`config-conventional`)"
|
||||
- **Contributing files:** SKILL.md, references/conventional-commits-spec.md
|
||||
- **Contributing files:** SKILL.md, references/conventional-commits-spec.md, references/create-commit.md
|
||||
- **Status:** extracted
|
||||
|
||||
## org-commit-conventions
|
||||
|
||||
- **Description:** Organization commit message body template and git conventions (atomic commits, no `--no-verify`, no force-push main/master, `rtk git` wrapper) — content fully embedded in this skill; the org's `core/instructions/git.md` and `core/instructions/commits.md` are provenance only and are not a live dependency
|
||||
- **Research doc:** core/instructions/commits.md, core/instructions/git.md (org convention, not part of the plugin's research corpus)
|
||||
- **Contributing files:** SKILL.md, references/commit-template.md
|
||||
- **Contributing files:** SKILL.md, references/commit-template.md, references/create-commit.md, references/rewrite-history.md
|
||||
- **Status:** extracted
|
||||
|
||||
## context7-git-htmldocs
|
||||
|
||||
- **Description:** Official Git HTML documentation — `git commit --squash`/`--fixup` and `git rebase --autosquash` flag semantics
|
||||
- **Research doc:** plugins/git/docs/research/docs/git/cli-reference.md
|
||||
- **Contributing files:** SKILL.md
|
||||
- **Description:** Official Git HTML documentation — `git commit --squash`/`--fixup`, `git rebase --autosquash`, and `git cherry-pick` range and abort semantics
|
||||
- **Research doc:** plugins/git/docs/research/docs/git/cli-reference.md § "Committing", § "Rebasing", § "Cherry-picking"
|
||||
- **Contributing files:** SKILL.md, references/rewrite-history.md, references/cherry-pick.md
|
||||
- **Status:** extracted
|
||||
|
||||
@@ -16,9 +16,16 @@ Describe your commit task: create a new commit, amend, squash, or cherry-pick. T
|
||||
|
||||
## Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `SKILL.md` | Skill instructions for agents |
|
||||
| `references/conventional-commits-spec.md` | Full Conventional Commits specification |
|
||||
| `references/commit-template.md` | Why / Implementation Notes / Impact body structure and full trailer list |
|
||||
| File | Loaded when |
|
||||
|------|-------------|
|
||||
| `SKILL.md` | Always — gotchas, the flow dispatch table, the gates common to every flow, and the output shape |
|
||||
| `references/create-commit.md` | Composing a new commit from staged changes |
|
||||
| `references/rewrite-history.md` | Amending, squashing, or folding a `fixup!`/`squash!` commit into an earlier one |
|
||||
| `references/cherry-pick.md` | Replaying an existing commit onto the current branch |
|
||||
| `references/conventional-commits-spec.md` | A type, footer, or breaking-change edge case is not obvious — full spec, 11-type set, commitlint constraint table |
|
||||
| `references/commit-template.md` | Writing a body for a non-trivial commit — Why / Implementation Notes / Impact structure and the full trailer list |
|
||||
| `references/sources.md` | Research sources and provenance |
|
||||
|
||||
## Composition
|
||||
|
||||
Part of the git plugin's domain suite. This skill owns commit authoring and history-rewriting operations only; `git-history` inspects history, `git-branches` owns branch lifecycle, and `git-workflow` is the conversational entry point that routes between them.
|
||||
|
||||
@@ -2,16 +2,13 @@
|
||||
name: git-commits
|
||||
|
||||
description: >
|
||||
Use when creating, amending, squashing, or cherry-picking commits.
|
||||
Generates well-formatted commit messages following Conventional Commits spec (type, scope, description, body, footers).
|
||||
Validates against commitlint config-conventional constraints (header max 100 chars, lowercase subject, no trailing periods, type must be one of 11 standard types).
|
||||
Communicates SemVer impact (MAJOR for breaking changes, MINOR for features, PATCH for fixes).
|
||||
Handles confirmation gates for history-altering operations (amend, rebase, squash).
|
||||
Provides interactive guidance for humans, structured JSON output for agents.
|
||||
Do not use for: inspecting git history, branch management, or repository state inspection — those are separate skills.
|
||||
Use when creating, amending, squashing, or cherry-picking commits, including
|
||||
writing and validating the Conventional Commits message.
|
||||
Not history inspection -> `git-history`.
|
||||
Not branch lifecycle -> `git-branches`.
|
||||
|
||||
metadata:
|
||||
version: "0.1.2"
|
||||
version: "0.1.3"
|
||||
category: git
|
||||
source_keys:
|
||||
- conventional-commits-spec
|
||||
@@ -24,92 +21,45 @@ allowed-tools: Bash
|
||||
|
||||
## Gotchas
|
||||
|
||||
- **Type must be one of 11 standard types** — `feat`, `fix`, `perf`, `revert`, `docs`, `style`, `refactor`, `test`, `build`, `ci`, `chore`. Non-standard types will fail commitlint validation. Note: the Conventional Commits spec itself only mandates `feat`/`fix` — the 11-type set is a commitlint/Angular convention this skill validates against, not a spec requirement.
|
||||
- **Scope is optional but should be used** — helps identify which part of the system changed. Examples: `api`, `db`, `cli`, `config`.
|
||||
- **Header max 100 characters** — type + scope + colon + description must fit. If longer, move detail to body.
|
||||
- **BREAKING CHANGE notation** — use `!` before the colon (`feat!: drop Node 6`) for visibility in `git log --oneline`. Footer notation (`BREAKING CHANGE: ...`) is machine-readable but hidden in log.
|
||||
- **SemVer mapping is not optional** — agents must communicate: `feat` → MINOR bump, `fix`/`perf`/`revert` → PATCH, any with breaking change → MAJOR.
|
||||
- **Confirmation gates are mandatory for destructive operations** — amend, rebase, squash require explicit user/agent approval before execution.
|
||||
- **Never skip hooks with `--no-verify`** — hooks are the automated QA gate; bypassing them breaks the pipeline. Do not add this flag to any commit command unless the user explicitly demands it, and warn them if they do.
|
||||
- **Never force-push `main`/`master`** — even after an amend or interactive rebase, refuse to force-push a protected branch (`main`, `master`) and explain why; force-push is only safe on branches no one else has based work on.
|
||||
- **Command examples use the `rtk git` wrapper** — this org's convention routes all git invocations through `rtk git <subcommand>` instead of bare `git <subcommand>`. Follow this prefix in any command you actually run.
|
||||
- **Never commit secrets, credentials, or environment-specific config** — if staged changes contain what looks like an API key, token, password, or connection string, stop and flag it before committing rather than committing it.
|
||||
- **Commits must be atomic and leave the repo working** — each commit should be one logical, independently reviewable and reversible change, and should leave the repository in a buildable/testable state. If staged changes bundle unrelated work, suggest splitting before committing.
|
||||
- **Commit messages explain why, not what** — the diff already shows what changed; the message's job is to capture context the diff can't (motivation, root cause, tradeoffs). See `references/commit-template.md` for the structure this maps to.
|
||||
- **Run git as `rtk git <subcommand>`, never bare `git`** — org convention, in `&&` chains too.
|
||||
- **Refuse to force-push `main`/`master`** — a rewrite leaves the branch diverged and the reflex is to force it back; safe only where nobody else has based work on it.
|
||||
- **Never add `--no-verify`** — using it when a hook fails bypasses the QA gate the pipeline depends on. Only on the user's explicit demand, with a warning.
|
||||
|
||||
## Workflow
|
||||
## Dispatch
|
||||
|
||||
### For creating a new commit:
|
||||
Read exactly one flow file. Each is self-contained.
|
||||
|
||||
1. **Gather context** — what changed and why? (from staged changes, PR description, issue context). Verify the staged diff is one logical, atomic change and that the repo would still build/test at this commit — if not, suggest splitting before proceeding.
|
||||
2. **Check for secrets** — scan the staged diff for anything that looks like a credential, API key, token, or environment-specific config. Stop and flag it rather than committing.
|
||||
3. **Determine type** — is this a feature (`feat`), bug fix (`fix`), or other? Default: check the change itself.
|
||||
4. **Determine scope** — which system/module? Use scope from plugin config if set, otherwise infer from files changed.
|
||||
5. **Write description** — imperative mood, no period. Neither source spec sets a length target below the 100-char header max, but convention favors keeping it to ~50 characters where possible for `git log --oneline` readability. Examples: "add user authentication", "fix race condition in cache".
|
||||
6. **Add body if needed** — explain why (not what). Blank line before body, wrap at 100 chars. For non-trivial changes, follow the Why / Implementation Notes / Impact structure in `references/commit-template.md`.
|
||||
7. **Add footers if needed** — `Fixes: #123`, `Refs: #123`, `ADR: 0012`, `RFC: 0003`, `Design: <link>`, `Reviewed-by: Name`, `Co-authored-by: Name <email>`, `Signed-off-by: Name <email>`, `BREAKING CHANGE: description`. See `references/commit-template.md` for the full trailer list.
|
||||
8. **Validate** — check header length, type correctness, no trailing periods, lowercase.
|
||||
9. **Confirm and execute** — for agents, require explicit approval; for humans, show preview and ask. Never add `--no-verify` to skip hooks.
|
||||
| Condition | Flow | Read |
|
||||
|---|---|---|
|
||||
| Composing a new commit from staged changes | create | `references/create-commit.md` |
|
||||
| Amending, squashing, or folding a fixup into an earlier commit | rewrite | `references/rewrite-history.md` |
|
||||
| Replaying an existing commit onto the current branch | cherry-pick | `references/cherry-pick.md` |
|
||||
|
||||
### For amending a commit:
|
||||
## Gates on every flow
|
||||
|
||||
1. **Stage new changes** (or changes to undo)
|
||||
2. **Run amend operation** — executes `rtk git commit --amend [--no-edit]` based on user intent
|
||||
3. **Offer message edit** — if user wants to change commit message, show current message and prompt for new one
|
||||
4. **Confirm before force-push** — amending is only safe on non-shared branches; if the current branch is `main`/`master`, refuse to force-push and explain why rather than warning and proceeding
|
||||
1. **Confirmation.** No history rewrite executes without explicit approval from the user or the calling agent. Cherry-pick needs the destination branch confirmed first.
|
||||
2. **Secrets.** Before any commit or amend, scan the staged diff for anything resembling an API key,
|
||||
token, password, connection string, or environment-specific config. Stop and flag it rather than
|
||||
committing it.
|
||||
3. **Validation.** Check the message against commitlint `config-conventional` before committing. If a type, footer, or breaking-change edge case is not obvious, read `references/conventional-commits-spec.md` — it carries the constraint table, the 11-type set, and the footer token rules.
|
||||
4. **SemVer impact.** Report the bump the commit implies: `feat` → MINOR, `fix`/`perf`/`revert` → PATCH, any breaking change → MAJOR, everything else → none. Callers decide releases from this, so never omit it.
|
||||
5. **Conflicts.** If a rebase or cherry-pick halts, offer resolution or an abort. Do not resolve automatically without confirmation.
|
||||
|
||||
### For squashing commits (interactive rebase):
|
||||
## Output
|
||||
|
||||
1. **Identify commits to squash** — typically the last N commits on current branch
|
||||
2. **Confirm operation** — squashing rewrites history; get explicit approval
|
||||
3. **Execute rebase** — `rtk git rebase -i HEAD~N`, mark older commits as `squash` or `fixup`
|
||||
4. **Handle merge conflicts** — if rebase halts, offer conflict resolution options or abort; do not resolve automatically without confirmation
|
||||
5. **Offer message composition** — if squashing interactive, allow message editing
|
||||
|
||||
### For squashing commits (autosquash — preferred when tagging at commit time):
|
||||
|
||||
Prefer this over manual interactive rebase when a commit is written to be folded into an earlier one, since it removes the manual "mark as squash/fixup" step and the risk of reordering the wrong line:
|
||||
|
||||
1. **Create the fixup/squash commit** — `rtk git commit --fixup=<commit>` (keeps target's message) or `rtk git commit --squash=<commit>` (lets you edit the combined message later). Both prefix the message with `fixup!`/`squash!` and target `<commit>`.
|
||||
2. **Confirm operation** — rewriting history still requires explicit approval before the rebase runs.
|
||||
3. **Execute** — `rtk git rebase --autosquash HEAD~N` (or `-i --autosquash` to review the plan first); git reorders and marks the `fixup!`/`squash!` commits against their targets automatically.
|
||||
4. **Handle merge conflicts** — same as manual rebase: offer resolution or abort, never resolve automatically without confirmation.
|
||||
|
||||
### For cherry-picking:
|
||||
|
||||
1. **Identify source commit(s)** — hash or branch reference
|
||||
2. **Confirm destination branch** — cherry-pick will replay commits on current branch
|
||||
3. **Execute cherry-pick** — `rtk git cherry-pick <commit-hash>`
|
||||
4. **Handle conflicts** — offer conflict resolution or abort
|
||||
5. **Report outcome** — successful replays, conflicts, or rejected commits
|
||||
|
||||
## Output format (for agent consumption)
|
||||
|
||||
Return structured JSON:
|
||||
For an agent caller, return:
|
||||
|
||||
```json
|
||||
{
|
||||
"operation": "create|amend|squash|cherry-pick",
|
||||
"status": "success|conflict|rejected",
|
||||
"message": "Commit message or error description",
|
||||
"message": "commit message or error description",
|
||||
"commit_hash": "abc1234",
|
||||
"semver_impact": "MAJOR|MINOR|PATCH|none",
|
||||
"breaking_change": true|false,
|
||||
"confirmation_required": true|false,
|
||||
"details": {
|
||||
"type": "feat",
|
||||
"scope": "api",
|
||||
"description": "add user authentication",
|
||||
"body": "optional body text",
|
||||
"footers": ["Fixes: #123", "Refs: #456", "ADR: 0012", "Reviewed-by: Alice", "Co-authored-by: Bob <bob@example.com>", "Signed-off-by: Alice <alice@example.com>"]
|
||||
}
|
||||
"breaking_change": false,
|
||||
"confirmation_required": false,
|
||||
"details": { "type": "feat", "scope": "api", "description": "add user authentication" }
|
||||
}
|
||||
```
|
||||
|
||||
For interactive human use, format as readable prose with clear prompts and previews.
|
||||
|
||||
## Reference
|
||||
|
||||
If a footer or type/scope edge case isn't covered above, read `references/conventional-commits-spec.md` for the full specification.
|
||||
|
||||
For the Why / Implementation Notes / Impact body structure and the full trailer list, read `references/commit-template.md`.
|
||||
For a human caller, show the same fields as a prose preview with a confirmation prompt.
|
||||
|
||||
12
plugins/git/skills/git-commits/references/cherry-pick.md
Normal file
12
plugins/git/skills/git-commits/references/cherry-pick.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
source_keys:
|
||||
- context7-git-htmldocs
|
||||
---
|
||||
|
||||
# Cherry-picking a commit
|
||||
|
||||
1. **Identify the source commit** — a hash or a branch reference.
|
||||
2. **Confirm the destination** — cherry-pick replays onto the branch currently checked out, so verify that is the intended branch before running anything.
|
||||
3. **Execute** — `rtk git cherry-pick <commit-hash>`. A range is `<a>..<b>` (exclusive of `<a>`) or `<a>^..<b>` (inclusive); `-n` stages without committing, for when the replay needs editing first.
|
||||
4. **Handle conflicts** — if the replay halts, offer resolution or `rtk git cherry-pick --abort`. Never resolve automatically without confirmation.
|
||||
5. **Report the outcome** — which commits replayed, which conflicted, and which were rejected.
|
||||
@@ -7,7 +7,7 @@ source_keys:
|
||||
|
||||
Use this structure for the body/footer of any non-trivial commit (skip sections that don't apply — do not leave placeholders in the actual commit).
|
||||
|
||||
```
|
||||
```text
|
||||
<type>(<scope>): <concise summary>
|
||||
```
|
||||
The header is required. Describe the intended outcome, not the implementation.
|
||||
@@ -53,7 +53,7 @@ Omit if there are no noteworthy impacts.
|
||||
|
||||
Structured metadata for traceability and tooling. Use only the trailers that apply:
|
||||
|
||||
```
|
||||
```text
|
||||
Fixes:
|
||||
Refs:
|
||||
ADR:
|
||||
|
||||
@@ -10,7 +10,7 @@ Conventional Commits is a lightweight convention on top of commit messages that
|
||||
|
||||
## Message Format
|
||||
|
||||
```
|
||||
```text
|
||||
<type>[optional scope]: <description>
|
||||
|
||||
[optional body]
|
||||
@@ -58,20 +58,20 @@ A `BREAKING CHANGE` footer or `!` on **any** type always triggers a MAJOR bump.
|
||||
Two equivalent notations:
|
||||
|
||||
**`!` in header** (preferred — visible in `git log --oneline`):
|
||||
```
|
||||
```text
|
||||
feat!: drop support for Node 6
|
||||
feat(api)!: remove deprecated endpoint
|
||||
```
|
||||
|
||||
**`BREAKING CHANGE` footer** (machine-readable body):
|
||||
```
|
||||
```text
|
||||
feat: allow config to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key now used for extending config files
|
||||
```
|
||||
|
||||
**Both together** (most explicit):
|
||||
```
|
||||
```text
|
||||
feat!: drop support for Node 6
|
||||
|
||||
BREAKING CHANGE: use JavaScript features not available in Node 6.
|
||||
@@ -85,7 +85,7 @@ Rules:
|
||||
|
||||
## Footer Token Rules
|
||||
|
||||
```
|
||||
```text
|
||||
<token>: <value>
|
||||
<token> #<value> # for issue references
|
||||
```
|
||||
@@ -96,7 +96,7 @@ Rules:
|
||||
- Blank line required before the footer block.
|
||||
|
||||
Valid footer examples:
|
||||
```
|
||||
```text
|
||||
Reviewed-by: Z
|
||||
Refs: #123
|
||||
Co-authored-by: Alice <alice@example.com>
|
||||
@@ -106,29 +106,29 @@ BREAKING CHANGE: the `--format` flag now requires a value
|
||||
## Examples
|
||||
|
||||
Minimal — no body, no footer:
|
||||
```
|
||||
```text
|
||||
docs: correct spelling of CHANGELOG
|
||||
```
|
||||
|
||||
With scope:
|
||||
```
|
||||
```text
|
||||
feat(lang): add Polish language
|
||||
```
|
||||
|
||||
Breaking change via `!`:
|
||||
```
|
||||
```text
|
||||
feat!: send an email to the customer when a product is shipped
|
||||
```
|
||||
|
||||
Breaking change via footer:
|
||||
```
|
||||
```text
|
||||
feat: allow provided config object to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||
```
|
||||
|
||||
Multi-paragraph body with multiple footers:
|
||||
```
|
||||
```text
|
||||
fix: prevent racing of requests
|
||||
|
||||
Introduce a request id and a reference to latest request. Dismiss
|
||||
@@ -142,7 +142,7 @@ Refs: #123
|
||||
```
|
||||
|
||||
Revert:
|
||||
```
|
||||
```text
|
||||
revert: let us never again speak of the noodle incident
|
||||
|
||||
Refs: 676104e, a215868
|
||||
|
||||
17
plugins/git/skills/git-commits/references/create-commit.md
Normal file
17
plugins/git/skills/git-commits/references/create-commit.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
source_keys:
|
||||
- conventional-commits-spec
|
||||
- commitlint-config-conventional
|
||||
- org-commit-conventions
|
||||
---
|
||||
|
||||
# Creating a new commit
|
||||
|
||||
1. **Gather context** — what changed and why, from the staged diff, the PR description, or the issue. Confirm the staged diff is one logical, independently reviewable and reversible change that leaves the repository buildable and testable. If it bundles unrelated work, suggest splitting it before going further.
|
||||
2. **Determine the type** — read it off the change itself: a new user-visible feature is `feat`, a bug fix is `fix`. For the full 11-type set and each type's SemVer impact, read `references/conventional-commits-spec.md`.
|
||||
3. **Determine the scope** — use the scope from plugin config where one is set, otherwise infer it from the files changed (`api`, `db`, `cli`, `config`). Scope is optional, but it identifies which part of the system moved and is worth setting.
|
||||
4. **Write the description** — imperative mood, no trailing period: "add user authentication", "fix race condition in cache". Neither source spec sets a target below the 100-character header maximum, but convention favours roughly 50 characters so `git log --oneline` stays readable.
|
||||
5. **Add a body when the change is non-trivial** — blank line first, wrapped at 100 characters. Explain *why*, not what: the diff already shows what changed, and the message's job is the context the diff cannot carry — motivation, root cause, tradeoffs. Follow the Why / Implementation Notes / Impact structure in `references/commit-template.md`.
|
||||
6. **Add footers where they apply** — `Fixes: #123`, `Refs: #123`, `ADR: 0012`, `Co-authored-by: Name <email>`, `BREAKING CHANGE: description`. For the full trailer list, read `references/commit-template.md`.
|
||||
7. **Signal a breaking change with `!` before the colon** — `feat!: drop Node 6` is visible in `git log --oneline`, where the `BREAKING CHANGE:` footer alone is machine-readable but hidden. Use both when the break needs describing.
|
||||
8. **Validate, confirm, execute** — check header length, type, lowercase subject and trailing period against commitlint, show the message, and commit only once the caller has approved. Never add `--no-verify`.
|
||||
37
plugins/git/skills/git-commits/references/rewrite-history.md
Normal file
37
plugins/git/skills/git-commits/references/rewrite-history.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
source_keys:
|
||||
- org-commit-conventions
|
||||
- context7-git-htmldocs
|
||||
---
|
||||
|
||||
# Rewriting existing commits
|
||||
|
||||
Every flow on this page rewrites history. None of them runs before the caller has explicitly approved it, and none is followed by a force-push to `main`/`master` — refuse that and explain why instead.
|
||||
|
||||
## Amend the last commit
|
||||
|
||||
1. Stage the new changes, or the changes that undo something.
|
||||
2. Run `rtk git commit --amend`, adding `--no-edit` when the message stays as it is.
|
||||
3. If the message should change, show the current one and prompt for the replacement.
|
||||
4. The branch has now diverged from its remote. Amending is safe only on a branch nobody else has based work on; on `main`/`master`, refuse the force-push and explain, rather than warning and proceeding.
|
||||
|
||||
## Fold a commit into an earlier one (autosquash — preferred)
|
||||
|
||||
Prefer this whenever a commit is written to be folded, because git does the marking:
|
||||
|
||||
1. `rtk git commit --fixup=<commit>` keeps the target's message; `rtk git commit --squash=<commit>` lets you edit the combined message later. Both prefix the message with `fixup!`/`squash!` and name the target commit.
|
||||
2. Get explicit approval — the rebase still rewrites history.
|
||||
3. Run `rtk git rebase --autosquash HEAD~N`, or `-i --autosquash` to review the plan first. Git reorders the tagged commits against their targets automatically.
|
||||
|
||||
## Squash by hand (interactive rebase)
|
||||
|
||||
Use this when the commits were not tagged at commit time. **Interactive rebase has no undo once `rebase -i` starts — `git reflog` is the recovery path.**
|
||||
|
||||
1. Identify the commits to squash — typically the last N on the current branch.
|
||||
2. Get explicit approval.
|
||||
3. Run `rtk git rebase -i HEAD~N`, marking the older commits `squash` to keep their messages for editing, or `fixup` to discard them.
|
||||
4. Compose the combined message when the rebase stops to ask. For a non-trivial combined message, follow the structure in `references/commit-template.md`.
|
||||
|
||||
## When a rebase halts on a conflict
|
||||
|
||||
Offer conflict resolution or `rtk git rebase --abort`. Do not resolve conflicts automatically without confirmation.
|
||||
@@ -7,34 +7,34 @@ source_keys:
|
||||
- context7-git-htmldocs
|
||||
---
|
||||
|
||||
# Research Sources for git:commits Skill
|
||||
# Research Sources for git-commits Skill
|
||||
|
||||
Sources extracted from the git plugin research phase. Only sources that directly informed this skill are listed; sibling skills (git:branches, git:history, git:remotes, etc.) have their own sources.md.
|
||||
Sources extracted from the git plugin research phase. Only sources that directly informed this skill are listed; sibling skills (git-branches, git-history, git-remotes, etc.) have their own sources.md.
|
||||
|
||||
## conventional-commits-spec
|
||||
|
||||
- **Description:** Conventional Commits Specification (v1.0.0) — message format, types, breaking changes, footer rules
|
||||
- **Research doc:** plugins/git/docs/research/docs/git/commits.md § "Conventional Commits Specification (v1.0.0)"
|
||||
- **Contributing files:** SKILL.md, references/conventional-commits-spec.md
|
||||
- **Contributing files:** SKILL.md, references/conventional-commits-spec.md, references/create-commit.md
|
||||
- **Status:** extracted
|
||||
|
||||
## commitlint-config-conventional
|
||||
|
||||
- **Description:** commitlint config-conventional preset — validation constraints (max 100 chars header, no trailing periods, lowercase type, 11-type set enforcement)
|
||||
- **Research doc:** plugins/git/docs/research/docs/git/commits.md § "commitlint Constraints (`config-conventional`)"
|
||||
- **Contributing files:** SKILL.md, references/conventional-commits-spec.md
|
||||
- **Contributing files:** SKILL.md, references/conventional-commits-spec.md, references/create-commit.md
|
||||
- **Status:** extracted
|
||||
|
||||
## org-commit-conventions
|
||||
|
||||
- **Description:** Organization commit message body template and git conventions (atomic commits, no `--no-verify`, no force-push main/master, `rtk git` wrapper) — content fully embedded in this skill; the org's `core/instructions/git.md` and `core/instructions/commits.md` are provenance only and are not a live dependency
|
||||
- **Research doc:** core/instructions/commits.md, core/instructions/git.md (org convention, not part of the plugin's research corpus)
|
||||
- **Contributing files:** SKILL.md, references/commit-template.md
|
||||
- **Contributing files:** SKILL.md, references/commit-template.md, references/create-commit.md, references/rewrite-history.md
|
||||
- **Status:** extracted
|
||||
|
||||
## context7-git-htmldocs
|
||||
|
||||
- **Description:** Official Git HTML documentation — `git commit --squash`/`--fixup` and `git rebase --autosquash` flag semantics
|
||||
- **Research doc:** plugins/git/docs/research/docs/git/cli-reference.md
|
||||
- **Contributing files:** SKILL.md
|
||||
- **Description:** Official Git HTML documentation — `git commit --squash`/`--fixup`, `git rebase --autosquash`, and `git cherry-pick` range and abort semantics
|
||||
- **Research doc:** plugins/git/docs/research/docs/git/cli-reference.md § "Committing", § "Rebasing", § "Cherry-picking"
|
||||
- **Contributing files:** SKILL.md, references/rewrite-history.md, references/cherry-pick.md
|
||||
- **Status:** extracted
|
||||
|
||||
Reference in New Issue
Block a user