Implement token-saving skill and related evaluation files

.github/workflows/check_pr_release_notes.yml

@@ -21,3 +21,4 @@ jobs:
           github-repository: ${{ github.repository }}
           pr-number: ${{ github.event.number }}
           skip-labels: "no RN"
+          title: "## [Rr]elease [Nn]otes"

CONTRIBUTING.md

@@ -227,5 +227,6 @@ Before opening a pull request, verify:
 - [ ] No hardcoded credentials, secrets, or internal paths in skill body or scripts
 - [ ] Any script in `scripts/` is referenced from `SKILL.md` with usage guidance
 - [ ] New skill's description does not conflict with or shadow existing skills
+- [ ] Skill added to the catalog table in `README.md`
 - [ ] Evals exist (or a note explains why they are not applicable)
 - [ ] `skills-ref validate ./skills/my-skill` passes (install: `pip install skills-ref`)

README.md

@@ -75,7 +75,9 @@ For the full guide — what skills are, how they activate, project-scoped instal
 Browse all available skills in the **[skills/](./skills/)** directory — each skill folder contains a `SKILL.md` with
 its purpose, trigger phrases, and full instructions.
 
-> The catalog table will be populated as skills are added. See `skills/` for the current set.
+| Skill                                                | Description                                                                                                                         |
+|------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------|
+| **[token-saving](./skills/token-saving/)**           | Always-active response discipline — enforces brevity, no filler openers or closers, structured output, and a What/Why/How footer on code responses. Suspends on explicit "full detail" requests. |
 
 ## Finding More Skills
 
@@ -87,7 +89,7 @@ Before building a new skill, check whether one already exists:
 | [skills.sh](https://skills.sh)                                                       | Open registry — install with `npx skills add <owner/repo>`              |
 | [anthropics/skills](https://github.com/anthropics/skills)                            | Anthropic reference skills including `skill-creator`                    |
 | [absa-group/agent-skills](https://github.com/absa-group/agent-skills)                | Broader ABSA-owned skill collection                                     |
-| [absa-group/cps-agentic-toolkit](https://github.com/absa-group/cps-agentic-toolkit)  | CPS team's skill set built on top of this repo                          |
+| [absa-group/cps-agentic-toolkit](https://github.com/absa-group/cps-agentic-toolkit)  | CPS team's extended skill set (ABSA-internal)                           |
 
 ## Contributing
 
@@ -116,3 +118,4 @@ Claude, Cursor, Windsurf, and custom pipelines.
 ## Troubleshooting
 
 Setup issues and common fixes are covered in **[docs/troubleshooting.md](./docs/troubleshooting.md)**.
+All documentation guides are indexed at **[docs/](./docs/)**.

docs/README.md

@@ -2,13 +2,21 @@
 
 Navigation hub for all guides in this repository. Browse by category below.
 
-| Guide                                   | Audience | Description                                                                        |
-|-----------------------------------------|----------|------------------------------------------------------------------------------------|
-| [Getting Started](./getting-started.md) | Users    | What skills are, how to install them, Copilot CLI usage                            |
-| [Troubleshooting](./troubleshooting.md) | Users    | Setup guides and fixes for install, activation, and proxy issues                   |
-| [Contributing](../CONTRIBUTING.md)      | Authors  | Skill folder layout, frontmatter, description writing, body guidelines, PR process |
-| [Skill Testing](./skill-testing.md)     | Authors  | Eval creation, fixtures, regression loops, trigger and description optimization    |
-
-> **Keep this index up to date.** When you add a new guide under `docs/`, add a row to the table above.
+## Setup & Repository Guides
+
+| Guide                                   | Description                                                                         |
+|-----------------------------------------|-------------------------------------------------------------------------------------|
+| [Getting Started](./getting-started.md) | What skills are, how to install them, Copilot CLI usage                             |
+| [Contributing](../CONTRIBUTING.md)  | Skill folder layout, frontmatter, description writing, body guidelines, PR process |
+| [Skill Testing](./skill-testing.md) | Eval creation, fixtures, regression loops, trigger and description optimization    |
+| [Troubleshooting](./troubleshooting.md) | Setup fixes for install, activation, and proxy issues                               |
+
+## Skill Guides
+
+| Guide                               | Description                                                                        |
+|-------------------------------------|------------------------------------------------------------------------------------|
+| [Token Saving](./token-saving.md)       | Keeping AI responses concise — how the token-saving skill works and when it applies |
+
+> **Keep this index up to date.** When you add a new guide, add a row to the appropriate table above.
 
 See also the [main README](../README.md) for the skill catalog, scope, and FAQ.

docs/getting-started.md

@@ -132,7 +132,7 @@ Project skills take precedence over global skills when both exist.
 ### Add project-specific skills
 
 For skills that only apply to a specific repository, place them in `.github/skills/` within that repo. These are loaded
-automatically when Copilot CLI is launched from that directory, layered on top of your personal and CPS base skills.
+automatically when Copilot CLI is launched from that directory, layered on top of your personal and shared base skills.
 
 ```
 your-project-repo/

docs/token-saving.md

@@ -0,0 +1,71 @@
+# Token-Saving Skill
+
+The `token-saving` skill enforces concise, low-noise AI responses. It is **always active** — it applies to every reply without needing to be triggered by a specific phrase.
+
+---
+
+## What it changes
+
+Without the skill, AI assistants commonly pad responses with filler openers, closing platitudes, and repeated context. This skill removes that noise.
+
+| Behaviour | Without skill | With skill |
+|-----------|--------------|------------|
+| Response opener | "Great question! Certainly, I'd be happy to help..." | Directly answers |
+| Closing | "Let me know if you have any questions!" | Stops when done |
+| Repeated context | Restates what you just said | Skips it |
+| Factual answers | Unlimited prose | ≤ 5 lines |
+| Action lists | Unlimited bullets | Capped at 4 |
+| Full file dumps | Common | Only when you ask |
+
+---
+
+## Code output footer
+
+Every response that writes or changes code ends with exactly this footer — no more, no less:
+
+```
+**What changed:** <one line>
+**Why:** <one line>
+**How to verify:** <command or test instruction>
+```
+
+This applies to: new functions, patches, inline diffs, config snippets, or any code block representing a change.
+
+It does **not** apply to: Q&A, reviews, planning, comparisons, or conceptual explanations.
+
+---
+
+## Overriding the skill
+
+The brevity rules suspend for a single response when you explicitly ask for depth:
+
+> "Give me a full explanation."
+> "Deep dive into this."
+> "Don't hold back."
+> "Complete explanation."
+
+The next response is fully unrestricted. Rules resume after that.
+
+---
+
+## Precedence
+
+If another active skill specifies its own output format (e.g. a review skill with a Blocker / Important / Nit structure), that format takes precedence over this skill's rules.
+
+---
+
+## Installation
+
+The skill is installed along with the rest of the toolkit:
+
+```bash
+npx skills add https://github.com/AbsaOSS/agentic-toolkit -g
+```
+
+To install only this skill:
+
+```bash
+npx skills add https://github.com/AbsaOSS/agentic-toolkit -g --skill token-saving
+```
+
+See [Getting Started](./getting-started.md) for the full install guide.

skills/token-saving/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: token-saving
+description: >
+  Always-active response formatting rules — invoke for every reply without exception: coding
+  questions, code generation, debugging, explanations, comparisons, reviews, diffs, PR updates,
+  recaps, summaries, workflow tasks, non-technical requests, and anything else. Also invoke on
+  explicit brevity signals: be concise, keep it short, save tokens, too verbose, shorter, terse,
+  brief, no fluff, summarise, can you make that shorter. Rules: no filler openers (Certainly!,
+  Great question!, Happy to help!); no closing platitudes (Let me know if you have questions!);
+  concise within line limits; skip restating prior context; prefer tables/bullets over prose;
+  append What changed / Why / How to verify footer only for code-output responses, not Q&A,
+  reviews, or planning. Boundary: when user explicitly requests full detail, deep dive, complete
+  explanation, or says "don't hold back", length rules suspend — respond fully. Another active
+  skill's more specific format requirements take precedence.
+---
+
+# Token-Saving
+
+Always-active base behaviour. Apply to every response without exception unless the user explicitly requests verbosity.
+
+## Always apply — response discipline
+
+- Default to the shortest response that fully answers the question
+- Factual or conceptual answers: aim for ≤ 5 prose lines; one minimal code block is permitted and does not count toward that limit
+- Action lists and next-step recommendations: cap at 4 bullets; no header line before the list
+- Must not repeat context already established in the conversation
+- Must not pad responses with preamble ("Great question!", "Certainly!", "As an AI...")
+- Must not add closing summaries that restate what was just said
+- Stop when the task is complete — must not append "let me know if you need anything else" filler
+- Prefer structured output when it improves clarity: bullets, tables, and short code blocks over dense prose
+- If another active skill or task requires a more specific output format, that format takes precedence
+
+## Format code output responses
+
+End every response where you output code for the user to incorporate — new functions, patches, inline diffs, config snippets, or any code block that represents a change — with exactly this structure (no more, no less):
+
+```
+**What changed:** <one line>
+**Why:** <one line>
+**How to verify:** <command or test instruction>
+```
+
+This footer does NOT apply to pure Q&A, reviews, planning, comparisons, or conceptual explanations — only when you are writing or changing code.
+
+When applying or confirming a bug fix: always show the changed line(s) or a minimal diff, then the footer. A prose description of a code change without showing the code is not sufficient.
+
+- Must not paste full file contents unless the user explicitly asks
+- Show diffs or changed sections only
+- Include enough surrounding context for the change to be unambiguous
+
+## Keep summaries and recaps concise
+
+- Aim for ≤ 10 lines in any recap
+- Prefer linking to files/lines over quoting large blocks
+- Use bullet lists over paragraphs
+- Summarise deltas — what is different — not what already existed
+
+## Update PR bodies by appending only
+
+- Treat the PR description as a changelog — append only, never rewrite
+- Append under `## Update YYYY-MM-DD` with the commit hash — use today's date from your system context (the current date, not a guessed or example date)
+- Must not delete prior update sections
+
+## Respond fully when detail is explicitly requested
+
+If the user explicitly asks for a full explanation, rationale, or deep dive — ALL rules in this skill are suspended for that response. Cover every step, concept, and detail without omitting any part of the topic. Do not apply line limits, bullet caps, or summarisation.