{
  "manifest": {
    "id": "research-science",
    "name": "Research & Scientific Computing",
    "description": "Deep research workflows, literature review, scholar evaluation, PubMed/USPTO database queries, and scientific package discovery with gget",
    "version": "1.0.0",
    "author": "Adiuvo",
    "tags": [
      "research",
      "science",
      "pubmed",
      "literature",
      "patents"
    ],
    "icon": "",
    "created_at": "2026-06-11T01:40:46Z",
    "updated_at": "2026-06-11T01:40:46Z",
    "category": "",
    "pack_type": "knowledge",
    "required_mcp_servers": [],
    "optional_mcp_servers": [],
    "on_install": null,
    "procedure_count": 0,
    "context_file_count": 7,
    "always_loaded": false
  },
  "index": "# Research & Scientific Computing\n\nResearch and scientific computing patterns covering literature review, database queries, and discovery workflows.\n\n## What's Included\n\n- **Deep Research** -- Systematic deep research workflows, source evaluation, and knowledge synthesis\n- **Research Ops** -- Research operations, methodology, data collection, and reproducibility patterns\n- **Scientific Thinking: Literature Review** -- Structured literature review methodology, source quality assessment, and synthesis\n- **Scientific Thinking: Scholar Evaluation** -- Academic work evaluation, citation analysis, and research impact assessment\n- **Scientific DB: PubMed** -- PubMed database query patterns, MeSH terms, and biomedical literature search\n- **Scientific DB: USPTO** -- USPTO patent database queries, patent search strategies, and prior art analysis\n- **Scientific Pkg: gget** -- gget package for genomics data retrieval, gene queries, and bioinformatics workflows\n\n## When to Use\n\nActivate this pack when:\n- Conducting systematic research and literature reviews\n- Querying PubMed or USPTO databases\n- Evaluating academic sources and research quality\n- Building bioinformatics data retrieval pipelines\n- Planning and organizing research workflows\n",
  "procedures": [],
  "commands": [],
  "context_files": [
    {
      "filename": "deep-research.md",
      "content": "---\nname: deep-research\ndescription: Multi-source deep research using firecrawl and exa MCPs. Searches the web, synthesizes findings, and delivers cited reports with source attribution. Use when the user wants thorough research on any topic with evidence and citations.\norigin: ECC\n---\n\n# Deep Research\n\n> **Drift-prone skill.** Firecrawl/Exa MCP tool names, quotas, and result\n> shapes change. Verify the configured MCP tools and current API docs before\n> promising coverage or quoting live source counts.\n\nProduce thorough, cited research reports from multiple web sources using firecrawl and exa MCP tools.\n\n## When to Activate\n\n- User asks to research any topic in depth\n- Competitive analysis, technology evaluation, or market sizing\n- Due diligence on companies, investors, or technologies\n- Any question requiring synthesis from multiple sources\n- User says \"research\", \"deep dive\", \"investigate\", or \"what's the current state of\"\n\n## MCP Requirements\n\nAt least one of:\n- **firecrawl** — `firecrawl_search`, `firecrawl_scrape`, `firecrawl_crawl`\n- **exa** — `web_search_exa`, `web_search_advanced_exa`, `crawling_exa`\n\nBoth together give the best coverage. Configure in `~/.claude.json` or `~/.codex/config.toml`.\n\n## Workflow\n\n### Step 1: Understand the Goal\n\nAsk 1-2 quick clarifying questions:\n- \"What's your goal — learning, making a decision, or writing something?\"\n- \"Any specific angle or depth you want?\"\n\nIf the user says \"just research it\" — skip ahead with reasonable defaults.\n\n### Step 2: Plan the Research\n\nBreak the topic into 3-5 research sub-questions. Example:\n- Topic: \"Impact of AI on healthcare\"\n  - What are the main AI applications in healthcare today?\n  - What clinical outcomes have been measured?\n  - What are the regulatory challenges?\n  - What companies are leading this space?\n  - What's the market size and growth trajectory?\n\n### Step 3: Execute Multi-Source Search\n\nFor EACH sub-question, search using available MCP tools:\n\n**With firecrawl:**\n```\nfirecrawl_search(query: \"<sub-question keywords>\", limit: 8)\n```\n\n**With exa:**\n```\nweb_search_exa(query: \"<sub-question keywords>\", numResults: 8)\nweb_search_advanced_exa(query: \"<keywords>\", numResults: 5, startPublishedDate: \"2025-01-01\")\n```\n\n**Search strategy:**\n- Use 2-3 different keyword variations per sub-question\n- Mix general and news-focused queries\n- Aim for 15-30 unique sources total\n- Prioritize: academic, official, reputable news > blogs > forums\n\n### Step 4: Deep-Read Key Sources\n\nFor the most promising URLs, fetch full content:\n\n**With firecrawl:**\n```\nfirecrawl_scrape(url: \"<url>\")\n```\n\n**With exa:**\n```\ncrawling_exa(url: \"<url>\", tokensNum: 5000)\n```\n\nRead 3-5 key sources in full for depth. Do not rely only on search snippets.\n\n### Step 5: Synthesize and Write Report\n\nStructure the report:\n\n```markdown\n# [Topic]: Research Report\n*Generated: [date] | Sources: [N] | Confidence: [High/Medium/Low]*\n\n## Executive Summary\n[3-5 sentence overview of key findings]\n\n## 1. [First Major Theme]\n[Findings with inline citations]\n- Key point ([Source Name](url))\n- Supporting data ([Source Name](url))\n\n## 2. [Second Major Theme]\n...\n\n## 3. [Third Major Theme]\n...\n\n## Key Takeaways\n- [Actionable insight 1]\n- [Actionable insight 2]\n- [Actionable insight 3]\n\n## Sources\n1. [Title](url) — [one-line summary]\n2. ...\n\n## Methodology\nSearched [N] queries across web and news. Analyzed [M] sources.\nSub-questions investigated: [list]\n```\n\n### Step 6: Deliver\n\n- **Short topics**: Post the full report in chat\n- **Long reports**: Post the executive summary + key takeaways, save full report to a file\n\n## Parallel Research with Subagents\n\nFor broad topics, use Claude Code's Task tool to parallelize:\n\n```\nLaunch 3 research agents in parallel:\n1. Agent 1: Research sub-questions 1-2\n2. Agent 2: Research sub-questions 3-4\n3. Agent 3: Research sub-question 5 + cross-cutting themes\n```\n\nEach agent searches, reads sources, and returns findings. The main session synthesizes into the final report.\n\n## Quality Rules\n\n1. **Every claim needs a source.** No unsourced assertions.\n2. **Cross-reference.** If only one source says it, flag it as unverified.\n3. **Recency matters.** Prefer sources from the last 12 months.\n4. **Acknowledge gaps.** If you couldn't find good info on a sub-question, say so.\n5. **No hallucination.** If you don't know, say \"insufficient data found.\"\n6. **Separate fact from inference.** Label estimates, projections, and opinions clearly.\n\n## Examples\n\n```\n\"Research the current state of nuclear fusion energy\"\n\"Deep dive into Rust vs Go for backend services in 2026\"\n\"Research the best strategies for bootstrapping a SaaS business\"\n\"What's happening with the US housing market right now?\"\n\"Investigate the competitive landscape for AI code editors\"\n```\n"
    },
    {
      "filename": "research-ops.md",
      "content": "---\nname: research-ops\ndescription: Evidence-first current-state research workflow for ECC. Use when the user wants fresh facts, comparisons, enrichment, or a recommendation built from current public evidence and any supplied local context.\norigin: ECC\n---\n\n# Research Ops\n\nUse this when the user asks to research something current, compare options, enrich people or companies, or turn repeated lookups into a monitored workflow.\n\nThis is the operator wrapper around the repo's research stack. It is not a replacement for `deep-research`, `exa-search`, or `market-research`; it tells you when and how to use them together.\n\n## Skill Stack\n\nPull these ECC-native skills into the workflow when relevant:\n\n- `exa-search` for fast current-web discovery\n- `deep-research` for multi-source synthesis with citations\n- `market-research` when the end result should be a recommendation or ranked decision\n- `lead-intelligence` when the task is people/company targeting instead of generic research\n- `knowledge-ops` when the result should be stored in durable context afterward\n\n## When to Use\n\n- user says \"research\", \"look up\", \"compare\", \"who should I talk to\", or \"what's the latest\"\n- the answer depends on current public information\n- the user already supplied evidence and wants it factored into a fresh recommendation\n- the task may be recurring enough that it should become a monitor instead of a one-off lookup\n\n## Guardrails\n\n- do not answer current questions from stale memory when fresh search is cheap\n- separate:\n  - sourced fact\n  - user-provided evidence\n  - inference\n  - recommendation\n- do not spin up a heavyweight research pass if the answer is already in local code or docs\n\n## Workflow\n\n### 1. Start from what the user already gave you\n\nNormalize any supplied material into:\n\n- already-evidenced facts\n- needs verification\n- open questions\n\nDo not restart the analysis from zero if the user already built part of the model.\n\n### 2. Classify the ask\n\nChoose the right lane before searching:\n\n- quick factual answer\n- comparison or decision memo\n- lead/enrichment pass\n- recurring monitoring candidate\n\n### 3. Take the lightest useful evidence path first\n\n- use `exa-search` for fast discovery\n- escalate to `deep-research` when synthesis or multiple sources matter\n- use `market-research` when the outcome should end in a recommendation\n- hand off to `lead-intelligence` when the real ask is target ranking or warm-path discovery\n\n### 4. Report with explicit evidence boundaries\n\nFor important claims, say whether they are:\n\n- sourced facts\n- user-supplied context\n- inference\n- recommendation\n\nFreshness-sensitive answers should include concrete dates.\n\n### 5. Decide whether the task should stay manual\n\nIf the user is likely to ask the same research question repeatedly, say so explicitly and recommend a monitoring or workflow layer instead of repeating the same manual search forever.\n\n## Output Format\n\n```text\nQUESTION TYPE\n- factual / comparison / enrichment / monitoring\n\nEVIDENCE\n- sourced facts\n- user-provided context\n\nINFERENCE\n- what follows from the evidence\n\nRECOMMENDATION\n- answer or next move\n- whether this should become a monitor\n```\n\n## Pitfalls\n\n- do not mix inference into sourced facts without labeling it\n- do not ignore user-provided evidence\n- do not use a heavy research lane for a question local repo context can answer\n- do not give freshness-sensitive answers without dates\n\n## Verification\n\n- important claims are labeled by evidence type\n- freshness-sensitive outputs include dates\n- the final recommendation matches the actual research mode used\n"
    },
    {
      "filename": "scientific-db-pubmed.md",
      "content": "---\nname: pubmed-database\ndescription: Direct PubMed and NCBI E-utilities search workflows for biomedical literature, MeSH queries, PMID lookup, citation retrieval, and API-backed literature monitoring.\norigin: community\n---\n\n# PubMed Database\n\nUse this skill when a task needs biomedical literature from PubMed rather than\ngeneral web search.\n\n## When to Use\n\n- Searching MEDLINE or life-sciences literature.\n- Building PubMed queries with MeSH terms, field tags, dates, or article types.\n- Looking up PMIDs, abstracts, publication metadata, or related citations.\n- Running systematic-review search passes that need repeatable search strings.\n- Using NCBI E-utilities directly from Python, shell, or another HTTP client.\n\n## Query Construction\n\nStart with the research question, split it into concepts, then combine concepts\nwith Boolean operators.\n\n```text\nconcept_1 AND concept_2 AND filter\nsynonym_a OR synonym_b\nNOT exclusion_term\n```\n\nUseful PubMed field tags:\n\n- `[ti]`: title\n- `[ab]`: abstract\n- `[tiab]`: title or abstract\n- `[au]`: author\n- `[ta]`: journal title abbreviation\n- `[mh]`: MeSH term\n- `[majr]`: major MeSH topic\n- `[pt]`: publication type\n- `[dp]`: date of publication\n- `[la]`: language\n\nExamples:\n\n```text\ndiabetes mellitus[mh] AND treatment[tiab] AND systematic review[pt] AND 2023:2026[dp]\n(metformin[nm] OR insulin[nm]) AND diabetes mellitus, type 2[mh] AND randomized controlled trial[pt]\nsmith ja[au] AND cancer[tiab] AND 2026[dp] AND english[la]\n```\n\n## MeSH and Subheadings\n\nPrefer MeSH when the concept has a stable controlled-vocabulary term. Combine\nMeSH with title/abstract terms when the topic is new or terminology varies.\n\nCorrect subheading syntax puts the subheading before the field tag:\n\n```text\ndiabetes mellitus, type 2/drug therapy[mh]\ncardiovascular diseases/prevention & control[mh]\n```\n\nUse `[majr]` only when the topic must be central to the paper. It can improve\nprecision but may miss relevant work.\n\n## Filters\n\nPublication types:\n\n- `clinical trial[pt]`\n- `meta-analysis[pt]`\n- `randomized controlled trial[pt]`\n- `review[pt]`\n- `systematic review[pt]`\n- `guideline[pt]`\n\nDate filters:\n\n```text\n2026[dp]\n2020:2026[dp]\n2026/03/15[dp]\n```\n\nAvailability filters:\n\n```text\nfree full text[sb]\nhasabstract[text]\n```\n\n## E-utilities Workflow\n\nNCBI E-utilities supports repeatable API workflows:\n\n1. `esearch.fcgi`: search and return PMIDs.\n2. `esummary.fcgi`: return lightweight article metadata.\n3. `efetch.fcgi`: fetch abstracts or full records in XML, MEDLINE, or text.\n4. `elink.fcgi`: find related articles and linked resources.\n\nUse an email and API key for production scripts. Store API keys in environment\nvariables, never in committed files or command history.\n\n```python\nimport os\nimport time\nimport requests\n\nBASE = \"https://eutils.ncbi.nlm.nih.gov/entrez/eutils\"\n\n\ndef esearch(query: str, retmax: int = 20) -> list[str]:\n    params = {\n        \"db\": \"pubmed\",\n        \"term\": query,\n        \"retmode\": \"json\",\n        \"retmax\": retmax,\n        \"tool\": \"ecc-pubmed-search\",\n        \"email\": os.environ.get(\"NCBI_EMAIL\", \"\"),\n    }\n    api_key = os.environ.get(\"NCBI_API_KEY\")\n    if api_key:\n        params[\"api_key\"] = api_key\n\n    response = requests.get(f\"{BASE}/esearch.fcgi\", params=params, timeout=30)\n    response.raise_for_status()\n    time.sleep(0.35)\n    return response.json()[\"esearchresult\"][\"idlist\"]\n\n\npmids = esearch(\"hypertension[mh] AND randomized controlled trial[pt] AND 2024:2026[dp]\")\nprint(pmids)\n```\n\nFor batches, prefer NCBI history server parameters (`usehistory=y`,\n`WebEnv`, `query_key`) instead of passing very long PMID lists through URLs.\n\n## Output Discipline\n\nFor each search pass, record:\n\n- exact search string\n- database searched\n- date searched\n- filters used\n- result count\n- export format\n- any manual exclusions\n\nExample:\n\n```markdown\n| Database | Date searched | Query | Filters | Results |\n| --- | --- | --- | --- | ---: |\n| PubMed | 2026-05-11 | `sickle cell disease[mh] AND CRISPR[tiab]` | 2020:2026[dp], English | 42 |\n```\n\n## Review Checklist\n\n- Are field tags valid PubMed tags?\n- Are MeSH terms paired with free-text synonyms for newer topics?\n- Is the date range explicit and appropriate?\n- Does the search log include enough detail to reproduce the query?\n- Are API keys loaded from the environment?\n- Does HTTP code call `raise_for_status()` or otherwise handle non-200\n  responses before parsing?\n- Are rate limits respected?\n\n## References\n\n- [PubMed help](https://pubmed.ncbi.nlm.nih.gov/help/)\n- [NCBI E-utilities documentation](https://www.ncbi.nlm.nih.gov/books/NBK25501/)\n- [NCBI API key guidance](https://support.nlm.nih.gov/kbArticle/?pn=KA-05317)\n- NCBI support: <eutilities@ncbi.nlm.nih.gov>\n"
    },
    {
      "filename": "scientific-db-uspto.md",
      "content": "---\nname: uspto-database\ndescription: USPTO patent and trademark data workflow for official record lookup, PatentSearch queries, TSDR checks, assignment data, and reproducible IP research logs.\norigin: community\n---\n\n# USPTO Database\n\nUse this skill when a task needs official United States patent or trademark\nrecords from USPTO systems.\n\n## When to Use\n\n- Searching granted patents or pre-grant publications.\n- Checking patent application status, file-wrapper data, assignments, or\n  public prosecution history.\n- Looking up trademark status, documents, or assignment history.\n- Building reproducible prior-art, portfolio, or IP landscape research logs.\n- Comparing USPTO records with secondary tools such as Google Patents,\n  Lens.org, Semantic Scholar, or company patent pages.\n\nDo not use this skill to give legal advice. Treat it as a data-gathering and\nrecord-verification workflow.\n\n## Source Selection\n\nPrefer official USPTO or USPTO-supported surfaces first:\n\n- Open Data Portal (ODP): current home for migrated USPTO datasets and APIs.\n- Patent File Wrapper: public patent application bibliographic data and file\n  wrapper records.\n- PatentSearch API: PatentsView search API for granted patents and pre-grant\n  publication datasets.\n- TSDR Data API: trademark status and document retrieval.\n- Patent and Trademark Assignment Search: ownership transfer records.\n- PTAB data in ODP: Patent Trial and Appeal Board proceedings.\n\nUse secondary sources only as convenience indexes. When the answer matters,\ncross-check the official record.\n\n## Authentication and Secrets\n\nMany USPTO API flows require an API key. Store keys in environment variables or\na secret manager, never in committed files or pasted transcripts.\n\nCommon environment names:\n\n```bash\nexport USPTO_API_KEY=\"...\"\nexport PATENTSVIEW_API_KEY=\"...\"\n```\n\nFor PatentSearch, send the key with the `X-Api-Key` header. For TSDR, follow\nthe current USPTO API Manager instructions and rate-limit guidance.\n\n## PatentSearch Workflow\n\nUse PatentSearch for broad patent and pre-grant publication search when the\nquestion is about trends, inventors, assignees, classifications, dates, or\nportfolio slices.\n\nWorkflow:\n\n1. Identify the endpoint from the current PatentSearch reference or Swagger UI.\n2. Build a JSON query with explicit filters.\n3. Request only the fields needed for the analysis.\n4. Sort and paginate deterministically.\n5. Record the endpoint, query body, date, data currency note, and result count.\n\nPython request skeleton:\n\n```python\nimport os\nimport requests\n\nAPI_KEY = os.environ[\"PATENTSVIEW_API_KEY\"]\nBASE = \"https://search.patentsview.org/api/v1\"\n\npayload = {\n    \"q\": {\n        \"_and\": [\n            {\"patent_date\": {\"_gte\": \"2024-01-01\"}},\n            {\"assignees.assignee_organization\": {\"_text_any\": [\"Google\", \"Alphabet\"]}},\n        ]\n    },\n    \"f\": [\"patent_id\", \"patent_title\", \"patent_date\"],\n    \"s\": [{\"patent_date\": \"desc\"}],\n    \"o\": {\"per_page\": 100, \"page\": 1},\n}\n\nresponse = requests.post(\n    f\"{BASE}/patent/\",\n    headers={\"X-Api-Key\": API_KEY, \"Content-Type\": \"application/json\"},\n    json=payload,\n    timeout=30,\n)\nresponse.raise_for_status()\nprint(response.json())\n```\n\nBefore reusing a query, verify current endpoint names, field paths, request\nparameters, and API-key availability in the live PatentSearch docs.\n\n## Trademark/TSDR Workflow\n\nUse TSDR when the task needs trademark case status, documents, images, owner\nhistory, or prosecution events.\n\nWorkflow:\n\n1. Normalize the serial number or registration number.\n2. Check the current TSDR API instructions and required API-key header.\n3. Fetch status first, then documents only if needed.\n4. Respect the lower rate limit for PDF, ZIP, and multi-case downloads.\n5. Capture retrieval date and serial/registration identifier in the output.\n\nFor large trademark pulls, prefer documented bulk-data flows rather than\nscreen-scraping public pages.\n\n## File Wrapper and Prosecution History\n\nFor application status, transaction history, and prosecution documents:\n\n- Start with ODP Patent File Wrapper search.\n- Use exact identifiers when available: application number, publication number,\n  patent number, or party name.\n- Record whether the record is a granted patent, pre-grant publication, or\n  pending application.\n- Cross-check document dates and status against the record detail page before\n  citing them.\n\n## Assignment Workflow\n\nFor patent or trademark ownership:\n\n1. Search official assignment data by patent/application/registration number,\n   assignor, assignee, or reel/frame when available.\n2. Record conveyance text, execution date, recordation date, and parties.\n3. Distinguish assignment records from current legal ownership conclusions.\n4. If ownership is material, flag the result for attorney or subject-matter\n   review.\n\n## Reproducible Output\n\nEvery USPTO research pass should include a log table:\n\n```markdown\n| Source | Date searched | Identifier/query | Filters | Results | Notes |\n| --- | --- | --- | --- | ---: | --- |\n| PatentSearch | 2026-05-11 | `assignee=Alphabet AND date>=2024` | patent endpoint | 118 | API docs checked before run |\n| TSDR | 2026-05-11 | `serial=90000000` | status only | 1 | API-key flow, no document bulk pull |\n```\n\nFor final writeups, separate:\n\n- official record facts\n- inferred analysis\n- secondary-source convenience matches\n- unresolved gaps or records that require legal review\n\n## Review Checklist\n\n- Did you use an official USPTO or USPTO-supported source first?\n- Did you verify current endpoint and field names before running code?\n- Are API keys kept out of files, shell history, and output logs?\n- Does the query log include the date searched and exact request shape?\n- Are rate limits respected?\n- Are legal conclusions avoided or explicitly escalated?\n- Are secondary sources labeled as secondary?\n\n## References\n\n- [USPTO APIs catalog](https://developer.uspto.gov/api-catalog)\n- [USPTO Open Data Portal](https://data.uspto.gov/)\n- [PatentSearch API reference](https://search.patentsview.org/docs/docs/Search%20API/SearchAPIReference/)\n- [PatentSearch API updates](https://search.patentsview.org/docs/)\n- [TSDR API bulk download FAQ](https://developer.uspto.gov/faq/tsdr-api-bulk-download)\n"
    },
    {
      "filename": "scientific-literature-review.md",
      "content": "---\nname: literature-review\ndescription: Systematic literature-review workflow for academic, biomedical, technical, and scientific topics, including search planning, source screening, synthesis, citation checks, and evidence logging.\norigin: community\n---\n\n# Literature Review\n\nUse this skill when the task is to find, screen, synthesize, and cite a body of\nacademic or technical literature.\n\n## When to Use\n\n- Building a systematic, scoping, or narrative literature review.\n- Synthesizing the state of the art for a research question.\n- Finding gaps, contradictions, or future-work directions.\n- Preparing citation-backed background sections for papers or reports.\n- Comparing evidence across peer-reviewed papers, preprints, patents, and\n  technical reports.\n\n## Review Types\n\n- **Narrative review**: broad synthesis; useful for orientation.\n- **Scoping review**: maps concepts, methods, and evidence gaps.\n- **Systematic review**: predefined protocol, reproducible search, explicit\n  screening and exclusion.\n- **Meta-analysis**: systematic review plus quantitative effect aggregation.\n\nAsk the user which level of rigor is needed. If unspecified, default to a\nscoping review for exploratory work and a systematic review for publication or\nclinical claims.\n\n## Workflow\n\n### 1. Define the Question\n\nConvert the prompt into a searchable research question.\n\nFor clinical or biomedical work, use PICO:\n\n- Population\n- Intervention or exposure\n- Comparator\n- Outcome\n\nFor technical work, use:\n\n- system or domain\n- method or intervention\n- comparison baseline\n- evaluation metric\n\n### 2. Plan the Search\n\nCreate a search protocol before collecting sources:\n\n- databases to search\n- date range\n- languages\n- publication types\n- inclusion criteria\n- exclusion criteria\n- exact search strings\n\nMinimum useful database set:\n\n- PubMed for biomedical and life-sciences literature.\n- arXiv for CS, math, physics, quantitative biology, and preprints.\n- Semantic Scholar or Crossref for broad academic discovery.\n- Domain-specific sources when relevant, such as clinical-trial registries,\n  patent databases, standards bodies, or official technical docs.\n\n### 3. Search and Log Evidence\n\nKeep a search log that makes the review reproducible:\n\n```markdown\n| Database | Date searched | Query | Filters | Results | Export |\n| --- | --- | --- | --- | ---: | --- |\n| PubMed | 2026-05-11 | `(\"CRISPR\"[tiab] OR \"Cas9\"[tiab]) AND \"sickle cell\"[tiab]` | 2020:2026, English | 86 | PMID list |\n| arXiv | 2026-05-11 | `CRISPR sickle cell gene editing` | q-bio, 2020:2026 | 9 | BibTeX |\n```\n\nSave raw IDs, URLs, DOIs, abstracts, and notes separately from the final prose.\n\n### 4. Deduplicate\n\nDeduplicate in this order:\n\n1. DOI\n2. PMID or arXiv ID\n3. exact title\n4. normalized title plus first author and year\n\nRecord how many duplicates were removed.\n\n### 5. Screen Sources\n\nScreen in stages:\n\n1. title\n2. abstract\n3. full text\n\nFor systematic work, record exclusion reasons:\n\n- wrong population\n- wrong intervention\n- wrong outcome\n- not primary research\n- duplicate\n- unavailable full text\n- outside date range\n\n### 6. Extract Data\n\nUse a structured extraction table:\n\n```markdown\n| Study | Design | Population/Data | Method | Comparator | Outcome | Key finding | Limitations |\n| --- | --- | --- | --- | --- | --- | --- | --- |\n| Author Year | RCT/cohort/review/etc. | sample or corpus | method | baseline | measured outcome | result | caveat |\n```\n\nFor technical papers, include dataset, benchmark, metric, baseline, and\nreproducibility notes.\n\n### 7. Synthesize\n\nGroup evidence by theme rather than summarizing papers one by one.\n\nUseful synthesis lenses:\n\n- strongest evidence\n- conflicting evidence\n- methodological weaknesses\n- population or dataset limits\n- recency and replication\n- practical implications\n- unanswered questions\n\nSeparate claims by confidence:\n\n- **High confidence**: replicated, high-quality evidence across sources.\n- **Medium confidence**: plausible but limited by sample, method, or recency.\n- **Low confidence**: early, speculative, single-source, or weakly measured.\n\n### 8. Verify Citations\n\nBefore finalizing:\n\n- verify DOI, PMID, arXiv ID, or official URL\n- check author names and publication year\n- do not cite a paper for a claim it does not make\n- mark preprints as preprints\n- distinguish reviews from primary evidence\n\n## Output Template\n\n```markdown\n# Literature Review: <Topic>\n\nGenerated: <date>\nReview type: <narrative | scoping | systematic | meta-analysis>\nSearch window: <dates>\nDatabases: <list>\n\n## Research Question\n\n## Search Strategy\n\n## Inclusion and Exclusion Criteria\n\n## Evidence Summary\n\n## Thematic Synthesis\n\n## Gaps and Limitations\n\n## References\n\n## Search Log\n```\n\n## Pitfalls\n\n- Do not treat search snippets as evidence.\n- Do not mix preprints, reviews, and primary studies without labeling them.\n- Do not omit negative or conflicting findings.\n- Do not claim systematic-review rigor without a reproducible protocol.\n- Do not use a single database for a broad claim unless the scope is explicitly\n  limited to that database.\n"
    },
    {
      "filename": "scientific-pkg-gget.md",
      "content": "---\nname: gget\ndescription: gget CLI and Python workflow for quick genomic database queries, sequence lookup, BLAST-style searches, enrichment checks, and reproducible bioinformatics evidence logs.\norigin: community\n---\n\n# gget\n\nUse this skill when a task needs quick bioinformatics lookup across genomic\nreference databases with the `gget` CLI or Python package.\n\n## When to Use\n\n- Finding Ensembl IDs, gene metadata, transcript details, or sequences.\n- Running quick BLAST or BLAT lookups without building a full local pipeline.\n- Fetching reference genome links and annotations from Ensembl.\n- Querying protein structure, pathway, cancer, expression, or disease-association\n  modules through a single interface.\n- Creating a reproducible first-pass evidence log before moving to heavier\n  tools such as Biopython, Snakemake, Nextflow, BLAST+, or database-specific\n  clients.\n\nUse a dedicated workflow instead of `gget` when the task requires regulated\nclinical interpretation, high-throughput production pipelines, or fine-grained\ncontrol over database versions and local indexes.\n\n## Installation\n\nUse a clean Python environment.\n\n```bash\npython -m venv .venv\n. .venv/bin/activate\npython -m pip install --upgrade pip\npython -m pip install --upgrade gget\ngget --help\n```\n\nIf `uv` is available:\n\n```bash\nuv venv\n. .venv/bin/activate\nuv pip install gget\n```\n\nBefore relying on an older environment, upgrade `gget` and re-check the module\ndocs. The upstream databases queried by `gget` change over time.\n\n## Basic Patterns\n\nCLI shape:\n\n```bash\ngget <module> [arguments] [options]\n```\n\nPython shape:\n\n```python\nimport gget\n\nresult = gget.search([\"BRCA1\"], species=\"human\")\nprint(result)\n```\n\nCommon workflow:\n\n1. Identify the species, assembly, gene ID type, and database needed.\n2. Check the current module documentation for arguments.\n3. Run a small query first.\n4. Save output with an explicit filename and date.\n5. Record module name, version, arguments, and database assumptions.\n\n## Common Modules\n\nUse current upstream docs for exact arguments. These modules are common first\nchoices:\n\n- `gget search`: find Ensembl IDs from search terms.\n- `gget info`: retrieve metadata for Ensembl, UniProt, or related IDs.\n- `gget seq`: fetch nucleotide or amino-acid sequences.\n- `gget ref`: retrieve reference genome download links.\n- `gget blast`: run a quick BLAST query.\n- `gget blat`: locate a sequence against supported genome assemblies.\n- `gget muscle`: run multiple sequence alignment.\n- `gget diamond`: run local sequence alignment against reference sequences.\n- `gget alphafold` and `gget pdb`: inspect protein-structure references.\n- `gget enrichr`, `gget opentargets`, `gget archs4`, `gget bgee`, `gget cbio`,\n  and `gget cosmic`: explore enrichment, target, expression, cancer, and disease\n  association data.\n\nDo not assume every module supports every Python version or dependency set.\nSome optional scientific dependencies have narrower version support than the\ncore package.\n\n## Quick Examples\n\nFind genes:\n\n```bash\ngget search -s human brca1 dna repair -o brca1-search.json\n```\n\nFetch gene metadata:\n\n```bash\ngget info ENSG00000012048 -o brca1-info.json\n```\n\nFetch a sequence:\n\n```bash\ngget seq ENSG00000012048 -o brca1-seq.fa\n```\n\nRun a small BLAST query:\n\n```bash\ngget blast \"MEEPQSDPSVEPPLSQETFSDLWKLLPEN\" -l 10 -o blast-results.json\n```\n\nPython example:\n\n```python\nimport gget\n\ngenes = gget.search([\"BRCA1\", \"DNA repair\"], species=\"human\")\ninfo = gget.info([\"ENSG00000012048\"])\nsequence = gget.seq(\"ENSG00000012048\")\n```\n\n## Reproducibility Log\n\nFor scientific outputs, include enough metadata to replay the query.\n\n```markdown\n| Date | gget version | Module | Query | Species/assembly | Output | Notes |\n| --- | --- | --- | --- | --- | --- | --- |\n| 2026-05-11 | `gget --version` | search | `BRCA1 DNA repair` | human | `brca1-search.json` | Docs checked before run |\n```\n\nAlso record:\n\n- Python version and environment manager.\n- Any optional dependency installed through `gget setup`.\n- Database-specific identifiers returned by the query.\n- Whether output is JSON, CSV, FASTA, or a DataFrame export.\n- Any failures that were resolved by upgrading `gget`.\n\n## Review Checklist\n\n- Did you upgrade or verify the installed `gget` version?\n- Did you check the current upstream module docs before using arguments?\n- Is the species or assembly explicit?\n- Are identifiers preserved exactly, including Ensembl/UniProt prefixes?\n- Is the result labeled as database output rather than clinical interpretation?\n- Is the query reproducible from the saved command or Python snippet?\n- Are optional dependencies installed in an isolated environment?\n\n## References\n\n- [gget documentation](https://pachterlab.github.io/gget/)\n- [gget updates](https://pachterlab.github.io/gget/en/updates.html)\n- [gget GitHub repository](https://github.com/pachterlab/gget)\n- [gget Bioinformatics paper](https://doi.org/10.1093/bioinformatics/btac836)\n"
    },
    {
      "filename": "scientific-scholar-evaluation.md",
      "content": "---\nname: scholar-evaluation\ndescription: Structured scholarly-work evaluation for papers, proposals, literature reviews, methods sections, evidence quality, citation support, and research-writing feedback.\norigin: community\n---\n\n# Scholar Evaluation\n\nUse this skill to evaluate academic or scientific work with a repeatable rubric.\n\n## When to Use\n\n- Reviewing a research paper, proposal, thesis chapter, or literature review.\n- Checking whether claims are supported by cited evidence.\n- Evaluating methodology, study design, analysis, or limitations.\n- Comparing two or more papers for quality or relevance.\n- Producing structured feedback for revision.\n\n## Evaluation Scope\n\nStart by identifying the artifact:\n\n- empirical research paper\n- theoretical paper\n- technical report\n- systematic or narrative literature review\n- research proposal\n- thesis or dissertation chapter\n- conference abstract or short paper\n\nThen choose scope:\n\n- **comprehensive**: all rubric dimensions\n- **targeted**: one or two dimensions, such as method or citations\n- **comparative**: rank multiple works against the same rubric\n\n## Rubric\n\nScore each applicable dimension from 1 to 5:\n\n- 5: excellent; clear, rigorous, and publication-ready\n- 4: good; minor improvements needed\n- 3: adequate; meaningful gaps but usable\n- 2: weak; substantial revision needed\n- 1: poor; major validity or clarity problems\n\nUse `N/A` for dimensions that do not apply.\n\n### 1. Problem and Research Question\n\n- Is the problem clear and specific?\n- Is the contribution meaningful?\n- Are scope and assumptions explicit?\n- Does the question match the claimed contribution?\n\n### 2. Literature and Context\n\n- Is relevant prior work covered?\n- Does the work synthesize rather than merely list sources?\n- Are gaps accurately identified?\n- Are recent and foundational sources balanced?\n\n### 3. Methodology\n\n- Does the method answer the research question?\n- Are design choices justified?\n- Are variables, datasets, participants, or materials described clearly?\n- Could another researcher reproduce the work?\n- Are ethical and practical constraints acknowledged?\n\n### 4. Data and Evidence\n\n- Are data sources credible and appropriate?\n- Is sample size or corpus coverage adequate?\n- Are inclusion, exclusion, and preprocessing decisions documented?\n- Are missing data and bias risks discussed?\n\n### 5. Analysis\n\n- Are statistical, qualitative, or computational methods appropriate?\n- Are baselines and controls fair?\n- Are uncertainty, sensitivity, or robustness checks included when needed?\n- Are alternative explanations considered?\n\n### 6. Results and Interpretation\n\n- Are results clearly presented?\n- Do claims stay within the evidence?\n- Are figures, tables, and metrics understandable?\n- Are negative or null results handled honestly?\n\n### 7. Limitations and Threats to Validity\n\n- Are limitations specific rather than generic?\n- Are internal, external, construct, and conclusion-validity risks addressed?\n- Does the paper distinguish speculation from demonstrated results?\n\n### 8. Writing and Structure\n\n- Is the argument easy to follow?\n- Are sections organized around the research question?\n- Are definitions and notation clear?\n- Is the tone precise and scholarly?\n\n### 9. Citations\n\n- Do cited papers support the claims attached to them?\n- Are primary sources used where possible?\n- Are reviews labeled as reviews?\n- Are preprints labeled as preprints?\n- Are citation metadata and links correct?\n\n## Review Process\n\n1. Read the abstract, introduction, figures, and conclusion for claimed\n   contribution.\n2. Read methods and results for evidence quality.\n3. Check the strongest claims against cited sources.\n4. Score each applicable dimension.\n5. Separate critical blockers from revision suggestions.\n6. End with concrete next edits.\n\n## Output Template\n\n```markdown\n# Scholar Evaluation: <Artifact>\n\n## Overall Assessment\n\n- Overall score: <1-5 or N/A>\n- Confidence: <high | medium | low>\n- Summary: <3-5 sentences>\n\n## Dimension Scores\n\n| Dimension | Score | Evidence | Revision priority |\n| --- | ---: | --- | --- |\n| Problem and question |  |  |  |\n| Literature and context |  |  |  |\n| Methodology |  |  |  |\n| Data and evidence |  |  |  |\n| Analysis |  |  |  |\n| Results and interpretation |  |  |  |\n| Limitations |  |  |  |\n| Writing and structure |  |  |  |\n| Citations |  |  |  |\n\n## Critical Issues\n\n## Recommended Revisions\n\n## Evidence Checks Needed\n```\n\n## Pitfalls\n\n- Do not use the score as a substitute for concrete feedback.\n- Do not penalize a paper for omitting a dimension outside its scope.\n- Do not treat citation count, venue, or author reputation as proof of quality.\n- Do not accept unsupported claims just because they appear in the abstract.\n"
    }
  ]
}