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/binary-husky/alphaautoresearch/blueprint_gennpx skills add binary-husky/AlphaAutoResearch --skill blueprint_gengit clone --depth 1 https://github.com/binary-husky/AlphaAutoResearchWhat 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.00000 | $0.00990 |
| Opus 5 | $0.00000 | $0.00495 |
| Sonnet 5 | $0.00000 | $0.00198 |
| Haiku 4.5 | $0.00000 | $0.00099 |
Grade A, and why
blueprint_gen 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 3d 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.
What it actually says
Your task is to generate a experiment blueprint at user's current working dir.
-
采用试错循环
- 编写代码 & yaml配置 -> 运行训练 -> 发现异常 -> 修复异常直到训练成功 -> 编写代码 & yaml配置 -> (循环往复,优化成功率) -> ....
-
每个实验
8GPU
Experiment blueprints are designed to execute experiments that validate hypotheses or gather necessary data.
An experiment blueprint is a markdown file (blueprint.md). It must contain 7 sections (write clearly; no strict format required, but each section must have textual explanation):
-
[exp_purpose] Experiment purpose (text): Briefly describe the main purpose of this experiment and the key differences from other blueprints (e.g., which hyperparameter or environment variable differs).
-
[exp_codebase_dir] Main experiment code path (absolute path): The absolute path containing all code needed to run the experiment. Relatively small in size. Does not include the Python virtual environment. Default: ./
-
[exp_venv_exe] Python virtual environment path (absolute path to python executable): Path to the Python executable. Default: ./venv/bin/python
-
[exp_yaml_path] Experiment config file path (absolute path): Path to the experiment configuration YAML file. Should be placed alongside the blueprint file. Default: NA, the agent must write its own yaml file for the experiment.
-
[exp_launch_command] Training execution command (string): Default: the agent must write its own command
-
[exp_result_dir] Result data storage path (absolute path): Path for output data storage. Default: ./auto_agent/exp_results/
-
[exp_max_time] Maximum runtime is ${MaxTime}; each experiment is forcefully terminated after ${MaxTime} Default:
- MaxTime per run: 24 hours
- First step success timeout: 20 minutes (when you see the first kl loss value printed in tmux window, that means the first step is successful, if you did not see any kl loss value printed in tmux window after 20 minutes, that means the first step is failed, you can check the log file for details)
-
Additional notes: e.g., what preparation is needed before running, how to configure necessary dependencies; what cleanup is needed after running. Also, if the user's "main task description" contains critical information, attach it here. A todo list is recommended here.
Once blueprints are issued, other agents will execute them. Therefore, each section should have textual explanation — the more detailed the better.
Here is an example of an experiment blueprint (for exp_purpose ,exp_codebase_dir ,exp_venv_exe ,exp_yaml_path ,exp_launch_command ,exp_result_dir ,exp_max_time, add additonal fields such as description and hint):
<blueprint_example_begin>
# Experiment Blueprint
## [exp_purpose]
- description:
- hint:
- content 1:
- content 2:
- content 3:
## [exp_codebase_dir]
- description:
- hint:
- content 1:
- content 2:
- content 3:
- warning 1:
- warning 2:
## [exp_venv_exe]
- description:
- hint:
- content 1:
- content 2:
- content 3:
- warning 1:
- warning 2:
## [exp_yaml_path]
- description:
- hint:
- content 1:
- content 2:
- content 3:
- warning 1:
- warning 2:
## [exp_launch_command]
- description:
- hint:
- content 1:
- content 2:
- content 3:
- warning 1:
- warning 2:
## [exp_result_dir]
- description:
- hint:
- content 1:
- content 2:
- content 3:
- warning 1:
- warning 2:
## [exp_max_time]
- description:
- hint:
- content 1:
- content 2:
- content 3:
- warning 1:
- warning 2:
## Other Notes
- description:
- note 1:
- note 2:
- note 3:
- note 4:
- note 5:
....
<blueprint_example_end>
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.
- 3d ago First seen · 125 lines · 0 tokens per session scan A 45ee39c0eae3
blueprint_gen is a skill published in the GitHub repository binary-husky/AlphaAutoResearch (11 stars, last pushed 3mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 990 tokens. 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
instrument-data-to-allotrope
Convert laboratory instrument output files (PDF, CSV, Excel, TXT) to Allotrope Simple Model (ASM) JSON format or flattened 2D CSV. Use this skill when scientists need to standardize instrument data for LIMS systems, data lakes, or downstream analysis. Supports auto-detection of instrument types. Outputs include full…
exploratory-data-analysis
Perform bounded, local exploratory analysis of explicitly supported scientific files. Use for redacted CSV/TSV/JSON profiles; optional NumPy, HDF5, FASTA/FASTQ, and basic image metadata inspection; missingness/leakage audits; outlier and transformation sensitivity; and rigorous EDA report scaffolds. Other domain…
mapping-to-snomed
Maps clinical concept spans extracted by OpenMed to SNOMED CT concepts through a USER-SUPPLIED terminology server (the user's own Ontoserver, Snowstorm, or UMLS/UTS), never a bundled vocabulary. Use when the user wants to code findings, disorders, procedures, body structures, or substances to SNOMED CT, run an ECL…
auditing-subgroup-fairness
Audit an OpenMed NER or de-identification model for performance disparities across demographic subgroups (sex, age band, race/ethnicity when available) using openmed.eval.fairnessreport. Use when the user wants per-subgroup recall and leakage, wants to check whether de-identification under-protects a group, wants to…
overleaf-sync
Two-way sync between a local paper directory and an Overleaf project, so ARIS audit/edit workflows stay on the local copy while collaborators edit in the Overleaf web UI. Use when user says "同步 overleaf", "overleaf sync", "推送到 overleaf", "connect overleaf", "Overleaf 桥接", "pull overleaf", "push overleaf", or wants to…
mixed-precision
Use FP16/BF16 mixed precision to accelerate training and reduce memory. Use when optimizing GPU performance.