← Maven BioCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Maven Bio
Snapshot Sep 30, 2026 · 23:11 UTC · version 2.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Map who is developing what for an indication, mechanism, or target, grouped by phase, company, or mechanism. Use for competitive questions, for example 'map the NSCLC landscape', 'who else is working on TL1A', 'what is the competition for X'. This is drug-program-centric: use indication-research when the question is about the disease itself, and funding-landscape when it is about capital flow.",
"included_files": [
{
"relative_path": "LICENSE",
"size_in_bytes": 802
},
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 334
},
{
"relative_path": "references/evidence-research.md",
"size_in_bytes": 4449
}
],
"name": "competitive-pipeline",
"skill_md_contents": "---\nname: competitive-pipeline\ndescription: \"Map who is developing what for an indication, mechanism, or target, grouped by phase, company, or mechanism. Use for competitive questions, for example 'map the NSCLC landscape', 'who else is working on TL1A', 'what is the competition for X'. This is drug-program-centric: use indication-research when the question is about the disease itself, and funding-landscape when it is about capital flow.\"\n---\n\n# Competitive Pipeline\n\n## Using this skill\n\nUse the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.\n\nHyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format=\"citations\"`.\n\nThis workflow coordinates primitives to produce a reusable pipeline intelligence package.\n\nThe pipeline view is drug-program-centric (which assets are in development, at what phase, with what mechanism). For the capital-flow view of the same space (recent rounds, total raised, investor mix, deal cadence), route to `funding-landscape` instead. The two layers are independent and a complete competitive picture often needs both.\n\n## Primary Primitives\n\n- `enumerate-entities`\n- `profile-entity`\n- `synthesize-evidence`\n\n## Optional Primitives\n\n- `trace-events`\n- `benchmark-assets`\n- `synthesize-evidence` -- when the pipeline question includes per-row evaluation criteria beyond catalog metadata (e.g., \"which of these have an oral formulation\", \"which target KRAS G12C specifically\"); narrow the set before evaluating rather than thinning the evidence per row\n- `validate-target` -- when the pipeline view ranks programs by target genetic validation or specificity\n\n## Output Contract\n\nReturn a structured package that can include:\n\n- scoped asset universe\n- core confirmed asset set\n- watchlist / uncertain asset set\n- per-asset evidence-backed profiles\n- verification gaps and rows needing follow-up\n- key competitive dimensions\n- recent catalysts or notable events\n- gaps, exclusions, and scope caveats\n\nFor pipeline tables or asset lists, use two tiers:\n\n- **Core confirmed**: assets with indication-relevant trial identifiers in the structured payload, or assets confirmed in-session with `read_document`, `research_entity`, or another document/read path.\n- **Watchlist / uncertain**: assets without indication-relevant trial identifiers, assets supported only by discovery/search snippets, ambiguous sponsor/name/status matches, conflicting evidence, or assets that need follow-up before promotion.\n\n## Aggregation Shortcuts\n\nFor the shape of the pipeline (counts by phase, by mechanism, by sponsor) rather than per-asset detail, use `aggregate_records(entity_type=\"drug\", ...)`. This complements `research_landscape` (which returns the asset list) by giving a chart-ready distribution in a single call.\n\n- Phase distribution: `query=\"active drugs in {indication} grouped by phase\"`\n- Mechanism crowding: `query=\"active drugs in {indication} grouped by mechanism, top 25\"`\n- Sponsor concentration: `query=\"active drugs in {indication} grouped by company, top 25\"` (note: `companies` is M2M-exploded; co-developed assets count once per owning company)\n\n`aggregate_records` is for the count layer, not the evidence layer. Any quoted statistic still needs a document or trial identifier behind it before it goes into the core confirmed tier.\n\n## Core Research Pattern\n\nThis workflow should follow a three-step pattern:\n\n1. **Enumerate** the baseline pipeline universe with structured MCP tools. For the aggregate shape (phase distribution, mechanism crowding, sponsor concentration), use `aggregate_records` to get the picture before enumerating individual assets.\n2. **Augment** that baseline with `search_documents`, `read_document`, and event/document checks\n3. **Reconcile** the final asset set and key claims before returning the package\n\n`research_landscape` and related structured tools are the right starting point, but they are not the full truth source for a master pipeline analysis. Use document search to surface:\n\n- assets missing from the structured layer\n- recent status changes or new disclosures\n- naming, ownership, or mechanism discrepancies\n- stronger support for the highest-impact competitive claims\n\n## Workflow Rules\n\n- treat scoping as a first-class step\n- keep inclusion logic explicit\n- treat structured search as the baseline universe, not the final truth\n- require a document augmentation pass before finalizing the package\n- do not finalize a pipeline after only `research_landscape`, `search_entities`, `fetch_related`, or entity profiles\n- before final output, run a scope-reconciliation gate:\n - compare the returned row count to the expected order of magnitude implied by the prompt or prior context\n - check that major mechanism/modality classes and phase/status buckets requested by the user are represented\n - check known anchor assets from the prompt, retrieved documents, or domain context\n - decide whether missing anchors are true exclusions, unresolved gaps, or a signal to broaden the search\n- split pipeline outputs into core confirmed rows and watchlist / uncertain rows when row-level confidence varies\n- do not promote a structured-search row without an indication-relevant NCT or trial identifier into the core confirmed tier unless you confirmed it in-session with `read_document`, `research_entity`, or another read/fetch path\n- confirm key per-asset facts from `search_entities` and `research_landscape` with `search_documents` plus `read_document` or `research_entity` before treating them as evidence-backed claims\n- reconcile contradictions between structured outputs and document findings\n- use evidence synthesis for the claims that matter most\n- avoid assuming a final report, table, or chart format\n- group programs by trial phase AND approval status. An approved drug is not Phase 4; for any asset that may already be approved in a covered region, confirm against the catalog phase (`Approved`/`Filed`) and, where the distinction carries the answer, against an FDA filing via `search_documents` plus `read_document`\n- For independent evidence workstreams, follow the [evidence research procedure](references/evidence-research.md) for each scoped pass, then reconcile the claims before synthesis. Run passes sequentially, or in parallel when the host supports it and the task authorizes it.\n\n## Fallback Rules\n\n- If you are resolving one named asset, company, or indication, use `match_entity`; reserve `search_entities` for broader criteria-based discovery.\n- When calling `match_entity`, keep the raw entity name in `name` and put sponsor/company/disambiguating text in `context`.\n- When calling `research_landscape`, keep the raw indication name in `indication` and put extra disambiguating text in `context`.\n- If `research_landscape` or related structured enumeration looks too small, run a secondary `search_entities` pass and broad `search_documents` augmentation before finalizing.\n- If structured enumeration looks large but noisy, keep the broad set as discovery scaffolding, then use document evidence and explicit exclusion rules to separate core confirmed rows from watchlist rows.\n- If a named asset fails to resolve, retry with the raw entity name and move sponsor/company text into the optional context hint.\n- If host web fetch is blocked, use `search_documents` plus `read_document`.\n"
}SHA-256 of public snapshot: 6310079748c9bdc00780f601f3f340dd8428b2c87179f256265634face3a306e