@@ -3,8 +3,6 @@ name: agents-md-review
 description: Audit an existing AGENTS.md or CLAUDE.md line by line for wrong, stale, discoverable, duplicated, or content-free guidance and propose the pruned file. Use when asked to review, prune, shrink, or clean up one.
 ---
 
-# AGENTS.md review
-
 Verdicts apply the test in `agents-md`: more than one cheap feedback round to discover and fix, and stated in no skill or always-read file.
 
 ## Verify, then classify
@@ -20,6 +18,8 @@ Check each block against reality before judging it; one piece of evidence per ve
 - Rules against the installed skills and always-read files: **Duplicated**.
 - Everything else against the test above: **Discoverable**, **Content-free**, or **Plain command**.
 - An always-loaded pointer to a long guide: **Misplaced**; it belongs in the skill that needs it.
+- Opening banners against the file location and body: **Content-free** when they add no context, because the scope or purpose is already stated.
+  Keep headings that organize the rules or add context.
 
 A block can earn more than one verdict, each with its own evidence; lead with the one that needs no human confirmation, so pruning can start before the maintainer answers.
 
 
@@ -3,8 +3,6 @@ name: agents-md
 description: Discipline for writing and updating AGENTS.md (or CLAUDE.md) so it holds only what an agent cannot infer - policy, gotchas, and pointers - and stays under about 40 lines. Use instead of /init when creating, editing, or adapting one.
 ---
 
-# AGENTS.md
-
 `AGENTS.md` is loaded on every task, so every line is a cost paid everywhere.
 Measured on real repositories (arXiv 2602.11988): developer-written files raised resolve rate about 4% and cost about 20%; LLM-generated files lowered resolve rate; repository overviews did not help.
 What helped agents was locating the right place to change, not writing better patches.
@@ -31,6 +29,9 @@ Put positively: there is no way the agent learns this unless we write it.
 What `/init` generates is the blacklist: product overview, directory map, command lists, "follow standard conventions", inventories of packages or scopes, and lossy summaries of `STYLE.md`.
 Examples without the rule behind them are the costliest lines; agents copy the example, mistakes included.
 
+Omit an opening banner that only repeats the repository, path, or body context, because it adds no guidance.
+Keep headings that organize the rules or add context.
+
 ## Division of labour
 
 ```text
 
@@ -3,8 +3,6 @@ name: blind-testsuite
 description: Write or extend a conformance suite from a CONTRACT*.md and published sources only, by an author who never sees an implementation, kept read-only while implementations are built against it. Use when a contract has or will have several implementations, or a wrong expected value would be invisible to the implementer, as in cryptography, codecs, and wire protocols.
 ---
 
-# Blind test suite
-
 The suite is independent evidence derived from the contract, not the definition of conformance, so a failing test says the implementation or the test is wrong, never the contract.
 `test-writer` decides each test's shape and `test-oracle-reviewer` what counts as an independent value; this skill is the isolation around them.
 
 
@@ -3,8 +3,6 @@ name: code-compressor
 description: Aggressively review changed code for unnecessary complexity and propose smaller, clearer, behavior-preserving alternatives. Use for code reviews, refactor assessments, or any diff where simplification, deletion, reuse, flatter control flow, or fewer abstractions may improve the implementation.
 ---
 
-# Code compressor
-
 Treat every added branch, state, abstraction, helper, conversion, and dependency as complexity that must earn its place.
 Look for duplicated logic, speculative generality, needless indirection, over-modeled state, tangled control flow, verbose data transformations, and code that existing APIs can replace.
 
 
@@ -3,8 +3,6 @@ name: commit-and-pr-conventions
 description: Follow the adopted commit and pull-request conventions. Use whenever creating a commit or opening, editing, reviewing, or preparing to squash-merge a PR, including requests to commit, push, or open a PR.
 ---
 
-# Commit and PR conventions
-
 Treat the PR title and initial body as the exact commit message that squash-and-merge will land.
 
 ## Commit message
@@ -38,6 +36,6 @@ Issue: PROJECT-123
 - Do not manually wrap the PR body; GitHub handles display wrapping.
 - Keep permanent history concise: record motivation, material behavior, and side effects.
 - Put experiments, alternatives, extensive validation, and implementation chronology in follow-up comments.
-- Post a follow-up comment with the lines changed, split at least into production code, tests, and other files, so a reviewer sees where the change's weight lies before reading it; how to count and present them is yours, and refresh it when the diff changes materially.
+- Post a follow-up comment with the lines changed, split at least into production code (what ships to users), tests, and other files, with CI, build scripts, and developer tooling counted as other files, so a reviewer sees where the change's weight lies before reading it; how to count and present them is yours, and refresh it when the diff changes materially.
 - Update the title and initial body as the implementation evolves.
 - Before opening, updating, or merging, read `title + blank line + body` as one commit message and correct any mismatch.
@@ -3,8 +3,6 @@ name: contract-authoring
 description: Author or extend a normative CONTRACT*.md - an exact, testable specification of an interface, protocol, or provider boundary that independent implementations and a conformance suite derive from. Use when designing a spec, contract, protocol document, or provider API that several components or backends must agree on.
 ---
 
-# Contract authoring
-
 A contract defines a surface that two independently built parties must agree on: a backend author implements from it alone, and the conformance suite derives its expectations from it and the standards it cites, never from an implementation.
 It names the parties in scope without schedule ("e.g.: Product A, Product B", not "A now, B later"), since a release stage is not a rule a party agrees to, and a statement belongs only if one of them must agree to it.
 Of a party's own realisation (`intent-files`), only the parts a named second party depends on enter.
 
@@ -3,8 +3,6 @@ name: contract-review
 description: Review a normative CONTRACT*.md for overreach, unspecified failure paths, duplicated lists, examples standing in for rules, one-implementation bias, and untestable wording; returns findings with proposed rewordings, never edits. Use when asked to review, critique, tighten, or prepare a rewrite of a contract or protocol specification.
 ---
 
-# Contract review
-
 A contract is implemented and tested by parties who read only it, so every ambiguity becomes a divergence between implementations.
 
 ## Gather
@@ -26,7 +24,7 @@ Apply each to every normative sentence and quote it, so the author finds it afte
 - **Order for precedence**: an evaluation order where only which-outcome-wins matters, or two outcomes equally valid for one input.
 - **Unowned field**: a stored field with no statement of who initialises it and which operations update it or must not.
 - **Second copy**: a list, mapping, or encoding defined twice; keep one and point.
-- **Anchor**: an operation or normative section without an anchor, a published anchor renamed, or an anchor removed while citations still name it, since the suite, the code, and the intent cite sections by anchor (`intent-files` Anchors).
+- **Anchor**: an operation or normative section without an anchor, an id repeated within the file, a published anchor renamed, or an anchor removed while citations still name it, since the suite, the code, and the intent cite sections by anchor (`intent-files` Anchors).
   Propose the id or restore the old one; for a removal, list the citers a search for the id finds.
 - **Example as rule**: a transcript or template whose free aspects (order, case, whitespace) are not stated; propose the statement and vectors that vary them.
 - **One-implementation bias**: a library's behaviour, a number, or a rationale true for one backend; ask whether it was written to fit one implementation.
 
@@ -3,8 +3,6 @@ name: contribute
 description: Pick the delivery flow by scale - a test-first fix in place, one led pull request, or an orchestrated multi-pull-request effort - and where the intent, contract, test, and review skills enter. Use at the start of any non-trivial change, or when asked how to approach or stage work.
 ---
 
-# Contribute
-
 Every flow is the same loop at a different scale: decide what must hold, write the check that fails without it, make it pass, and have someone who did not write it review.
 
 ## Pick the smallest flow that fits
 
@@ -3,8 +3,6 @@ name: dependency-pruner
 description: Audit the dependencies a change added or widened before its pull request opens, keep each only where it is load-bearing, and replace the rest with a few lines, a lighter package, or one already in the tree. Use at the end of a change, as the last worker task before the pull request opens, or when asked to trim or justify a package's dependencies.
 ---
 
-# Dependency pruner
-
 A dependency is a maintenance contract: every one costs build time, audit surface, and a future upgrade, so each must be load-bearing, which means removing it would cost more than it saves.
 Run once per change, on the diff, after the code is complete, because a package added mid-way is often not needed by the end.
 
 
@@ -3,8 +3,6 @@ name: dependency-reviewer
 description: Review the dependencies a diff or pull request adds or widens against the `dependency-pruner` rules - load-bearing, no proc-macro in a foundational package, plain code over a package unless unsafe, minimal and maintained alternatives - and flag what is probably not necessary. Use when a diff changes a manifest or lockfile, or when asked whether a dependency belongs.
 ---
 
-# Dependency reviewer
-
 Invoke `dependency-pruner` and use its decision rules as review criteria without running its procedure; this skill judges the manifest and lockfile changes and does not edit.
 Review only dependencies the diff adds or widens, features and transitive additions included, unless the user asks for a whole-package audit.