[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6M0MTE9BST8PT7ECHCC5KJK":3,"skill-same:01M6M0MTE9BST8PT7ECHCC5KJK":146},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":48,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":6,"ownerHtmlUrl":70,"ownerBlogUrl":71,"ownerDescription":72,"updatedAt":73,"install":74,"resources":87},"01M6M0MTE9BST8PT7ECHCC5KJK","build-research-paper",null,"Cross-domain \u002F Scientific writing and publication — Build\nbeautifully-formatted, arxiv-ready research paper PDFs from a mix of\nhand-authored LaTeX and\u002For markdown + PNG figures, using `tectonic`\n(default) or `pandoc` (escape hatch). Captures the reusable pattern that\nresearch projects keep re-discovering: `report\u002Fmain.tex` + `references.bib`\n+ `generate_figures.py` + iterative feedback\u002Fresponse scaffolding, all\nbuildable with a single command. WHEN: write a research paper, arxiv\nsubmission, prepub, generate PDF from markdown, LaTeX paper, build main.tex,\njournal manuscript, referee revision, response to referee, resubmission\npackage, publication-quality figures, matplotlib publication style, tectonic\nbuild, pandoc build, generate arxiv-ready PDF, bibliography from BibTeX.","microsoft\u002Fdiscovery","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BDVENS7NFPQQV19R5KA3B",289,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"build research paper","research","build","paper","scaffolding","hand","tectonic","mix","re","generate pdf","scientific","journal","PDF","main","references","default","ready","command","projects","writing","2026-11-10 10:12:30",false,"---\nname: build-research-paper\ndescription: |\n  Cross-domain \u002F Scientific writing and publication — Build\n  beautifully-formatted, arxiv-ready research paper PDFs from a mix of\n  hand-authored LaTeX and\u002For markdown + PNG figures, using `tectonic`\n  (default) or `pandoc` (escape hatch). Captures the reusable pattern that\n  research projects keep re-discovering: `report\u002Fmain.tex` + `references.bib`\n  + `generate_figures.py` + iterative feedback\u002Fresponse scaffolding, all\n  buildable with a single command. WHEN: write a research paper, arxiv\n  submission, prepub, generate PDF from markdown, LaTeX paper, build main.tex,\n  journal manuscript, referee revision, response to referee, resubmission\n  package, publication-quality figures, matplotlib publication style, tectonic\n  build, pandoc build, generate arxiv-ready PDF, bibliography from BibTeX.\nlicense: MIT\nmetadata:\n  author: Tim Meyers\n  version: \"2\"\n  category: \"Cross-domain\"\n  subfield: \"Scientific writing and publication\"\n---\n\n# build-research-paper — Research Paper Builder Skill\n\nTurn a project's results + figures + notes into a **publication-quality,\narxiv-ready PDF**. This skill captures a pattern re-discovered across many\nresearch projects, distilled into two build paths: a LaTeX-first path\n(`tectonic`, the default) and a Markdown-first path (`pandoc`, the escape\nhatch).\n\n## First: a paper is a paper\n\nRead this before touching `main.tex`, and re-read it before declaring done.\nEverything below is tooling. **This is the point.**\n\n**A paper is a document a human being reads, front to back, to learn\nsomething they did not know.** That is the whole definition. Not a compliance\nartifact. Not a results dump. Not a receipt proving work occurred. Not a\nserialization of a task tree.\n\nIt follows that:\n\n- **The paper has a thesis** — a story the data is telling. If you cannot say\n  in one sentence what this paper found, it is not ready, regardless of how\n  many sections exist. Write that sentence down before you write anything else.\n- **The reader is a domain expert, not a validator.** They came for the\n  finding. They will grant that you did the work carefully if you *show* them\n  it holds; they will not read twenty pages of proof that it does before being\n  told what \"it\" is.\n- **Figures carry the argument.** A picture shows shape; a table files values.\n  A data-analysis paper with no charts has not been written, only assembled.\n- **Rigor is the warrant, not the subject.** Provenance, validation, failure\n  logs and reproduction tests make the story *trustable*. They are not the\n  story. When they migrate to the front, the paper has inverted itself.\n- **Nothing in the body may be unresolvable to an outsider.** Internal task\n  IDs, ticket numbers, commit SHAs and pipeline filenames mean nothing to a\n  reader. If a sentence only parses inside your workspace, it is not prose.\n- **A paper is finished when someone has read it**, not when the checks pass.\n  Build the PDF, open it, and read it like a stranger would.\n\nThe characteristic agent failure mode is producing something that satisfies\nevery stated requirement and is still not a paper: technically correct,\nexhaustively sourced, verifiably reproducible, and unreadable. **Requirements\nare a floor, not a specification.** No list of criteria adds up to a document\nworth reading — that judgment is yours, and you have to exercise it.\n\nIf you find yourself optimizing a metric about the paper rather than the\npaper, stop and open the PDF.\n\n## When to use\n\nTrigger this skill whenever the user is working on a research report or\nmanuscript in a Discovery-style repo and asks to:\n\n- \"write \u002F build \u002F compile the paper\"\n- \"produce an arxiv-ready PDF\"\n- \"generate figures for the paper\"\n- \"respond to referee feedback \u002F do a revision pass\"\n- \"package for submission\"\n- Starts from scratch: \"we need to write up these results\"\n\nIf the repo already has a `report\u002Fmain.tex`, **prefer editing it** over\nregenerating from scratch. If it has no report directory yet, scaffold one\nwith `new-paper.sh`.\n\n## Locating this skill's scripts and templates\n\nThis skill can be installed as a personal skill, a project skill, or as part\nof a plugin, so never hardcode its location. Resolve it once per session and\nreuse `$SKILL_DIR`:\n\n```bash\nSKILL_DIR=$(dirname \"$(find ~\u002F.copilot\u002Fskills ~\u002F.copilot\u002Finstalled-plugins \\\n                            ~\u002F.agents\u002Fskills .github\u002Fskills .claude\u002Fskills \\\n                            .agents\u002Fskills \\\n                            -name new-paper.sh -path '*build-research-paper*' \\\n                            2>\u002Fdev\u002Fnull | head -1)\")\u002F..\nSKILL_DIR=$(cd \"$SKILL_DIR\" && pwd)\necho \"$SKILL_DIR\"\n```\n\nIf `$SKILL_DIR` does not resolve, tell the user the skill payload could not be\nlocated and stop. The scripts themselves self-locate their sibling\n`templates\u002F`, so they can be invoked from anywhere once found.\n\nThe bundled wrappers require Bash. They run directly on macOS and Linux; on\nWindows, use WSL or Git Bash. Before the first build, run\n`bash \"$SKILL_DIR\"\u002Fscripts\u002Fcheck-deps.sh` for platform-specific installation\nguidance. The Markdown path also requires `pandoc`; the default LaTeX path does\nnot.\n\n## The default pattern (hand-authored LaTeX + tectonic)\n\nThis is the workflow that produced the reference paper above. It is the\ndefault because it gives the best equation, theorem-environment, and figure\nplacement control, and arxiv expects LaTeX sources.\n\n```\n\u003Crepo>\u002Freport\u002F\n├── main.tex              # THE manuscript. Hand-authored \u002F agent-edited.\n├── references.bib        # BibTeX. Target 40+ entries for a full paper.\n├── generate_figures.py   # matplotlib -> figures\u002F*.pdf and figures\u002F*.png\n├── figures\u002F              # Both .pdf (vector, embedded in PDF) AND .png (for\n│                         #   markdown previews \u002F README). Version subdirs\n│                         #   (figures\u002Fv5\u002F) when you iterate.\n├── feedback_v{N}.md      # Referee report(s), one per revision round.\n├── response_to_referee_v{N}.md   # Point-by-point response letter.\n├── revision_checklist.md # Triage: A\u002FB\u002FC\u002FD\u002FE categories from feedback.\n├── v{N}_polish_log.md    # What changed in each polish pass.\n├── v{N}_edit_plan.md     # Plan for the next revision round.\n└── RESUBMISSION_PACKAGE.md   # Cover doc that describes the submission.\n```\n\n### Build command (default)\n\n```bash\ncd \u003Crepo>\u002Freport\ntectonic main.tex          # single command, self-contained, no *.aux junk\n```\n\nOr use the wrapper: `bash \"$SKILL_DIR\"\u002Fscripts\u002Fbuild.sh \u003Creport-dir>`.\n\nTectonic auto-fetches missing LaTeX packages, so the first build on a new\nmachine takes 30–60s; subsequent builds are fast. **Do not use pdflatex +\nbibtex + pdflatex + pdflatex** — that's what everyone re-discovers not to do.\n\n### Sanity checks after every build\n\nRun `bash \"$SKILL_DIR\"\u002Fscripts\u002Fcheck.sh \u003Creport-dir>` (or do these manually):\n\n1. `grep -n \"??\" main.pdf.log` — undefined references\n2. `grep -n \"Warning\" main.log | grep -iE \"citation|reference\"` — missing cites\n3. `grep -c \"\\\\\\\\cite\" main.tex` vs `grep -c \"@\" references.bib` — cite\u002Fbib coverage\n4. Every `\\includegraphics{figures\u002F...}` file exists on disk\n5. **The paper contains figures at all** — check 4 passes trivially at zero\n6. Any section named \"appendix\" actually follows an `\\appendix` command\n7. `main.pdf` opens; page count matches expectations\n\n### Then open the PDF and read it\n\n**Do not skip this, and do not substitute metrics for it.** In the\na project post-mortem, days were spent verifying page counts, citation\ncoverage and reproduction tests without anyone opening `main.pdf`. Both\ndefects that eventually mattered — an appendix printed as body section 2, and\nzero figures — were visible immediately to the first person who scrolled it.\n\nRead the built PDF front to back and ask:\n\n- Following it from page one, **do I find the story**, or an audit trail?\n- **Do the figures carry the argument**, or is every claim a table?\n- Does anything in the body reference something a reader cannot resolve?\n- Is the machinery at the back where it belongs?\n\nThe audience test: **a domain reader is reading this, not a validator.**\nMetrics describe the deliverable; they are not the deliverable.\n\n## The escape hatch (markdown + pandoc)\n\nUse this when the user hasn't written any LaTeX and wants a fast draft, or\nfor shorter pieces (technical notes, RFI responses — the pattern used in\na Markdown-first project directory).\n\n```\n\u003Crepo>\u002Freport\u002F\n├── manuscript.md         # Standard markdown with $math$, ![figs](path), refs\n├── header.tex            # LaTeX preamble that pandoc will inject\n├── references.bib\n├── figures\u002F*.png         # PNG is fine here; pandoc will embed\n└── build-md.sh\n```\n\nBuild: `bash \"$SKILL_DIR\"\u002Fscripts\u002Fbuild-md.sh \u003Creport-dir>`.\n\nUnder the hood: `pandoc manuscript.md -o main.pdf --pdf-engine=tectonic\n--include-in-header=header.tex --citeproc --bibliography=references.bib`.\n\n## Starter templates\n\nAll under `\"$SKILL_DIR\"\u002Ftemplates\u002F`:\n\n- `main.tex` — arxiv-ready single-column article skeleton with the exact\n  package stack used by the bundled `main.tex` (natbib, booktabs,\n  algorithm\u002Falgpseudocode, cleveref, hyperref[hidelinks], theorem envs).\n- `references.bib` — empty starter with a comment block explaining\n  BibTeX key conventions.\n- `header.tex` — the pandoc preamble variant (from the Markdown-first pattern).\n- `generate_figures.py` — matplotlib publication style + PDF+PNG dual output.\n\nCopy these into the target repo with\n`bash \"$SKILL_DIR\"\u002Fscripts\u002Fnew-paper.sh \u003Ctarget-repo>`, then edit — never\nsymlink, because each project needs to diverge.\n\n## Figure discipline\n\nThe single most re-discovered lesson:\n\n0. **THE PAPER MUST ACTUALLY HAVE FIGURES.** Before the rules below can help\n   you, figures have to exist. Rules 1–4 are all *universally quantified* —\n   \"every figure has a script\", \"every figure is saved as both formats\" — and\n   **every one of them is vacuously true of a paper with zero figures.**\n   A reviewed 47-page data-analysis paper passed a\n   requirement reading \"every published figure is emitted by committed\n   pipeline code\" while containing **no charts at all**, and shipped with 55\n   tables instead. A human found it in ten seconds of scrolling; no automated\n   gate ever could, because nothing was false.\n\n   > **General rule, applies far beyond this skill: any \"every X must Y\"\n   > criterion is satisfied by producing no X. Pair every universally\n   > quantified check with an existence check.** `scripts\u002Fcheck.sh` now\n   > counts figures for exactly this reason.\n\n   A contributing cause was lexical: that project used \"figure\" to mean\n   *number* throughout (\"headline figures\", \"prevalence figures\"), so the\n   visual sense was never tested. When a project overloads the word, say\n   **chart \u002F plot \u002F visualization** in requirements so the check is unambiguous.\n\n   Sizing guidance: a full empirical paper wants **6+ figures**. If you are\n   below 4, ask what the reader should *see*. **Tables do not count** — a\n   table files data, a figure shows shape. Where a chart renders a\n   distribution better than a table, *replace* the table; do not print both.\n   Forty tables in one section is a filing cabinet, not an argument.\n\n1. **Every figure has a `.py` script** that regenerates it deterministically\n   from experimental data (results JSON\u002FCSV). Never hand-edit figure files.\n2. **Every figure is saved as BOTH `.pdf` (vector) AND `.png` (raster)** in\n   the same directory. `main.tex` uses `.pdf`; markdown previews use `.png`.\n3. **Set publication style once** at the top of `generate_figures.py`\n   (see template — font.family='serif', dpi=300, savefig.bbox='tight').\n4. **Version the figures directory** (`figures\u002Fv3\u002F`, `figures\u002Fv5\u002F`) when\n   revising, so old paper builds stay reproducible.\n5. **Place figures in the body, beside the claim they support.** Never\n   warehouse them in an appendix. Captions state N and, where more than one\n   denominator is in play, which one applies.\n6. **A figure must never contradict its table.** If both survive, have the\n   verification script check the figure's source values against the same\n   artifact the table reads, so a chart cannot silently drift.\n\n## Document order and register\n\nMechanically correct papers fail here, and only a human reader notices.\n\n### Default paper shape\n\nUse this as the starting skeleton for any new paper unless the user's\nprompt calls for something different (a short technical note, a specific\njournal template, a workshop 4-pager, etc.). It reflects the reading order\nthat works for the empirical Discovery-style papers this skill exists to\nsupport.\n\n```\n1. Abstract\n2. Introduction\n3. Background and Related Work\n4. \u003CA section (with subsections) describing the work we did>\n5. \u003CA section (with subsections) describing the findings>\n6. Limitations and\u002For Future Work                    [optional]\n7. Acknowledgements                                  [optional]\n8. Conclusion\n9. References  (a.k.a. Bibliography or Citations)\n10. Appendix 1 - \u003CTitle>\n    Appendix 2 - \u003CTitle>\n    …                                                [zero or more]\n```\n\nNotes on the shape:\n\n- **Sections 4 and 5 are placeholders** — name them for *this* paper's\n  contribution, not literally \"The Work\" and \"The Findings\". \"Methods\",\n  \"System\", \"Approach\", \"Experiments\", \"Evaluation\", \"Results\", and\n  domain-specific titles are all fair game. What matters is that the\n  work-we-did section precedes the findings section, and both precede\n  the conclusion.\n- **Every appendix is titled `Appendix N - \u003CTitle>`** (e.g., \"Appendix 1\n  - Provenance and Data Sources\", \"Appendix 2 - Validation History\").\n  Issue `\\appendix` before the first one so LaTeX letters them properly\n  (A, B, C…) — the `N` in the label is the reader-facing ordinal, not\n  necessarily the LaTeX section number.\n- Provenance, validation history, failure logs, exhaustive method\n  detail, and long tables belong in appendices — not in the body.\n- Prefer the singular \"Conclusion\" over \"Conclusions\" unless there\n  really are several distinct concluding claims.\n- **This is guidance, not a straitjacket.** A more specific prompt\n  instruction (e.g., \"follow the NeurIPS template\", \"this is a\n  two-page RFI response\", \"combine background into introduction\")\n  overrules the default shape. When in doubt, ask.\n\n### Order sections for a reader, not for the author\n\nAssembling `\\input{}` lines in the order tasks finished is how a 20-page\nprocess\u002Fvalidation appendix ended up as **body section 2 of 5**, ahead of\nevery finding. Reading order is:\n\n```\nabstract → introduction → background → work → FINDINGS → discussion\n        → conclusion → references → \\appendix → provenance, validation, logs\n```\n\n- Issue `\\appendix` before the back-matter `\\input{}`s. Without it LaTeX\n  renders them as numbered body sections — the file name says \"appendix\" but\n  the PDF says \"2\". `check.sh` flags this.\n- Consider putting findings **before** an evidence-appraisal section: a reader\n  wants the story before an assessment of the evidence beneath it.\n- Methodology in the body should be short and readable; the exhaustive version\n  belongs in the appendix.\n\n**Purge internal identifiers from body prose.** Task IDs (`DX-17`), ticket\nnumbers, commit SHAs, pipeline artifact names and `.py` filenames are\nunresolvable to anyone outside the workspace. Replace the handle with the\nthing itself, cross-referencing the appendix where provenance matters — but\n**never silently delete a reference that carried meaning**; the replacement\nmust still get the reader there by a route they can follow. Internal IDs are\ncorrect *inside* the provenance appendix. Stable public identifiers (dataset\nrecord IDs, DOIs, accession numbers) stay.\n\n**Reproducibility is the paper's warrant, not its subject.** Sourcing and\nvalidation make the narrative trustable; they are not the narrative. When\nprocess material crowds out findings, the paper has inverted itself.\n\n**Use American English spelling and usage throughout.** This is a hard rule\nfor every artifact this skill produces — `main.tex`, `manuscript.md`,\nfigure captions, `references.bib` comments, response letters, checklists,\npolish logs, and the `RESUBMISSION_PACKAGE.md` cover doc. Prefer `-ize` over\n`-ise` (organize, analyze, optimize, characterize, summarize), `-or` over\n`-our` (color, behavior, favor, labor), `-er` over `-re` (center, fiber,\nliter), and American variants elsewhere (gray, program, catalog, defense,\nlicense as a noun, toward, while, among, learned, spelled). Preserve\nBritish spellings only inside proper nouns, direct quotations, and cited\ntitles in `references.bib` — never \"fix\" a quote or a published title.\nWhen editing pre-existing prose from a user or referee, silently normalize\ntheir spellings to American English in the manuscript unless the user\nexplicitly requests otherwise.\n\n## Iterative revision pattern\n\nWhen the user shares referee feedback, run this loop:\n\n1. Save the referee report verbatim as `feedback_v{N}.md`.\n2. Create `revision_checklist.md` triaging every point into categories\n   (A: theory, B: empirics, C: claim discipline, D: scope, E: writing).\n3. Draft `response_to_referee_v{N}.md` with a point-by-point table:\n   `| # | Referee point | Section | Response |`.\n4. Edit `main.tex` addressing each item; log what changed in\n   `v{N}_polish_log.md`.\n5. Build. Re-check. Update `RESUBMISSION_PACKAGE.md`.\n\nKeep real examples of all five artifacts in your own `report\u002F` directory —\nread them for style before drafting the next revision.\n\n## arXiv submission checklist\n\nBefore declaring \"arxiv-ready\":\n\n- [ ] Single self-contained `main.tex` (no `\\input{}` chains beyond the bib)\n- [ ] All figures are PDF or PNG (no EPS, no proprietary formats)\n- [ ] **The paper HAS figures** — 6+ for a full empirical paper; tables don't count\n- [ ] `generate_figures.py` committed, and it emits every published figure\n- [ ] Sections in reading order; `\\appendix` issued before back-matter\n- [ ] No internal task IDs, ticket numbers or commit SHAs in body prose\n- [ ] American English spelling and usage throughout (see \"Document order and register\")\n- [ ] `references.bib` present; every `\\cite{...}` resolves\n- [ ] No undefined references \u002F `??` in the PDF\n- [ ] `\\usepackage{hyperref}` loaded **before** cleveref\u002Fdoi (cleveref patches hyperref, so it must load after; doi also depends on hyperref)\n- [ ] Title, single-line author with affiliation footnote, abstract present\n- [ ] Line length ≤ 100 chars in `.tex` (arxiv's tar preserves lines)\n- [ ] Build produces PDF ≤ 10 MB (arxiv soft limit)\n- [ ] **Someone opened the PDF and read it end to end**\n- [ ] Zip: `zip -r submission.zip main.tex references.bib figures\u002F`\n\nSee `references\u002Farxiv-submission.md` for the full checklist.\n\n## Files this skill provides\n\n```\nbuild-research-paper\u002F\n├── SKILL.md                          # this file\n├── templates\u002F\n│   ├── main.tex                      # LaTeX skeleton\n│   ├── references.bib                # empty starter\n│   ├── header.tex                    # pandoc preamble\n│   └── generate_figures.py           # matplotlib pub style\n├── scripts\u002F\n│   ├── check-deps.sh                 # dependency and platform preflight\n│   ├── new-paper.sh                  # scaffold report\u002F dir\n│   ├── build.sh                      # tectonic build (default)\n│   ├── build-md.sh                   # pandoc build (escape hatch)\n│   └── check.sh                      # post-build sanity checks\n└── references\u002F\n    ├── patterns.md                   # deeper notes from both build patterns\n    ├── review-cycle.md               # feedback_vN convention details\n    └── arxiv-submission.md           # arxiv rules & full pre-submit checklist\n```\n\n## Installing from the Microsoft Discovery catalog\n\nInstall the skill directly from the public Microsoft Discovery repository:\n\n```bash\ngh skill install microsoft\u002Fdiscovery build-research-paper\n```\n\nAfter installation, use it whenever building or revising `report\u002Fmain.tex`,\ngenerating publication figures, or packaging a submission.\n","# build-research-paper — Research Paper Builder Skill\n\nTurn a project's results + figures + notes into a **publication-quality,\narxiv-ready PDF**. This skill captures a pattern re-discovered across many\nresearch projects, distilled into two build paths: a LaTeX-first path\n(`tectonic`, the default) and a Markdown-first path (`pandoc`, the escape\nhatch).\n\n## First: a paper is a paper\n\nRead this before touching `main.tex`, and re-read it before declaring done.\nEverything below is tooling. **This is the point.**\n\n**A paper is a document a human being reads, front to back, to learn\nsomething they did not know.** That is the whole definition. Not a compliance\nartifact. Not a results dump. Not a receipt proving work occurred. Not a\nserialization of a task tree.\n\nIt follows that:\n\n- **The paper has a thesis** — a story the data is telling. If you cannot say\n  in one sentence what this paper found, it is not ready, regardless of how\n  many sections exist. Write that sentence down before you write anything else.\n- **The reader is a domain expert, not a validator.** They came for the\n  finding. They will grant that you did the work carefully if you *show* them\n  it holds; they will not read twenty pages of proof that it does before being\n  told what \"it\" is.\n- **Figures carry the argument.** A picture shows shape; a table files values.\n  A data-analysis paper with no charts has not been written, only assembled.\n- **Rigor is the warrant, not the subject.** Provenance, validation, failure\n  logs and reproduction tests make the story *trustable*. They are not the\n  story. When they migrate to the front, the paper has inverted itself.\n- **Nothing in the body may be unresolvable to an outsider.** Internal task\n  IDs, ticket numbers, commit SHAs and pipeline filenames mean nothing to a\n  reader. If a sentence only parses inside your workspace, it is not prose.\n- **A paper is finished when someone has read it**, not when the checks pass.\n  Build the PDF, open it, and read it like a stranger would.\n\nThe characteristic agent failure mode is producing something that satisfies\nevery stated requirement and is still not a paper: technically correct,\nexhaustively sourced, verifiably reproducible, and unreadable. **Requirements\nare a floor, not a specification.** No list of criteria adds up to a document\nworth reading — that judgment is yours, and you have to exercise it.\n\nIf you find yourself optimizing a metric about the paper rather than the\npaper, stop and open the PDF.\n\n## When to use\n\nTrigger this skill whenever the user is working on a research report or\nmanuscript in a Discovery-style repo and asks to:\n\n- \"write \u002F build \u002F compile the paper\"\n- \"produce an arxiv-ready PDF\"\n- \"generate figures for the paper\"\n- \"respond to referee feedback \u002F do a revision pass\"\n- \"package for submission\"\n- Starts from scratch: \"we need to write up these results\"\n\nIf the repo already has a `report\u002Fmain.tex`, **prefer editing it** over\nregenerating from scratch. If it has no report directory yet, scaffold one\nwith `new-paper.sh`.\n\n## Locating this skill's scripts and templates\n\nThis skill can be installed as a personal skill, a project skill, or as part\nof a plugin, so never hardcode its location. Resolve it once per session and\nreuse `$SKILL_DIR`:\n\n```bash\nSKILL_DIR=$(dirname \"$(find ~\u002F.copilot\u002Fskills ~\u002F.copilot\u002Finstalled-plugins \\\n                            ~\u002F.agents\u002Fskills .github\u002Fskills .claude\u002Fskills \\\n                            .agents\u002Fskills \\\n                            -name new-paper.sh -path '*build-research-paper*' \\\n                            2>\u002Fdev\u002Fnull | head -1)\")\u002F..\nSKILL_DIR=$(cd \"$SKILL_DIR\" && pwd)\necho \"$SKILL_DIR\"\n```\n\nIf `$SKILL_DIR` does not resolve, tell the user the skill payload could not be\nlocated and stop. The scripts themselves self-locate their sibling\n`templates\u002F`, so they can be invoked from anywhere once found.\n\nThe bundled wrappers require Bash. They run directly on macOS and Linux; on\nWindows, use WSL or Git Bash. Before the first build, run\n`bash \"$SKILL_DIR\"\u002Fscripts\u002Fcheck-deps.sh` for platform-specific installation\nguidance. The Markdown path also requires `pandoc`; the default LaTeX path does\nnot.\n\n## The default pattern (hand-authored LaTeX + tectonic)\n\nThis is the workflow that produced the reference paper above. It is the\ndefault because it gives the best equation, theorem-environment, and figure\nplacement control, and arxiv expects LaTeX sources.\n\n```\n\u003Crepo>\u002Freport\u002F\n├── main.tex              # THE manuscript. Hand-authored \u002F agent-edited.\n├── references.bib        # BibTeX. Target 40+ entries for a full paper.\n├── generate_figures.py   # matplotlib -> figures\u002F*.pdf and figures\u002F*.png\n├── figures\u002F              # Both .pdf (vector, embedded in PDF) AND .png (for\n│                         #   markdown previews \u002F README). Version subdirs\n│                         #   (figures\u002Fv5\u002F) when you iterate.\n├── feedback_v{N}.md      # Referee report(s), one per revision round.\n├── response_to_referee_v{N}.md   # Point-by-point response letter.\n├── revision_checklist.md # Triage: A\u002FB\u002FC\u002FD\u002FE categories from feedback.\n├── v{N}_polish_log.md    # What changed in each polish pass.\n├── v{N}_edit_plan.md     # Plan for the next revision round.\n└── RESUBMISSION_PACKAGE.md   # Cover doc that describes the submission.\n```\n\n### Build command (default)\n\n```bash\ncd \u003Crepo>\u002Freport\ntectonic main.tex          # single command, self-contained, no *.aux junk\n```\n\nOr use the wrapper: `bash \"$SKILL_DIR\"\u002Fscripts\u002Fbuild.sh \u003Creport-dir>`.\n\nTectonic auto-fetches missing LaTeX packages, so the first build on a new\nmachine takes 30–60s; subsequent builds are fast. **Do not use pdflatex +\nbibtex + pdflatex + pdflatex** — that's what everyone re-discovers not to do.\n\n### Sanity checks after every build\n\nRun `bash \"$SKILL_DIR\"\u002Fscripts\u002Fcheck.sh \u003Creport-dir>` (or do these manually):\n\n1. `grep -n \"??\" main.pdf.log` — undefined references\n2. `grep -n \"Warning\" main.log | grep -iE \"citation|reference\"` — missing cites\n3. `grep -c \"\\\\\\\\cite\" main.tex` vs `grep -c \"@\" references.bib` — cite\u002Fbib coverage\n4. Every `\\includegraphics{figures\u002F...}` file exists on disk\n5. **The paper contains figures at all** — check 4 passes trivially at zero\n6. Any section named \"appendix\" actually follows an `\\appendix` command\n7. `main.pdf` opens; page count matches expectations\n\n### Then open the PDF and read it\n\n**Do not skip this, and do not substitute metrics for it.** In the\na project post-mortem, days were spent verifying page counts, citation\ncoverage and reproduction tests without anyone opening `main.pdf`. Both\ndefects that eventually mattered — an appendix printed as body section 2, and\nzero figures — were visible immediately to the first person who scrolled it.\n\nRead the built PDF front to back and ask:\n\n- Following it from page one, **do I find the story**, or an audit trail?\n- **Do the figures carry the argument**, or is every claim a table?\n- Does anything in the body reference something a reader cannot resolve?\n- Is the machinery at the back where it belongs?\n\nThe audience test: **a domain reader is reading this, not a validator.**\nMetrics describe the deliverable; they are not the deliverable.\n\n## The escape hatch (markdown + pandoc)\n\nUse this when the user hasn't written any LaTeX and wants a fast draft, or\nfor shorter pieces (technical notes, RFI responses — the pattern used in\na Markdown-first project directory).\n\n```\n\u003Crepo>\u002Freport\u002F\n├── manuscript.md         # Standard markdown with $math$, ![figs](path), refs\n├── header.tex            # LaTeX preamble that pandoc will inject\n├── references.bib\n├── figures\u002F*.png         # PNG is fine here; pandoc will embed\n└── build-md.sh\n```\n\nBuild: `bash \"$SKILL_DIR\"\u002Fscripts\u002Fbuild-md.sh \u003Creport-dir>`.\n\nUnder the hood: `pandoc manuscript.md -o main.pdf --pdf-engine=tectonic\n--include-in-header=header.tex --citeproc --bibliography=references.bib`.\n\n## Starter templates\n\nAll under `\"$SKILL_DIR\"\u002Ftemplates\u002F`:\n\n- `main.tex` — arxiv-ready single-column article skeleton with the exact\n  package stack used by the bundled `main.tex` (natbib, booktabs,\n  algorithm\u002Falgpseudocode, cleveref, hyperref[hidelinks], theorem envs).\n- `references.bib` — empty starter with a comment block explaining\n  BibTeX key conventions.\n- `header.tex` — the pandoc preamble variant (from the Markdown-first pattern).\n- `generate_figures.py` — matplotlib publication style + PDF+PNG dual output.\n\nCopy these into the target repo with\n`bash \"$SKILL_DIR\"\u002Fscripts\u002Fnew-paper.sh \u003Ctarget-repo>`, then edit — never\nsymlink, because each project needs to diverge.\n\n## Figure discipline\n\nThe single most re-discovered lesson:\n\n0. **THE PAPER MUST ACTUALLY HAVE FIGURES.** Before the rules below can help\n   you, figures have to exist. Rules 1–4 are all *universally quantified* —\n   \"every figure has a script\", \"every figure is saved as both formats\" — and\n   **every one of them is vacuously true of a paper with zero figures.**\n   A reviewed 47-page data-analysis paper passed a\n   requirement reading \"every published figure is emitted by committed\n   pipeline code\" while containing **no charts at all**, and shipped with 55\n   tables instead. A human found it in ten seconds of scrolling; no automated\n   gate ever could, because nothing was false.\n\n   > **General rule, applies far beyond this skill: any \"every X must Y\"\n   > criterion is satisfied by producing no X. Pair every universally\n   > quantified check with an existence check.** `scripts\u002Fcheck.sh` now\n   > counts figures for exactly this reason.\n\n   A contributing cause was lexical: that project used \"figure\" to mean\n   *number* throughout (\"headline figures\", \"prevalence figures\"), so the\n   visual sense was never tested. When a project overloads the word, say\n   **chart \u002F plot \u002F visualization** in requirements so the check is unambiguous.\n\n   Sizing guidance: a full empirical paper wants **6+ figures**. If you are\n   below 4, ask what the reader should *see*. **Tables do not count** — a\n   table files data, a figure shows shape. Where a chart renders a\n   distribution better than a table, *replace* the table; do not print both.\n   Forty tables in one section is a filing cabinet, not an argument.\n\n1. **Every figure has a `.py` script** that regenerates it deterministically\n   from experimental data (results JSON\u002FCSV). Never hand-edit figure files.\n2. **Every figure is saved as BOTH `.pdf` (vector) AND `.png` (raster)** in\n   the same directory. `main.tex` uses `.pdf`; markdown previews use `.png`.\n3. **Set publication style once** at the top of `generate_figures.py`\n   (see template — font.family='serif', dpi=300, savefig.bbox='tight').\n4. **Version the figures directory** (`figures\u002Fv3\u002F`, `figures\u002Fv5\u002F`) when\n   revising, so old paper builds stay reproducible.\n5. **Place figures in the body, beside the claim they support.** Never\n   warehouse them in an appendix. Captions state N and, where more than one\n   denominator is in play, which one applies.\n6. **A figure must never contradict its table.** If both survive, have the\n   verification script check the figure's source values against the same\n   artifact the table reads, so a chart cannot silently drift.\n\n## Document order and register\n\nMechanically correct papers fail here, and only a human reader notices.\n\n### Default paper shape\n\nUse this as the starting skeleton for any new paper unless the user's\nprompt calls for something different (a short technical note, a specific\njournal template, a workshop 4-pager, etc.). It reflects the reading order\nthat works for the empirical Discovery-style papers this skill exists to\nsupport.\n\n```\n1. Abstract\n2. Introduction\n3. Background and Related Work\n4. \u003CA section (with subsections) describing the work we did>\n5. \u003CA section (with subsections) describing the findings>\n6. Limitations and\u002For Future Work                    [optional]\n7. Acknowledgements                                  [optional]\n8. Conclusion\n9. References  (a.k.a. Bibliography or Citations)\n10. Appendix 1 - \u003CTitle>\n    Appendix 2 - \u003CTitle>\n    …                                                [zero or more]\n```\n\nNotes on the shape:\n\n- **Sections 4 and 5 are placeholders** — name them for *this* paper's\n  contribution, not literally \"The Work\" and \"The Findings\". \"Methods\",\n  \"System\", \"Approach\", \"Experiments\", \"Evaluation\", \"Results\", and\n  domain-specific titles are all fair game. What matters is that the\n  work-we-did section precedes the findings section, and both precede\n  the conclusion.\n- **Every appendix is titled `Appendix N - \u003CTitle>`** (e.g., \"Appendix 1\n  - Provenance and Data Sources\", \"Appendix 2 - Validation History\").\n  Issue `\\appendix` before the first one so LaTeX letters them properly\n  (A, B, C…) — the `N` in the label is the reader-facing ordinal, not\n  necessarily the LaTeX section number.\n- Provenance, validation history, failure logs, exhaustive method\n  detail, and long tables belong in appendices — not in the body.\n- Prefer the singular \"Conclusion\" over \"Conclusions\" unless there\n  really are several distinct concluding claims.\n- **This is guidance, not a straitjacket.** A more specific prompt\n  instruction (e.g., \"follow the NeurIPS template\", \"this is a\n  two-page RFI response\", \"combine background into introduction\")\n  overrules the default shape. When in doubt, ask.\n\n### Order sections for a reader, not for the author\n\nAssembling `\\input{}` lines in the order tasks finished is how a 20-page\nprocess\u002Fvalidation appendix ended up as **body section 2 of 5**, ahead of\nevery finding. Reading order is:\n\n```\nabstract → introduction → background → work → FINDINGS → discussion\n        → conclusion → references → \\appendix → provenance, validation, logs\n```\n\n- Issue `\\appendix` before the back-matter `\\input{}`s. Without it LaTeX\n  renders them as numbered body sections — the file name says \"appendix\" but\n  the PDF says \"2\". `check.sh` flags this.\n- Consider putting findings **before** an evidence-appraisal section: a reader\n  wants the story before an assessment of the evidence beneath it.\n- Methodology in the body should be short and readable; the exhaustive version\n  belongs in the appendix.\n\n**Purge internal identifiers from body prose.** Task IDs (`DX-17`), ticket\nnumbers, commit SHAs, pipeline artifact names and `.py` filenames are\nunresolvable to anyone outside the workspace. Replace the handle with the\nthing itself, cross-referencing the appendix where provenance matters — but\n**never silently delete a reference that carried meaning**; the replacement\nmust still get the reader there by a route they can follow. Internal IDs are\ncorrect *inside* the provenance appendix. Stable public identifiers (dataset\nrecord IDs, DOIs, accession numbers) stay.\n\n**Reproducibility is the paper's warrant, not its subject.** Sourcing and\nvalidation make the narrative trustable; they are not the narrative. When\nprocess material crowds out findings, the paper has inverted itself.\n\n**Use American English spelling and usage throughout.** This is a hard rule\nfor every artifact this skill produces — `main.tex`, `manuscript.md`,\nfigure captions, `references.bib` comments, response letters, checklists,\npolish logs, and the `RESUBMISSION_PACKAGE.md` cover doc. Prefer `-ize` over\n`-ise` (organize, analyze, optimize, characterize, summarize), `-or` over\n`-our` (color, behavior, favor, labor), `-er` over `-re` (center, fiber,\nliter), and American variants elsewhere (gray, program, catalog, defense,\nlicense as a noun, toward, while, among, learned, spelled). Preserve\nBritish spellings only inside proper nouns, direct quotations, and cited\ntitles in `references.bib` — never \"fix\" a quote or a published title.\nWhen editing pre-existing prose from a user or referee, silently normalize\ntheir spellings to American English in the manuscript unless the user\nexplicitly requests otherwise.\n\n## Iterative revision pattern\n\nWhen the user shares referee feedback, run this loop:\n\n1. Save the referee report verbatim as `feedback_v{N}.md`.\n2. Create `revision_checklist.md` triaging every point into categories\n   (A: theory, B: empirics, C: claim discipline, D: scope, E: writing).\n3. Draft `response_to_referee_v{N}.md` with a point-by-point table:\n   `| # | Referee point | Section | Response |`.\n4. Edit `main.tex` addressing each item; log what changed in\n   `v{N}_polish_log.md`.\n5. Build. Re-check. Update `RESUBMISSION_PACKAGE.md`.\n\nKeep real examples of all five artifacts in your own `report\u002F` directory —\nread them for style before drafting the next revision.\n\n## arXiv submission checklist\n\nBefore declaring \"arxiv-ready\":\n\n- [ ] Single self-contained `main.tex` (no `\\input{}` chains beyond the bib)\n- [ ] All figures are PDF or PNG (no EPS, no proprietary formats)\n- [ ] **The paper HAS figures** — 6+ for a full empirical paper; tables don't count\n- [ ] `generate_figures.py` committed, and it emits every published figure\n- [ ] Sections in reading order; `\\appendix` issued before back-matter\n- [ ] No internal task IDs, ticket numbers or commit SHAs in body prose\n- [ ] American English spelling and usage throughout (see \"Document order and register\")\n- [ ] `references.bib` present; every `\\cite{...}` resolves\n- [ ] No undefined references \u002F `??` in the PDF\n- [ ] `\\usepackage{hyperref}` loaded **before** cleveref\u002Fdoi (cleveref patches hyperref, so it must load after; doi also depends on hyperref)\n- [ ] Title, single-line author with affiliation footnote, abstract present\n- [ ] Line length ≤ 100 chars in `.tex` (arxiv's tar preserves lines)\n- [ ] Build produces PDF ≤ 10 MB (arxiv soft limit)\n- [ ] **Someone opened the PDF and read it end to end**\n- [ ] Zip: `zip -r submission.zip main.tex references.bib figures\u002F`\n\nSee `references\u002Farxiv-submission.md` for the full checklist.\n\n## Files this skill provides\n\n```\nbuild-research-paper\u002F\n├── SKILL.md                          # this file\n├── templates\u002F\n│   ├── main.tex                      # LaTeX skeleton\n│   ├── references.bib                # empty starter\n│   ├── header.tex                    # pandoc preamble\n│   └── generate_figures.py           # matplotlib pub style\n├── scripts\u002F\n│   ├── check-deps.sh                 # dependency and platform preflight\n│   ├── new-paper.sh                  # scaffold report\u002F dir\n│   ├── build.sh                      # tectonic build (default)\n│   ├── build-md.sh                   # pandoc build (escape hatch)\n│   └── check.sh                      # post-build sanity checks\n└── references\u002F\n    ├── patterns.md                   # deeper notes from both build patterns\n    ├── review-cycle.md               # feedback_vN convention details\n    └── arxiv-submission.md           # arxiv rules & full pre-submit checklist\n```\n\n## Installing from the Microsoft Discovery catalog\n\nInstall the skill directly from the public Microsoft Discovery repository:\n\n```bash\ngh skill install microsoft\u002Fdiscovery build-research-paper\n```\n\nAfter installation, use it whenever building or revising `report\u002Fmain.tex`,\ngenerating publication figures, or packaging a submission.\n",{"name":5,"license":15,"metadata":60,"description":65},{"author":61,"version":62,"category":63,"subfield":64},"Tim Meyers","2","Cross-domain","Scientific writing and publication","Cross-domain \u002F Scientific writing and publication — Build\nbeautifully-formatted, arxiv-ready research paper PDFs from a mix of\nhand-authored LaTeX and\u002For markdown + PNG figures, using `tectonic`\n(default) or `pandoc` (escape hatch). Captures the reusable pattern that\nresearch projects keep re-discovering: `report\u002Fmain.tex` + `references.bib`\n+ `generate_figures.py` + iterative feedback\u002Fresponse scaffolding, all\nbuildable with a single command. WHEN: write a research paper, arxiv\nsubmission, prepub, generate PDF from markdown, LaTeX paper, build main.tex,\njournal manuscript, referee revision, response to referee, resubmission\npackage, publication-quality figures, matplotlib publication style, tectonic\nbuild, pandoc build, generate arxiv-ready PDF, bibliography from BibTeX.\n","cf09508181841f379724f7287bc74e8852360ae6","skills\u002Fbuild-research-paper",100,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 00:05:47",{"source":8,"skillName":5,"commands":75,"prompt":85,"zipAvailable":86},[76,79,82],{"tool":77,"command":78},"npx","npx skills add microsoft\u002Fdiscovery --skill build-research-paper",{"tool":80,"command":81},"bunx","bunx skills add microsoft\u002Fdiscovery --skill build-research-paper",{"tool":83,"command":84},"pnpm","pnpm dlx skills add microsoft\u002Fdiscovery --skill build-research-paper","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002FSKILL.md",true,[88,94,98,102,106,112,116,120,124,128,132,138,142],{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Farxiv-submission.md","REFERENCE","参考文档",3598,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Freferences\u002Farxiv-submission.md",{"path":95,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fpatterns.md",4420,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Freferences\u002Fpatterns.md",{"path":99,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Freview-cycle.md",3335,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Freferences\u002Freview-cycle.md",{"path":103,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":104,"sourceHtmlUrl":105},"requirements.txt",28,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Frequirements.txt",{"path":107,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":110,"sourceHtmlUrl":111},"scripts\u002Fbuild-md.sh","SCRIPT","脚本",983,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Fscripts\u002Fbuild-md.sh",{"path":113,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":114,"sourceHtmlUrl":115},"scripts\u002Fbuild.sh",835,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Fscripts\u002Fbuild.sh",{"path":117,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":118,"sourceHtmlUrl":119},"scripts\u002Fcheck-deps.sh",2021,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Fscripts\u002Fcheck-deps.sh",{"path":121,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":122,"sourceHtmlUrl":123},"scripts\u002Fcheck.sh",4898,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Fscripts\u002Fcheck.sh",{"path":125,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":126,"sourceHtmlUrl":127},"scripts\u002Fnew-paper.sh",2075,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Fscripts\u002Fnew-paper.sh",{"path":129,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":130,"sourceHtmlUrl":131},"templates\u002Fgenerate_figures.py",2882,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Ftemplates\u002Fgenerate_figures.py",{"path":133,"resourceType":134,"resourceTypeDesc":135,"sizeBytes":136,"sourceHtmlUrl":137},"templates\u002Fheader.tex","OTHER","其他",2480,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Ftemplates\u002Fheader.tex",{"path":139,"resourceType":134,"resourceTypeDesc":135,"sizeBytes":140,"sourceHtmlUrl":141},"templates\u002Fmain.tex",4440,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Ftemplates\u002Fmain.tex",{"path":143,"resourceType":134,"resourceTypeDesc":135,"sizeBytes":144,"sourceHtmlUrl":145},"templates\u002Freferences.bib",817,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-research-paper\u002Ftemplates\u002Freferences.bib",[147,166,204,215,228,241],{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":55},"01M6PJFHF9C2GSFK8DFW6D5RF7","token-estimator-mvp","Estimate AI planning ranges from a work description or explicitly authorized safe project context. Provides coarse class ranges or conditional planning bases without requiring token guesses.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Ftoken-estimator-mvp\u002FSKILL.md",[],[154,155,156,157,158,159,160,161,162,163,164,165],"token estimator mvp","mvp","token","safe","planning","work","context","bases","project context","project","estimate","conditional",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":184,"publishedAt":55},"01M69BE9GW375EBM6ETNWD84E3","add-example-agents","Add agents from the public microsoft\u002Fdiscovery GitHub repository to this workspace, either (a) locally for the Copilot app by emitting a `.agent.md` companion per agent (so each is invocable via `runSubagent`), (b) into a Microsoft Discovery project via `UpsertAgent` sourced fresh from upstream (binding pre-existing tool ARM resources when present, or building + pushing + registering them in Azure first when missing), or (c) promoting an agent already added to the local Copilot app (sourced from its `.github\u002Fagents\u002F\u003Cname>.agent.md` companion; tool-bearing agents also carry a `discovery_catalog\u002F\u003Cname>\u002F` folder plus a locally-built tool container, while toolless agents have only the companion) up to a specific Microsoft Discovery project + Azure without re-fetching or refreshing from upstream. The user picks exactly one of the three targets per run. USE FOR: 'add the discovery agents', 'download discovery agents', 'install all Microsoft discovery agents', 'add agents from microsoft\u002Fdiscovery', 'create copilot agents from microsoft\u002Fdiscovery', 'deploy discovery agents to Foundry', 'deploy discovery agents to Azure', 'promote a local agent to Microsoft Discovery', 'push my local agent and container to a Discovery project', 'copy a local app agent to Azure'. Always refreshes every selected subfolder under `agents\u002F\u003Cname>\u002F` of the upstream repo into `discovery_catalog\u002F\u003Cname>\u002F` so the local catalog stays current (new agents appear, removed agents are surfaced, updated content is applied). The presence check for what is 'already locally added' uses `.github\u002Fagents\u002F\u003Cname>.agent.md` (the Copilot companion), not the `discovery_catalog\u002F` folder. For local deployment, each generated `.agent.md` carries a lazy Docker-bootstrap preamble so the agent builds its tool image on first use only if absent. For Discovery + Azure deployment, pre-flights every declared tool via `GetDiscoveryTool` against the workspace's RG and **skips Docker build \u002F ACR push \u002F AcrPull RBAC entirely when the tool already exists** (common for shared catalog images on registries like `mdqacr`); only builds + registers tools that are actually missing. Always creates the agent in the chosen Discovery project via `UpsertAgent` and polls **`GetAgent` for `provisioningState=Succeeded`** (the MCP `GetAgentOperation` tool returns an opaque error in practice; never rely on it). All MCP calls flow through PowerShell scripts embedded in this SKILL.md and materialized into `.vscode\u002F` during Step 4d — the skill does not depend on sibling helper files or on the VS Code MCP runtime surfacing `mcp_microsoft-dis_*` tools mid-session. Local Discovery runtime registration via `agents action=create` is optional and skipped by default. DO NOT USE FOR: running an already-deployed agent (use runSubagent), or editing a single agent's prompt (edit `agent.yaml` directly).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002Fskills\u002Fadd-example-agents\u002FSKILL.md",[172,175,178,181],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":176,"categoryName":177,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":182,"categoryName":183,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师",[185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,9,203],"add example agents","copilot","windows","distributed","azure","podman","bootstrap","deployment","create","run","code","MCP","image","python","github","docker","valid","editor","vscode",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":210,"publishedAt":55},"01M69BE703VQGX4F9Z5J4MTJV2","migrate-podman-containerfile","Migrate a Podman Containerfile to the canonical Dockerfile required by the Discovery catalog. Use when a PR fails POL-022, a tool contains Containerfile or Dockerfile.in, or a contributor asks to convert Podman build files for Docker. Creates the Dockerfile directly only when the migration is mechanically safe and refuses ambiguous preprocessing or multi-file builds.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fmigrate-podman-containerfile\u002FSKILL.md",[],[211,190,212,157,200,213,214],"migrate podman containerfile","discovery catalog","dockerfile","pr",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":222,"publishedAt":55},"01M69BE4KN4J5R2RY3927C8PM6","discovery-services-starter-kit-deployer","Deploy Discovery catalog starter-kits end-to-end: validate kit.json agentRefs, build and deploy every referenced agent tool, deploy each referenced agent individually, and summarize deployed agents\u002Ftools plus customer-ready sample prompts. Use this skill whenever the user asks to deploy a Discovery starter-kit or deploy all agents listed in starter-kits\u002F*\u002Fkit.json.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fdiscovery-services-starter-kit-deployer\u002FSKILL.md",[221],{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},[223,224,225,226,227,212],"discovery services starter kit deployer","summarize","customer","validate","deploy",{"skillNo":229,"name":230,"nameZh":6,"description":231,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":232,"categories":233,"keywords":239,"publishedAt":55},"01M69BE20F244MGDJC74AFXGZ2","discovery-services-agent-deployer","Deploy Discovery catalog agents end-to-end with one command: discover the agent, build and bind its tool when present, skip tool stages for agents without tools, deploy the agent, and optionally run validation. Use this skill whenever the user asks to deploy a Discovery agent, publish or rebuild an agent tool image, register a Discovery tool from a repo Dockerfile\u002Ftool.yaml, resume a failed deployment, or produce a dry-run deployment plan for an agent in this catalog.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fdiscovery-services-agent-deployer\u002FSKILL.md",[234,235,236],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":237,"categoryName":238,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000038","人力资源",[240,227,197,194,192,212,213],"discovery services agent deployer",{"skillNo":242,"name":243,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":244,"categories":245,"keywords":253,"publishedAt":55},"01M69BDZZS2J28VZFZX97G33WC","discovery-design-tasks","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdiscovery\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fdiscovery-design-tasks\u002FSKILL.md",[246,249,250],{"categoryNo":247,"categoryName":248,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":251,"categoryName":252,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师",[254,255,256],"tasks","design","discovery design tasks"]