Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add kBashar/myagentskills --skill feature-decisionsgit clone --depth 1 https://github.com/kBashar/myagentskillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/kbashar/myagentskills/feature-decisions)<a href="https://agentmods.dev/skills/kbashar/myagentskills/feature-decisions"><img src="https://agentmods.dev/badge/skills/kbashar/myagentskills/feature-decisions/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/kbashar/myagentskills/feature-decisions"><img src="https://agentmods.dev/badge/skills/kbashar/myagentskills/feature-decisions.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00045 | $0.00675 |
| Opus 5.5 | $0.00018 | $0.00270 |
| Sonnet 5.5 | $0.00009 | $0.00135 |
| Haiku 4.5 | $0.00005 | $0.00068 |
Grade A, and why
feature-decisions scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Feature decisions
Overview
Turn a built feature into one page of its product decisions. The reader is a product person. They care what the feature does, not how the code does it.
REQUIRED SUB-SKILL: use visual-docs to build the page.
Sources
- The built code is the truth. Read the feature's diff against its base branch. Plans, logs and chat explain a decision; the code states it.
- The first design (design doc, spec or issue) shows what changed. If the user gave none, ask for it. If none exists, leave out the chips.
The keep test
An item goes on the page only when all three are true:
- It is what, not how. It says what the built feature lets a user do, see or get. Code names, tables, migrations, algorithms, HTTP methods, error codes, validation and access checks are how.
- It is the new feature, now. Old routes, old data and later work are out.
- A product person would not assume it. "A failed save keeps the old data" is assumed. "The count includes only your own organisation" is not.
State each decision by its effect on the user. Merge items that state one idea.
| How | What |
|---|---|
| The server refuses a body over 10 MB with 413. | A user can upload a file of up to 10 MB. |
Budget: about five decisions per endpoint. More means how or assumed items got through.
The page
These parts, in this order:
- Header — title, one-line lede, issue or PR numbers, date of the first design.
- Terms — one sentence per product word. Use the product word on the whole page. When the API uses another word, say so in the term.
- How it works — two figures. First, what one main action does to what the user sees. Then the flow, with user, screen and API lanes only.
- Decisions
- A table of the endpoints: name, route, used by, what it does.
- One group per endpoint: its route, then its decisions. A feature with no endpoints groups by screen or command.
- Number the decisions 1, 2, 3 … across the whole page.
- One or two sentences per decision. Chip it
changedoraddedwhen it differs from the first design. The chip is enough; the old rule stays off the page. - One sample call per endpoint: request and response JSON, colour-highlighted, in a collapsed
<details>. Check each sample against the real schemas in the code. - A worked example with real numbers goes right after the group it explains.
- Sources — one line: issue or PR numbers and dates.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 52 lines · 45 tokens per session scan A 5e73609b9a8d
feature-decisions is a skill published in the GitHub repository kBashar/myagentskills (2 stars, last pushed 2d ago), licensed Apache-2.0. It adds 45 tokens to every session and 675 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-28.
Other skills, from other repositories
story-readiness
Checks whether a story is ready to implement: clear acceptance criteria, no open questions, valid ADR and dependencies. Use when the user asks if a story, or the sprint's stories, are ready to start or build.
recipe-create-meet-space
Create a Google Meet meeting space and share the join link.
workthreads
SpecStory Workthreads - a weekly work-thread rollup across a team's repos from SpecStory coding histories (any agent - Claude Code, Codex, Cursor, Gemini, and more). It groups the window's sessions into threads of work per project and labels each new / open / recently closed, so a lead sees what shipped, what is still…
atmos-config
Atmos root configuration: atmos.yaml discovery, precedence, deep merging, basepath, imports, minimal bootstrap, and routing to narrower Atmos skills.
qa-project-bootstrap
Onboard a new QA engineer to an existing codebase, or audit an existing test architecture. Produces a 30-day ramp plan: codebase orientation, framework walkthrough, test architecture audit, mentorship pairing, and first-test guidance. Use when: "QA onboarding," "new tester," "ramp up," "test architecture audit,"…
remove
Remove a deployed framework or addon from the current workspace.