docs: trim repeated boilerplate in git, gitea, and bin skills
Finding 13: five blocks of near-identical wording were repeated across skills within a plugin — the gitea "resolve owner and repo" step (5 skills), the 404-masks-403 note (6 files), the manual pagination explanation (8 files), the git plugin's main/master force-push refusal (7 files, some with multiple internal restatements), and the bin skills' domain-glossary/ADR paragraph (5 skills). Tightened each instance in place — same meaning, fewer words — rather than extracting to a shared file, which ADR-0014's one-file-per-skill install constraint rules out. Left the three git skills' structured-result JSON shapes alone (coupled to the separate, out-of-scope git-orchestrate merge candidate, finding 19). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YR2CjVumUbEGWcMikcoXBD
This commit is contained in:
@@ -5,14 +5,14 @@ description: >
|
||||
broken, throwing, or failing, or says something got slow. Not filing or
|
||||
triaging a reported bug -> `triage`. Not test-first feature work -> `tdd`.
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
# Diagnose
|
||||
|
||||
A discipline for hard bugs. Skip phases only when explicitly justified.
|
||||
|
||||
When exploring the codebase, use the project's domain glossary to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
|
||||
When exploring the codebase, use the domain glossary for a clear mental model of the relevant modules, and check ADRs in the area.
|
||||
|
||||
## Phase 1 — Build a feedback loop
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ description: >
|
||||
into deep ones, informed by `CONTEXT.md` and `docs/adr/`. Not debugging a
|
||||
failure -> `diagnose`.
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
# Improve Codebase Architecture
|
||||
@@ -41,7 +41,7 @@ This skill is _informed_ by the project's domain model. The domain language give
|
||||
|
||||
### 1. Explore
|
||||
|
||||
Read the project's domain glossary and any ADRs in the area you're touching first.
|
||||
Read the domain glossary and any ADRs in the area first.
|
||||
|
||||
Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ description: >
|
||||
red-green-refactor loop, one behaviour at a time. Not diagnosing an existing
|
||||
bug -> `diagnose`. Not throwaway exploratory code -> `prototype`.
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
# Test-Driven Development
|
||||
@@ -49,7 +49,7 @@ RIGHT (vertical):
|
||||
|
||||
### 1. Planning
|
||||
|
||||
When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.
|
||||
When exploring the codebase, use the domain glossary so test names and interface vocabulary match the project's language, and respect ADRs in the area.
|
||||
|
||||
Before writing any code:
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ description: >
|
||||
tracker's triage states, or an issue prepared for an AFK agent. Not debugging
|
||||
the bug itself -> `diagnose`. Not fleshing out a design -> `grill-with-docs`.
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
# Triage
|
||||
@@ -65,7 +65,7 @@ Show counts and a one-line summary per issue. Let the maintainer pick.
|
||||
|
||||
## Triage a specific issue
|
||||
|
||||
1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
|
||||
1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
|
||||
|
||||
2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ name: zoom-out
|
||||
description: Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.
|
||||
disable-model-invocation: true
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary vocabulary.
|
||||
I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary.
|
||||
|
||||
@@ -5,14 +5,14 @@ description: >
|
||||
broken, throwing, or failing, or says something got slow. Not filing or
|
||||
triaging a reported bug -> `triage`. Not test-first feature work -> `tdd`.
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
# Diagnose
|
||||
|
||||
A discipline for hard bugs. Skip phases only when explicitly justified.
|
||||
|
||||
When exploring the codebase, use the project's domain glossary to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
|
||||
When exploring the codebase, use the domain glossary for a clear mental model of the relevant modules, and check ADRs in the area.
|
||||
|
||||
## Phase 1 — Build a feedback loop
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ description: >
|
||||
into deep ones, informed by `CONTEXT.md` and `docs/adr/`. Not debugging a
|
||||
failure -> `diagnose`.
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
# Improve Codebase Architecture
|
||||
@@ -41,7 +41,7 @@ This skill is _informed_ by the project's domain model. The domain language give
|
||||
|
||||
### 1. Explore
|
||||
|
||||
Read the project's domain glossary and any ADRs in the area you're touching first.
|
||||
Read the domain glossary and any ADRs in the area first.
|
||||
|
||||
Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ description: >
|
||||
red-green-refactor loop, one behaviour at a time. Not diagnosing an existing
|
||||
bug -> `diagnose`. Not throwaway exploratory code -> `prototype`.
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
# Test-Driven Development
|
||||
@@ -49,7 +49,7 @@ RIGHT (vertical):
|
||||
|
||||
### 1. Planning
|
||||
|
||||
When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.
|
||||
When exploring the codebase, use the domain glossary so test names and interface vocabulary match the project's language, and respect ADRs in the area.
|
||||
|
||||
Before writing any code:
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ description: >
|
||||
tracker's triage states, or an issue prepared for an AFK agent. Not debugging
|
||||
the bug itself -> `diagnose`. Not fleshing out a design -> `grill-with-docs`.
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
# Triage
|
||||
@@ -65,7 +65,7 @@ Show counts and a one-line summary per issue. Let the maintainer pick.
|
||||
|
||||
## Triage a specific issue
|
||||
|
||||
1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
|
||||
1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
|
||||
|
||||
2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ name: zoom-out
|
||||
description: Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.
|
||||
disable-model-invocation: true
|
||||
metadata:
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
---
|
||||
|
||||
I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary vocabulary.
|
||||
I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary.
|
||||
|
||||
Reference in New Issue
Block a user