QuantMind Contributor Workflow
A standardized contribution workflow for the QuantMind codebase: contributor setup, issue filing, commit and PR conventions, module development, and deterministic verification.
Docs-only contributor workflow skill: no code execution, no network calls, no credential access; explicitly forbids bypassing hooks without user authorization and requires the user to run gh auth login themselves. Data flow transparent, minimal privilege. Deducted because key instructions depend on referenced files not fully presented in evidence (scripts/verify.sh, contexts/ pages), so static review cannot confirm what those scripts do.
Instructions are internally self-consistent: workflow routing, commit/PR/test/contexts rules cross-reference coherently with a single deterministic gate (verify.sh). Deducted: static review only — verify.sh itself is not provided; CI files corroborate the description but execution is unverifiable; failure-feedback details depend on unshown scripts. Static cap 10 applies.
Audience (QuantMind contributors) and triggers (setup/issue/commit/PR/component dev/contexts pages) are clearly declared in frontmatter and Select Workflow; Boundaries explicitly exclude library users and product decisions. Deducted: full English docs with weaker Chinese support; uv/GitHub/OpenAI dependencies carry mainland-China reachability risk (Tsinghua PyPI mirror shows partial awareness); no explicit input/output examples for trigger calibration.
Well-layered progressive disclosure (SKILL.md → references/), stable naming, explicit dual-mirror sync rule, MIT license, version in pyproject (0.2.0), CI matching descriptions. Deducted: skill lacks its own version/changelog and named maintenance owner; several referenced contexts files (labels.md, github-writing.md) absent from evidence, leaving hidden assumptions.
Clear, directly executable contribution workflow with concrete commands and paths; real marginal value over letting an agent guess repo norms. Deducted: static review cannot confirm referenced files exist and commands run; correctness depends on unshown verify.sh; comparative-benefit evidence is self-reported only. Static cap 7; scored 6.
Key claims (CI runs the same verify.sh, path-filtered e2e, 75% coverage floor) cross-corroborate with provided ci.yml, e2e.yml and pyproject.toml — auditable primary material. Deducted: no executed reproduction (static), only one sample test file provided, repository marketing claims (NeurIPS acceptance, production use) lack independent corroboration. Capped at 5.
- Static review only, nothing executed; verify.sh and most referenced contexts/ files are absent from evidence, so runnability is unverified.
- Docs are English-only; the workflow depends on GitHub, uv, and optional OpenAI/OpenRouter credentials, with mainland-China reachability risk (partially mitigated by the Tsinghua PyPI mirror).
- Publisher is not verified by the FollowSkills registry and is treated as unknown; the skill has no own version or changelog, and its update path depends on repository maintenance.
- This skill applies only to contributing to the QuantMind codebase, not to using QuantMind as a library; misuse outside that scope will leave referenced instructions inapplicable.
What does this skill do, and when should you use it?
quantmind-dev is the official contributor skill for QuantMind, an agent-native knowledge extraction and retrieval framework for quantitative finance. It walks an agent through contributor environment setup, issue filing to repo conventions, commit and PR formats, and code development across the quantmind/ modules (etl, knowledge, configs, preprocess, rag, flows, mind, utils). Its core requirement is running bash scripts/verify.sh as deterministic verification, and new features must ship with a unit test and a focused example. The skill explicitly covers only contributing to QuantMind itself, not using it as a library.
The skill reads repository context documents (contexts/README.md, AGENTS.md/CLAUDE.md, docs/README.md) to load architecture constraints and the module map; for each task type (setup, issues, commits, PRs, component development, contexts-page editing) it loads exactly one matching reference from references/. When executing, it drives: running bash scripts/verify.sh (lint, types, import boundaries, tests); running component-specific smoke tests listed in e2e.yml when changing public-network components; writing issue and PR bodies following the repo's label guidance and GitHub writing style (including a no-hard-wrap rule); ensuring new features include a unit test and example; and keeping docs/README.md as the single catalog of component smoke-test commands.
- A developer who wants to contribute to QuantMind and needs first-time environment setup, pre-commit hook installation, and an initial verification run
- A user who found a bug or missing capability and wants to file a well-structured issue per repo conventions
- A contributor with staged changes who needs to commit in the required format and open a compliant PR
- A coding agent implementing or refactoring code under quantmind/ while honoring the test-and-example requirements
- A contributor adding a new external-network component who must add a component-level e2e test and register it in the smoke-test catalog
- Someone maintaining or writing agent-facing pages under contexts/
What are this skill's strengths and limitations?
- Deterministic verification backstop: scripts/verify.sh runs the exact same checks as CI, so local results are reproducible
- Progressive-disclosure references/ structure means the agent loads only the one reference its task needs
- Clear repo-level conventions for issue, commit, PR formats and GitHub writing style produce consistent output
- Explicit boundary declaration (contributing to QuantMind only) prevents misuse
- Mirrored under both .agents/ and .claude/, so Claude and Codex users follow one identical workflow
- Only useful inside the QuantMind repository; no value for other projects
- Does not cover using QuantMind as a Python library (library usage is in the README Quick Start)
- verify.sh depends on the full repo environment (pre-commit hooks, CI harness), so setup must be done first
- E2E behavior for external services depends on the GitHub Actions e2e.yml workflow; local behavior relies on the catalog in docs/README.md
- No independent third-party evaluation or user feedback evidence beyond the repo's own claims
How do you install this skill?
The skill ships as part of the LLMQuant/quant-mind repository: after git clone https://github.com/LLMQuant/quant-mind.git, it lives at .agents/skills/quantmind-dev/ (with an identical mirror at .claude/skills/quantmind-dev/). It is usable by starting Claude Code or Codex inside the checkout; both copies must be updated in the same change when editing. The README does not document installing this skill standalone into other projects.
How do you use this skill?
Start a coding agent inside the quant-mind checkout and describe your task in natural language, e.g. "set me up as a contributor", "file an issue: <what you need>", or "I want to contribute <your change>". Claude Code users can trigger the same tasks with the /quantmind-dev prefix. A typical feature task chains three workflows: develop → commit → pull request. You must run bash scripts/verify.sh before every push and before marking a PR ready.
How does this skill compare with similar options?
The README draws an analogy between QuantMind's overall methodology and SWE-bench's paired-trial model (quantmind-bench is still in design, with no published numbers), but the skill itself is a repo-specific contributor workflow and the source names no directly comparable alternative skill.