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 agentmods add skills/docsector/docsector-reader/docsector-feature-developmentnpx skills add docsector/docsector-reader --skill docsector-feature-developmentgit clone --depth 1 https://github.com/docsector/docsector-readerWhat 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 | $0.00058 | $0.00707 |
| Opus 5 | $0.00029 | $0.00353 |
| Sonnet 5 | $0.00012 | $0.00141 |
| Haiku 4.5 | $0.00006 | $0.00071 |
Grade A, and why
docsector-feature-development 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 — 68 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Docsector Feature Development
When to Use
- Create a new feature in Docsector.
- Evolve existing behavior with functional impact.
- Deliver a change that needs regression coverage and documentation updates.
Expected Outcome
- The relevant environment was mapped before implementation.
- Blocking questions were clarified, or non-blocking assumptions were made explicit.
- The feature is covered by regression tests in the narrowest possible scope.
- README.md is updated in the related section.
- Executable validation was run for the change, or a limitation was documented.
Procedure
-
Map the environment.
- Find the nearest code path that actually decides the feature behavior.
- Identify relevant files, components, composables, stores, routes, existing tests, and the potentially affected README.md section.
- Form a local hypothesis: where the change belongs, which test can discriminate the expected behavior, and which narrow validation should be used.
-
Ask when in doubt.
- If there is ambiguity about expected behavior, scope, naming, user experience, compatibility, or which README section must be updated, ask before editing.
- Ask only the smallest set of genuinely blocking questions.
- If the uncertainty is not blocking, proceed with the smallest reasonable assumption and record it in the final summary.
-
Implement regression tests.
- Write or adjust a test that would fail without the feature and validates the expected behavior once the feature is applied.
- Prefer the narrowest possible test first: validate the touched slice before broader checks unless they are necessary.
- After the first substantive edit, immediately run the corresponding focused validation.
-
Implement the feature.
- Make the smallest change needed to reach the desired behavior.
- Fix the root cause instead of only working around the symptom.
- Preserve Docsector's existing style and abstractions.
-
Update README.md.
- Find the section most closely related to the delivered feature.
- Document what changed, when to use it, and any relevant impact for project consumers.
- If there is no exact section, update the nearest canonical section and state that explicitly in the final summary.
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 · 68 lines · 58 tokens per session scan A 295de06ddc96
docsector-feature-development is a skill published in the GitHub repository docsector/docsector-reader (21 stars, last pushed 29d ago), licensed MIT. It adds 58 tokens to every session and 707 once invoked, about $0.0003 per session on Opus 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-08-30.
Other skills, from other repositories
golden-rss
Use when testing the rss golden build.
golden-chat-single
Use when testing the goldenchatsingle golden build.
dev-pain-finder
Scrape real developer pain points for any keyword, technology, or problem space from Reddit, Hacker News, dev.to, and GitHub Discussions simultaneously — then group complaints by theme, score them by frequency and upvote weight, and return a ranked opportunity map showing where developer frustration is high and…
decided-import
Reformat ONE existing document (a decision, requirement, design, roadmap, or prompt) into ONE valid RAC (requirements-as-code) artifact, with a mandatory human-review step before any file is written and decided validate as the deterministic close. Use when a user wants to add or import a single existing decision or…
plan-a-feature-to-confluence
Builds a feature specification from scratch with plan-a-feature and publishes it to a user-specified Confluence location, posting the spec as a parent page and each companion artifact (decision log, team findings, technical notes) as a child page beneath it. Use when the user wants a new feature planned, designed…
keep-the-why
Preserves or recovers the reasoning behind a codebase - architectural decisions, rejected alternatives, workarounds, incident learnings, operational constraints, and historical context the code itself cannot explain. Use when implementing or reviewing a non-trivial change involving a design decision, workaround…