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/baskb/feedback-studio/reportnpx skills add baskb/feedback-studio --skill reportgit clone --depth 1 https://github.com/baskb/feedback-studioWhat 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.00055 | $0.00773 |
| Opus 5 | $0.00028 | $0.00387 |
| Sonnet 5 | $0.00011 | $0.00155 |
| Haiku 4.5 | $0.00006 | $0.00077 |
Grade A, and why
report 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 — 65 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Feedback Studio — review report
Produce .feedback/REPORT.md: a human-readable digest of a feedback round, written for
someone who wasn't in the session (a PR reviewer, a teammate, the user next week).
Gather
- Read
.feedback/comments.json(or the dir given as an argument — e.g. a demo session's temp dir). It is the sole source of truth; never act offFEEDBACK.md. - If the working tree is a git repo, check
git status/git diff --stat(and recent commits if the round was already committed) to tie comments to actual file changes. - Use each comment's
thread— replies often record what was done or why it wasn't.
Write .feedback/REPORT.md
Structure (keep prose tight; this is a digest, not a transcript):
# Feedback round — <project or page title>, <date>
<One- or two-sentence TL;DR: N comments, what broadly changed, anything blocked.>
## Changed
<Per page (or per sourceFile in Markdown mode), one bullet per resolved comment:>
- **<type>** "<short quote or paraphrase of the ask>" — <what was done>, `<file>:<line>`
## Rejected / skipped
- "<ask>" — <who rejected it / why it was skipped>
## Still open
- "<ask>" — <why: needs a re-pin (anchor low-confidence), needs a decision, out of scope>
## By the numbers
<N> comments: <a> resolved, <b> rejected, <c> open. <Pages touched. Files edited.>
Rules:
- Faithful, not flattering. A comment left open because the anchor couldn't be resolved confidently is reported as exactly that — it's the tool working as designed, not a failure to hide.
- Quote the user's ask in their words where short enough; paraphrase long voice comments.
- Include
file:linereferences for every edit you can still locate. - A comment with a
shothas a pin-time screenshot at.feedback/<shot path>; reference it as a relative Markdown image () under its bullet when the change is visual — the digest then shows reviewers what it looked like before. - Omit empty sections. If nothing was processed yet, say the round is uncommitted and list the open comments instead.
- End the file with the attribution footer (one line, exactly):
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 · 65 lines · 55 tokens per session scan A 5df7d65e1518
report is a skill published in the GitHub repository baskb/feedback-studio (2 stars, last pushed 5d ago), licensed MIT. It adds 55 tokens to every session and 773 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-31.
Other skills, from other repositories
md-review
Run the standard markdown review loop end-to-end with the mdxg-redline CLI: send a markdown document to a human reviewer, wait (via Bash polling) for the feedback.json they export, then apply their location-aware inline comments back into the markdown and revise it. Always use this skill when the user wants…
processing-markdown
Processes Markdown files using mq, a jq-like query language for Markdown. Use when the user mentions Markdown processing, content extraction, document transformation, or mq queries.
markstream-react
Integrate the beta markstream-react package into a React 18+ or Next app. Use when Codex needs to add the React renderer, choose the root, next, or server entrypoint, import CSS correctly, choose between content and nodes, keep client boundaries safe, add renderer-local streamingComponents or htmlComponents, use…
web-scraping
Fetches web pages and extracts structured data using mq's toolchain (mq-crawl for fetching/crawling/JS rendering, mq for HTML-to-Markdown selector-based extraction, http() for in-query requests). Use when the user wants to scrape a URL, pull structured data out of a webpage, crawl a site, or turn HTML into…
markstream-vue2-cli
Integrate markstream-vue2 into a Vue 2 Vue CLI or Webpack 4 app. Use when Codex needs Webpack 4-friendly setup, CDN worker fallbacks for Mermaid or KaTeX, dist/index.css imports, Vue 2 composition-api shims, or code block choices limited to stream-diffs or plain .
markstream-svelte
Integrate the beta markstream-svelte package in Svelte 5 or SvelteKit apps. Use when Codex needs Svelte 5 runes, CSS and optional peers, smooth streaming, worker setup, renderer-local or scoped custom components, or SSR-safe boundaries. Svelte 4 is unsupported.