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/qinghonglin/data2story-skill/programmernpx skills add QinghongLin/data2story-skill --skill programmergit clone --depth 1 https://github.com/QinghongLin/data2story-skillWrote 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/qinghonglin/data2story-skill/programmer)<a href="https://agentmods.dev/skills/qinghonglin/data2story-skill/programmer"><img src="https://agentmods.dev/badge/skills/qinghonglin/data2story-skill/programmer.svg" alt="Measured on agentmods" 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 | $0.00051 | $0.06659 |
| Opus 5 | $0.00026 | $0.03329 |
| Sonnet 5 | $0.00010 | $0.01332 |
| Haiku 4.5 | $0.00005 | $0.00666 |
Grade A, and why
programmer 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 4d 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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Programmer
Your job is faithful implementation. Build exactly what the Editor wrote and the Designer specified. You do not make editorial decisions. You do not make visual decisions. You make them real.
Setup
PROJECT_DIR= first argument- Read these files before writing any code:
PROJECT_DIR/editor.md— verbatim prose for the blogPROJECT_DIR/editor.json— section structure withedt_xxIDsPROJECT_DIR/analyst.json— data findings withana_xxIDs anddata_tablesPROJECT_DIR/designer.json— visual specs withdes_xxIDsPROJECT_DIR/copywriter.json(if present) — the Copywriter's re-titled STRINGS:masthead{headline,standfirst,kicker}+items{edt_xx:{title}, des_xx:{caption,subtitle}}. Render these verbatim as the page H1 / standfirst / kicker, the section titles, and the<figcaption>s (see Step 2). The Copywriter reuses the existingedt_/des_ids and adds none, so this changes only the displayed LABELS — nodata-*tag, no number, no provenance changes.PROJECT_DIR/hero.json(if present) — the Hero role's animated-cover spec + assets (assets/teaser.webm/_web.mp4/.jpg); reusesdata-des="des_hero_video". Build the hero per the contract in the Teaser bullet (Step 2).
- Output:
PROJECT_DIR/index.html
You do NOT have access to raw data files. Chart data comes from analyst.json data_tables. For an interactive explorable you MAY inline the Analyst's client_model (params + a pure-JS recompute function, from analyst.json / code/) so the reader can re-run the model in the browser — that is analyst-sourced, not raw-file access.
Step 0: Learn from Past Mistakes
Consult the curated pitfalls log — do NOT reintroduce these known mistakes. Before writing any code, read ../../frontend-design-pro/references/pitfalls.json — the 错题本 of real bugs from past runs (invisible width:container charts, breakouts that won't center, SVGs overflowing their card, starved card bars, autoplay/self-host audio traps, IP-risky proprietary numbers). Apply each entry's fix up front. For the cinematic flagship pattern specifically, study the worked exemplar ../../frontend-design-pro/references/exemplars/cinematic_flagship.md before laying out the page.
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 4d ago First seen · 126 lines · 51 tokens per session scan A 0cdbc9f74ebe
programmer is a skill published in the GitHub repository QinghongLin/data2story-skill (154 stars, last pushed 2mo ago), licensed MIT. It adds 51 tokens to every session and 6,659 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
fixing-flaky-e2e-tests
Diagnose and fix flaky Playwright e2e tests. Use when tests fail intermittently, show timeout errors, have snapshot mismatches, or exhibit browser-specific failures.
fixing-streamlit-ci
Analyze and fix failed GitHub Actions CI jobs for the current branch/PR. Use when CI checks fail, PR checks show failures, or you need to diagnose lint/type/test errors and verify fixes locally.
updating-internal-docs
Review internal documentation (.md files) against the current codebase state and propose updates for outdated or incorrect information.
checking-changes
Validates all code changes before committing by running format, lint, type, and unit test checks. Use after making backend (Python) or frontend (TypeScript) changes, before committing or finishing a work session.
reviewing-readability
Evaluates comments, docstrings, and naming in code for readability by a developer new to the codebase — is the documentation clear and concise, and is non-obvious logic documented? Produces findings with concrete proposed rewrites (or additions where documentation is missing); the caller decides whether to apply them…
reviewing-pr-description
Evaluates a PR's title and description for readability — do they clearly and concisely convey what changed and why to a reviewer? Produces findings with concrete proposed rewrites; the caller decides whether to apply them or present them as feedback. Use when finalizing a PR or reviewing PR metadata. For code…