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 instructions/quantmind/quantflow/releasegit clone --depth 1 https://github.com/quantmind/quantflowWhat 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.00667 | $0.00667 |
| Opus 5 | $0.00333 | $0.00333 |
| Sonnet 5 | $0.00133 | $0.00133 |
| Haiku 4.5 | $0.00067 | $0.00067 |
Grade A, and why
quantflow release.instructions.md 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 — 53 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Instructions
Releases are driven by v* git tags. Pushing a tag triggers
.github/workflows/release.yml, which runs lint and the test suite, publishes
the package to PyPI (make publish), then extracts the matching ## vX.Y.Z
section from docs/release-notes.md and publishes it as the GitHub Release
body.
Cutting a release
- Bump
versioninpyproject.tomlto the new release version. - Add a
## vX.Y.Zsection at the top ofdocs/release-notes.mdwith the notes for the release. The header text is matched verbatim by the workflow'sawkextractor, so it must be## vX.Y.Zexactly (no trailing dash, no title after the version). The release workflow fails if this section is missing. - Commit and merge to
main; let thebuildworkflow pass. - From
main, runmake release— it reads the version frompyproject.toml, asks for confirmation, then creates an annotatedvX.Y.Ztag and pushes it. Thereleaseworkflow takes it from there.
Do not publish to PyPI manually, and do not revive the old
head_commit.message == 'release' flow — the tag-triggered workflow is the
only supported path.
Release-notes conventions
The ## vX.Y.Z section in docs/release-notes.md is rendered both on the
docs site and as the GitHub Release body, so it must follow these conventions:
- Open with a one-paragraph summary describing the theme of the release. If the release contains breaking changes, point readers to the Breaking changes section in that paragraph.
- Group entries under H3 subsections in this order:
### Breaking changes,### New features,### Improvements and fixes,### Documentation and assets. Omit any subsection that has no entries. - Every PR reference must be a markdown link of the form
[#NN](https://github.com/quantmind/quantflow/pull/NN)— never a bare(#NN). GitHub's auto-linking only works in some contexts, and the explicit URL works everywhere. When one entry references multiple PRs, list them comma-separated inside one set of parentheses, each as its own link. - Build the PR list by running
git log vPREV..HEAD --onelineagainst the previous release tag and following each squashed-merge commit back to its PR. Cross-check withgh pr list --state merged --base mainfor any PRs merged since the previous tag. - End the section with a
[Full changelog](https://github.com/quantmind/quantflow/compare/vPREV...vX.Y.Z)link comparing the new tag against the previous one.
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 · 53 lines · 667 tokens per session scan A 138de9245ed0
quantflow release.instructions.md is an instructions file published in the GitHub repository quantmind/quantflow (52 stars, last pushed 16d ago), licensed BSD-3-Clause. It adds 667 tokens to every session, about $0.0033 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 instructions, from other repositories
maverick-mcp AGENTS.md
Instructions for wshobson/maverick-mcp, covering repository guidelines, project overview, project structure, documentation map and build, test, and development commands.
awesome-quant AGENTS.md
AGENTS.md instructions for wilsonfreitas/awesome-quant, covering agents.md, project overview, architecture, commands and install deps (requires python 3.11+).
TradingAgents-Telegram CLAUDE.md
Instructions for IvanWng97/TradingAgents-Telegram, covering tradingagents-telegram — architecture reference, layout, architecture (for code reviewers), request lifecycle (manual /watch tap) and state ownership.
tiingo-mcp AGENTS.md
Instructions for major7apps/tiingo-mcp, covering agents.md, project map, public contract, operating rules and commands.
deckforge CLAUDE.md
Instructions for Whatsonyourmind/deckforge, covering deckforge, tech stack, project structure, key commands and local development.
open-stocks-mcp CLAUDE.md
Instructions for Open-Agent-Tools/open-stocks-mcp, covering claude.md, project overview, quick reference, development setup and testing.