diff --git a/.agents/skills/parallel-account-briefs b/.agents/skills/parallel-account-briefs new file mode 120000 index 0000000..85f69b9 --- /dev/null +++ b/.agents/skills/parallel-account-briefs @@ -0,0 +1 @@ +../../skills/parallel-account-briefs/ \ No newline at end of file diff --git a/.agents/skills/parallel-account-enrichment b/.agents/skills/parallel-account-enrichment new file mode 120000 index 0000000..082d1b3 --- /dev/null +++ b/.agents/skills/parallel-account-enrichment @@ -0,0 +1 @@ +../../skills/parallel-account-enrichment/ \ No newline at end of file diff --git a/.agents/skills/parallel-book-risk-monitoring b/.agents/skills/parallel-book-risk-monitoring new file mode 120000 index 0000000..e590208 --- /dev/null +++ b/.agents/skills/parallel-book-risk-monitoring @@ -0,0 +1 @@ +../../skills/parallel-book-risk-monitoring/ \ No newline at end of file diff --git a/.agents/skills/parallel-claims-research b/.agents/skills/parallel-claims-research new file mode 120000 index 0000000..dc957d8 --- /dev/null +++ b/.agents/skills/parallel-claims-research @@ -0,0 +1 @@ +../../skills/parallel-claims-research/ \ No newline at end of file diff --git a/.agents/skills/parallel-code-quickstart b/.agents/skills/parallel-code-quickstart new file mode 120000 index 0000000..6b114c9 --- /dev/null +++ b/.agents/skills/parallel-code-quickstart @@ -0,0 +1 @@ +../../skills/parallel-code-quickstart/ \ No newline at end of file diff --git a/.agents/skills/parallel-code-setup b/.agents/skills/parallel-code-setup new file mode 120000 index 0000000..41ce3da --- /dev/null +++ b/.agents/skills/parallel-code-setup @@ -0,0 +1 @@ +../../skills/parallel-code-setup/ \ No newline at end of file diff --git a/.agents/skills/parallel-company-profiles b/.agents/skills/parallel-company-profiles new file mode 120000 index 0000000..3a8500a --- /dev/null +++ b/.agents/skills/parallel-company-profiles @@ -0,0 +1 @@ +../../skills/parallel-company-profiles/ \ No newline at end of file diff --git a/.agents/skills/parallel-competitive-landscape b/.agents/skills/parallel-competitive-landscape new file mode 120000 index 0000000..33f9607 --- /dev/null +++ b/.agents/skills/parallel-competitive-landscape @@ -0,0 +1 @@ +../../skills/parallel-competitive-landscape/ \ No newline at end of file diff --git a/.agents/skills/parallel-current-scaffolding b/.agents/skills/parallel-current-scaffolding new file mode 120000 index 0000000..d68f6c4 --- /dev/null +++ b/.agents/skills/parallel-current-scaffolding @@ -0,0 +1 @@ +../../skills/parallel-current-scaffolding/ \ No newline at end of file diff --git a/.agents/skills/parallel-dependency-monitoring b/.agents/skills/parallel-dependency-monitoring new file mode 120000 index 0000000..d54aa04 --- /dev/null +++ b/.agents/skills/parallel-dependency-monitoring @@ -0,0 +1 @@ +../../skills/parallel-dependency-monitoring/ \ No newline at end of file diff --git a/.agents/skills/parallel-diligence-briefs b/.agents/skills/parallel-diligence-briefs new file mode 120000 index 0000000..fb5ce02 --- /dev/null +++ b/.agents/skills/parallel-diligence-briefs @@ -0,0 +1 @@ +../../skills/parallel-diligence-briefs/ \ No newline at end of file diff --git a/.agents/skills/parallel-doc-grounded-review b/.agents/skills/parallel-doc-grounded-review new file mode 120000 index 0000000..5b376e4 --- /dev/null +++ b/.agents/skills/parallel-doc-grounded-review @@ -0,0 +1 @@ +../../skills/parallel-doc-grounded-review/ \ No newline at end of file diff --git a/.agents/skills/parallel-emerging-risk-research b/.agents/skills/parallel-emerging-risk-research new file mode 120000 index 0000000..d7757fc --- /dev/null +++ b/.agents/skills/parallel-emerging-risk-research @@ -0,0 +1 @@ +../../skills/parallel-emerging-risk-research/ \ No newline at end of file diff --git a/.agents/skills/parallel-entity-context b/.agents/skills/parallel-entity-context new file mode 120000 index 0000000..e8be5a3 --- /dev/null +++ b/.agents/skills/parallel-entity-context @@ -0,0 +1 @@ +../../skills/parallel-entity-context/ \ No newline at end of file diff --git a/.agents/skills/parallel-entity-diligence b/.agents/skills/parallel-entity-diligence new file mode 120000 index 0000000..eafc76d --- /dev/null +++ b/.agents/skills/parallel-entity-diligence @@ -0,0 +1 @@ +../../skills/parallel-entity-diligence/ \ No newline at end of file diff --git a/.agents/skills/parallel-exposure-discovery b/.agents/skills/parallel-exposure-discovery new file mode 120000 index 0000000..8ba3118 --- /dev/null +++ b/.agents/skills/parallel-exposure-discovery @@ -0,0 +1 @@ +../../skills/parallel-exposure-discovery/ \ No newline at end of file diff --git a/.agents/skills/parallel-finance-quickstart b/.agents/skills/parallel-finance-quickstart new file mode 120000 index 0000000..59ddc62 --- /dev/null +++ b/.agents/skills/parallel-finance-quickstart @@ -0,0 +1 @@ +../../skills/parallel-finance-quickstart/ \ No newline at end of file diff --git a/.agents/skills/parallel-finance-setup b/.agents/skills/parallel-finance-setup new file mode 120000 index 0000000..0a6b504 --- /dev/null +++ b/.agents/skills/parallel-finance-setup @@ -0,0 +1 @@ +../../skills/parallel-finance-setup/ \ No newline at end of file diff --git a/.agents/skills/parallel-findall b/.agents/skills/parallel-findall new file mode 120000 index 0000000..01034ff --- /dev/null +++ b/.agents/skills/parallel-findall @@ -0,0 +1 @@ +../../skills/parallel-findall/ \ No newline at end of file diff --git a/.agents/skills/parallel-gtm-quickstart b/.agents/skills/parallel-gtm-quickstart new file mode 120000 index 0000000..8e9c427 --- /dev/null +++ b/.agents/skills/parallel-gtm-quickstart @@ -0,0 +1 @@ +../../skills/parallel-gtm-quickstart/ \ No newline at end of file diff --git a/.agents/skills/parallel-gtm-setup b/.agents/skills/parallel-gtm-setup new file mode 120000 index 0000000..fd06df5 --- /dev/null +++ b/.agents/skills/parallel-gtm-setup @@ -0,0 +1 @@ +../../skills/parallel-gtm-setup/ \ No newline at end of file diff --git a/.agents/skills/parallel-in-product-research b/.agents/skills/parallel-in-product-research new file mode 120000 index 0000000..253c9a1 --- /dev/null +++ b/.agents/skills/parallel-in-product-research @@ -0,0 +1 @@ +../../skills/parallel-in-product-research/ \ No newline at end of file diff --git a/.agents/skills/parallel-insurance-kyb-kyc b/.agents/skills/parallel-insurance-kyb-kyc new file mode 120000 index 0000000..8a58de5 --- /dev/null +++ b/.agents/skills/parallel-insurance-kyb-kyc @@ -0,0 +1 @@ +../../skills/parallel-insurance-kyb-kyc/ \ No newline at end of file diff --git a/.agents/skills/parallel-insurance-quickstart b/.agents/skills/parallel-insurance-quickstart new file mode 120000 index 0000000..415699c --- /dev/null +++ b/.agents/skills/parallel-insurance-quickstart @@ -0,0 +1 @@ +../../skills/parallel-insurance-quickstart/ \ No newline at end of file diff --git a/.agents/skills/parallel-insurance-setup b/.agents/skills/parallel-insurance-setup new file mode 120000 index 0000000..47a4397 --- /dev/null +++ b/.agents/skills/parallel-insurance-setup @@ -0,0 +1 @@ +../../skills/parallel-insurance-setup/ \ No newline at end of file diff --git a/.agents/skills/parallel-knowledge-freshness b/.agents/skills/parallel-knowledge-freshness new file mode 120000 index 0000000..a883228 --- /dev/null +++ b/.agents/skills/parallel-knowledge-freshness @@ -0,0 +1 @@ +../../skills/parallel-knowledge-freshness/ \ No newline at end of file diff --git a/.agents/skills/parallel-kyb-kyc b/.agents/skills/parallel-kyb-kyc new file mode 120000 index 0000000..71e37d2 --- /dev/null +++ b/.agents/skills/parallel-kyb-kyc @@ -0,0 +1 @@ +../../skills/parallel-kyb-kyc/ \ No newline at end of file diff --git a/.agents/skills/parallel-landscape-deep-research b/.agents/skills/parallel-landscape-deep-research new file mode 120000 index 0000000..96e8a62 --- /dev/null +++ b/.agents/skills/parallel-landscape-deep-research @@ -0,0 +1 @@ +../../skills/parallel-landscape-deep-research/ \ No newline at end of file diff --git a/.agents/skills/parallel-lead-discovery b/.agents/skills/parallel-lead-discovery new file mode 120000 index 0000000..c9422e0 --- /dev/null +++ b/.agents/skills/parallel-lead-discovery @@ -0,0 +1 @@ +../../skills/parallel-lead-discovery/ \ No newline at end of file diff --git a/.agents/skills/parallel-legal-quickstart b/.agents/skills/parallel-legal-quickstart new file mode 120000 index 0000000..3bdd792 --- /dev/null +++ b/.agents/skills/parallel-legal-quickstart @@ -0,0 +1 @@ +../../skills/parallel-legal-quickstart/ \ No newline at end of file diff --git a/.agents/skills/parallel-legal-setup b/.agents/skills/parallel-legal-setup new file mode 120000 index 0000000..00bfb0e --- /dev/null +++ b/.agents/skills/parallel-legal-setup @@ -0,0 +1 @@ +../../skills/parallel-legal-setup/ \ No newline at end of file diff --git a/.agents/skills/parallel-licensing-discovery b/.agents/skills/parallel-licensing-discovery new file mode 120000 index 0000000..f189af1 --- /dev/null +++ b/.agents/skills/parallel-licensing-discovery @@ -0,0 +1 @@ +../../skills/parallel-licensing-discovery/ \ No newline at end of file diff --git a/.agents/skills/parallel-life-sciences-quickstart b/.agents/skills/parallel-life-sciences-quickstart new file mode 120000 index 0000000..f8b0710 --- /dev/null +++ b/.agents/skills/parallel-life-sciences-quickstart @@ -0,0 +1 @@ +../../skills/parallel-life-sciences-quickstart/ \ No newline at end of file diff --git a/.agents/skills/parallel-life-sciences-setup b/.agents/skills/parallel-life-sciences-setup new file mode 120000 index 0000000..25d929e --- /dev/null +++ b/.agents/skills/parallel-life-sciences-setup @@ -0,0 +1 @@ +../../skills/parallel-life-sciences-setup/ \ No newline at end of file diff --git a/.agents/skills/parallel-literature-mining b/.agents/skills/parallel-literature-mining new file mode 120000 index 0000000..49d015a --- /dev/null +++ b/.agents/skills/parallel-literature-mining @@ -0,0 +1 @@ +../../skills/parallel-literature-mining/ \ No newline at end of file diff --git a/.agents/skills/parallel-monitor b/.agents/skills/parallel-monitor new file mode 120000 index 0000000..106456e --- /dev/null +++ b/.agents/skills/parallel-monitor @@ -0,0 +1 @@ +../../skills/parallel-monitor/ \ No newline at end of file diff --git a/.agents/skills/parallel-org-chart b/.agents/skills/parallel-org-chart new file mode 120000 index 0000000..da28ac6 --- /dev/null +++ b/.agents/skills/parallel-org-chart @@ -0,0 +1 @@ +../../skills/parallel-org-chart/ \ No newline at end of file diff --git a/.agents/skills/parallel-pipeline-monitoring b/.agents/skills/parallel-pipeline-monitoring new file mode 120000 index 0000000..9077cc5 --- /dev/null +++ b/.agents/skills/parallel-pipeline-monitoring @@ -0,0 +1 @@ +../../skills/parallel-pipeline-monitoring/ \ No newline at end of file diff --git a/.agents/skills/parallel-platform-web-access b/.agents/skills/parallel-platform-web-access new file mode 120000 index 0000000..0ae89d9 --- /dev/null +++ b/.agents/skills/parallel-platform-web-access @@ -0,0 +1 @@ +../../skills/parallel-platform-web-access/ \ No newline at end of file diff --git a/.agents/skills/parallel-portfolio-monitoring b/.agents/skills/parallel-portfolio-monitoring new file mode 120000 index 0000000..53d3318 --- /dev/null +++ b/.agents/skills/parallel-portfolio-monitoring @@ -0,0 +1 @@ +../../skills/parallel-portfolio-monitoring/ \ No newline at end of file diff --git a/.agents/skills/parallel-productivity-quickstart b/.agents/skills/parallel-productivity-quickstart new file mode 120000 index 0000000..aedb7c6 --- /dev/null +++ b/.agents/skills/parallel-productivity-quickstart @@ -0,0 +1 @@ +../../skills/parallel-productivity-quickstart/ \ No newline at end of file diff --git a/.agents/skills/parallel-productivity-setup b/.agents/skills/parallel-productivity-setup new file mode 120000 index 0000000..71af36b --- /dev/null +++ b/.agents/skills/parallel-productivity-setup @@ -0,0 +1 @@ +../../skills/parallel-productivity-setup/ \ No newline at end of file diff --git a/.agents/skills/parallel-regulatory-monitoring b/.agents/skills/parallel-regulatory-monitoring new file mode 120000 index 0000000..a950baf --- /dev/null +++ b/.agents/skills/parallel-regulatory-monitoring @@ -0,0 +1 @@ +../../skills/parallel-regulatory-monitoring/ \ No newline at end of file diff --git a/.agents/skills/parallel-signal-monitoring b/.agents/skills/parallel-signal-monitoring new file mode 120000 index 0000000..aba58c4 --- /dev/null +++ b/.agents/skills/parallel-signal-monitoring @@ -0,0 +1 @@ +../../skills/parallel-signal-monitoring/ \ No newline at end of file diff --git a/.agents/skills/parallel-source-grounded-research b/.agents/skills/parallel-source-grounded-research new file mode 120000 index 0000000..21eccd0 --- /dev/null +++ b/.agents/skills/parallel-source-grounded-research @@ -0,0 +1 @@ +../../skills/parallel-source-grounded-research/ \ No newline at end of file diff --git a/.agents/skills/parallel-target-discovery b/.agents/skills/parallel-target-discovery new file mode 120000 index 0000000..c20960c --- /dev/null +++ b/.agents/skills/parallel-target-discovery @@ -0,0 +1 @@ +../../skills/parallel-target-discovery/ \ No newline at end of file diff --git a/.agents/skills/parallel-task-mcp-setup b/.agents/skills/parallel-task-mcp-setup new file mode 120000 index 0000000..6e03021 --- /dev/null +++ b/.agents/skills/parallel-task-mcp-setup @@ -0,0 +1 @@ +../../skills/parallel-task-mcp-setup/ \ No newline at end of file diff --git a/.agents/skills/parallel-tech-deep-research b/.agents/skills/parallel-tech-deep-research new file mode 120000 index 0000000..64812bc --- /dev/null +++ b/.agents/skills/parallel-tech-deep-research @@ -0,0 +1 @@ +../../skills/parallel-tech-deep-research/ \ No newline at end of file diff --git a/.agents/skills/parallel-thesis-research b/.agents/skills/parallel-thesis-research new file mode 120000 index 0000000..a8a9f6b --- /dev/null +++ b/.agents/skills/parallel-thesis-research @@ -0,0 +1 @@ +../../skills/parallel-thesis-research/ \ No newline at end of file diff --git a/.agents/skills/parallel-underwriting-risk-profiles b/.agents/skills/parallel-underwriting-risk-profiles new file mode 120000 index 0000000..1cb3507 --- /dev/null +++ b/.agents/skills/parallel-underwriting-risk-profiles @@ -0,0 +1 @@ +../../skills/parallel-underwriting-risk-profiles/ \ No newline at end of file diff --git a/.agents/skills/parallel-workspace-agent b/.agents/skills/parallel-workspace-agent new file mode 120000 index 0000000..ec30c21 --- /dev/null +++ b/.agents/skills/parallel-workspace-agent @@ -0,0 +1 @@ +../../skills/parallel-workspace-agent/ \ No newline at end of file diff --git a/README.md b/README.md index 34efaaf..61387c7 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ # Parallel Agent Skills -[Agent Skills](https://agentskills.io/specification) for [Parallel](https://parallel.ai) — web search, content extraction, deep research, and data enrichment for AI coding agents. +[Agent Skills](https://agentskills.io/specification) for [Parallel](https://parallel.ai): web search, content extraction, deep research, data enrichment, and domain workflows for AI coding agents. ## Prerequisites -Most execution skills require `parallel-cli` (installed, authenticated, and funded). The [`parallel-cli-setup`](skills/parallel-cli-setup/SKILL.md) skill walks an agent through install, auth, balance, and skills install end-to-end — install the plugin/skills below, then run `/parallel:parallel-cli-setup` from your agent. +Most execution skills require `parallel-cli` (installed, authenticated, and funded). The [`parallel-cli-setup`](skills/parallel-cli-setup/SKILL.md) skill walks an agent through installation, authentication, balance checks, and skill installation. Install the plugin or skills below, then run `/parallel:parallel-cli-setup` from your agent. `migrate-to-parallel` updates an application's own web-data integration. It uses the appropriate Parallel API or SDK and needs `PARALLEL_API_KEY` only for an explicitly authorized live smoke test. @@ -52,14 +52,14 @@ A human + machine-readable catalog is published at [skills.parallel.ai](https:// Useful endpoints: -- [skills.parallel.ai](https://skills.parallel.ai) — human-friendly catalog and install instructions -- [skills.parallel.ai/index.json](https://skills.parallel.ai/index.json) — machine-readable skill index -- `https://skills.parallel.ai//SKILL.md` — live raw skill file -- `https://skills.parallel.ai//manifest.json` — file manifest + checksums -- `https://skills.parallel.ai//versions.json` — release history for that skill -- `https://skills.parallel.ai/archives//.zip` — immutable GitHub Release archive via CDN redirect +- [skills.parallel.ai](https://skills.parallel.ai): human-friendly catalog and install instructions +- [skills.parallel.ai/index.json](https://skills.parallel.ai/index.json): machine-readable skill index +- `https://skills.parallel.ai//SKILL.md`: live raw skill file +- `https://skills.parallel.ai//manifest.json`: file manifest and checksums +- `https://skills.parallel.ai//versions.json`: release history for that skill +- `https://skills.parallel.ai/archives//.zip`: immutable GitHub Release archive via CDN redirect -## Skills +## Core skills Skills follow the [Agent Skills](https://agentskills.io/specification) specification and double as Claude Code slash commands. @@ -74,9 +74,24 @@ Skills follow the [Agent Skills](https://agentskills.io/specification) specifica | **parallel-memory** | Recall and manage saved Parallel runs | | **migrate-to-parallel** | Migrate Exa, Tavily, Perplexity, or Firecrawl integrations to Parallel | | **parallel-cli-setup** | Install/update CLI, authenticate, and handle balance | +| **parallel-task-mcp-setup** | Install, authenticate, and verify Parallel Task MCP | | **status** | Check running research task status | | **result** | Get completed research task result | +## Domain workflow skills + +Each domain includes a setup router and focused skills for its common workflows. + +| Domain | Skills | +| ------ | ------ | +| **Code** | [`parallel-code-setup`](skills/parallel-code-setup/SKILL.md), [`parallel-code-quickstart`](skills/parallel-code-quickstart/SKILL.md), [`parallel-current-scaffolding`](skills/parallel-current-scaffolding/SKILL.md), [`parallel-dependency-monitoring`](skills/parallel-dependency-monitoring/SKILL.md), [`parallel-doc-grounded-review`](skills/parallel-doc-grounded-review/SKILL.md), [`parallel-platform-web-access`](skills/parallel-platform-web-access/SKILL.md), [`parallel-tech-deep-research`](skills/parallel-tech-deep-research/SKILL.md) | +| **Finance** | [`parallel-finance-setup`](skills/parallel-finance-setup/SKILL.md), [`parallel-company-profiles`](skills/parallel-company-profiles/SKILL.md), [`parallel-finance-quickstart`](skills/parallel-finance-quickstart/SKILL.md), [`parallel-kyb-kyc`](skills/parallel-kyb-kyc/SKILL.md), [`parallel-portfolio-monitoring`](skills/parallel-portfolio-monitoring/SKILL.md), [`parallel-target-discovery`](skills/parallel-target-discovery/SKILL.md), [`parallel-thesis-research`](skills/parallel-thesis-research/SKILL.md) | +| **GTM** | [`parallel-gtm-setup`](skills/parallel-gtm-setup/SKILL.md), [`parallel-account-briefs`](skills/parallel-account-briefs/SKILL.md), [`parallel-account-enrichment`](skills/parallel-account-enrichment/SKILL.md), [`parallel-gtm-quickstart`](skills/parallel-gtm-quickstart/SKILL.md), [`parallel-lead-discovery`](skills/parallel-lead-discovery/SKILL.md), [`parallel-org-chart`](skills/parallel-org-chart/SKILL.md), [`parallel-signal-monitoring`](skills/parallel-signal-monitoring/SKILL.md) | +| **Insurance** | [`parallel-insurance-setup`](skills/parallel-insurance-setup/SKILL.md), [`parallel-book-risk-monitoring`](skills/parallel-book-risk-monitoring/SKILL.md), [`parallel-claims-research`](skills/parallel-claims-research/SKILL.md), [`parallel-emerging-risk-research`](skills/parallel-emerging-risk-research/SKILL.md), [`parallel-insurance-kyb-kyc`](skills/parallel-insurance-kyb-kyc/SKILL.md), [`parallel-insurance-quickstart`](skills/parallel-insurance-quickstart/SKILL.md), [`parallel-underwriting-risk-profiles`](skills/parallel-underwriting-risk-profiles/SKILL.md) | +| **Legal** | [`parallel-legal-setup`](skills/parallel-legal-setup/SKILL.md), [`parallel-diligence-briefs`](skills/parallel-diligence-briefs/SKILL.md), [`parallel-entity-diligence`](skills/parallel-entity-diligence/SKILL.md), [`parallel-exposure-discovery`](skills/parallel-exposure-discovery/SKILL.md), [`parallel-legal-quickstart`](skills/parallel-legal-quickstart/SKILL.md), [`parallel-regulatory-monitoring`](skills/parallel-regulatory-monitoring/SKILL.md), [`parallel-source-grounded-research`](skills/parallel-source-grounded-research/SKILL.md) | +| **Life sciences** | [`parallel-life-sciences-setup`](skills/parallel-life-sciences-setup/SKILL.md), [`parallel-competitive-landscape`](skills/parallel-competitive-landscape/SKILL.md), [`parallel-landscape-deep-research`](skills/parallel-landscape-deep-research/SKILL.md), [`parallel-licensing-discovery`](skills/parallel-licensing-discovery/SKILL.md), [`parallel-life-sciences-quickstart`](skills/parallel-life-sciences-quickstart/SKILL.md), [`parallel-literature-mining`](skills/parallel-literature-mining/SKILL.md), [`parallel-pipeline-monitoring`](skills/parallel-pipeline-monitoring/SKILL.md) | +| **Productivity** | [`parallel-productivity-setup`](skills/parallel-productivity-setup/SKILL.md), [`parallel-entity-context`](skills/parallel-entity-context/SKILL.md), [`parallel-in-product-research`](skills/parallel-in-product-research/SKILL.md), [`parallel-knowledge-freshness`](skills/parallel-knowledge-freshness/SKILL.md), [`parallel-productivity-quickstart`](skills/parallel-productivity-quickstart/SKILL.md), [`parallel-workspace-agent`](skills/parallel-workspace-agent/SKILL.md) | + ## Examples ```text diff --git a/skills/parallel-account-briefs/SKILL.md b/skills/parallel-account-briefs/SKILL.md new file mode 100644 index 0000000..4ea9bd0 --- /dev/null +++ b/skills/parallel-account-briefs/SKILL.md @@ -0,0 +1,150 @@ +--- +name: parallel-account-briefs +description: Full, source-cited pre-meeting brief on a target account, a snapshot (what they do, how they make money, how they're doing), their current business initiatives, why-now triggers, and who to reach (the buying committee). Use when the user wants a "pre-call brief", "deep research on this account", or "prep me for this meeting". Runs on the user's own Parallel account via Task deep research. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Account Briefs + +A full, cited pre-meeting brief on a target account, the deep version of the quickstart. It +gives a rep, in order: a one-glance **snapshot** (what they do, how they make money, how +they're doing), their current **business initiatives**, **why now** (recent triggers), and +**who to reach** (the buying committee). Every point is sourced and dated so it's auditable, +and nothing is fabricated, if it can't be verified it says so. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`). +- **CLI / build-on-top:** the installed **`parallel-deep-research`** skill (`parallel-cli + skills install`), maintained by Parallel. + +Raw HTTP API at the bottom for pipelines. If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its ICP / value framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +1. **Which target company?** One domain, or a priority list (one run each). +2. **Which sections?** Default: snapshot, initiatives, why-now, who-to-reach. +3. **Tier?** `pro` for a real brief; `core2x`/`core` for routine or high volume. + +Confirm, then run. + +## Run it + +Deep research warrants a higher tier, default `pro` here. Substitute the target domain. +Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["company", "snapshot", "business_initiatives", "why_now", "buying_committee"], + "properties": { + "company": {"type": "string"}, + "snapshot": { + "type": "object", + "additionalProperties": false, + "required": ["what_they_do", "how_they_make_money", "business_health"], + "properties": { + "what_they_do": {"type": "string", "description": "one line: the product/service and who it's for"}, + "how_they_make_money": {"type": "string", "description": "revenue model / main lines of business"}, + "business_health": {"type": "string", "description": "how they're doing: growth, funding, scale, or trouble signs (sourced)"} + } + }, + "business_initiatives": { + "type": "array", + "description": "current, public strategic initiatives / priorities", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["initiative", "why_it_matters", "source_url"], + "properties": { + "initiative": {"type": "string", "description": "a current initiative/priority, from a public source"}, + "why_it_matters": {"type": "string", "description": "one line on the implication / the opening it creates"}, + "source_url": {"type": "string", "description": "resolving source; must load"} + } + } + }, + "why_now": { + "type": "array", + "description": "recent triggers (last ~6 months) making now a good time to reach out; empty array if none", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["signal", "signal_date", "source_url"], + "properties": { + "signal": {"type": "string"}, + "signal_type": {"type": "string", "enum": ["funding", "hiring", "product_launch", "exec_change", "expansion", "customer_win", "m_and_a", "other"]}, + "signal_date": {"type": "string", "description": "ISO 8601 date"}, + "source_url": {"type": "string"} + } + } + }, + "buying_committee": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["person_name", "title", "role_in_deal", "source_url"], + "properties": { + "person_name": {"type": "string"}, + "title": {"type": "string"}, + "role_in_deal": {"type": "string", "enum": ["champion", "economic_buyer", "influencer", "technical_evaluator", "blocker", "other"]}, + "source_url": {"type": "string"} + } + } + } + } +} +``` + +Prompt (substitute the target domain): + +> Produce a pre-meeting brief on the company at {TARGET_DOMAIN}. Cite a resolving source with +> a date for every claim; never invent anything, say "Not found" if you can't verify it. +> +> 1) **Snapshot** (one line each): what they do, how they make money, and how they're doing as +> a business (growth, funding, scale, or trouble signs). +> +> 2) **Business initiatives:** their current, public strategic priorities. For each: the +> initiative (sourced) and one line on why it matters / the opening it creates. +> +> 3) **Why now:** recent events (last ~6 months), funding, notable hiring, a product/AI +> launch, an exec change, expansion, a customer win, or M&A, with a one-line summary, date, +> and source. +> +> 4) **Who to reach:** champion, economic buyer, technical evaluator, influencers, blockers, +> with name, exact title, role in the deal, and source. +> +> Lead the reader to: who they are, what they're focused on, why now, and who to call. + +## Read it + +Top to bottom: the **snapshot** (who they are in three lines) → **initiatives** (what they're +focused on, each with why it matters) → the freshest **why-now** as the reason to reach out +now → **who to reach** (champion + economic buyer first). Where something came back "Not +found", say so, the refusal to fabricate is the point. + +## Config seams (build on top) + +1. **Input**: one company, or batch a priority list (one run each). +2. **Sections**: edit the schema to the sections your reps want. +3. **Tier**: `pro` for a real brief; `core2x`/`core` for routine (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, `GET /v1/tasks/runs/{run_id}/result`; +citations in `output.basis`. Auth `x-api-key`, server-side only. Prefer the CLI/MCP unless you +need raw control. + +## Next + +- Just need who-to-reach + why-now fast → **gtm-quickstart** (the light version). +- Whole list, lighter → **account-enrichment** (tear sheets). +- Keep the brief live → **signal-monitoring**. diff --git a/skills/parallel-account-enrichment/SKILL.md b/skills/parallel-account-enrichment/SKILL.md new file mode 100644 index 0000000..a60de1a --- /dev/null +++ b/skills/parallel-account-enrichment/SKILL.md @@ -0,0 +1,103 @@ +--- +name: parallel-account-enrichment +description: Enrich a list of accounts into structured, source-cited tear sheets, revenue band, headcount, tech stack, funding, strategic initiatives, with a confidence score and a source for every field. Use when the user wants to "enrich these accounts", "build tear sheets", "fill in our CRM", or turn a prospect list into CRM-ready intelligence. Runs on the user's own Parallel account. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Account Enrichment + +Start with a list of accounts, get back a structured, cited **tear sheet** for each, ready +for your CRM. Every field carries a confidence score and a resolving source; if a fact +isn't on a reachable source, the field comes back empty, never guessed. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`), one input per account. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-data-enrichment`** skill + (`parallel-cli skills install`). + +If Parallel is not configured, run the relevant setup skill first. See +[docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its company / ICP / value framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Three quick questions before running (each account is a billable enrichment): +1. **Your account list?** Domains, names + domains, or a pasted list. +2. **Which fields?** Default is the tear sheet (revenue band, headcount, tech stack, funding, strategy). Add or drop to match your CRM. +3. **Run how many now?** Start with a small batch (5-10) to check quality, then scale. + +Confirm, then run. + +## Run it + +One task per account (batch the list). Output shape, the tear sheet: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["company", "fields"], + "properties": { + "company": {"type": "string"}, + "fields": { + "type": "object", + "additionalProperties": false, + "properties": { + "revenue_band": {"type": "string", "description": "e.g. $20-50M; empty string if not found"}, + "headcount": {"type": "string", "description": "e.g. 201-500; empty if not found"}, + "tech_stack": {"type": "string", "description": "notable tools/platforms in use"}, + "funding": {"type": "string", "description": "latest round + amount + date"}, + "strategic_initiatives":{"type": "string", "description": "current priorities / direction"} + } + }, + "basis": { + "type": "array", + "description": "one entry per field: the source behind it and a confidence", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["field", "source_url", "confidence"], + "properties": { + "field": {"type": "string"}, + "source_url": {"type": "string", "description": "resolving source that backs the field; must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + } + } +} +``` + +Prompt (per account, substitute the domain): + +> Build a tear sheet for the company at {COMPANY_DOMAIN}: revenue band, headcount, tech +> stack, latest funding (round, amount, date), and current strategic initiatives. For every +> field, cite a resolving source URL and give a 0-100 confidence. Never invent a value, if a +> fact isn't on a reachable source, return an empty string for that field. Prefer a small +> correct sheet over a full speculative one. + +## Config seams (build on top) + +1. **Input**: your account list (domains or names+domains); run one enrichment per row. +2. **Fields**: edit the `fields` object to the columns your CRM needs. Keys become columns. +3. **Tier**: `core` default; `core2x`/`pro` for depth, `lite` for a fast pass. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations return in `output.basis`. Auth via +`x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the CLI/MCP. + +## Next + +- Don't have the list yet → **lead-discovery** (describe your ICP, get candidates). +- Keep it fresh → **signal-monitoring** (re-enrich or alert when something changes). +- Go deeper on the priority accounts → **account-briefs** (full research report). diff --git a/skills/parallel-book-risk-monitoring/SKILL.md b/skills/parallel-book-risk-monitoring/SKILL.md new file mode 100644 index 0000000..30afe92 --- /dev/null +++ b/skills/parallel-book-risk-monitoring/SKILL.md @@ -0,0 +1,92 @@ +--- +name: parallel-book-risk-monitoring +description: Watch the entities, locations, and regulations tied to your policies and get alerted the moment something material changes, adverse media, sanctions listings, litigation, catastrophe exposure, and fraud signals, deduped and cited. Use when the user wants to "monitor my book", "alert me on sanctions/catastrophe/litigation across policies", "watch these insureds", or set up book-of-business risk surveillance. Runs on the user's own Parallel account via Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(curl:*) +metadata: + author: parallel +--- + +# Book Risk Monitoring + +Watch the entities, locations, and regulations tied to your policies and get alerted the moment +something material changes, an adverse-media story, a sanctions listing, new litigation, a +catastrophe exposure, or a fraud signal. Dedup is handled, so you only hear about real changes, +and each alert is structured and cited so it can route straight to the underwriter or claims +handler who owns the policy. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **CLI / build-on-top:** the installed **`parallel-monitor`** skill (`parallel-cli skills + install`) is the maintained path. +- Monitor is the stable `v1` API; the raw endpoint is included below for pipelines. + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its lines / jurisdictions framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Before creating monitors (each is a recurring, billable watch): +1. **Which policies / entities?** The insureds, locations, or entities to watch (one monitor per entity, or per location cohort). +2. **Which signals?** Default: adverse media, sanctions, litigation, catastrophe exposure, fraud. Trim to what you act on. +3. **Cadence?** Daily (`1d`) is the usual default; tighten around an active catastrophe window. + +Confirm, then create. + +## Run it + +The shape that works: run **one broad monitor per entity** (or per location cohort) and classify +the signal downstream, not one monitor per signal type. It's far cheaper per record and dedups +cleanly. A monitor runs on a schedule, catches new matches, and returns structured output. + +Output shape per detected signal: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["signal_type", "subject", "summary", "signal_date", "source_url"], + "properties": { + "signal_type": {"type": "string", "enum": ["adverse_media", "sanctions", "litigation", "catastrophe", "fraud", "regulatory", "other"]}, + "subject": {"type": "string", "description": "the insured / entity / location the signal concerns"}, + "policies_affected": {"type": "string", "description": "which policies this touches, if known (e.g. '14 policies in evacuation zone')"}, + "summary": {"type": "string", "description": "one-line factual summary of what changed"}, + "signal_date": {"type": "string", "description": "ISO 8601 date"}, + "route_to": {"type": "string", "description": "who/what this should route to, e.g. the policy owner"}, + "source_url": {"type": "string", "description": "resolving source (OFAC, NOAA/NHC, court records, news); must load"} + } +} +``` + +Query per entity (substitute): + +> Notify me whenever {ENTITY_OR_LOCATION} shows a concrete, sourced material-risk signal: adverse +> media, a sanctions or watchlist listing, new litigation, a catastrophe exposure (storm, +> wildfire, flood), or a fraud indicator. Give a one-line summary, the date, and a resolving +> source (OFAC, NOAA/NHC, court records, or the news item). Where you can, note which policies it +> touches. Prioritize named, dated, sourced facts; exclude rumor. + +## Config seams (build on top) + +1. **Entities:** one monitor per insured, or per location cohort for catastrophe (loop your book). +2. **Signal types:** edit the `signal_type` enum + the query to what you act on. +3. **Policy mapping:** `policies_affected` + `route_to` push each signal to the right owner and file. +4. **Cadence:** daily (`1d`) default; tighten around an active catastrophe window, cadence controls latency, not how much you catch. +5. **Processor:** `lite` is the cheap forward-watch default; `base` for heavier scans. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ `POST /v1/monitors` +(`type: event_stream`, `frequency`, `processor`, `settings.query`, `settings.output_schema`), +read hits at `GET /v1/monitors/{id}/events`, optional `webhook` to push into your claims / policy +system. `event_stream` only catches change **going forward**, seed current exposure with a Task +first if you need a baseline now. Auth via `x-api-key`, same key creates and reads. + +## Next + +- Re-underwrite an insured a signal flags → **underwriting-risk-profiles**. +- Re-screen an entity a sanctions hit flags → **kyb-kyc**. +- Research the peril behind a catastrophe cluster → **emerging-risk-research**. diff --git a/skills/parallel-claims-research/SKILL.md b/skills/parallel-claims-research/SKILL.md new file mode 100644 index 0000000..16b751c --- /dev/null +++ b/skills/parallel-claims-research/SKILL.md @@ -0,0 +1,107 @@ +--- +name: parallel-claims-research +description: Research a claim line by line, like-kind-and-quality matching, live pricing, and intake review, run against your own claim rules, with high-confidence lines cleared automatically and edge cases routed to a human, each line confidence-scored and cited. Use when the user wants to "research this claim", "match like-kind-and-quality", "price these lost items", or automate contents-claim intake. Runs on the user's own Parallel account via Task and Extract. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__claude_ai_Parallel_Web_Search_Paid__web_search, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Claims Research + +Research a claim **line by line**: like-kind-and-quality matching, live pricing, and intake +review, run against your own claim rules. High-confidence lines clear automatically; edge cases +route to a human. Every line is confidence-scored and carries the source behind the match and +price, so the auto-cleared ones are auditable and the routed ones arrive with the evidence +already attached. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`), one input per claim (or per line batch). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-web-search`** and + **`parallel-data-enrichment`** skills (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its lines and rules_source framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Three quick questions before running (each claim researched is a billable run): +1. **The claim lines?** The lost / damaged items (description, and any make/model or age). +2. **Your rules?** The claim rules to apply (depreciation, caps, coverage limits) and the auto-clear confidence threshold. +3. **Run how many now?** Start with one claim to check fidelity, then batch. + +Confirm, then run. + +## Run it + +One task per claim; each line gets a like-kind-and-quality match, a price, and a disposition. +Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["claim_ref", "lines"], + "properties": { + "claim_ref": {"type": "string"}, + "lines": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["lost_item", "like_kind_match", "price", "disposition", "confidence", "source_url"], + "properties": { + "lost_item": {"type": "string"}, + "like_kind_match": {"type": "string", "description": "the current like-kind-and-quality equivalent"}, + "price": {"type": "string", "description": "current price of the match, with currency"}, + "rule_applied": {"type": "string", "description": "the claim rule applied (depreciation, cap), if any"}, + "disposition": {"type": "string", "enum": ["auto_cleared", "human_review"], "description": "human_review when confidence is below threshold or a rule needs judgment"}, + "confidence": {"type": "integer", "description": "0-100"}, + "source_url": {"type": "string", "description": "resolving source for the match + price; must load"} + } + } + } + } +} +``` + +Prompt (substitute the claim + rules): + +> Research claim {CLAIM_REF} line by line. For each lost or damaged item, find the current +> like-kind-and-quality equivalent, its current price with a resolving source, and apply these +> claim rules: {RULES}. Give each line a 0-100 confidence and a disposition: "auto_cleared" if +> confidence is at or above {THRESHOLD} and no rule needs human judgment, otherwise +> "human_review". Never invent a match, a price, or a source, if you can't source a line, set +> low confidence and route it to human_review rather than guessing. + +**Read it:** the auto-cleared lines are done, each with its cited match and price; the +human_review lines are the queue, and they arrive with the evidence and the reason attached. The +threshold is the dial between throughput and touch, tune it on real claims. + +## Config seams (build on top) + +1. **Input:** the claim lines; run one task per claim, batch the queue. +2. **Rules:** encode your depreciation, caps, and coverage logic in the prompt (or a rules file you pass in). +3. **Threshold:** the auto-clear confidence cutoff is the throughput / touch dial. +4. **Tier:** `core` for volume (auto-clear the easy lines); `core2x` for a harder book or edge-case review (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations and confidence in `output.basis`. +Pricing lookups run through Search. Auth via `x-api-key`, server-side only. Prefer the CLI/MCP +unless you need raw control. + +## Next + +- Underwrite the risk behind the policy → **underwriting-risk-profiles**. +- Verify the claimant or business → **kyb-kyc**. +- Watch the book for fraud and catastrophe signals → **book-risk-monitoring**. diff --git a/skills/parallel-code-quickstart/SKILL.md b/skills/parallel-code-quickstart/SKILL.md new file mode 100644 index 0000000..0d27628 --- /dev/null +++ b/skills/parallel-code-quickstart/SKILL.md @@ -0,0 +1,78 @@ +--- +name: parallel-code-quickstart +description: Connect Parallel (if needed) and get ranked, current, source-cited answers for any library, framework, or error, from the official docs to the GitHub issue or Stack Overflow thread that explains the fix. Use when the user asks to "search the docs for X", "why is this error happening", "what's the current way to do Y in this library", or wants the Parallel code quickstart. Runs on the user's own Parallel account via Search. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__claude_ai_Parallel_Web_Search_Paid__web_search, mcp__claude_ai_Parallel_Web_Search_Paid__web_fetch +metadata: + author: parallel +--- + +# Code Quickstart + +The fastest way to see Parallel ground a coding agent: name a library, framework, or error and +get back **ranked, current sources**, the official doc, the changelog entry, the GitHub issue, +or the Stack Overflow thread where the fix actually lives, each with a link that resolves. +Replaces a brittle in-house web-search stack with one call, and nothing is invented: if the +answer isn't on a reachable source, it says so. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Parallel Web Search** tool (`web_search`, `web_fetch`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-web-search`** and + **`parallel-web-extract`** skills (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its stack and "current" framing (captured once at setup) to bias +the query toward your libraries and versions, don't re-ask it; only get the per-run specifics +below. + +Two quick questions before running (a search costs credits): +1. **What are you trying to resolve?** A library + task ("Next.js 15 app router middleware config"), or an exact error string. +2. **Any version to pin to?** Defaults to the current stable; name a version if you're on an older line. + +Confirm, then run. + +## Run it + +Issue the search with the objective phrased the way a developer would ask it. Prefer official +docs and the primary issue/thread over blog reposts. Read the ranked results; if excerpts are +enough, answer from them, only `web_fetch` a URL when you need exact wording to quote. + +Example objective: + +> Next.js 15 app router middleware config: the current, supported way to match dynamic routes, +> and any recent breaking change. Prefer nextjs.org docs, the relevant GitHub issue, and the +> accepted Stack Overflow answer. Return ranked sources with a one-line takeaway each, and cite +> a resolving URL for every claim. If the current behavior isn't documented on a reachable +> source, say so rather than guessing. + +**Read it:** lead with the current answer and the one authoritative source behind it (docs or +changelog), then the corroborating issue/thread, with the version the answer applies to. Where +a claim can't be sourced, say so out loud, that refusal to fabricate is what makes it safe to +hand to an agent. + +## Config seams (build on top) + +1. **The objective**: the library + task or the error string; this is the whole input. Seed it from the workspace `PROFILE.md` file so results skew to your stack. +2. **Source preference**: bias toward official docs, changelogs, and the primary issue/thread; down-rank blog reposts. +3. **Latency**: the Search / Responses path is latency-budgeted (`low` / `medium` / `high`) for when an agent is waiting on the result; see the tier guidance in this skill. +4. **Fetch only when needed**: answer from ranked excerpts by default; `web_fetch` a URL only for exact quotes or full-page analysis. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Search API: `POST +/v1/search` (objective + optional constraints), returns ranked results with excerpts and URLs; +`POST /v1/extract` (or the fetch endpoint) for clean quotable page text. Auth via `x-api-key`, +server-side only. Hardcoding means you own keeping it current, prefer the MCP/CLI. + +## Next + +- Review a diff against what you just found → **doc-grounded-review**. +- Scaffold against the current versions → **current-scaffolding**. +- Keep watching a library for changes → **dependency-monitoring**. diff --git a/skills/parallel-code-setup/SKILL.md b/skills/parallel-code-setup/SKILL.md new file mode 100644 index 0000000..f08ae77 --- /dev/null +++ b/skills/parallel-code-setup/SKILL.md @@ -0,0 +1,62 @@ +--- +name: parallel-code-setup +description: Connect a user's Parallel account and route code workflows to the matching skill. Use this first, or when the user says "set up Parallel", "get me started", or isn't sure which use case they need. +allowed-tools: Bash(command:*), Bash(claude:*), Bash(parallel-cli:*), Bash(script:*), Bash(git:*) +metadata: + author: parallel +--- + +# Code Setup + +Get connected once, then get pointed to the right use case. Everything runs on the user's own +Parallel account, no key is pasted. + +## 1. Ask what they want to do first (route before installing) + +Don't install or run anything yet. Ask one orienting question and route to the matching skill, +so the first thing they do is the thing they came for: + +> **What do you want to do first?** +> - **Find current sources for a library, framework, or error** → `parallel-code-quickstart` +> - **Review a change against live docs and deprecated APIs** → `parallel-doc-grounded-review` +> - **Scaffold or generate against the latest stable libraries** → `parallel-current-scaffolding` +> - **Get alerted on new releases, breaking changes, or CVEs** → `parallel-dependency-monitoring` +> - **Give every app on your platform live-web access** → `parallel-platform-web-access` +> - **Research a technical decision (migration, framework choice)** → `parallel-tech-deep-research` + +If they're unsure, start with `parallel-code-quickstart`, it's the fastest to value. + +## 2. Pick the surface and connect (once) + +**Non-technical (co-work / chat): just want output:** +Connect the Task MCP and run the use case in chat. See the `parallel-task-mcp-setup` skill. + +**Technical (build on top):** +Run the `parallel-cli-setup` skill to install and authenticate the CLI. Clone the repository only when the user wants to work from the source: + +```bash +git clone https://github.com/parallel-web/parallel-agent-skills +``` + +> If a call returns `401 Invalid API key`, a stale `PARALLEL_API_KEY` in your shell is +> overriding the login, run `unset PARALLEL_API_KEY` and retry. + +## 3. Capture the code profile once + +So the user doesn't re-enter their context on every run, capture what *they* build here, once: + +1. Ask: **what are you building, and on what stack?** (domain + product type). +2. Research the product on Parallel (a quick lookup) and infer the product type, stack, how + they'd integrate, and what "current" means to them. **Show the user what you found and let + them correct it, never assume**, a wrong guess on the first run is the thing that loses trust. +3. Write the confirmed result to `PROFILE.md` in the current workspace, using the + shape in [references/PROFILE.example.md](references/PROFILE.example.md). `PROFILE.md` is gitignored, so their details stay local. + +Every use-case skill reads `PROFILE.md` and uses that stack and "current" framing, so from here +the user only supplies the per-run target (which library, change, or question), not their whole +context each time. This is optional, skip it and each skill will just ask per-run. + +## 4. Hand off to the chosen use case + +Open that use case's `SKILL.md` and follow its guided intake (each one asks 1-3 questions and +confirms before anything billable runs). The use-case skills carry the build logic; this setup connects your account and chooses the next skill. diff --git a/skills/parallel-code-setup/references/PROFILE.example.md b/skills/parallel-code-setup/references/PROFILE.example.md new file mode 100644 index 0000000..3539d87 --- /dev/null +++ b/skills/parallel-code-setup/references/PROFILE.example.md @@ -0,0 +1,25 @@ +# Your code profile + +Captured once during setup (`parallel-code-setup`) and read by every skill, so you don't +re-enter your stack on every run. Setup writes this to `PROFILE.md` (which is gitignored, your +details stay local and are never committed). Edit it anytime. + +Fill these in (setup does it for you, inferred from your product and confirmed with you): + +- **product:** +- **domain:** +- **product_type:** +- **stack:** +- **integration:** +- **what_current_means:** +- **priorities:** + +Example (illustrative, not a real company): + +- **product:** Foundry Labs +- **domain:** foundrylabs.example +- **product_type:** app builder / codegen platform (users describe an app, we generate it) +- **stack:** TypeScript, Next.js, React, Tailwind, Drizzle ORM, Postgres, Zod +- **integration:** a build-step plus an agent tool, called server-side on the user's behalf +- **what_current_means:** latest stable minor for framework deps; security patches applied promptly +- **priorities:** generated apps must resolve against current library versions and avoid deprecated APIs, every fix cites a live source diff --git a/skills/parallel-company-profiles/SKILL.md b/skills/parallel-company-profiles/SKILL.md new file mode 100644 index 0000000..978bb68 --- /dev/null +++ b/skills/parallel-company-profiles/SKILL.md @@ -0,0 +1,109 @@ +--- +name: parallel-company-profiles +description: Turn a company name or a list into structured, source-cited tear sheets, financials, leadership, competitive position, and strategic trajectory, with a confidence score and a source for every field. Use when the user wants to "build a tear sheet", "profile these companies", "prep a diligence one-pager", or profile a vendor or counterparty. Runs on the user's own Parallel account. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Company Profiles + +Give a company name, get back a structured, cited **tear sheet**, financials, leadership, +competitive position, and strategic trajectory, sourced from filings, investor materials, and +the web. Works the same for a target, a vendor, or a counterparty. Every field carries a +confidence score and a resolving source; if a fact isn't on a reachable source, the field +comes back empty, never guessed. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`), one input per company. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-data-enrichment`** skill + (`parallel-cli skills install`). + +If Parallel is not configured, run the relevant setup skill first. See +[docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its firm / mandate / diligence-focus framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Three quick questions before running (each company is a billable profile): +1. **Which company or list?** Names, names + domains, or a pasted list. +2. **Which fields?** Default is the tear sheet (financials, leadership, competitive position, strategic trajectory). Add or drop to match your diligence checklist. +3. **Run how many now?** Start with a small batch (5-10) to check quality, then scale. + +Confirm, then run. + +## Run it + +One task per company (batch the list). Output shape, the tear sheet: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["company", "fields"], + "properties": { + "company": {"type": "string"}, + "fields": { + "type": "object", + "additionalProperties": false, + "properties": { + "financials": {"type": "string", "description": "revenue / EBITDA / margins with period; empty string if not public"}, + "ownership": {"type": "string", "description": "public/private, owners or sponsor, last financing"}, + "leadership": {"type": "string", "description": "CEO/CFO and other key executives"}, + "competitive_position": {"type": "string", "description": "market, main competitors, how they differentiate"}, + "strategic_trajectory": {"type": "string", "description": "current priorities and direction, sourced"} + } + }, + "basis": { + "type": "array", + "description": "one entry per field: the source behind it and a confidence", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["field", "source_url", "confidence"], + "properties": { + "field": {"type": "string"}, + "source_url": {"type": "string", "description": "resolving source that backs the field; must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + } + } +} +``` + +Prompt (per company, substitute the name/domain): + +> Build a tear sheet for {COMPANY}: financials (revenue, EBITDA, margins, with the period they +> cover), ownership (public or private, owners or sponsor, last financing), leadership (CEO, +> CFO, other key executives), competitive position (market, main competitors, how they +> differentiate), and strategic trajectory (current priorities and direction). Prefer SEC +> filings and investor materials for public companies. For every field, cite a resolving +> source URL and give a 0-100 confidence. Never invent a value, if a fact isn't on a reachable +> source, return an empty string for that field. Prefer a small correct sheet over a full +> speculative one. + +## Config seams (build on top) + +1. **Input**: your company list (names or names+domains); run one profile per row. +2. **Fields**: edit the `fields` object to your diligence checklist. Keys become columns. +3. **Tier**: `core` default; `core2x`/`pro` for depth on priority names, `lite` for a fast pass. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations return in `output.basis`. Auth via +`x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the CLI/MCP. + +## Next + +- Don't have the list yet → **target-discovery** (describe criteria, get candidates). +- Keep it fresh → **portfolio-monitoring** (re-profile or alert when something changes). +- Go deeper on a market or thesis → **thesis-research** (full cited report). +- Screening a counterparty → **kyb-kyc** (registry, ownership, sanctions, adverse media). diff --git a/skills/parallel-competitive-landscape/SKILL.md b/skills/parallel-competitive-landscape/SKILL.md new file mode 100644 index 0000000..9a4283a --- /dev/null +++ b/skills/parallel-competitive-landscape/SKILL.md @@ -0,0 +1,106 @@ +--- +name: parallel-competitive-landscape +description: Map a therapeutic area, target, or mechanism, approved and investigational assets, the companies behind them, clinical status, and the investors active in the space, as one structured, source-cited output. Use when the user wants to map the landscape for a target or area, identify who else is developing a mechanism, view the competitive set, or run a landscape analysis. Runs on the user's own Parallel account via Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Competitive Landscape + +Give it a therapeutic area, a target, or a mechanism, and get back the **competitive set** as +one structured, cited output: the approved and investigational assets, the companies behind +them, each asset's clinical status, and the investors active in the space. Every asset resolves +to a source; the long-tail programs that don't sit in a commercial database are surfaced too. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill + (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its therapeutic-area / focus framing (captured once at setup), it +often names the target or area to map, don't re-ask it; only get the per-run specifics below. + +Three quick questions before running (a landscape map is a billable run): +1. **What's the space?** A target (e.g. KRAS G12D), a mechanism, or a therapeutic area / indication. +2. **Which fields per asset?** Default: asset, company, phase, modality, indication, latest milestone. Add investors, deal status, or trial IDs. +3. **Scope?** All phases (default), or restrict (e.g. clinical-stage only, or a modality). + +Confirm, then run. + +## Run it + +One task for the space. Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["space", "assets"], + "properties": { + "space": {"type": "string", "description": "the target, mechanism, or area mapped"}, + "assets": { + "type": "array", + "description": "the competitive set; empty array if none are found on a reachable source", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["asset", "company", "phase", "source_url"], + "properties": { + "asset": {"type": "string", "description": "asset name / code"}, + "company": {"type": "string", "description": "developer / sponsor"}, + "phase": {"type": "string", "description": "clinical status or approval"}, + "modality": {"type": "string", "description": "small molecule, biologic, etc."}, + "indication": {"type": "string"}, + "investors": {"type": "string", "description": "investors active in the asset/company, if public; empty string if not found"}, + "source_url": {"type": "string", "description": "resolving source; must load"} + } + } + } + } +} +``` + +Prompt (substitute the space): + +> Map the competitive landscape for {SPACE}. Return every approved and investigational asset you +> can source: the asset, the company developing it, its clinical phase or approval status, the +> modality, the indication, and the investors active in the asset or company where public. +> Include long-tail and private-company programs, not just the well-covered ones. Cite a +> resolving source (ClinicalTrials.gov, FDA/EMA, company or investor disclosure, or the primary +> literature) for every asset. Never invent an asset, a phase, or a source, if you can't source +> a field, return an empty string. Prefer a smaller correct map over a padded speculative one. + +**Read it:** it's a competitive table, sort by phase to see who's ahead, and treat empty +`investors` or `phase` cells as "not sourced," not "none." The long-tail private programs are +usually the ones a commercial database misses. + +## Config seams (build on top) + +1. **Input:** the target, mechanism, or area; this is the whole input. Seed it from the workspace `PROFILE.md` file. +2. **Fields:** edit the `assets` shape to your landscape template (add deal status, next catalyst, patents). +3. **Scope:** all phases vs a filter (clinical-stage only, a modality, a geography). +4. **Tier:** `core2x` default for a thorough map; `core` for a quick scan, `pro` for a board-ready one (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations in `output.basis`. Auth via +`x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw control. + +## Next + +- Enrich or snapshot a single asset from the map → **life-sciences-quickstart**. +- Find net-new assets by BD criteria → **licensing-discovery**. +- Watch the set for changes → **pipeline-monitoring**. diff --git a/skills/parallel-current-scaffolding/SKILL.md b/skills/parallel-current-scaffolding/SKILL.md new file mode 100644 index 0000000..da92fa7 --- /dev/null +++ b/skills/parallel-current-scaffolding/SKILL.md @@ -0,0 +1,104 @@ +--- +name: parallel-current-scaffolding +description: Resolve the latest stable versions for a stack and scaffold or generate against live library references, so the apps you (or your users) generate run on what's current, not on deprecated methods the model learned in training. Use when the user wants to "scaffold an app", "pin the latest stable versions", "generate against current libraries", or ground a codegen step in the live web. Runs on the user's own Parallel account via Search and Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__claude_ai_Parallel_Web_Search_Paid__web_search, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Current Scaffolding + +Before you scaffold, resolve the **latest stable version** of every library in the stack and +pull the **current** reference for how to wire them together, so the app that gets generated +runs on what's current, not on the training-era defaults a model would otherwise emit. Every +version and pattern resolves to a source; unknowns are surfaced, not filled with a plausible +guess. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Parallel Web Search** tool (`web_search`) to resolve versions, the + **Task MCP** (`createTaskGroup`) to assemble the cited stack manifest. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-web-search`** and + **`parallel-deep-research`** skills (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its stack and "current" framing (captured once at setup), that +is usually the stack to resolve, don't re-ask it; only get the per-run specifics below. + +Two quick questions before running (resolving + assembling costs credits): +1. **Which libraries?** The dependency set to resolve (or "the stack in my profile"). +2. **Which channel?** Latest stable (default), latest minor within a pinned major, or include betas / RCs. + +Confirm, then run. + +## Run it + +Resolve each library to its current version and the current wiring reference, then assemble a +cited manifest. Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["stack", "dependencies"], + "properties": { + "stack": {"type": "string", "description": "what's being scaffolded, one line"}, + "dependencies": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["name", "latest_stable", "as_of", "source_url"], + "properties": { + "name": {"type": "string"}, + "latest_stable": {"type": "string", "description": "current stable version, e.g. ^15.5.x; empty string if not resolvable"}, + "as_of": {"type": "string", "description": "date the version was confirmed"}, + "note": {"type": "string", "description": "a current-usage caveat or breaking change to respect; empty if none"}, + "source_url": {"type": "string", "description": "resolving source (registry, release notes, docs); must load"} + } + } + } + } +} +``` + +Prompt (substitute the stack): + +> Resolve the latest {CHANNEL} version of each of these libraries and the current, supported way +> to wire them together: {LIBRARIES}. For each, return the version, the date you confirmed it, +> a resolving source (package registry, release notes, or official docs), and any current-usage +> caveat or breaking change a generated app must respect. Do not guess a version, if you can't +> resolve one from a reachable source, return an empty string and say so. Prefer official +> registries and docs over blog posts. + +**Read it:** it's a manifest to hand to your scaffolder, each dependency pinned to a current +version with the source that confirmed it and any caveat the generated code must respect. Where +a version couldn't be resolved, that's flagged, don't let the generator invent one. + +## Config seams (build on top) + +1. **Input**: the dependency set (or read it from the workspace `PROFILE.md` file); this is the whole input. +2. **Channel**: latest stable (default), latest minor within a pinned major, or include betas. +3. **Manifest fields**: extend `dependencies` (peer deps, min runtime, license) to what your scaffolder consumes. +4. **Tier**: `core` for assembling the manifest; the version lookups run through Search. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Resolve versions via +Search (`POST /v1/search`), assemble via Task (`POST /v1/tasks/runs` with +`task_spec.output_schema`, then `GET /v1/tasks/runs/{run_id}/result`; citations in +`output.basis`). Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw +control. + +## Next + +- Review the generated code against those versions → **doc-grounded-review**. +- Keep the manifest fresh as libraries move → **dependency-monitoring**. +- Offer this to every app on your platform → **platform-web-access**. diff --git a/skills/parallel-dependency-monitoring/SKILL.md b/skills/parallel-dependency-monitoring/SKILL.md new file mode 100644 index 0000000..ba93de4 --- /dev/null +++ b/skills/parallel-dependency-monitoring/SKILL.md @@ -0,0 +1,91 @@ +--- +name: parallel-dependency-monitoring +description: Watch a set of dependencies and get alerted the moment something material ships, a new release, a breaking change, a deprecation, or a CVE, deduped and cited, so you can apply safe updates instead of chasing changelogs. Use when the user wants to "monitor my dependencies", "alert me on breaking changes or CVEs", "watch for new releases", or set up safe-update automation. Runs on the user's own Parallel account via Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(curl:*) +metadata: + author: parallel +--- + +# Dependency Monitoring + +Watch the libraries you depend on and get alerted the moment something material ships, a new +release, a breaking change, a deprecation, or a CVE. Dedup is handled, so you only hear about +real changes, and each alert is structured and cited so an agent can decide whether the update +is safe to apply. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **CLI / build-on-top:** the installed **`parallel-monitor`** skill (`parallel-cli skills + install`) is the maintained path. +- Monitor is the stable `v1` API; the raw endpoint is included below for pipelines. + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its stack and "current" framing (captured once at setup), that's +usually the set to watch, don't re-ask it; only get the per-run specifics below. + +Before creating monitors (each is a recurring, billable watch): +1. **Which dependencies?** The libraries to watch (one monitor per library, or one per stack). +2. **Which events?** Default: new release, breaking change, deprecation, CVE / security advisory. Trim to what you act on. +3. **Cadence?** Daily (`1d`) is the usual default; hourly for security-critical deps. + +Confirm, then create. + +## Run it + +The shape that works: run **one broad monitor per library** (or per stack) and classify the +event downstream, not one monitor per event type. It's far cheaper per record and dedups +cleanly. A monitor runs on a schedule, catches new matches, and returns structured output. + +Output shape per detected event: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["event_type", "library", "summary", "event_date", "source_url"], + "properties": { + "event_type": {"type": "string", "enum": ["release", "breaking_change", "deprecation", "cve", "eol", "other"]}, + "library": {"type": "string"}, + "version": {"type": "string", "description": "the version the event concerns, if applicable"}, + "summary": {"type": "string", "description": "one-line factual summary of what changed"}, + "safe_to_apply": {"type": "string", "enum": ["yes", "no", "needs_review"], "description": "needs_review when a breaking change or CVE is involved"}, + "event_date": {"type": "string", "description": "ISO 8601 date"}, + "source_url": {"type": "string", "description": "resolving source (release notes, advisory); must load"} + } +} +``` + +Query per library (substitute): + +> Notify me whenever {LIBRARY} has a concrete, sourced change: a new release, a breaking change, +> a deprecation, or a CVE / security advisory. Give the version, a one-line summary, the date, +> and a resolving source (release notes, changelog, or advisory). Mark whether it looks safe to +> apply, use "needs_review" for any breaking change or security issue. Prioritize named, dated, +> sourced facts; exclude rumor and pre-announcement chatter. + +## Config seams (build on top) + +1. **Libraries**: one monitor per dependency you track (loop your manifest or the workspace `PROFILE.md` file). +2. **Event types**: edit the `event_type` enum + the query to what you act on. +3. **Safe-update gate**: `safe_to_apply` drives automation: auto-PR the `yes` items, hold `needs_review` for a human. +4. **Cadence**: daily (`1d`) default; hourly for security-critical deps, cadence controls latency, not how much you catch. +5. **Processor**: `lite` is the cheap forward-watch default; `base` for heavier scans. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ `POST /v1/monitors` +(`type: event_stream`, `frequency`, `processor`, `settings.query`, `settings.output_schema`), +read hits at `GET /v1/monitors/{id}/events`, optional `webhook` to push into CI. `event_stream` +only catches change **going forward**, seed current state with a Task first if you need it now. +Auth via `x-api-key`, same key creates and reads. + +## Next + +- Turn a `needs_review` alert into a grounded review → **doc-grounded-review**. +- Re-pin the manifest when a safe update lands → **current-scaffolding**. +- Offer monitoring to every app on your platform → **platform-web-access**. diff --git a/skills/parallel-diligence-briefs/SKILL.md b/skills/parallel-diligence-briefs/SKILL.md new file mode 100644 index 0000000..c81f0d8 --- /dev/null +++ b/skills/parallel-diligence-briefs/SKILL.md @@ -0,0 +1,169 @@ +--- +name: parallel-diligence-briefs +description: Full, source-cited pre-matter brief on a counterparty or target, a snapshot (what they are, how they're structured, how they're doing), corporate + ownership structure, litigation and regulatory history, key people, and red flags / why-now. Use when the user wants a "pre-deal brief", "deep diligence on this company", "prep me on this counterparty", or a full research memo on one entity. Runs on the user's own Parallel account via Deep Research. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__createDeepResearch, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Diligence Briefs + +A full, cited pre-matter brief on one counterparty or target, the deep version of the +quickstart. It gives you, in order: a one-glance **snapshot** (what they are, how they're +structured, how they're doing), **corporate + ownership structure**, **litigation and +regulatory history**, **key people**, and **red flags / why-now**. Every point is sourced and +dated so it's auditable, and nothing is fabricated, if it can't be verified it says so. It's a +research memo to prep a matter, not legal advice or a certified report. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **Chat / co-work:** the **Task MCP** (`createDeepResearch` for the full report, or + `createTaskGroup` for the structured shape below). +- **CLI / build-on-top:** the installed **`parallel-deep-research`** skill (`parallel-cli + skills install`), maintained by Parallel. + +Raw HTTP API at the bottom for pipelines. If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its jurisdiction / priority framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +1. **Which entity?** One company (name + a disambiguator), or a priority list (one run each). +2. **Which sections?** Default: snapshot, structure + ownership, litigation + regulatory, key people, red flags. +3. **Tier?** `pro` for a real brief; `core2x`/`core` for routine or high volume (see the tier guidance in this skill). + +Confirm, then run. + +## Run it + +Deep research warrants a higher tier, default `pro` here. Substitute the entity. Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["entity", "snapshot", "structure_ownership", "litigation_regulatory", "key_people", "red_flags"], + "properties": { + "entity": {"type": "string", "description": "the resolved entity (name + disambiguator)"}, + "snapshot": { + "type": "object", + "additionalProperties": false, + "required": ["what_they_are", "how_structured", "business_health"], + "properties": { + "what_they_are": {"type": "string", "description": "one line: the business / activity and who it's for"}, + "how_structured": {"type": "string", "description": "entity type, domicile, parent/group at a glance"}, + "business_health": {"type": "string", "description": "how they're doing: scale, funding, trajectory, or trouble signs (sourced)"} + } + }, + "structure_ownership": { + "type": "array", + "description": "corporate structure and ownership, each point sourced", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["point", "source_url"], + "properties": { + "point": {"type": "string", "description": "e.g. registered as X in Y; parent is Z; UBO is W (only if sourced)"}, + "source_url": {"type": "string", "description": "resolving source; must load"} + } + } + }, + "litigation_regulatory": { + "type": "array", + "description": "litigation, enforcement, and regulatory history; empty array if none found, never invented", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["matter", "type", "status", "date", "source_url"], + "properties": { + "matter": {"type": "string"}, + "type": {"type": "string", "enum": ["litigation", "enforcement", "regulatory_action", "investigation", "sanction", "other"]}, + "status": {"type": "string", "description": "e.g. filed, ongoing, settled, dismissed; empty if not sourced"}, + "date": {"type": "string", "description": "ISO 8601 date of the most relevant event"}, + "source_url": {"type": "string", "description": "resolving source (docket, filing, regulator, credible report)"} + } + } + }, + "key_people": { + "type": "array", + "description": "directors, officers, or beneficial owners relevant to the matter", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["person_name", "role", "source_url"], + "properties": { + "person_name": {"type": "string"}, + "role": {"type": "string", "description": "title / relationship to the entity"}, + "source_url": {"type": "string"} + } + } + }, + "red_flags": { + "type": "array", + "description": "concrete, sourced concerns and any why-now triggers; empty array if none, never speculative", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["flag", "source_url"], + "properties": { + "flag": {"type": "string", "description": "one line: the concern / trigger and why it matters"}, + "date": {"type": "string", "description": "ISO 8601 date if time-relevant; empty otherwise"}, + "source_url": {"type": "string"} + } + } + } + } +} +``` + +Prompt (substitute the entity): + +> Produce a pre-matter diligence brief on {ENTITY} (disambiguate to the correct legal entity +> first). Cite a resolving source with a date for every claim; never invent anything, say +> "Not found" if you can't verify it. +> +> 1) **Snapshot** (one line each): what they are, how they're structured (entity type, +> domicile, parent/group), and how they're doing as a business. +> +> 2) **Structure + ownership:** corporate structure and ownership / ultimate beneficial owners, +> each point only where a source states it. +> +> 3) **Litigation + regulatory:** lawsuits, enforcement actions, regulatory actions, +> investigations, sanctions, each with description, type, status, date, and a resolving source. +> +> 4) **Key people:** directors, officers, or beneficial owners relevant to the matter, with +> role and source. +> +> 5) **Red flags / why-now:** concrete, sourced concerns and any recent triggers, with dates. +> +> Lead the reader to: what they are, how they're structured, what's on their record, who's +> behind them, and what to look at closely. + +## Read it + +Top to bottom: the **snapshot** (who they are in three lines) → **structure + ownership** → +**litigation + regulatory** (the record) → **key people** → **red flags / why-now** (what to +look at closely). Where something came back "Not found", say so, the refusal to fabricate is +the point, and the gaps tell you where to send a human or a paid database next. + +## Config seams (build on top) + +1. **Input**: one entity, or batch a priority list (one run each). +2. **Sections**: edit the schema to the sections your intake memo wants. +3. **Tier**: `pro` for a real brief; `core2x`/`core` for routine (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, `GET /v1/tasks/runs/{run_id}/result`; +citations in `output.basis`. Auth `x-api-key`, server-side only. Prefer the CLI/MCP unless you +need raw control. + +## Next + +- Just need the fast read → **legal-quickstart** (the light version). +- Whole list, lighter → **entity-diligence** (tear sheets). +- Quote the primary sources behind a finding → **source-grounded-research**. +- Keep the brief live → **regulatory-monitoring**. diff --git a/skills/parallel-doc-grounded-review/SKILL.md b/skills/parallel-doc-grounded-review/SKILL.md new file mode 100644 index 0000000..71a63c3 --- /dev/null +++ b/skills/parallel-doc-grounded-review/SKILL.md @@ -0,0 +1,106 @@ +--- +name: parallel-doc-grounded-review +description: Review a code change against current library references, deprecated APIs, and standards, not the model's stale memory, and return findings with clean extracted source text the model can quote word-for-word. Use when the user wants to "review this diff", "check for deprecated APIs", "is this the current way to do X", or ground code review in live docs. Runs on the user's own Parallel account via Task and Extract. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Doc-Grounded Review + +Check a change against the **current** library references, deprecated APIs, and standards, not +what the model learned in training, and get back findings with clean **extracted source text** +it can quote word-for-word. The point is fewer false positives: a review that says "this is +deprecated" only when a live doc actually says so, with the quote attached. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`), one input per change or symbol. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-web-extract`** and + **`parallel-data-enrichment`** skills (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its stack and "current" framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Three quick questions before running (each reviewed change is a billable check): +1. **What's the change?** A diff, a file, or the specific APIs / symbols to check. +2. **Against which versions?** Defaults to the current stable of each library; name pins if you target an older line. +3. **How strict?** Default flags deprecated / removed APIs and clear standard violations; add style or security if you want. + +Confirm, then run. + +## Run it + +One task per change (or per symbol batch). Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["subject", "findings"], + "properties": { + "subject": {"type": "string", "description": "the file, symbol, or diff reviewed"}, + "findings": { + "type": "array", + "description": "empty array if nothing is flaggable against current sources; never invented", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["symbol", "verdict", "current_guidance", "quote", "source_url"], + "properties": { + "symbol": {"type": "string", "description": "the API / method / pattern in question"}, + "verdict": {"type": "string", "enum": ["deprecated", "removed", "changed", "discouraged", "current", "unverifiable"]}, + "current_guidance":{"type": "string", "description": "what the current, supported approach is"}, + "quote": {"type": "string", "description": "verbatim text extracted from the source that backs the verdict; empty string if none"}, + "source_url": {"type": "string", "description": "resolving source (doc, changelog, release note); must load"}, + "applies_to": {"type": "string", "description": "the library version(s) this applies to"} + } + } + } + } +} +``` + +Prompt (substitute the change / symbols): + +> Review the following change against the current, supported references for each library +> involved: {DIFF_OR_SYMBOLS}. For each API, method, or pattern, determine whether it is +> current, deprecated, removed, changed, or discouraged as of the latest stable version. Back +> every verdict with a verbatim quote extracted from a resolving source (official docs, the +> changelog, or the release note) and the version it applies to. State the current supported +> approach. Do not flag anything you cannot back with a live source, mark it "unverifiable" +> rather than guessing, and return an empty findings array if nothing is flaggable. For any +> blank field use an empty string, never the word "null". + +**Read it:** lead with the deprecated/removed findings (each with its quote and the current +replacement), then changed/discouraged, and note anything "unverifiable" plainly. The quote is +what makes the finding trustworthy, no quote, no finding. + +## Config seams (build on top) + +1. **Input**: a diff, a file, or a symbol list; run one task per change or batch. +2. **Strictness**: extend the `verdict` enum and the prompt (add security, style, license). +3. **Quote handling**: `quote` + `source_url` are what your agent surfaces inline in the review comment. +4. **Tier**: `core` default; `core2x` for a stricter pass on a large or critical diff (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations in `output.basis`. Clean quotable text +via the Extract endpoint. Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless you +need raw control. + +## Next + +- Find the current source first → **code-quickstart**. +- Keep the libraries current going forward → **dependency-monitoring**. +- Generate new code against current versions → **current-scaffolding**. diff --git a/skills/parallel-emerging-risk-research/SKILL.md b/skills/parallel-emerging-risk-research/SKILL.md new file mode 100644 index 0000000..5e14a6e --- /dev/null +++ b/skills/parallel-emerging-risk-research/SKILL.md @@ -0,0 +1,83 @@ +--- +name: parallel-emerging-risk-research +description: Commission a structured, source-cited report on a peril, a liability class, or a regulatory change affecting your book, exposure drivers, loss trends, the regulatory picture, and the implications for pricing and appetite, every claim traced to a source. Use when the user wants to research an emerging risk, assess exposure to a peril, determine how a regulation affects a book, or prepare an actuarial or portfolio research write-up. Runs on the user's own Parallel account via Deep Research. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createDeepResearch, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Emerging Risk Research + +Ask an open question about a peril, a liability class, or a regulatory change, and get back a +**structured, cited report**: what's driving the exposure, the loss trends, the regulatory +picture, and what it means for pricing and appetite, with every claim traced to a resolving +source. Nothing is fabricated; where the data is thin or the trend is early, the report says so +instead of overstating it. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** `createDeepResearch`. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill + (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its lines and jurisdictions framing (captured once at setup) to +anchor the report on your actual book; don't re-ask it. + +Two quick questions before running (deep research is a higher-tier, billable run): +1. **What's the question?** One clear peril, liability class, or regulatory change. +2. **What must it cover?** Default sections: exposure drivers, loss trends, regulatory picture, and implications for pricing / appetite. Add or drop. + +Confirm, then run. + +## Run it + +Deep research warrants a higher tier, default `pro` here. Give it the question and the sections +to cover. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +Prompt (substitute your question): + +> Produce a structured research report answering: "{RISK_QUESTION}". Cite a resolving source URL +> for every claim, and prefer primary sources (regulator and agency data, catastrophe models and +> bulletins, court records, filings) over secondary commentary. Cover, in order: +> +> 1) **Exposure drivers:** what creates and concentrates the risk, with figures. +> 2) **Loss trends:** frequency and severity trends, sourced, with the period they cover. +> 3) **Regulatory picture:** the rules, filings, or actions that bear on it, and where they're headed. +> 4) **Implications:** what it means for pricing, terms, and appetite for a book like the reader's. +> +> Never invent a loss figure, a ruling, or a source. Where the data is thin or the trend is +> early, say so and show the uncertainty rather than resolving it artificially. + +**Read it:** start with the implications and the two or three loss or exposure datapoints that +carry them, then use drivers / trends / regulatory as the support, following the citations on +anything you'd take to a pricing or appetite decision. Where the report flags thin data, treat it +as a monitoring target, not a settled conclusion. + +## Config seams (build on top) + +1. **The question:** one sharp peril, liability class, or regulatory change; this is the whole input. +2. **Sections:** edit the section list to your actuarial / portfolio template (add reinsurance, accumulation, comparables). +3. **Tier:** `pro` default for a real report; `core2x` for a quicker read, `ultra` for the highest-stakes questions (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Deep Research runs on +the Task API (stable, `v1`): `POST /v1/tasks/runs` with a deep-research processor and +`task_spec.output_schema`, then `GET /v1/tasks/runs/{run_id}/result`; citations in +`output.basis`. Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw +control. + +## Next + +- Turn the exposure findings into a live watch → **book-risk-monitoring**. +- Re-underwrite the risks it flags → **underwriting-risk-profiles**. +- Get a fast read on a single flagged entity → **insurance-quickstart**. diff --git a/skills/parallel-entity-context/SKILL.md b/skills/parallel-entity-context/SKILL.md new file mode 100644 index 0000000..d635483 --- /dev/null +++ b/skills/parallel-entity-context/SKILL.md @@ -0,0 +1,101 @@ +--- +name: parallel-entity-context +description: Enrich the people, companies, places, and topics your product touches, in a query, a doc, or a meeting, with cited real-world background so your product responds with the right context automatically. Use when the user wants to "add background on this person/company", "build a meeting brief", "who is X and why do they matter", or enrich an entity inline. Runs on the user's own Parallel account via Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Entity Context + +Enrich the people, companies, places, and topics your product touches, in a query, a doc, or a +meeting, so it responds with the right **background automatically**. Give it an entity, get back +a tight, cited briefing your product can drop inline. Every fact resolves to a source; anything +unverifiable comes back empty, never invented, so a meeting brief never puts a made-up detail in +front of a user. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`), one input per entity. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-data-enrichment`** skill + (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its product / surfaces framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Two quick questions before running (each entity is a billable enrichment): +1. **Which entity?** A person, company, place, or topic (with any disambiguator, e.g. the company they're at). +2. **For which surface?** A meeting brief, a doc annotation, or an inline answer, so the length and framing fit. + +Confirm, then run. + +## Run it + +One task per entity. Output shape (a person shown; adapt fields per entity type): + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["entity", "briefing", "facts"], + "properties": { + "entity": {"type": "string"}, + "briefing": {"type": "string", "description": "2-4 sentence background your product can show inline"}, + "facts": { + "type": "array", + "description": "the discrete cited facts behind the briefing; empty array if little can be sourced", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["fact", "source_url", "as_of"], + "properties": { + "fact": {"type": "string", "description": "one sourced fact (role, recent move, funding, notable event)"}, + "source_url": {"type": "string", "description": "resolving source; must load"}, + "as_of": {"type": "string", "description": "date of the fact / source"} + } + } + } + } +} +``` + +Prompt (substitute the entity + surface): + +> Enrich {ENTITY} for a {SURFACE}. Return a 2-4 sentence background briefing and the discrete +> facts behind it, role and organization, recent moves or funding, and anything a user would want +> to know before engaging. Cite a resolving source with a date for every fact. Never invent a +> role, a fact, or a source, if something can't be verified, leave it out and keep the briefing +> to what's sourced. Keep it tight enough to show inline. + +**Read it:** the `briefing` is what your product renders; the `facts` are the citations behind +it, each dated and clickable. If the facts list is thin, the briefing should be short and honest, +not padded. + +## Config seams (build on top) + +1. **Input:** the entity + surface; run one per entity, batch a meeting's attendees or a doc's mentions. +2. **Fields:** adapt the shape per entity type (company: funding, headcount, news; place: what it is, recent events). +3. **Length:** tune the briefing length to the surface (a chip vs a full brief). +4. **Tier:** `core` default; `core2x` for a priority entity, `lite` for a quick inline chip (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations in `output.basis`. Auth via +`x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw control. + +## Next + +- Answer a follow-up question about the entity → **productivity-quickstart**. +- Keep the entity's context fresh → **knowledge-freshness**. +- Go deep on a question the entity raises → **in-product-research**. diff --git a/skills/parallel-entity-diligence/SKILL.md b/skills/parallel-entity-diligence/SKILL.md new file mode 100644 index 0000000..b7bc1e9 --- /dev/null +++ b/skills/parallel-entity-diligence/SKILL.md @@ -0,0 +1,112 @@ +--- +name: parallel-entity-diligence +description: Turn a list of counterparties or target companies into structured, source-cited diligence tear sheets, corporate structure, ownership / UBO, jurisdictions, sanctions and watchlist exposure, litigation history, and regulatory status, with a confidence score and a source for every field. Use when the user wants to "run diligence on these companies", "KYB this list", "screen these counterparties", or turn a vendor/target list into diligence-ready intelligence. Runs on the user's own Parallel account. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Entity Diligence + +Start with a list of counterparties or targets, get back a structured, cited **diligence +tear sheet** for each: corporate structure, ownership, jurisdictions, sanctions/watchlist +exposure, litigation history, regulatory status. Every field carries a confidence score and a +resolving source; if a fact isn't on a reachable source, the field comes back empty, never +guessed. This is a research layer to speed triage, not a certified screening or legal advice, +verify hits against the primary registry or list before you rely on them. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`), one input per entity. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-data-enrichment`** skill + (`parallel-cli skills install`). + +If Parallel is not configured, run the relevant setup skill first. See +[docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its jurisdiction / priority framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Three quick questions before running (each entity is a billable enrichment): +1. **Your entity list?** Names, names + domains, or names + jurisdiction (jurisdiction sharply cuts wrong-entity matches). +2. **Which fields?** Default is the diligence tear sheet (structure, ownership, sanctions exposure, litigation, regulatory status). Add or drop to match your intake form. +3. **Run how many now?** Start with a small batch (5-10) to check quality and entity resolution, then scale. + +Confirm, then run. + +## Run it + +One task per entity (batch the list), processor `core2x` (diligence default, recall matters, +see the tier guidance in this skill). Output shape, the tear sheet: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["entity", "fields"], + "properties": { + "entity": {"type": "string", "description": "the resolved entity (name + disambiguator)"}, + "fields": { + "type": "object", + "additionalProperties": false, + "properties": { + "corporate_structure": {"type": "string", "description": "entity type, parent/subsidiary, registration; empty if not found"}, + "ownership": {"type": "string", "description": "known owners / ultimate beneficial owners if publicly sourced; empty otherwise"}, + "jurisdictions": {"type": "string", "description": "domicile + operating jurisdictions"}, + "sanctions_exposure": {"type": "string", "description": "any sanctions / watchlist / debarment hits found; 'none found' if searched and clear"}, + "litigation_history": {"type": "string", "description": "notable litigation / enforcement, one line each"}, + "regulatory_status": {"type": "string", "description": "licenses, registrations, regulatory actions where applicable"} + } + }, + "basis": { + "type": "array", + "description": "one entry per field: the source behind it and a confidence", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["field", "source_url", "confidence"], + "properties": { + "field": {"type": "string"}, + "source_url": {"type": "string", "description": "resolving source that backs the field; must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + } + } +} +``` + +Prompt (per entity, substitute): + +> Build a diligence tear sheet for {ENTITY} (disambiguate to the correct legal entity first). +> Fields: corporate structure (type, parent/subsidiary, registration), ownership / ultimate +> beneficial owners where publicly sourced, jurisdictions, sanctions and watchlist exposure, +> litigation history, and regulatory status. For every field, cite a resolving source URL and +> give a 0-100 confidence. Never invent a value, an owner, a sanctions hit, or a case: if a +> fact isn't on a reachable source, return an empty string, and for a field you searched and +> found clean (e.g. sanctions), say "none found" rather than leaving it ambiguous. Prefer a +> small correct sheet over a full speculative one. + +## Config seams (build on top) + +1. **Input**: your entity list (names + domains, or names + jurisdiction); run one enrichment per row. +2. **Fields**: edit the `fields` object to your intake form. Keys become columns. +3. **Tier**: `core2x` default for diligence; `pro` for high-stakes single subjects, `core` for a lighter first pass. +4. **Screening discipline**: treat sanctions/watchlist fields as *leads*: confirm any hit against the issuing list's primary record before acting. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations return in `output.basis`. Auth via +`x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the CLI/MCP. + +## Next + +- Don't have the list yet → **exposure-discovery** (describe the population, get the entities). +- Go deeper on the priority subjects → **diligence-briefs** (full research report). +- Keep it fresh → **regulatory-monitoring** (alert when status changes or a new action lands). diff --git a/skills/parallel-exposure-discovery/SKILL.md b/skills/parallel-exposure-discovery/SKILL.md new file mode 100644 index 0000000..b6c06b4 --- /dev/null +++ b/skills/parallel-exposure-discovery/SKILL.md @@ -0,0 +1,87 @@ +--- +name: parallel-exposure-discovery +description: Describe a legal population in plain language and get back a researched, source-cited list of the entities in it, including the long tail that isn't in existing databases, "all companies subject to regulation X", "all litigation involving Y", "all entities on watchlist Z", "all portfolio companies exposed to sanctions regime W". Use when the user wants to "find all entities that...", "map exposure to...", "build a population of...", or enumerate a legal set. Runs on the user's own Parallel account via FindAll. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *) +metadata: + author: parallel +--- + +# Exposure Discovery (FindAll) + +Describe a legal population in plain language, get back a **researched, cited list of the +entities in it**. Works across companies, people, matters, and the long tail that doesn't fit +existing databases: everyone subject to a rule, everyone in a litigation, everyone exposed to +a sanctions regime. Every match resolves to a source; noise and non-matches are filtered. +It's a discovery layer to build a working set, verify each member against its primary source +before you act on it. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +FindAll is exposed through **`parallel-cli findall`** (installed by `parallel-cli skills +install`), this is the maintained path, and it's what you should build on. FindAll is in +**public beta**, so the raw HTTP endpoints can change (30 days' notice); riding the CLI means +Parallel absorbs those changes on update. If Parallel is not configured, run the relevant setup skill first. Check [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its jurisdiction framing (captured once at setup) to scope the population, don't re-ask it; confirm-or-tweak rather than re-ask. + +Before the paid run: +1. **Describe the population** in plain language, be specific about the entity type and the criteria that define membership (the rule, the jurisdiction, the matter, the threshold). +2. **How many candidates?** Start around 25 (`-n 25`) to gauge quality and precision, then extend. +3. **Preview first?** Run `ingest` (below) to see the parsed query before paying. + +Confirm, then run. + +## Run it + +Preview the parsed query before you pay: + +``` +parallel-cli findall ingest "" +``` + +Then run and poll results to disk: + +``` +parallel-cli findall run "US-registered money services businesses that had a state regulator enforcement action in the last 24 months" -g core -n 50 --no-wait --json +parallel-cli findall poll "" -o /tmp/population.json --timeout 540 +``` + +Add fields to each member (optional): + +``` +parallel-cli findall enrich "" '{"properties":{"jurisdiction":{"type":"string"},"action_date":{"type":"string"},"regulator":{"type":"string"}}}' +``` + +Each candidate returns `name`, `url`, `description`, a `match_status` (`matched` is the +keeper), enriched fields under `output`, and per-field citations under `basis`. Keep only +`matched`, and treat each as a lead to confirm against its cited primary source. + +## Config seams (build on top) + +1. **The objective**: your population in plain language. This is the whole input; be specific + about the entity type and the membership criteria (rule, jurisdiction, matter, threshold). +2. **Generator tier**: `-g core` default, `-g pro` for comprehensive/sparse populations, + `-g preview` for a fast scan, skip `-g base` for real data. +3. **Count**: `-n` (5 to 1000); start small to check precision, then `parallel-cli findall + extend "" 50` for more. +4. **Enrichment fields**: the `properties` you add become columns (jurisdiction, action date, + regulator, docket); keys are yours to define. +5. **Exclude**: `--exclude '[{"name":"...","url":"..."}]'` to skip entities you've already cleared. + +## Production (raw HTTP API): beta, verify before hardcoding + +_As of 2026-08; FindAll is public beta, confirm at [docs.parallel.ai](https://docs.parallel.ai)._ +`POST /v1beta/findall/ingest` → `POST /v1beta/findall/entity-search` (fast candidates) or the +full run → `GET /v1beta/findall/runs/{findall_id}/result` (returns `candidates[]` with +`output` + `basis`). Because it's `v1beta`, prefer `parallel-cli findall` so tier/shape changes +don't break your build. + +## Next + +- Run full diligence on each member → **entity-diligence** (tear sheet per entity). +- Watch the population for new members or status changes → **regulatory-monitoring**. +- Go deep on a priority member → **diligence-briefs**. diff --git a/skills/parallel-finance-quickstart/SKILL.md b/skills/parallel-finance-quickstart/SKILL.md new file mode 100644 index 0000000..c393006 --- /dev/null +++ b/skills/parallel-finance-quickstart/SKILL.md @@ -0,0 +1,119 @@ +--- +name: parallel-finance-quickstart +description: Connect Parallel (if needed) and get a fast, source-cited snapshot of any company, what they do, how they make money, latest financials, and key people, with a source for every fact. Use when the user asks to "get me up to speed on a company", "quick read on X before a call", or wants the Parallel finance quickstart. Runs on the user's own Parallel account. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Finance Quickstart + +The fastest way to see Parallel work on a real company: name one, get back a tight, cited +**snapshot**, what they do, how they make money, the latest financials that are public, and +the key people. Every fact is backed by a resolving source; if something can't be verified it +comes back empty, never invented. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill. + +If Parallel is not configured, run the relevant setup skill first. +Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its firm / mandate framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Two quick questions before running (the run costs credits): +1. **Which company?** A domain (e.g. `acme.com`), or a ticker / name you resolve to one and confirm first. +2. **Public or private company?** Shapes where the financials come from (filings vs. estimates and press). Default: infer from the company. + +Confirm, then run. + +## Run it + +Call `createTaskGroup` once with the company as the input, processor `core`, and the output +shape below. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["company", "what_they_do", "how_they_make_money", "financials", "key_people"], + "properties": { + "company": {"type": "string"}, + "what_they_do": {"type": "string", "description": "one line: the business and who it serves"}, + "how_they_make_money": {"type": "string", "description": "revenue model / main lines of business"}, + "financials": { + "type": "array", + "description": "the public financial facts you can source; empty array if none are public", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["metric", "value", "as_of", "source_url"], + "properties": { + "metric": {"type": "string", "description": "e.g. revenue, EBITDA, headcount, last raise"}, + "value": {"type": "string"}, + "as_of": {"type": "string", "description": "period or date the figure covers"}, + "source_url": {"type": "string", "description": "resolving source; must load"} + } + } + }, + "key_people": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["person_name", "title", "source_url"], + "properties": { + "person_name": {"type": "string"}, + "title": {"type": "string"}, + "source_url": {"type": "string", "description": "resolving source backing name + title; must load"} + } + } + } + } +} +``` + +Prompt (substitute the company): + +> For the company at {COMPANY}, produce a fast snapshot and cite a resolving source URL for +> every fact. (1) What they do, in one line. (2) How they make money. (3) Financials: the +> public figures you can source, revenue, EBITDA, headcount, last financing, each with the +> period it covers and a source; prefer filings for public companies. (4) Key people: the +> executives who matter, with exact title and a source to verify. Never invent a figure, a +> name, or a source. If a fact isn't on a reachable source, leave it out rather than guess; +> for any blank field use an empty string, never the word "null". + +> Via the MCP, `createTaskGroup` takes a natural-language output description, not a strict +> schema, so the shape above is guidance there, lean on the prompt wording to keep it clean. + +**Read it:** lead with what they do and how they make money, then the freshest sourced +financials, then who to know. Where a figure came back empty, say so, that refusal to +fabricate is the point. + +## Config seams (build on top) + +1. **Input**: swap the single company for a list (run one per company). +2. **Fields**: edit the `financials` / `key_people` shape to what you track; keys become columns. +3. **Tier**: `core` default; `core2x`/`pro` for depth, `lite` for a fast pass (see the tier guidance in this skill). + +Riding the MCP/CLI means an API change is absorbed on update, you don't re-clone for it. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations in `output.basis`. Auth via +`x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the MCP/CLI. + +## Next + +- Whole list, or a fuller sheet → **company-profiles** (financials, leadership, competitive position, trajectory). +- Keep it live → **portfolio-monitoring** (alert when a filing, an exec change, or an earnings signal fires). +- Deeper on a market question → **thesis-research** (a full cited report). diff --git a/skills/parallel-finance-setup/SKILL.md b/skills/parallel-finance-setup/SKILL.md new file mode 100644 index 0000000..c934ca6 --- /dev/null +++ b/skills/parallel-finance-setup/SKILL.md @@ -0,0 +1,64 @@ +--- +name: parallel-finance-setup +description: Connect a user's Parallel account and route finance workflows to the matching skill. Use this first, or when the user says "set up Parallel", "get me started", or isn't sure which use case they need. +allowed-tools: Bash(command:*), Bash(claude:*), Bash(parallel-cli:*), Bash(script:*), Bash(git:*) +metadata: + author: parallel +--- + +# Finance Setup + +Get connected once, then get pointed to the right use case. Everything runs on the user's +own Parallel account, no key is pasted. + +## 1. Ask what they want to do first (route before installing) + +Don't install or run anything yet. Ask one orienting question and route to the matching +skill, so the first thing they do is the thing they came for: + +> **What do you want to do first?** +> - **Get up to speed on one company fast** → `parallel-finance-quickstart` +> - **Build cited tear sheets on a name or a list** → `parallel-company-profiles` +> - **Find targets matching your criteria** → `parallel-target-discovery` +> - **Get alerted when a position or target moves** → `parallel-portfolio-monitoring` +> - **Commission a research report on a thesis** → `parallel-thesis-research` +> - **Run KYB / KYC on a company or counterparty** → `parallel-kyb-kyc` + +If they're unsure, start with `parallel-finance-quickstart`, it's the fastest to value. + +## 2. Pick the surface and connect (once) + +**Non-technical (co-work / chat): just want output:** +Connect the Task MCP and run the use case in chat. See the `parallel-task-mcp-setup` skill. + +**Technical (build on top):** +Run the `parallel-cli-setup` skill to install and authenticate the CLI. Clone the repository only when the user wants to work from the source: + +```bash +git clone https://github.com/parallel-web/parallel-agent-skills +``` + +> If a call returns `401 Invalid API key`, a stale `PARALLEL_API_KEY` in your shell is +> overriding the login, run `unset PARALLEL_API_KEY` and retry. + +## 3. Capture the finance profile once + +So the user doesn't re-enter their context on every run, capture who *they* are here, once: + +1. Ask: **what firm are you at, and what's your mandate?** (domain + firm type). +2. Research the firm on Parallel (a quick lookup) and infer the firm type, mandate (sectors, + geographies, check size or EBITDA range), and screening criteria. **Show the user what you + found and let them correct it, never assume**, a wrong guess on the first run is the thing + that loses trust. +3. Write the confirmed result to `PROFILE.md` in the current workspace, using the shape in + [references/PROFILE.example.md](references/PROFILE.example.md). `PROFILE.md` is gitignored, so their details stay local. + +Every use-case skill reads `PROFILE.md` and uses that firm / mandate / screening framing, so +from here the user only supplies the per-run target (which company, list, or thesis), not +their whole context each time. This is optional, skip it and each skill will just ask per-run. + +## 4. Hand off to the chosen use case + +Open that use case's `SKILL.md` and follow its guided intake (each one asks 1-3 questions and +confirms before anything billable runs). The use-case skills carry the build logic; this +setup just gets you connected and cloned. diff --git a/skills/parallel-finance-setup/references/PROFILE.example.md b/skills/parallel-finance-setup/references/PROFILE.example.md new file mode 100644 index 0000000..8f4cacc --- /dev/null +++ b/skills/parallel-finance-setup/references/PROFILE.example.md @@ -0,0 +1,25 @@ +# Your finance profile + +Captured once during setup (`parallel-finance-setup`) and read by every skill, so you +don't re-enter your firm and mandate on every run. Setup writes this to `PROFILE.md` (which is +gitignored, your details stay local and are never committed). Edit it anytime. + +Fill these in (setup does it for you, inferred from your firm and confirmed with you): + +- **firm:** +- **domain:** +- **firm_type:** +- **mandate:** +- **screening_criteria:** +- **diligence_focus:** +- **compliance_posture:** + +Example (illustrative, not a real firm): + +- **firm:** Meridian Capital Partners +- **domain:** meridiancap.example +- **firm_type:** mid-market private equity +- **mandate:** North American cold-chain logistics and industrial services, $20-80M EBITDA, control buyouts +- **screening_criteria:** founder- or family-owned, no existing PE sponsor, web signals of growth (new facilities, headcount, fleet), fragmented markets with roll-up potential +- **diligence_focus:** revenue and EBITDA, ownership and cap structure, customer concentration, competitive position, capex and asset base +- **compliance_posture:** beneficial-ownership and sanctions screening on every target and counterparty at LOI, US and Canadian registries diff --git a/skills/parallel-gtm-quickstart/SKILL.md b/skills/parallel-gtm-quickstart/SKILL.md new file mode 100644 index 0000000..82fc15f --- /dev/null +++ b/skills/parallel-gtm-quickstart/SKILL.md @@ -0,0 +1,125 @@ +--- +name: parallel-gtm-quickstart +description: Connect Parallel (if needed) and get go-to-market account intelligence for any company, who to reach (buying committee) and why now (recent cited signals). Use when the user asks to "research this account", "who do I reach at X and why now", "get me up to speed on a company before a call", or wants the Parallel GTM quickstart. Runs on the user's own Parallel account. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# GTM Quickstart + +The fastest way to see Parallel work on a real account: name one company, get back the two +things a rep needs before touching it, **who to reach** (the buying committee) and **why +now** (a recent, cited signal). Every fact is backed by a resolving source; if something +can't be verified it comes back empty, never invented. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill. + +If Parallel is not configured, run the relevant setup skill first. +Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its company / ICP / value framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Two quick questions before running (the run costs credits): +1. **Which company?** A domain (e.g. `acme.com`). Resolve a bare name to a domain and confirm first. +2. **Technical or GTM/revenue sale?** Shapes which roles count as the committee. Default: technical. + +Confirm, then run. + +## Run it + +Call `createTaskGroup` once with the company domain as the input, processor `core`, and the +output shape below. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["company", "buying_committee", "why_now"], + "properties": { + "company": {"type": "string"}, + "buying_committee": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["person_name", "title", "role_in_deal", "source_url", "confidence", "why_reach_them"], + "properties": { + "person_name": {"type": "string"}, + "title": {"type": "string"}, + "reports_to": {"type": "string", "description": "name/title this person reports to ONLY if a public source states it; else an empty string. Never inferred, never the literal 'null'"}, + "role_in_deal": {"type": "string", "enum": ["champion", "economic_buyer", "influencer", "technical_evaluator", "blocker", "other"]}, + "linkedin_url": {"type": "string", "description": "the person's LinkedIn; empty string if not found"}, + "source_url": {"type": "string", "description": "a resolving source backing this person + title; must load"}, + "confidence": {"type": "integer", "description": "0-100; low>=75, medium>=85, high>=95"}, + "why_reach_them": {"type": "string", "description": "one line on why this person matters"} + } + } + }, + "why_now": { + "type": "array", + "description": "recent cited signals that make now a good time to reach out; empty array if none, never invented", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["signal", "signal_date", "source_url"], + "properties": { + "signal": {"type": "string"}, + "signal_type": {"type": "string", "enum": ["funding", "hiring", "product_launch", "exec_change", "expansion", "customer_win", "m_and_a", "other"]}, + "signal_date": {"type": "string", "description": "ISO 8601 date"}, + "source_url": {"type": "string"} + } + } + } + } +} +``` + +Prompt (substitute the domain): + +> For the company at {COMPANY_DOMAIN}, produce go-to-market account intelligence, and cite a +> resolving source URL for every fact. (1) Buying committee: the likely champion, economic +> buyer, technical evaluator, and any clear influencers or blockers, with name, exact title, +> role in the deal, and LinkedIn to verify. Set reports_to only when a public source states +> the reporting line, else an empty string. (2) Why now: recent events (last ~6 months) that +> make now a good time to reach out (funding, notable hiring, a product/AI launch, an exec +> change, expansion, a customer win, M&A) with a one-line summary, date, and source. Never +> invent a name, title, signal, reporting line, or source. If you can't verify someone, say +> "Not found"; if there's no recent signal, return an empty why_now array. For any blank +> field use an empty string, never the word "null". + +> Via the MCP, `createTaskGroup` takes a natural-language output description, not a strict +> schema, so the shape above is guidance there, lean on the prompt wording to keep it clean. + +**Read it:** lead with the action, champion + economic buyer up top with a one-line why and a +clickable source, then the freshest "why now" as the reason to reach out. Where a role or +signal came back empty, say so, that refusal to fabricate is the point. + +## Config seams (build on top) + +1. **Input**: swap the single domain for your account list (run one per account). +2. **Fields**: edit the `buying_committee` / `why_now` shape to the columns you need; keys become columns. +3. **Tier**: `core` default; `core2x`/`pro` for depth, `lite` for a fast pass (see the tier guidance in this skill). + +Riding the MCP/CLI means an API change is absorbed on update, you don't re-clone for it. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations in `output.basis`. Auth via +`x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the MCP/CLI. + +## Next + +- Whole book of accounts → **account-enrichment** (batch this shape per account). +- Keep it live → **signal-monitoring** (alert when a new signal fires or the org changes). +- Deeper on priority accounts → **account-briefs** (full research report). diff --git a/skills/parallel-gtm-setup/SKILL.md b/skills/parallel-gtm-setup/SKILL.md new file mode 100644 index 0000000..41131be --- /dev/null +++ b/skills/parallel-gtm-setup/SKILL.md @@ -0,0 +1,63 @@ +--- +name: parallel-gtm-setup +description: Connect a user's Parallel account and route GTM workflows to the matching skill. Use this first, or when the user says "set up Parallel", "get me started", or isn't sure which use case they need. +allowed-tools: Bash(command:*), Bash(claude:*), Bash(parallel-cli:*), Bash(script:*), Bash(git:*) +metadata: + author: parallel +--- + +# GTM Setup + +Get connected once, then get pointed to the right use case. Everything runs on the user's +own Parallel account, no key is pasted. + +## 1. Ask what they want to do first (route before installing) + +Don't install or run anything yet. Ask one orienting question and route to the matching +skill, so the first thing they do is the thing they came for: + +> **What do you want to do first?** +> - **Get up to speed on one company before a call** → `parallel-gtm-quickstart` +> - **Map the org chart / who reports to whom** → `parallel-org-chart` +> - **Enrich a list of accounts into tear sheets** → `parallel-account-enrichment` +> - **Find new accounts matching an ICP** → `parallel-lead-discovery` +> - **Get alerted when accounts show buying signals** → `parallel-signal-monitoring` +> - **Deep pre-meeting brief on a priority account** → `parallel-account-briefs` + +If they're unsure, start with `parallel-gtm-quickstart`, it's the fastest to value. + +## 2. Pick the surface and connect (once) + +**Non-technical (co-work / chat): just want output:** +Connect the Task MCP and run the use case in chat. See the `parallel-task-mcp-setup` skill. + +**Technical (build on top):** +Run the `parallel-cli-setup` skill to install and authenticate the CLI. Clone the repository only when the user wants to work from the source: + +```bash +git clone https://github.com/parallel-web/parallel-agent-skills +``` + +> If a call returns `401 Invalid API key`, a stale `PARALLEL_API_KEY` in your shell is +> overriding the login, run `unset PARALLEL_API_KEY` and retry. + +## 3. Capture the GTM profile once + +So the user doesn't re-enter their context on every run, capture who *they* are here, once: + +1. Ask: **what company are you at?** (domain). +2. Research it on Parallel (a quick lookup) and infer what they sell, their ICP, and the + personas they target. **Show the user what you found and let them correct it, never + assume**, a wrong guess on the first run is the thing that loses trust. +3. Write the confirmed result to `PROFILE.md` in the current workspace, using the shape in + [references/PROFILE.example.md](references/PROFILE.example.md). `PROFILE.md` is gitignored, so their details stay local. + +Every use-case skill reads `PROFILE.md` and uses that company / ICP / value framing, so from +here the user only supplies the per-run target (which account or list), not their whole +context each time. This is optional, skip it and each skill will just ask per-run. + +## 4. Hand off to the chosen use case + +Open that use case's `SKILL.md` and follow its guided intake (each one asks 1-3 questions and +confirms before anything billable runs). The use-case skills carry the build logic; this +setup just gets you connected and cloned. diff --git a/skills/parallel-gtm-setup/references/PROFILE.example.md b/skills/parallel-gtm-setup/references/PROFILE.example.md new file mode 100644 index 0000000..53df1c3 --- /dev/null +++ b/skills/parallel-gtm-setup/references/PROFILE.example.md @@ -0,0 +1,23 @@ +# Your GTM profile + +Captured once during setup (`parallel-gtm-setup`) and read by every skill, so you +don't re-enter your company and ICP on every run. Setup writes this to `PROFILE.md` (which is +gitignored, your details stay local and are never committed). Edit it anytime. + +Fill these in (setup does it for you, inferred from your company and confirmed with you): + +- **company:** +- **domain:** +- **what_we_sell:** +- **icp:** +- **target_personas:** +- **value_props:** <1-3 reasons your ICP buys; used to frame "why now" and outreach, not to spin the data> + +Example (illustrative, not a real company): + +- **company:** Acme Cloud +- **domain:** acme.example +- **what_we_sell:** a B2B SaaS platform that helps teams do one job well (one line: the product and the problem it solves) +- **icp:** mid-market B2B companies, 200-2000 employees, in your target sectors, showing a buying signal (recent funding, relevant hiring, a matching tech stack) +- **target_personas:** the buying committee you sell to (e.g. VP Engineering, Head of Ops, the economic buyer) +- **value_props:** 1-3 reasons your ICP buys; used to frame "why now" and outreach, not to spin the data diff --git a/skills/parallel-in-product-research/SKILL.md b/skills/parallel-in-product-research/SKILL.md new file mode 100644 index 0000000..74c18e6 --- /dev/null +++ b/skills/parallel-in-product-research/SKILL.md @@ -0,0 +1,79 @@ +--- +name: parallel-in-product-research +description: Ship a research feature backed by a web subagent, give it an objective, get back a structured, cited report, with compute you dial per task. Use when the user wants to "add a research feature to my product", "give my agent a deep-research capability", "objective in, cited report out", or offer research as a product surface. Runs on the user's own Parallel account via Deep Research and Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createDeepResearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# In-Product Research + +Offer a **research capability** inside your product, backed by a web subagent: your user (or +your agent) gives it an objective, and it returns a structured, cited report. The compute is a +**dial per task**, a quick comparison and a deep multi-source report use the same shape at +different tiers, so you spend per request what the request is worth. Every claim traces to a +resolving source; thin evidence is flagged, not filled in. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** `createDeepResearch` (deep) or `createTaskGroup` (lighter, + structured). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill + (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its product framing (captured once at setup), don't re-ask it; +only get the per-run specifics below. + +Two quick questions before running (deep research is a higher-tier, billable run): +1. **The objective?** The research question your user or agent submits. +2. **How much compute?** How deep this task is worth, the dial from a quick structured answer to a full multi-source report. + +Confirm, then run. + +## Run it + +Give it the objective and the report shape. For a deep report use `createDeepResearch` at `pro`; +for a lighter structured answer use `createTaskGroup` at `core`/`core2x`. Poll `getStatus`, then +read with `getResultMarkdown`. + +Example objective (a comparison your product might expose): + +> Compare how two named companies each acquired their first million users: what each did +> differently, and how customer sentiment changed over time. Return a short strategy summary per +> company and a brief comparative analysis. Cite a resolving source URL for every claim, and +> prefer primary and contemporaneous sources. Never invent a figure, a tactic, or a source; +> where the record is thin, say so rather than filling it in. + +**Read it:** lead with the comparative takeaway, then the per-entity detail, each claim clickable +to its source. Expose the compute dial to your product so a user can ask for "quick" vs "deep," +and pass that straight to the tier. + +## Config seams (build on top) + +1. **The objective:** the user's research question; this is the input your feature accepts. +2. **Compute dial:** map your product's "quick / standard / deep" to `core` / `core2x` / `pro` (that is the "dial per task"). +3. **Report shape:** define the sections your surface renders (summary, per-entity, comparison, sources). +4. **Async UX:** deep reports run seconds-to-minutes; stream status or notify on completion rather than blocking. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Runs on the Task API +(stable, `v1`): `POST /v1/tasks/runs` with a deep-research processor and `task_spec.output_schema`, +then `GET /v1/tasks/runs/{run_id}/result`; citations in `output.basis`. The processor is your +compute dial. Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw +control. + +## Next + +- Serve the fast inline answers alongside it → **productivity-quickstart**. +- Enrich the entities the report surfaces → **entity-context**. +- Keep the report's topic current after → **knowledge-freshness**. diff --git a/skills/parallel-insurance-kyb-kyc/SKILL.md b/skills/parallel-insurance-kyb-kyc/SKILL.md new file mode 100644 index 0000000..83834cf --- /dev/null +++ b/skills/parallel-insurance-kyb-kyc/SKILL.md @@ -0,0 +1,108 @@ +--- +name: parallel-insurance-kyb-kyc +description: Verify any business or individual at submission, onboarding, or renewal, beneficial ownership, registry data, sanctions, licensing, and negative news, across thousands of entities in parallel, in one cited, confidence-scored profile. Use when the user wants to "verify this applicant", "run KYB/KYC on submission", "check ownership and sanctions", or screen a book at renewal. Runs on the user's own Parallel account via Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# KYB / KYC + +Verify a business or individual at submission, onboarding, or renewal, and get back one +**cited, confidence-scored profile**: beneficial ownership, registry data, sanctions, licensing, +and negative news. Runs across thousands of entities in parallel, so a whole submission batch or +renewal book gets screened at once. The rule that makes it audit-ready: nothing is asserted +without a source, and a "no match" is a checked result, not a blank. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`), one input per entity. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-data-enrichment`** skill + (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +See [docs.parallel.ai](https://docs.parallel.ai). + +> This surfaces public-record evidence with citations to speed a review. It is not legal or +> compliance advice and does not replace your regulated screening provider or a human decision; +> treat it as cited input, and confirm any sanctions hit against the official list. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its jurisdictions framing (captured once at setup), don't re-ask +it; only get the per-run specifics below. + +Before running (each entity is a billable screen): +1. **Which entity or batch?** A business (name + location) or individual, or the submission / renewal batch. +2. **Which checks?** Default: registry status, beneficial ownership, sanctions, licensing, negative news. Add PEP or litigation if your policy requires. +3. **At which stage?** Submission, onboarding, or renewal, so the framing matches your workflow. + +Confirm, then run. + +## Run it + +One task per entity (batch the submission or renewal list). Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["entity", "checks", "verdict"], + "properties": { + "entity": {"type": "string"}, + "checks": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["check", "result", "source_url", "confidence"], + "properties": { + "check": {"type": "string", "enum": ["registry_status", "beneficial_ownership", "sanctions", "licensing", "negative_news", "pep", "litigation", "other"]}, + "result": {"type": "string", "description": "the finding, or an explicit 'No match found' / 'Not found'; never left blank"}, + "source_url": {"type": "string", "description": "resolving source that backs the result; must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + }, + "verdict": {"type": "string", "enum": ["clear", "review", "decline", "insufficient_evidence"], "description": "use insufficient_evidence rather than guessing when checks can't be resolved"} + } +} +``` + +Prompt (substitute the entity + stage): + +> Verify {ENTITY} at {STAGE}. For each check, return the finding with a resolving source URL and +> a 0-100 confidence: (1) registry status, (2) beneficial ownership (named owners and stakes), +> (3) sanctions and watchlist screening, (4) licensing (required licenses and standing), (5) +> negative news. Where a check finds nothing, state "No match found" explicitly, never leave it +> blank. Then give a verdict of clear / review / decline, or "insufficient_evidence" if the +> checks can't be resolved. Never assert a sanction, an owner, or a license without a source; +> confirm any potential sanctions hit against the official list rather than inferring it. + +**Read it:** the verdict is the routing call, "clear" moves the submission, "review" and +"decline" carry the sourced reason, and "insufficient_evidence" is distinct from clean, don't let +an unresolved screen read as passing. + +## Config seams (build on top) + +1. **Input:** one entity, or batch the submission / renewal book (one screen each). +2. **Checks:** edit the `check` enum + the prompt to your policy (add PEP, litigation, source-of-funds). +3. **Verdict routing:** map clear / review / decline / insufficient_evidence to your submission workflow. +4. **Tier:** `core2x` default here (compliance leans up); `core` for a lighter first pass (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations and confidence in `output.basis`. Auth +via `x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw control. + +## Next + +- Build the risk profile behind the applicant → **underwriting-risk-profiles**. +- Keep the entity under watch after bind → **book-risk-monitoring**. +- Get the fast read first → **insurance-quickstart**. diff --git a/skills/parallel-insurance-quickstart/SKILL.md b/skills/parallel-insurance-quickstart/SKILL.md new file mode 100644 index 0000000..e77aead --- /dev/null +++ b/skills/parallel-insurance-quickstart/SKILL.md @@ -0,0 +1,107 @@ +--- +name: parallel-insurance-quickstart +description: Connect Parallel (if needed) and get a fast, source-cited snapshot of a business, address, or claim, what it is, the key risk flags, and a KYB status at a glance, with a source and confidence on every field. Use when the user asks to "get a quick read on this business/address", "any red flags on this applicant", or wants the Parallel insurance quickstart. Runs on the user's own Parallel account via Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Insurance Quickstart + +The fastest way to see Parallel work on a real risk: name one business, address, or claim and +get back a tight, cited **snapshot**, what it is, the handful of risk flags that matter, and a +KYB status at a glance. Every field carries a source and a confidence; if something can't be +verified it comes back empty, never invented, so a low-confidence or empty field is a signal, +not a gap. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-data-enrichment`** skill. + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its lines / workflows framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Two quick questions before running (the run costs credits): +1. **What's the subject?** A business (name + location), an address, or a claim reference. +2. **What matters most?** The default flags: registry status, obvious catastrophe / hazard exposure, and any adverse news. Add or drop. + +Confirm, then run. + +## Run it + +Call `createTaskGroup` once with the subject as the input, processor `core`, and the output +shape below. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["subject", "what_it_is", "risk_flags"], + "properties": { + "subject": {"type": "string"}, + "what_it_is": {"type": "string", "description": "one line: the business / property / claim in plain terms"}, + "registry_status": {"type": "string", "description": "active / dissolved / not found; empty string if not resolvable"}, + "risk_flags": { + "type": "array", + "description": "the notable risk signals found; empty array if none surfaced (say so, don't invent)", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["flag", "detail", "source_url", "confidence"], + "properties": { + "flag": {"type": "string", "enum": ["catastrophe_exposure", "adverse_media", "sanctions", "litigation", "licensing", "safety_record", "other"]}, + "detail": {"type": "string", "description": "one-line factual detail"}, + "source_url": {"type": "string", "description": "resolving source; must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + } + } +} +``` + +Prompt (substitute the subject): + +> For {SUBJECT}, produce a fast risk snapshot and cite a resolving source with a 0-100 +> confidence for every field: what it is in one line, its registry status, and the notable risk +> flags (catastrophe or hazard exposure, adverse media, sanctions, litigation, licensing, or +> safety record). Prefer official and public-record sources. Never invent a flag, a detail, or a +> source, if nothing surfaces for a category, leave it out rather than guess, and return an empty +> risk_flags array if the subject looks clean. For any blank field use an empty string, never the +> word "null". + +> Via the MCP, `createTaskGroup` takes a natural-language output description, not a strict +> schema, so the shape above is guidance there, lean on the prompt wording to keep it clean. + +**Read it:** lead with what it is and registry status, then the risk flags worth a human's +attention, each with its source and confidence. An empty flags list is a clean read, not a +missing one, say so. + +## Config seams (build on top) + +1. **Input:** swap the single subject for a list (run one per subject). +2. **Flags:** edit the `flag` enum + the shape to the signals your workflow acts on. +3. **Tier:** `core` default; `core2x`/`pro` for depth on a priority risk, `lite` for a fast triage pass (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations and confidence in `output.basis`. Auth +via `x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the MCP/CLI. + +## Next + +- Full underwriting workup → **underwriting-risk-profiles**. +- Full compliance check → **kyb-kyc**. +- Keep the subject under watch → **book-risk-monitoring**. diff --git a/skills/parallel-insurance-setup/SKILL.md b/skills/parallel-insurance-setup/SKILL.md new file mode 100644 index 0000000..e80fbf4 --- /dev/null +++ b/skills/parallel-insurance-setup/SKILL.md @@ -0,0 +1,62 @@ +--- +name: parallel-insurance-setup +description: Connect a user's Parallel account and route insurance workflows to the matching skill. Use this first, or when the user says "set up Parallel", "get me started", or isn't sure which use case they need. +allowed-tools: Bash(command:*), Bash(claude:*), Bash(parallel-cli:*), Bash(script:*), Bash(git:*) +metadata: + author: parallel +--- + +# Insurance Setup + +Get connected once, then get pointed to the right use case. Everything runs on the user's own +Parallel account, no key is pasted. + +## 1. Ask what they want to do first (route before installing) + +Don't install or run anything yet. Ask one orienting question and route to the matching skill, +so the first thing they do is the thing they came for: + +> **What do you want to do first?** +> - **Get a fast read on one business, address, or claim** → `parallel-insurance-quickstart` +> - **Research a claim line by line against your rules** → `parallel-claims-research` +> - **Build a P&C underwriting risk profile** → `parallel-underwriting-risk-profiles` +> - **Verify a business or person (KYB / KYC)** → `parallel-insurance-kyb-kyc` +> - **Monitor risk across your book** → `parallel-book-risk-monitoring` +> - **Research an emerging peril, liability class, or regulation** → `parallel-emerging-risk-research` + +If they're unsure, start with `parallel-insurance-quickstart`, it's the fastest to value. + +## 2. Pick the surface and connect (once) + +**Non-technical (co-work / chat): just want output:** +Connect the Task MCP and run the use case in chat. See the `parallel-task-mcp-setup` skill. + +**Technical (build on top):** +Run the `parallel-cli-setup` skill to install and authenticate the CLI. Clone the repository only when the user wants to work from the source: + +```bash +git clone https://github.com/parallel-web/parallel-agent-skills +``` + +> If a call returns `401 Invalid API key`, a stale `PARALLEL_API_KEY` in your shell is +> overriding the login, run `unset PARALLEL_API_KEY` and retry. + +## 3. Capture the insurance profile once + +So the user doesn't re-enter their context on every run, capture what *they* work on here, once: + +1. Ask: **what's your organization, and what do you write or handle?** (domain + org type). +2. Research the organization on Parallel (a quick lookup) and infer the org type, lines of + business, the workflows they run, and their jurisdictions. **Show the user what you found and + let them correct it, never assume**, a wrong guess on the first run is the thing that loses trust. +3. Write the confirmed result to `PROFILE.md` in the current workspace, using + the shape in [references/PROFILE.example.md](references/PROFILE.example.md). `PROFILE.md` is gitignored, so their details stay local. + +Every use-case skill reads `PROFILE.md` and uses that lines / workflows framing, so from here the +user only supplies the per-run target (which claim, address, or entity), not their whole context +each time. This is optional, skip it and each skill will just ask per-run. + +## 4. Hand off to the chosen use case + +Open that use case's `SKILL.md` and follow its guided intake (each one asks 1-3 questions and +confirms before anything billable runs). The use-case skills carry the build logic; this setup connects your account and chooses the next skill. diff --git a/skills/parallel-insurance-setup/references/PROFILE.example.md b/skills/parallel-insurance-setup/references/PROFILE.example.md new file mode 100644 index 0000000..544176c --- /dev/null +++ b/skills/parallel-insurance-setup/references/PROFILE.example.md @@ -0,0 +1,25 @@ +# Your insurance profile + +Captured once during setup (`parallel-insurance-setup`) and read by every skill, so you +don't re-enter your context on every run. Setup writes this to `PROFILE.md` (which is +gitignored, your details stay local and are never committed). Edit it anytime. + +Fill these in (setup does it for you, inferred from your organization and confirmed with you): + +- **org:** +- **domain:** +- **org_type:** +- **lines:** +- **workflows:** +- **rules_source:** +- **jurisdictions:** + +Example (illustrative, not a real organization): + +- **org:** Harborline Specialty +- **domain:** harborline.example +- **org_type:** MGA / MGU +- **lines:** commercial property and light-manufacturing P&C, coastal-exposed +- **workflows:** submission triage, P&C underwriting risk profiles, contents-claim like-kind-and-quality research, book-wide catastrophe and sanctions monitoring +- **rules_source:** internal underwriting guidelines and claim-handling rules (referenced, not stored here) +- **jurisdictions:** Gulf and Southeast US; wind / flood exposure is the dominant driver diff --git a/skills/parallel-knowledge-freshness/SKILL.md b/skills/parallel-knowledge-freshness/SKILL.md new file mode 100644 index 0000000..c6b5084 --- /dev/null +++ b/skills/parallel-knowledge-freshness/SKILL.md @@ -0,0 +1,90 @@ +--- +name: parallel-knowledge-freshness +description: Keep a feed or knowledge base current, watch the topics, sources, and entities your users care about and surface an update the moment something changes, deduped and cited, to power live feeds, alerts, and always-current knowledge. Use when the user wants to "keep my feed fresh", "update my product when X changes", "power a live feed", or keep a knowledge base current. Runs on the user's own Parallel account via Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(curl:*) +metadata: + author: parallel +--- + +# Knowledge Freshness + +Keep a feed or knowledge base **current**: watch the topics, sources, and entities your users +care about and surface an update the moment something changes. Powers live feeds, alerts, and +always-current knowledge. Dedup is handled, so your product only shows real changes, and each +update is structured and cited so it renders with a source and routes to the right user. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **CLI / build-on-top:** the installed **`parallel-monitor`** skill (`parallel-cli skills + install`) is the maintained path. +- Monitor is the stable `v1` API; the raw endpoint is included below for pipelines. + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its keep_current framing (captured once at setup), that's usually +what to watch, don't re-ask it; only get the per-run specifics below. + +Before creating monitors (each is a recurring, billable watch): +1. **What to watch?** The entities, topics, or sources your users track (one monitor per entity or topic). +2. **Which changes?** Default: job changes, fundraises, major announcements, and sentiment shifts. Trim to what your product surfaces. +3. **Cadence?** Daily (`1d`) is the usual default; tighter for a fast-moving feed. + +Confirm, then create. + +## Run it + +The shape that works: run **one broad monitor per entity** (or per topic) and classify the +update downstream, not one monitor per change type. It's far cheaper per record and dedups +cleanly. A monitor runs on a schedule, catches new matches, and returns structured output your +product can render straight into a feed. + +Output shape per detected update: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["change_type", "subject", "summary", "change_date", "source_url"], + "properties": { + "change_type": {"type": "string", "enum": ["job_change", "fundraise", "announcement", "acquisition", "sentiment_shift", "other"]}, + "subject": {"type": "string", "description": "the entity or topic the update concerns"}, + "summary": {"type": "string", "description": "one-line factual summary your product can show in the feed"}, + "change_date": {"type": "string", "description": "ISO 8601 date"}, + "route_to": {"type": "string", "description": "which user / workspace this update belongs to"}, + "source_url": {"type": "string", "description": "resolving source; must load"} + } +} +``` + +Query per entity (substitute): + +> Watch {ENTITY_OR_TOPIC} and notify me of any concrete, sourced change: a job change, a +> fundraise, a major announcement, an acquisition, or a clear shift in sentiment. Give a one-line +> summary, the date, and a resolving source. Prioritize named, dated, sourced facts; exclude +> rumor and generic commentary. + +## Config seams (build on top) + +1. **Watched set:** one monitor per entity or topic your users follow (loop from the workspace `PROFILE.md` file or your DB). +2. **Change types:** edit the `change_type` enum + the query to what your feed shows. +3. **Routing:** `route_to` maps each update to the user or workspace it belongs to (fan out from one monitor). +4. **Cadence:** daily (`1d`) default; tighter for a fast feed, cadence controls latency, not how much you catch. +5. **Processor:** `lite` is the cheap forward-watch default; `base` for heavier scans. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ `POST /v1/monitors` +(`type: event_stream`, `frequency`, `processor`, `settings.query`, `settings.output_schema`), +read hits at `GET /v1/monitors/{id}/events`, optional `webhook` to push into your feed pipeline. +`event_stream` only catches change **going forward**, seed the current state with a Task first if +you need a baseline now. Auth via `x-api-key`, same key creates and reads. + +## Next + +- Act on a change instead of just showing it → **workspace-agent**. +- Enrich the entity behind an update → **entity-context**. +- Answer a user's follow-up on the update → **productivity-quickstart**. diff --git a/skills/parallel-kyb-kyc/SKILL.md b/skills/parallel-kyb-kyc/SKILL.md new file mode 100644 index 0000000..ba6da72 --- /dev/null +++ b/skills/parallel-kyb-kyc/SKILL.md @@ -0,0 +1,123 @@ +--- +name: parallel-kyb-kyc +description: Run an audit-ready KYB / KYC screen on a company or counterparty, registry status, beneficial ownership, sanctions and watchlist screening, and adverse media, in one cited, confidence-scored profile, then keep it under continuous watch. Use when the user wants to "run KYB on X", "screen this counterparty", "check beneficial ownership and sanctions", or set up onboarding and ongoing compliance. Runs on the user's own Parallel account via Task and Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), Bash(curl:*), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# KYB / KYC + +Screen a company or counterparty and get back one **audit-ready, cited compliance profile**, +registry status, beneficial ownership, sanctions and watchlist screening, and adverse media, +each field confidence-scored with a resolving source. Run it at onboarding as a Task, then +keep the name under a Monitor so a new sanction, filing, or adverse story surfaces the moment +it appears. The rule that makes it audit-ready: nothing is asserted without a source, and a +"no match" is stated as a checked result, not left blank. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two primitives, both maintained by Parallel so API changes are absorbed for you: +- **Onboarding screen (point in time):** the **Task MCP** (`createTaskGroup`), or the installed + **`parallel-data-enrichment`** skill on the CLI. +- **Ongoing screen (continuous):** the installed **`parallel-monitor`** skill (`parallel-cli + skills install`), Monitor is the stable `v1` API. + +If Parallel is not configured, run the relevant setup skill first. See +[docs.parallel.ai](https://docs.parallel.ai). + +> This surfaces public-record evidence with citations to speed a compliance review. It is not +> legal advice and does not replace your regulated screening provider or a human decision; +> treat it as cited input to your process, and confirm sanctions hits against the official +> list. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its compliance-posture framing (jurisdictions, lists, risk +appetite, captured once at setup), don't re-ask it; only get the per-run specifics below. + +Before running (each screen is a billable run; the Monitor is recurring): +1. **Which company or counterparty?** Name + domain, and country of registration if you know it. +2. **Which checks?** Default: registry status, beneficial ownership, sanctions/watchlist, adverse media. Add PEP, litigation, or others your policy requires. +3. **One-time or ongoing?** Onboarding screen only (Task), or also stand up the continuous Monitor. + +Confirm, then run. + +## Run it + +### 1. Onboarding screen (Task) + +One task per counterparty. Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["company", "checks", "overall_risk"], + "properties": { + "company": {"type": "string"}, + "checks": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["check", "result", "source_url", "confidence"], + "properties": { + "check": {"type": "string", "enum": ["registry_status", "beneficial_ownership", "sanctions_watchlist", "adverse_media", "pep", "litigation", "other"]}, + "result": {"type": "string", "description": "the finding, or an explicit 'No match found' / 'Not found'; never left blank"}, + "source_url": {"type": "string", "description": "resolving source that backs the result; must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + }, + "overall_risk": {"type": "string", "enum": ["low", "medium", "high", "insufficient_evidence"], "description": "use insufficient_evidence rather than guessing when checks can't be resolved"} + } +} +``` + +Prompt (substitute the counterparty): + +> Run a KYB / KYC screen on {COMPANY} (country of registration: {COUNTRY_OR_UNKNOWN}). For each +> check, return the finding with a resolving source URL and a 0-100 confidence: (1) registry +> status (active/dissolved, jurisdiction, ID), (2) beneficial ownership (named owners / +> controllers), (3) sanctions and watchlist screening, (4) adverse media. Where a check finds +> nothing, state "No match found" explicitly, never leave it blank. Then give an overall risk +> of low / medium / high, or "insufficient_evidence" if the checks can't be resolved. Never +> assert a sanction, an owner, or a registry fact without a source; confirm any potential +> sanctions hit against the official list rather than inferring it. + +### 2. Ongoing screen (Monitor) + +Stand up one Monitor per counterparty so changes surface going forward. Query: + +> Notify me of any new sanction or watchlist listing, ownership or control change, registry +> status change (e.g. dissolution), litigation, or adverse media concerning {COMPANY}. +> Prioritize named, dated, sourced facts; exclude rumor. Return the change, its date, and a +> resolving source. + +Reuse the `parallel-portfolio-monitoring` output shape (swap the enum to the compliance events above), +`lite` processor, `1d` cadence. + +## Config seams (build on top) + +1. **Input**: one counterparty, or batch your onboarding queue (one screen each). +2. **Checks**: edit the `check` enum + the prompt to your policy (add PEP, litigation, source-of-funds). +3. **Risk model**: `overall_risk` is a summary; keep `insufficient_evidence` distinct from `low` so unresolved screens don't read as clean. +4. **Tier**: `core2x` default here (compliance leans up); `core` for a lighter first pass. +5. **Continuous**: the Monitor turns the point-in-time screen into ongoing coverage. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, `GET /v1/tasks/runs/{run_id}/result`; +citations in `output.basis`. Ongoing screening via `POST /v1/monitors` (`event_stream`), read at +`GET /v1/monitors/{id}/events`. Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless +you need raw control. + +## Next + +- Screen a whole target before the profile → **company-profiles** (full tear sheet). +- Screen the owners surfaced here as individuals → re-run this skill per person. +- Keep the whole book under watch → **portfolio-monitoring**. diff --git a/skills/parallel-landscape-deep-research/SKILL.md b/skills/parallel-landscape-deep-research/SKILL.md new file mode 100644 index 0000000..3abd59b --- /dev/null +++ b/skills/parallel-landscape-deep-research/SKILL.md @@ -0,0 +1,84 @@ +--- +name: parallel-landscape-deep-research +description: Commission a structured, source-cited report on a therapeutic area, mechanism, or life sciences investment question, every claim traced to a registry, filing, or paper. Use when the user wants to research a therapeutic area, assess whether to pursue a mechanism, size an indication, or prepare a cited report on a target or area. Runs on the user's own Parallel account via Deep Research. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createDeepResearch, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Landscape Deep Research + +Ask an open question about a therapeutic area, a mechanism, or an investment thesis, and get +back a **structured, cited report**: the biology and unmet need, the competitive pipeline, the +clinical and regulatory picture, the risks, and a read on the question, with every claim traced +to a registry, a filing, or the primary literature. Nothing is fabricated; where the evidence +is early or conflicting, the report says so instead of overstating it. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** `createDeepResearch`. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill + (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its therapeutic-area and modality framing (captured once at +setup) to focus the report; don't re-ask it. + +Two quick questions before running (deep research is a higher-tier, billable run): +1. **What's the question?** One clear area, mechanism, or thesis question, the sharper the better. +2. **What must it cover?** Default sections: biology and unmet need, competitive pipeline, clinical and regulatory landscape, risks, and a verdict. Add or drop. + +Confirm, then run. + +## Run it + +Deep research warrants a higher tier, default `pro` here. Give it the question and the sections +to cover. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +Prompt (substitute your question): + +> Produce a structured research report answering: "{AREA_OR_THESIS_QUESTION}". Cite a resolving +> source URL for every claim, and prefer primary sources (ClinicalTrials.gov, FDA/EMA records, +> peer-reviewed literature, company filings) over secondary commentary. Cover, in order: +> +> 1) **Biology and unmet need:** the target/mechanism, the indication, and the gap in current care. +> 2) **Competitive pipeline:** the assets in development, their sponsors, and their clinical status. +> 3) **Clinical and regulatory landscape:** key readouts, endpoints, and the FDA/EMA path. +> 4) **Risks:** the things that would break the thesis (biological, clinical, regulatory, commercial). +> 5) **Verdict:** a direct, evidence-weighted read on the question, with the key uncertainties named. +> +> Never invent a trial result, an approval, or a source. Where the evidence is early or +> conflicting, show both sides and label the uncertainty rather than resolving it artificially. + +**Read it:** start with the verdict and the two or three readouts or datapoints that carry it, +then use biology / pipeline / regulatory as the support, following the citations on anything +you'd put in front of a committee. Where the report flags thin or early evidence, treat that as +diligence to do, not a gap to smooth over. + +## Config seams (build on top) + +1. **The question:** one sharp area, mechanism, or thesis question; this is the whole input. +2. **Sections:** edit the section list to your diligence template (add deal comps, IP, market sizing, KOL view). +3. **Tier:** `pro` default for a real report; `core2x` for a quicker read, `ultra` for the highest-stakes questions (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Deep Research runs on +the Task API (stable, `v1`): `POST /v1/tasks/runs` with a deep-research processor and +`task_spec.output_schema`, then `GET /v1/tasks/runs/{run_id}/result`; citations in +`output.basis`. Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw +control. + +## Next + +- Turn the pipeline section into a live map → **competitive-landscape**. +- Find net-new assets the report surfaces → **licensing-discovery**. +- Watch the area for the events that confirm or break the thesis → **pipeline-monitoring**. diff --git a/skills/parallel-lead-discovery/SKILL.md b/skills/parallel-lead-discovery/SKILL.md new file mode 100644 index 0000000..604546b --- /dev/null +++ b/skills/parallel-lead-discovery/SKILL.md @@ -0,0 +1,81 @@ +--- +name: parallel-lead-discovery +description: Describe your ICP in plain language and get back a researched, source-cited list of candidate accounts (or people), including the long tail that isn't in existing databases. Use when the user wants to "find companies like X", "generate a prospect list", "find all Y matching Z", or build a net-new list. Runs on the user's own Parallel account via FindAll. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *) +metadata: + author: parallel +--- + +# Lead Discovery (FindAll) + +Describe your ideal customer in plain language, get back a **researched, cited list of +candidates**. Works across companies, people, and the long tail of entities that don't fit +existing databases. Every match resolves to a source; noise and non-matches are filtered. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +FindAll is exposed through **`parallel-cli findall`** (installed by `parallel-cli skills +install`), this is the maintained path, and it's what you should build on. FindAll is in +**public beta**, so the raw HTTP endpoints can change (30 days' notice); riding the CLI means +Parallel absorbs those changes on update. If Parallel is not configured, run the relevant setup skill first. Check [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its company / ICP / value framing (captured once at setup), it seeds the ICP so you're not starting blank; confirm-or-tweak rather than re-ask. + +Before the paid run: +1. **Describe your ICP** in plain language, be specific about the entity type and the criteria. +2. **How many candidates?** Start around 25 (`-n 25`) to gauge quality, then extend. +3. **Preview first?** Run `ingest` (below) to see the parsed query before paying. + +Confirm, then run. + +## Run it + +Preview the parsed query before you pay: + +``` +parallel-cli findall ingest "" +``` + +Then run and poll results to disk: + +``` +parallel-cli findall run "B2B SaaS companies, 200 to 2000 employees, that raised a Series A or B this year and are hiring engineers to build AI agents" -g core -n 50 --no-wait --json +parallel-cli findall poll "" -o /tmp/leads.json --timeout 540 +``` + +Add fields to each candidate (optional): + +``` +parallel-cli findall enrich "" '{"properties":{"funding_stage":{"type":"string"},"hq_location":{"type":"string"},"employee_count":{"type":"number"}}}' +``` + +Each candidate returns `name`, `url`, `description`, a `match_status` (`matched` is the +keeper), enriched fields under `output`, and per-field citations under `basis`. + +## Config seams (build on top) + +1. **The objective**: your ICP in plain language. This is the whole input; be specific + about the entity type and the criteria. +2. **Generator tier**: `-g core` default, `-g pro` for comprehensive/sparse, `-g preview` + for a fast scan, skip `-g base` for real data. +3. **Count**: `-n` (5 to 1000); start small to gauge quality, then `parallel-cli findall + extend "" 50` for more. +4. **Enrichment fields**: the `properties` you add become columns; keys are yours to define. +5. **Exclude**: `--exclude '[{"name":"...","url":"..."}]'` to skip what you already have. + +## Production (raw HTTP API): beta, verify before hardcoding + +_As of 2026-08; FindAll is public beta, confirm at [docs.parallel.ai](https://docs.parallel.ai)._ +`POST /v1beta/findall/ingest` → `POST /v1beta/findall/entity-search` (fast candidates) or the +full run → `GET /v1beta/findall/runs/{findall_id}/result` (returns `candidates[]` with +`output` + `basis`). Because it's `v1beta`, prefer `parallel-cli findall` so tier/shape changes +don't break your build. + +## Next + +- Enrich the list into full tear sheets → **account-enrichment**. +- Watch the new accounts for the right time to reach out → **signal-monitoring**. diff --git a/skills/parallel-legal-quickstart/SKILL.md b/skills/parallel-legal-quickstart/SKILL.md new file mode 100644 index 0000000..cd07a7d --- /dev/null +++ b/skills/parallel-legal-quickstart/SKILL.md @@ -0,0 +1,136 @@ +--- +name: parallel-legal-quickstart +description: Connect Parallel (if needed) and get the legal facts on any entity or matter fast, who they are legally, litigation and regulatory posture, and red flags, every fact backed by a resolving source. Use when the user asks to "run a quick check on this company", "what's the litigation/regulatory history of X", "get me up to speed on a counterparty", or wants the Parallel legal quickstart. Runs on the user's own Parallel account. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Legal Quickstart + +The fastest way to see Parallel work on a real entity: name one company, get back the things +you need before you touch a matter, **who they are legally** (entity profile + jurisdiction), +their **litigation and regulatory posture**, and any **red flags**. Every fact is backed by a +resolving source; if something can't be verified it comes back empty, never invented. This is +a research layer, not legal advice, treat outputs as cited leads to verify. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill. + +If Parallel is not configured, run the relevant setup skill first. Processor +tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its organization / jurisdiction / priority framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Two quick questions before running (the run costs credits): +1. **Which entity?** A company name and, ideally, a domain or jurisdiction to disambiguate. Resolve a bare name and confirm which entity you mean first, wrong-entity is the classic diligence error. +2. **What angle matters most?** Litigation history, regulatory/enforcement posture, sanctions/ownership, or a general check. Default: general check across all. + +Confirm, then run. + +## Run it + +Call `createTaskGroup` once with the entity as the input, processor `core`, and the output +shape below. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["entity", "profile", "litigation_and_regulatory", "red_flags"], + "properties": { + "entity": {"type": "string", "description": "the resolved entity you researched (name + a disambiguator)"}, + "profile": { + "type": "object", + "additionalProperties": false, + "required": ["legal_name", "what_they_do", "jurisdiction", "source_url"], + "properties": { + "legal_name": {"type": "string", "description": "registered legal name if found; else best-known name"}, + "what_they_do": {"type": "string", "description": "one line: the business / activity"}, + "jurisdiction": {"type": "string", "description": "domicile / registration jurisdiction if sourced; else empty string"}, + "entity_type": {"type": "string", "description": "e.g. Delaware C-corp, LLP, GmbH; empty if not sourced"}, + "source_url": {"type": "string", "description": "a resolving source backing the profile; must load"} + } + }, + "litigation_and_regulatory": { + "type": "array", + "description": "notable litigation, enforcement, or regulatory matters; empty array if none found, never invented", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["matter", "type", "status", "date", "source_url"], + "properties": { + "matter": {"type": "string", "description": "one-line factual description"}, + "type": {"type": "string", "enum": ["litigation", "enforcement", "regulatory_action", "investigation", "sanction", "other"]}, + "status": {"type": "string", "description": "e.g. filed, ongoing, settled, dismissed; empty if not sourced"}, + "date": {"type": "string", "description": "ISO 8601 date of the most relevant event"}, + "source_url": {"type": "string", "description": "resolving source; must load (docket, filing, regulator, credible report)"} + } + } + }, + "red_flags": { + "type": "array", + "description": "concrete, sourced concerns worth a closer look; empty array if none, never speculative", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["flag", "source_url"], + "properties": { + "flag": {"type": "string", "description": "one line: the concern and why it matters"}, + "source_url": {"type": "string"} + } + } + } + } +} +``` + +Prompt (substitute the entity): + +> For {ENTITY}, produce a fast legal read and cite a resolving source URL for every fact. +> (1) Profile: registered legal name, one line on what they do, domicile / registration +> jurisdiction, and entity type, only when a source states it. (2) Litigation and regulatory: +> notable lawsuits, enforcement actions, regulatory actions, investigations, or sanctions, +> each with a one-line description, type, status, date, and a resolving source (a docket, +> filing, regulator page, or credible report). (3) Red flags: concrete, sourced concerns +> worth a closer look. Never invent a matter, name, date, status, or source. If you can't +> verify something, leave it out or return an empty array, do not speculate. First disambiguate +> which entity is meant if the name is ambiguous. For any blank field use an empty string, +> never the word "null". + +> Via the MCP, `createTaskGroup` takes a natural-language output description, not a strict +> schema, so the shape above is guidance there, lean on the prompt wording to keep it clean. + +**Read it:** lead with the entity and one-line profile, then anything in +`litigation_and_regulatory` and `red_flags` (these are the reason to look closer), each with +a clickable source. Where a section came back empty, say "none found in public sources", that +refusal to fabricate, and the honest "none found", is the point in legal work. + +## Config seams (build on top) + +1. **Input**: swap the single entity for your list (run one per entity). +2. **Fields**: edit the shape to the angles you triage on; keys become columns. +3. **Tier**: `core` default; `core2x`/`pro` for a deeper read, `lite` for a fast scan (see the tier guidance in this skill). + +Riding the MCP/CLI means an API change is absorbed on update, you don't re-clone for it. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations in `output.basis`. Auth via +`x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the MCP/CLI. + +## Next + +- A whole list of counterparties → **entity-diligence** (batch this shape per entity). +- Need to quote the actual statute/case → **source-grounded-research**. +- Keep it live → **regulatory-monitoring** (alert when a new filing or action lands). +- Deeper on one subject → **diligence-briefs** (full research report). diff --git a/skills/parallel-legal-setup/SKILL.md b/skills/parallel-legal-setup/SKILL.md new file mode 100644 index 0000000..5da7f24 --- /dev/null +++ b/skills/parallel-legal-setup/SKILL.md @@ -0,0 +1,64 @@ +--- +name: parallel-legal-setup +description: Connect a user's Parallel account and route legal workflows to the matching skill. Use this first, or when the user says "set up Parallel", "get me started", or isn't sure which use case they need. +allowed-tools: Bash(command:*), Bash(claude:*), Bash(parallel-cli:*), Bash(script:*), Bash(git:*) +metadata: + author: parallel +--- + +# Legal Setup + +Get connected once, then get pointed to the right use case. Everything runs on the user's +own Parallel account, no key is pasted. + +## 1. Ask what they want to do first (route before installing) + +Don't install or run anything yet. Ask one orienting question and route to the matching +skill, so the first thing they do is the thing they came for: + +> **What do you want to do first?** +> - **Get up to speed on one entity or matter fast** → `parallel-legal-quickstart` +> - **Research the law / an authoritative source and quote it** → `parallel-source-grounded-research` +> - **Run diligence on a list of counterparties or targets** → `parallel-entity-diligence` +> - **Find every entity matching a legal criterion** → `parallel-exposure-discovery` +> - **Get alerted on new rules, filings, or sanctions changes** → `parallel-regulatory-monitoring` +> - **Deep pre-matter brief on one counterparty or target** → `parallel-diligence-briefs` + +If they're unsure, start with `parallel-legal-quickstart`, it's the fastest to value. + +## 2. Pick the surface and connect (once) + +**Non-technical (co-work / chat): just want output:** +Connect the Task MCP and run the use case in chat. See the `parallel-task-mcp-setup` skill. + +**Technical (build on top):** +Run the `parallel-cli-setup` skill to install and authenticate the CLI. Clone the repository only when the user wants to work from the source: + +```bash +git clone https://github.com/parallel-web/parallel-agent-skills +``` + +> If a call returns `401 Invalid API key`, a stale `PARALLEL_API_KEY` in your shell is +> overriding the login, run `unset PARALLEL_API_KEY` and retry. + +## 3. Capture the legal profile once + +So the user doesn't re-enter their context on every run, capture who *they* are here, once: + +1. Ask: **what organization are you at, and what legal work is this for?** (domain). +2. Research it on Parallel (a quick lookup) and infer what they do, the jurisdictions they + care about, and the matter types they run. **Show the user what you found and let them + correct it, never assume**, a wrong guess on the first run is the thing that loses trust. +3. Write the confirmed result to `PROFILE.md` in the current workspace, using + the shape in [references/PROFILE.example.md](references/PROFILE.example.md). `PROFILE.md` is gitignored, so their details stay local. + +Every use-case skill reads `PROFILE.md` and uses that organization / jurisdiction / priority +framing, so from here the user only supplies the per-run target (which entity, question, or +list), not their whole context each time. This is optional, skip it and each skill will just +ask per-run. + +## 4. Hand off to the chosen use case + +Open that use case's `SKILL.md` and follow its guided intake (each one asks 1-3 questions and +confirms before anything billable runs). The use-case skills carry the build logic; this +setup just gets you connected and cloned. diff --git a/skills/parallel-legal-setup/references/PROFILE.example.md b/skills/parallel-legal-setup/references/PROFILE.example.md new file mode 100644 index 0000000..9bb9f66 --- /dev/null +++ b/skills/parallel-legal-setup/references/PROFILE.example.md @@ -0,0 +1,23 @@ +# Your legal profile + +Captured once during setup (`parallel-legal-setup`) and read by every skill, so you +don't re-enter your context on every run. Setup writes this to `PROFILE.md` (which is +gitignored, your details stay local and are never committed). Edit it anytime. + +Fill these in (setup does it for you, inferred from your organization and confirmed with you): + +- **organization:** +- **domain:** +- **what_you_do:** +- **jurisdictions:** +- **matter_types:** +- **priorities:** <1-3 things that make a result useful to you; used to frame focus and red flags, never to spin the facts> + +Example (illustrative, not a real organization): + +- **organization:** Bellwether Counsel +- **domain:** bellwethercounsel.example +- **what_you_do:** counterparty and target-company diligence for mid-market M&A and vendor onboarding +- **jurisdictions:** US federal, Delaware, New York; UK (England & Wales); EU for data + sanctions +- **matter_types:** pre-signing target diligence, KYB / vendor onboarding, sanctions + watchlist screening, litigation history checks +- **priorities:** surface undisclosed litigation and regulatory actions early; flag ownership / sanctions exposure; every claim must resolve to a source diff --git a/skills/parallel-licensing-discovery/SKILL.md b/skills/parallel-licensing-discovery/SKILL.md new file mode 100644 index 0000000..8c8fa2b --- /dev/null +++ b/skills/parallel-licensing-discovery/SKILL.md @@ -0,0 +1,85 @@ +--- +name: parallel-licensing-discovery +description: Describe business-development criteria in plain language and get a researched, source-cited list of assets or companies, including private biotechs that traditional databases may omit. Use when the user wants to find licensing targets, find companies with an asset that matches defined criteria, build a BD target list, or discover M&A candidates. Runs on the user's own Parallel account via FindAll. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *) +metadata: + author: parallel +--- + +# Licensing Discovery (FindAll) + +Describe your BD criteria in plain language, get back a **researched, cited list of assets or +companies**, including the long tail of private biotechs that never make it onto commercial +databases. Founding year, modality, indication, development stage, IP-rights status, whatever +defines a good-fit target. Every match resolves to a source; noise and non-matches are filtered. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +FindAll is exposed through **`parallel-cli findall`** (installed by `parallel-cli skills +install`), this is the maintained path, and it's what you should build on. FindAll is in +**public beta**, so the raw HTTP endpoints can change (30 days' notice); riding the CLI means +Parallel absorbs those changes on update. If Parallel is not configured, run the relevant setup skill first. Check [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its therapeutic-area / modality framing (captured once at setup), +it seeds the criteria so you're not starting blank; confirm-or-tweak rather than re-ask. + +Before the paid run: +1. **Describe your criteria** in plain language, be specific about the entity (asset or company), the modality / indication, the stage, and any IP or ownership filter. +2. **How many candidates?** Start around 25 (`-n 25`) to gauge quality, then extend. +3. **Preview first?** Run `ingest` (below) to see the parsed query before paying. + +Confirm, then run. + +## Run it + +Preview the parsed query before you pay: + +``` +parallel-cli findall ingest "" +``` + +Then run and poll results to disk: + +``` +parallel-cli findall run "private biotechs with a clinical-stage autoimmune asset, founded after 2019, with ex-US IP rights unlicensed" -g core -n 50 --no-wait --json +parallel-cli findall poll "" -o /tmp/targets.json --timeout 540 +``` + +Add fields to each candidate (optional): + +``` +parallel-cli findall enrich "" '{"properties":{"lead_asset":{"type":"string"},"phase":{"type":"string"},"modality":{"type":"string"},"last_financing":{"type":"string"}}}' +``` + +Each candidate returns `name`, `url`, `description`, a `match_status` (`matched` is the keeper), +enriched fields under `output`, and per-field citations under `basis`. + +## Config seams (build on top) + +1. **The objective:** your BD criteria in plain language. This is the whole input; be specific + about the entity type, the modality / indication, the stage, and the IP / ownership filter. +2. **Generator tier:** `-g core` default, `-g pro` for a comprehensive or sparse universe, + `-g preview` for a fast scan, skip `-g base` for real data. +3. **Count:** `-n` (5 to 1000); start small to gauge quality, then `parallel-cli findall extend + "" 50` for more. +4. **Enrichment fields:** the `properties` you add become columns (lead asset, phase, modality, + last financing); keys are yours to define. +5. **Exclude:** `--exclude '[{"name":"...","url":"..."}]'` to skip names already in your CRM. + +## Production (raw HTTP API): beta, verify before hardcoding + +_As of 2026-08; FindAll is public beta, confirm at [docs.parallel.ai](https://docs.parallel.ai)._ +`POST /v1beta/findall/ingest` → `POST /v1beta/findall/entity-search` (fast candidates) or the +full run → `GET /v1beta/findall/runs/{findall_id}/result` (returns `candidates[]` with `output` ++ `basis`). Because it's `v1beta`, prefer `parallel-cli findall` so tier/shape changes don't +break your build. + +## Next + +- Profile a shortlisted target in full → **competitive-landscape** or **life-sciences-quickstart**. +- Watch the target for readouts and deals → **pipeline-monitoring**. +- Pull the clinical data behind its lead asset → **literature-mining**. diff --git a/skills/parallel-life-sciences-quickstart/SKILL.md b/skills/parallel-life-sciences-quickstart/SKILL.md new file mode 100644 index 0000000..0238228 --- /dev/null +++ b/skills/parallel-life-sciences-quickstart/SKILL.md @@ -0,0 +1,109 @@ +--- +name: parallel-life-sciences-quickstart +description: Connect Parallel (if needed) and get a fast, source-cited snapshot of any drug, target, or company, what it is, mechanism of action, indication, clinical phase, and sponsor, with a source for every fact. Use when the user asks for an overview of a drug or target, a quick read on an asset, or the Parallel life sciences quickstart. Runs on the user's own Parallel account via Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Life Sciences Quickstart + +The fastest way to see Parallel work on a real asset: name one drug, target, or company and get +back a tight, cited **snapshot**, what it is, its mechanism of action, the indication, the +current clinical phase, and the sponsor behind it. Every fact resolves to a source +(ClinicalTrials.gov, a label, a filing, or the primary paper); if something can't be verified +it comes back empty, never invented. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill. + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its therapeutic-area framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Two quick questions before running (the run costs credits): +1. **Which asset?** A drug / asset code (e.g. NVX-301), a target / mechanism, or a company. Resolve an ambiguous name and confirm first. +2. **Asset or company view?** Snapshot a single asset, or a company and its lead programs. Default: infer from what they named. + +Confirm, then run. + +## Run it + +Call `createTaskGroup` once with the asset as the input, processor `core`, and the output shape +below. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["subject", "what_it_is", "mechanism", "indication", "phase", "sponsor"], + "properties": { + "subject": {"type": "string", "description": "the drug, target, or company"}, + "what_it_is": {"type": "string", "description": "one line: modality and what it does"}, + "mechanism": {"type": "string", "description": "mechanism of action / target; empty string if not established"}, + "indication": {"type": "string", "description": "lead indication(s) under study or approved"}, + "phase": {"type": "string", "description": "current clinical phase or approval status"}, + "sponsor": {"type": "string", "description": "the company / sponsor developing it"}, + "basis": { + "type": "array", + "description": "one entry per field: the source behind it and a confidence", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["field", "source_url", "confidence"], + "properties": { + "field": {"type": "string"}, + "source_url": {"type": "string", "description": "resolving source (registry, label, filing, paper); must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + } + } +} +``` + +Prompt (substitute the asset): + +> For {ASSET}, produce a fast snapshot and cite a resolving source URL for every fact: what it +> is (modality and function), mechanism of action / target, lead indication(s), current +> clinical phase or approval status, and the sponsor. Prefer ClinicalTrials.gov, FDA/EMA +> records, and the primary literature over secondary summaries. Never invent a mechanism, a +> phase, or a source, if a fact isn't on a reachable source, return an empty string and say so. + +> Via the MCP, `createTaskGroup` takes a natural-language output description, not a strict +> schema, so the shape above is guidance there, lean on the prompt wording to keep it clean. + +**Read it:** lead with what it is and the mechanism, then indication and phase, then the +sponsor, each with its resolving source. Where a field came back empty, say so, that refusal to +fabricate is the point. + +## Config seams (build on top) + +1. **Input:** swap the single asset for a list (run one per asset). +2. **Fields:** edit the shape to what you track (add trial IDs, next milestone, partners); keys become columns. +3. **Tier:** `core` default; `core2x`/`pro` for depth, `lite` for a fast pass (see the tier guidance in this skill). + +Riding the MCP/CLI means an API change is absorbed on update, you don't re-clone for it. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations in `output.basis`. Auth via +`x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the MCP/CLI. + +## Next + +- Map the whole space around it → **competitive-landscape**. +- Keep it live → **pipeline-monitoring** (alert on readouts, phase changes, approvals). +- Pull the trial data behind it → **literature-mining**. diff --git a/skills/parallel-life-sciences-setup/SKILL.md b/skills/parallel-life-sciences-setup/SKILL.md new file mode 100644 index 0000000..0beeec7 --- /dev/null +++ b/skills/parallel-life-sciences-setup/SKILL.md @@ -0,0 +1,63 @@ +--- +name: parallel-life-sciences-setup +description: Connect a user's Parallel account and route life sciences workflows to the matching skill. Use this first, or when the user says "set up Parallel", "get me started", or isn't sure which use case they need. +allowed-tools: Bash(command:*), Bash(claude:*), Bash(parallel-cli:*), Bash(script:*), Bash(git:*) +metadata: + author: parallel +--- + +# Life Sciences Setup + +Get connected once, then get pointed to the right use case. Everything runs on the user's own +Parallel account, no key is pasted. + +## 1. Ask what they want to do first (route before installing) + +Don't install or run anything yet. Ask one orienting question and route to the matching skill, +so the first thing they do is the thing they came for: + +> **What do you want to do first?** +> - **Get up to speed on one drug, target, or company** → `parallel-life-sciences-quickstart` +> - **Map a therapeutic area or mechanism's competitive landscape** → `parallel-competitive-landscape` +> - **Find licensing / M&A targets by criteria** → `parallel-licensing-discovery` +> - **Get alerted on readouts, phase transitions, and approvals** → `parallel-pipeline-monitoring` +> - **Pull structured data out of papers, registries, and filings** → `parallel-literature-mining` +> - **Commission a research report on an area or thesis** → `parallel-landscape-deep-research` + +If they're unsure, start with `parallel-life-sciences-quickstart`, it's the fastest to value. + +## 2. Pick the surface and connect (once) + +**Non-technical (co-work / chat): just want output:** +Connect the Task MCP and run the use case in chat. See the `parallel-task-mcp-setup` skill. + +**Technical (build on top):** +Run the `parallel-cli-setup` skill to install and authenticate the CLI. Clone the repository only when the user wants to work from the source: + +```bash +git clone https://github.com/parallel-web/parallel-agent-skills +``` + +> If a call returns `401 Invalid API key`, a stale `PARALLEL_API_KEY` in your shell is +> overriding the login, run `unset PARALLEL_API_KEY` and retry. + +## 3. Capture the life sciences profile once + +So the user doesn't re-enter their context on every run, capture what *they* work on here, once: + +1. Ask: **what's your organization, and what areas do you focus on?** (domain + org type). +2. Research the organization on Parallel (a quick lookup) and infer the org type, therapeutic + areas, modalities, and what they track. **Show the user what you found and let them correct + it, never assume**, a wrong guess on the first run is the thing that loses trust. +3. Write the confirmed result to `PROFILE.md` in the current workspace, + using the shape in [references/PROFILE.example.md](references/PROFILE.example.md). `PROFILE.md` is gitignored, so their details + stay local. + +Every use-case skill reads `PROFILE.md` and uses that therapeutic-area and tracking framing, so +from here the user only supplies the per-run target (which drug, area, or thesis), not their +whole context each time. This is optional, skip it and each skill will just ask per-run. + +## 4. Hand off to the chosen use case + +Open that use case's `SKILL.md` and follow its guided intake (each one asks 1-3 questions and +confirms before anything billable runs). The use-case skills carry the build logic; this setup connects your account and chooses the next skill. diff --git a/skills/parallel-life-sciences-setup/references/PROFILE.example.md b/skills/parallel-life-sciences-setup/references/PROFILE.example.md new file mode 100644 index 0000000..1259dd7 --- /dev/null +++ b/skills/parallel-life-sciences-setup/references/PROFILE.example.md @@ -0,0 +1,25 @@ +# Your life sciences profile + +Captured once during setup (`parallel-life-sciences-setup`) and read by every skill, so +you don't re-enter your focus on every run. Setup writes this to `PROFILE.md` (which is +gitignored, your details stay local and are never committed). Edit it anytime. + +Fill these in (setup does it for you, inferred from your organization and confirmed with you): + +- **org:** +- **domain:** +- **org_type:** +- **therapeutic_areas:** +- **modalities:** +- **focus:** +- **what_you_track:** + +Example (illustrative, not a real organization): + +- **org:** Alder Therapeutics +- **domain:** aldertx.example +- **org_type:** clinical-stage biotech (with a competitive-intelligence and BD function) +- **therapeutic_areas:** oncology, focused on KRAS-driven solid tumors +- **modalities:** small molecule +- **focus:** the KRAS G12D / G12C competitive set and adjacent RAS-pathway targets +- **what_you_track:** phase transitions and trial readouts, FDA and EMA milestones, and licensing opportunities in adjacent targets diff --git a/skills/parallel-literature-mining/SKILL.md b/skills/parallel-literature-mining/SKILL.md new file mode 100644 index 0000000..06ed60b --- /dev/null +++ b/skills/parallel-literature-mining/SKILL.md @@ -0,0 +1,117 @@ +--- +name: parallel-literature-mining +description: Pull clean, structured data out of papers, trial registries, and regulatory filings, including efficacy, mechanism of action, endpoints, enrollment, and real-world evidence, each field cited to its source. Use when the user wants to "extract the trial data", "pull endpoints and efficacy from this paper/registry", "structure the clinical data for these assets", or mine the literature. Runs on the user's own Parallel account via Extract and Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__claude_ai_Parallel_Web_Search_Paid__web_fetch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Literature Mining + +Pull clean, **structured data** out of the primary sources, papers, trial registries, and +regulatory filings, so an asset's efficacy, mechanism, endpoints, enrollment, and real-world +evidence land as fields instead of PDFs. Every field is cited to the exact source it came from; +a value that isn't in the source comes back empty, never approximated. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`) with the source(s) named, plus + `web_fetch` for a specific page. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-web-extract`** and + **`parallel-data-enrichment`** skills (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its therapeutic-area framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Three quick questions before running (each source mined is a billable run): +1. **Which sources or assets?** A paper / registry entry / filing (URL or ID), or an asset whose data to mine across sources. +2. **Which fields?** Default: mechanism, indication, enrollment, primary endpoint + result, key efficacy, safety signal. Add or drop. +3. **How many now?** Start with a few to check fidelity, then batch. + +Confirm, then run. + +## Run it + +One task per source or asset. Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["asset", "fields"], + "properties": { + "asset": {"type": "string", "description": "the asset / trial the data describes"}, + "fields": { + "type": "object", + "additionalProperties": false, + "properties": { + "mechanism": {"type": "string", "description": "mechanism of action / target"}, + "indication": {"type": "string"}, + "enrollment": {"type": "string", "description": "n, and population"}, + "primary_endpoint": {"type": "string", "description": "the endpoint and its result (with CI if reported)"}, + "key_efficacy": {"type": "string", "description": "headline efficacy readout"}, + "safety_signal": {"type": "string", "description": "notable safety / tolerability finding; empty if none reported"}, + "rwe": {"type": "string", "description": "real-world evidence, if any; empty string if none"} + } + }, + "basis": { + "type": "array", + "description": "one entry per field: the exact source and a confidence", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["field", "source_url", "confidence"], + "properties": { + "field": {"type": "string"}, + "source_url": {"type": "string", "description": "resolving source (paper, registry, filing); must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + } + } +} +``` + +Prompt (substitute the source / asset): + +> Extract structured clinical data for {ASSET_OR_SOURCE}: mechanism of action, indication, +> enrollment (n and population), primary endpoint and its result (include the confidence +> interval if reported), headline efficacy, any notable safety signal, and any real-world +> evidence. Prefer ClinicalTrials.gov, the primary publication (PubMed / journal), and FDA/EMA +> documents. Cite the exact resolving source for every field and give a 0-100 confidence. Never +> approximate or infer a number, if a value isn't stated in a reachable source, return an empty +> string. Report results verbatim as stated (e.g. "ORR 41%, 95% CI 34-48"). + +**Read it:** it's a clean data row per asset, each figure clickable back to the paper or +registry that stated it. Treat empty fields as "not reported in source," and never let a +rounded or inferred number stand in for a cited one. + +## Config seams (build on top) + +1. **Input:** a source (URL / ID) or an asset to mine across sources; run one task each. +2. **Fields:** edit the `fields` object to your data model (add secondary endpoints, dosing, biomarker, comparator). +3. **Verbatim rule:** keep results as stated with units and CIs; don't normalize away precision. +4. **Tier:** `core2x` default (extraction fidelity from dense filings); `core` for a lighter pass (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Extract via the +Extract endpoint for clean source text; structure via Task (`POST /v1/tasks/runs` with +`task_spec.output_schema`, then `GET /v1/tasks/runs/{run_id}/result`; citations in +`output.basis`). Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw +control. + +## Next + +- Do this across a whole competitive set → **competitive-landscape**. +- Watch for the next readout to mine → **pipeline-monitoring**. +- Write it up into a full report → **landscape-deep-research**. diff --git a/skills/parallel-org-chart/SKILL.md b/skills/parallel-org-chart/SKILL.md new file mode 100644 index 0000000..1e957c9 --- /dev/null +++ b/skills/parallel-org-chart/SKILL.md @@ -0,0 +1,116 @@ +--- +name: parallel-org-chart +description: Build a structured, source-cited org chart for a company or a department, the people, exact titles, reporting lines, seniority, and likely deal roles, so you can see who to reach and who reports to whom. Use when the user wants to "build an org chart", "map the engineering org", "who reports to whom at X", "who are the decision makers", or multithread an account. Runs on the user's own Parallel account via Task deep research. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Org Chart + +Build a **structured, cited org chart** for a company or a single department: the people, their +exact titles, the reporting lines, seniority, and which of them map to buying roles for your +deal. It's the deep version of the quickstart's buying committee, a multi-level map you can +render as a tree and multithread against, instead of a one-line shortlist. Every person resolves +to a source; a reporting line is set only when a public source states it, never inferred. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill + (`parallel-cli skills install`). + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its ICP / what-you-sell framing (captured once at setup) to decide +which org to map and which roles count as the buying committee, don't re-ask it; only get the +per-run specifics below. + +Three quick questions before running (a deep org map is a billable run): +1. **Which company, and which org?** A domain, and the department to map (default: Engineering, since that's usually where the technical buyer sits). +2. **How deep?** How many levels down from the top of that org (default: through front-line managers). +3. **Watch it after?** Whether to set a monitor for changes to the chart (new hires, departures, reporting shifts), see `parallel-signal-monitoring`. + +Confirm, then run. + +## Run it + +Deep research warrants a higher tier, default `pro` here (a wrong reporting line sends a rep to +the wrong person). Substitute the company + org. Poll `getStatus`, then read with +`getResultMarkdown`. + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["company", "org", "people"], + "properties": { + "company": {"type": "string"}, + "org": {"type": "string", "description": "the department/org mapped, e.g. Engineering"}, + "people": { + "type": "array", + "description": "the org, top-down; empty array if nothing can be sourced, never invented", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["person_name", "title", "reports_to", "source_url", "confidence"], + "properties": { + "person_name": {"type": "string"}, + "title": {"type": "string", "description": "exact current title"}, + "department": {"type": "string"}, + "reports_to": {"type": "string", "description": "name/title of the manager ONLY if a public source states it; else an empty string. Never inferred, never the literal 'null'"}, + "seniority": {"type": "string", "enum": ["c_level", "vp", "director", "manager", "ic", "unknown"]}, + "role_in_deal": {"type": "string", "enum": ["champion", "economic_buyer", "influencer", "technical_evaluator", "blocker", "none"], "description": "likely role for this deal; 'none' if not a buyer"}, + "linkedin_url": {"type": "string", "description": "the person's LinkedIn; empty string if not found"}, + "source_url": {"type": "string", "description": "resolving source backing name + title (and the reporting line, if set); must load"}, + "confidence": {"type": "integer", "description": "0-100; low>=75, medium>=85, high>=95"} + } + } + } + } +} +``` + +Prompt (substitute the domain, org, depth): + +> Build an org chart for {COMPANY_DOMAIN}'s {ORG} organization, from the top of that org down +> through {DEPTH} (e.g. front-line managers). For each person return: name, exact current title, +> department, who they report to, seniority, and LinkedIn. Set reports_to only when a public +> source states the reporting line, else an empty string, never infer it. Flag each person's +> likely role in a {WHAT_YOU_SELL} deal (champion, economic buyer, technical evaluator, +> influencer, blocker, or none). Cite a resolving source URL and a 0-100 confidence for every +> person. Never invent a person, a title, a reporting line, or a source; if you can't verify +> someone, leave them out rather than guess, and use an empty string for any blank field, never +> the word "null". Prefer a smaller correct chart over a padded speculative one. + +**Read it:** render it top-down, C-level to VPs to directors to managers, with reporting lines +where they're sourced and the deal roles highlighted (champion and economic buyer first). An +empty `reports_to` means the reporting line wasn't on a public source, not that the person has no +manager, treat it as a gap to confirm, not a fact. To put a UI on top, hand the `people` array to +Claude and ask it to render the hierarchy. + +## Config seams (build on top) + +1. **Input:** the company + the org to map; run one per account, or batch your target list. +2. **Depth:** how many levels down (whole org vs just the leadership layer). +3. **Deal roles:** the `role_in_deal` mapping keys off what you sell (from the workspace `PROFILE.md` file); edit the enum to your motion. +4. **Tier:** `pro` default for a real chart; `core2x` for a lighter or higher-volume pass (see the tier guidance in this skill). +5. **Keep it live:** pair with **signal-monitoring** to watch the chart for new hires, departures, and reporting-line changes. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with a `pro` processor and `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations and confidence in `output.basis`. Auth +via `x-api-key`, server-side only. Hardcoding means you own keeping it current, prefer the MCP/CLI. + +## Next + +- Just need who to reach + why now, fast → **gtm-quickstart** (the light version). +- Watch the chart for changes → **signal-monitoring** (new hires, departures, reporting shifts). +- Full pre-meeting brief on the account → **account-briefs**. diff --git a/skills/parallel-pipeline-monitoring/SKILL.md b/skills/parallel-pipeline-monitoring/SKILL.md new file mode 100644 index 0000000..60209dd --- /dev/null +++ b/skills/parallel-pipeline-monitoring/SKILL.md @@ -0,0 +1,92 @@ +--- +name: parallel-pipeline-monitoring +description: Watch the drugs, programs, and competitors you care about and get alerted the moment something material changes, trial readouts, phase transitions, FDA and EMA approvals, guidance, and commercialization events, deduped and cited. Use when the user wants to "monitor this drug/program", "alert me on readouts or approvals", "watch my competitors' pipelines", or set up pipeline surveillance. Runs on the user's own Parallel account via Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(curl:*) +metadata: + author: parallel +--- + +# Pipeline Monitoring + +Watch the drugs, programs, and competitors you care about and get alerted the moment something +material changes, a trial readout, a phase transition, an FDA or EMA approval, a guidance +update, or a commercialization event. Dedup is handled, so you only hear about real events, and +each is structured and cited so it can route straight to the analyst or team who owns the +program. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **CLI / build-on-top:** the installed **`parallel-monitor`** skill (`parallel-cli skills + install`) is the maintained path. +- Monitor is the stable `v1` API; the raw endpoint is included below for pipelines. + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its focus / tracking framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Before creating monitors (each is a recurring, billable watch): +1. **Which programs?** The drugs, targets, or companies to watch (one monitor per program, or per competitor). +2. **Which events?** Default: trial readout, phase transition, FDA/EMA approval, guidance, commercialization. Trim to what you act on. +3. **Cadence?** Daily (`1d`) is the usual default; go tighter around a known catalyst window. + +Confirm, then create. + +## Run it + +The shape that works: run **one broad monitor per program** (or per competitor) and classify +the event downstream, not one monitor per event type. It's far cheaper per record and dedups +cleanly. A monitor runs on a schedule, catches new matches, and returns structured output. + +Output shape per detected event: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["event_type", "asset", "summary", "event_date", "source_url"], + "properties": { + "event_type": {"type": "string", "enum": ["trial_readout", "phase_transition", "regulatory_approval", "regulatory_action", "guidance", "commercialization", "other"]}, + "asset": {"type": "string", "description": "the drug / program / company the event concerns"}, + "summary": {"type": "string", "description": "one-line factual summary of what changed"}, + "event_date": {"type": "string", "description": "ISO 8601 date"}, + "route_to": {"type": "string", "description": "who/what this should route to, e.g. the program lead"}, + "source_url": {"type": "string", "description": "resolving source (ClinicalTrials.gov, FDA/EMA, company release); must load"} + } +} +``` + +Query per program (substitute): + +> Notify me whenever {PROGRAM} has a concrete, sourced event: a trial readout, a phase +> transition, an FDA or EMA approval or regulatory action, a guidance update, or a +> commercialization milestone. Give a one-line summary, the date, and a resolving source +> (ClinicalTrials.gov, an FDA/EMA record, or the company release). Prioritize named, dated, +> sourced facts; exclude rumor and pre-readout speculation. + +## Config seams (build on top) + +1. **Programs:** one monitor per drug / program / competitor you're tracking (loop your list). +2. **Event types:** edit the `event_type` enum + the query to what you act on. +3. **Cadence:** daily (`1d`) is the usual default; tighten around a catalyst window, cadence + controls latency, not how much you catch. +4. **Routing:** `route_to` + an optional webhook push each event into your workflow. +5. **Processor:** `lite` is the cheap forward-watch default; `base` for heavier scans. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ `POST /v1/monitors` +(`type: event_stream`, `frequency`, `processor`, `settings.query`, `settings.output_schema`), +read hits at `GET /v1/monitors/{id}/events`, optional `webhook` to push. `event_stream` only +catches change **going forward**, seed current pipeline state with a Task first if you need +history now. Auth via `x-api-key`, same key creates and reads. + +## Next + +- Map the whole competitive set you're watching → **competitive-landscape**. +- Feed new programs in from **licensing-discovery**. +- Pull the readout's clinical data into structured fields → **literature-mining**. diff --git a/skills/parallel-platform-web-access/SKILL.md b/skills/parallel-platform-web-access/SKILL.md new file mode 100644 index 0000000..5b8e99e --- /dev/null +++ b/skills/parallel-platform-web-access/SKILL.md @@ -0,0 +1,85 @@ +--- +name: parallel-platform-web-access +description: Give every app built on your platform live-web access, search, research, and monitoring, through one integration through one integration, instead of a retrieval stack each of your users has to wire up themselves. Use when the user runs an app builder, agent platform, or codegen product and wants to "add web search to my platform", "let user apps research and monitor the web", or offer grounded retrieval as a feature. Runs on the user's own Parallel account via Search, Task, and Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), Bash(curl:*), ToolSearch, mcp__claude_ai_Parallel_Web_Search_Paid__web_search, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Platform Web Access + +If you run an app builder, an agent platform, or a codegen product, this is the pattern for +giving **every app your users build** live-web access, search, research, and monitoring, +through **one integration** you own, instead of a retrieval stack each user has to wire up +themselves. Same primitives as the other code skills, exposed as a capability your platform +offers, with the honesty and citation guarantees passed straight through to the end app. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +This skill is build-on-top by nature, you're embedding Parallel into your product. Ride the +maintained surfaces so API changes are absorbed on update: +- **Search** (`web_search`) for retrieval, **Task** (`createTaskGroup`) for structured + research, **Monitor** for ongoing watches, all under one Parallel account (yours), scoped + per end-user in your own layer. +- **CLI / skills:** `parallel-cli skills install` gives you the reference implementations to + adapt (`parallel-web-search`, `parallel-deep-research`, `parallel-monitor`). + +The raw HTTP API is below for the server-side integration you'll actually ship. Not set up yet? +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its product type and integration framing (captured once at +setup), don't re-ask it; only get the per-run specifics below. + +Three quick questions before wiring it in: +1. **Which capabilities?** Search, research (Task), monitoring, or all three, exposed to the apps your users build. +2. **How is it called?** Per end-user request at runtime, at build time, or both. +3. **How do you meter it?** How you attribute and cap usage per end-user against your one Parallel account. + +Confirm, then wire the reference calls below. + +## Run it + +Expose the three primitives behind your own thin API, one Parallel account, per-user scoping in +your layer. Reference calls: + +- **Search** (an end app asks a live-web question): + + > Answer {END_USER_QUERY} from current, authoritative sources; return ranked results with a + > resolving URL per claim; if it isn't on a reachable source, say so. + +- **Research (Task)** (an end app needs a structured, cited answer): use the + `parallel-doc-grounded-review` or `parallel-tech-deep-research` shapes, called server-side with the end-user's + input substituted. + +- **Monitor** (an end app wants a standing watch): create one Monitor per watch the end-user + sets up, using the `parallel-dependency-monitoring` shape; route events back to that user. + +Pass the **citation and honesty guarantees straight through**: the end app should show the same +resolving sources and the same "not found" over a guess. That is the feature you're reselling, +don't strip it in your wrapper. + +## Config seams (build on top) + +1. **Capability surface**: which of Search / Task / Monitor you expose, and the shapes you standardize on. +2. **Per-user scoping**: attribute, rate-limit, and cap usage per end-user against your single account. +3. **Metering**: map Parallel usage to your own billing / quotas. +4. **Passthrough**: surface citations and confidence to the end app; keep the honesty gate intact. +5. **Tier**: pick per capability: Search for lookups, `core` Task for research, `lite` Monitor for watches (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Search `POST +/v1/search`; Task `POST /v1/tasks/runs` + `GET /v1/tasks/runs/{run_id}/result` (citations in +`output.basis`); Monitor `POST /v1/monitors` + `GET /v1/monitors/{id}/events` (optional +`webhook`). One `x-api-key` (yours), server-side; scope per end-user in your own layer. This is +the one skill you *do* build against the API directly, so track the dated endpoints here. + +## Next + +- Standardize the research shape you expose → **doc-grounded-review** or **tech-deep-research**. +- Standardize the watch shape you expose → **dependency-monitoring**. +- Resolve current versions for generated apps → **current-scaffolding**. diff --git a/skills/parallel-portfolio-monitoring/SKILL.md b/skills/parallel-portfolio-monitoring/SKILL.md new file mode 100644 index 0000000..0674376 --- /dev/null +++ b/skills/parallel-portfolio-monitoring/SKILL.md @@ -0,0 +1,89 @@ +--- +name: parallel-portfolio-monitoring +description: Watch your positions, targets, and markets and get alerted the moment something material changes, regulatory filings, leadership changes, earnings signals, M&A, and competitor activity, deduped so you only hear about material changes. Use when the user wants to "monitor my portfolio", "alert me when X files or changes", "watch these targets", or set up market surveillance. Runs on the user's own Parallel account via Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(curl:*) +metadata: + author: parallel +--- + +# Portfolio Monitoring + +Watch your positions and targets and get alerted the moment something material changes, a +regulatory filing, a leadership change, an earnings signal, an M&A event, or a competitor +move. Dedup is handled, so you only hear about material changes, and each signal is structured +and cited so it can route straight to the analyst who owns the name. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **CLI / build-on-top:** the installed **`parallel-monitor`** skill (`parallel-cli skills + install`) is the maintained path. +- Monitor is the stable `v1` API; the raw endpoint is included below for pipelines. + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its mandate / coverage framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Before creating monitors (each is a recurring, billable watch): +1. **Which names?** The positions or targets to watch (one monitor per name, or one per market). +2. **Which signals?** Default: regulatory filings, leadership changes, earnings signals, M&A, competitor activity. Trim to what you act on. +3. **Cadence?** Daily (`1d`) is the usual default; go hourly only for names where latency matters. + +Confirm, then create. + +## Run it + +The shape that works: run **one broad monitor per name** (or per market) and classify the +signal downstream, not one monitor per signal type. It's far cheaper per record and dedups +cleanly. A monitor runs on a schedule, catches new matches, and returns structured output. + +Output shape per detected signal: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["signal_type", "summary", "signal_date", "source_url"], + "properties": { + "signal_type": {"type": "string", "enum": ["regulatory_filing", "leadership_change", "earnings_signal", "m_and_a", "financing", "competitor_move", "other"]}, + "company": {"type": "string"}, + "summary": {"type": "string", "description": "one-line factual summary of what changed"}, + "signal_date": {"type": "string", "description": "ISO 8601 date"}, + "route_to": {"type": "string", "description": "who/what this should route to, e.g. the analyst who owns the name"}, + "source_url": {"type": "string", "description": "resolving source; must load"} + } +} +``` + +Query per name (substitute): + +> Notify me whenever {COMPANY} shows a concrete, sourced material change: a regulatory filing +> (8-K, S-1, 13D/G, or equivalent), a leadership change, an earnings or guidance signal, an +> M&A event, a financing, or a notable competitor move. Prioritize named, dated, sourced +> facts. Exclude rumor and generic commentary. + +## Config seams (build on top) + +1. **Names**: one monitor per position or target you're tracking (loop your list). +2. **Signal types**: edit the `signal_type` enum + the query to what you act on. +3. **Cadence**: daily (`1d`) is the usual default; hourly costs ~24x for the same volume over + a day, cadence controls latency, not how much you catch. +4. **Routing**: `route_to` + an optional webhook push each signal into your workflow. +5. **Processor**: `lite` is the cheap forward-watch default; `base` for heavier scans. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ `POST /v1/monitors` +(`type: event_stream`, `frequency`, `processor`, `settings.query`, `settings.output_schema`), +read hits at `GET /v1/monitors/{id}/events`, optional `webhook` to push. `event_stream` only +catches change **going forward**, seed a populated feed with a Task first if you need history +now. Auth via `x-api-key`, same key creates and reads. + +## Next + +- Pair with **company-profiles** so a fresh signal arrives against an up-to-date profile. +- Feed new names in from **target-discovery**. +- Turn a recurring compliance watch into **kyb-kyc** (continuous screening on counterparties). diff --git a/skills/parallel-productivity-quickstart/SKILL.md b/skills/parallel-productivity-quickstart/SKILL.md new file mode 100644 index 0000000..d05268d --- /dev/null +++ b/skills/parallel-productivity-quickstart/SKILL.md @@ -0,0 +1,74 @@ +--- +name: parallel-productivity-quickstart +description: Connect Parallel (if needed) and get a fresh, source-cited answer to any question with clean, quotable source text, fast enough to run in a product's request path. Use when the user asks to "answer this with current facts", "what's the latest on X", "give me a cited answer", or wants the Parallel productivity quickstart. Runs on the user's own Parallel account via Search and Extract. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__claude_ai_Parallel_Web_Search_Paid__web_search, mcp__claude_ai_Parallel_Web_Search_Paid__web_fetch +metadata: + author: parallel +--- + +# Productivity Quickstart + +The fastest way to see Parallel ground an assistant: ask any question and get back a **fresh, +cited answer** with clean, quotable source text, instead of stale training data. Fast enough to +run in the request path, so it can sit inline in a chat answer or a doc. Nothing is invented: if +the answer isn't on a reachable source, it says so. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Parallel Web Search** tool (`web_search`, `web_fetch`). +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-web-search`** and + **`parallel-web-extract`** skills (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its product / surfaces framing (captured once at setup) to bias +toward the entities and topics your product touches, don't re-ask it; only get the per-run +specifics below. + +Two quick questions before running (a search costs credits): +1. **The question?** The user question to answer, phrased the way it comes into your product. +2. **In the request path?** If a user is waiting inline, keep the latency budget low; if it's async, you can go deeper. + +Confirm, then run. + +## Run it + +Issue the search with the question as the objective. Read the ranked results; if the excerpts +answer it, answer from them, only `web_fetch` a URL when you need exact wording to quote. + +Example objective: + +> What industry changes are likely to have a major impact on the outcome of this project? +> Return the two or three most material, current trends with a one-line takeaway each and a +> resolving source URL, and pull a short quotable excerpt for each. Prefer recent, authoritative +> sources. If a claim isn't on a reachable source, leave it out rather than guessing. + +**Read it:** give the answer in one or two lines, then the cited trends with their quotable +excerpts, each clickable to the source. The citation and the quote are what make it safe to show +a user inline, keep them attached. + +## Config seams (build on top) + +1. **The objective:** the user question; this is the whole input. Seed context from the workspace `PROFILE.md` file. +2. **Latency:** the Search / Responses path is latency-budgeted (`low` / `medium` / `high`); use `low` for sub-2s inline answers, higher for async depth (see the tier guidance in this skill). +3. **Quote handling:** keep the extracted quote + source so your product can cite word-for-word. +4. **Fetch only when needed:** answer from ranked excerpts by default; `web_fetch` for exact quotes or full-page reads. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Search API: `POST +/v1/search` (objective + latency budget), returns ranked results with excerpts and URLs; `POST +/v1/extract` for clean quotable page text. Auth via `x-api-key`, server-side only. Hardcoding +means you own keeping it current, prefer the MCP/CLI. + +## Next + +- Enrich the entities in the answer → **entity-context**. +- Turn a big question into a full report → **in-product-research**. +- Keep the answer current over time → **knowledge-freshness**. diff --git a/skills/parallel-productivity-setup/SKILL.md b/skills/parallel-productivity-setup/SKILL.md new file mode 100644 index 0000000..f2eb156 --- /dev/null +++ b/skills/parallel-productivity-setup/SKILL.md @@ -0,0 +1,63 @@ +--- +name: parallel-productivity-setup +description: Connect a user's Parallel account and route productivity workflows to the matching skill. Use this first, or when the user says "set up Parallel", "get me started", or isn't sure which use case they need. +allowed-tools: Bash(command:*), Bash(claude:*), Bash(parallel-cli:*), Bash(script:*), Bash(git:*) +metadata: + author: parallel +--- + +# Productivity Setup + +Get connected once, then get pointed to the right use case. Everything runs on the user's own +Parallel account, no key is pasted. + +## 1. Ask what they want to do first (route before installing) + +Don't install or run anything yet. Ask one orienting question and route to the matching skill, +so the first thing they do is the thing they came for: + +> **What do you want to do first?** +> - **Answer a question with fresh, cited facts** → `parallel-productivity-quickstart` +> - **Add real-world background to a person, company, or topic** → `parallel-entity-context` +> - **Ship an in-product research feature** → `parallel-in-product-research` +> - **Keep a feed or knowledge base current** → `parallel-knowledge-freshness` +> - **Act on a change across the workspace** → `parallel-workspace-agent` + +If they're unsure, start with `parallel-productivity-quickstart`, it's the fastest to value. + +## 2. Pick the surface and connect (once) + +**Non-technical (co-work / chat): just want output:** +Connect the Task MCP and run the use case in chat. See the `parallel-task-mcp-setup` skill. + +**Technical (build on top):** +Run the `parallel-cli-setup` skill to install and authenticate the CLI. Clone the repository only when the user wants to work from the source: + +```bash +git clone https://github.com/parallel-web/parallel-agent-skills +``` + +> If a call returns `401 Invalid API key`, a stale `PARALLEL_API_KEY` in your shell is +> overriding the login, run `unset PARALLEL_API_KEY` and retry. + +## 3. Capture the productivity profile once + +So the user doesn't re-enter their context on every run, capture what *they* build here, once: + +1. Ask: **what are you building, and where does research show up in it?** (domain + product type + surfaces). +2. Research the product on Parallel (a quick lookup) and infer the product type, the surfaces + where research appears, the entities it touches, and its latency needs. **Show the user what + you found and let them correct it, never assume**, a wrong guess on the first run is the thing + that loses trust. +3. Write the confirmed result to `PROFILE.md` in the current workspace, + using the shape in [references/PROFILE.example.md](references/PROFILE.example.md). `PROFILE.md` is gitignored, so their details + stay local. + +Every use-case skill reads `PROFILE.md` and uses that product / surfaces / latency framing, so +from here the user only supplies the per-run target (which question, entity, or objective), not +their whole context each time. This is optional, skip it and each skill will just ask per-run. + +## 4. Hand off to the chosen use case + +Open that use case's `SKILL.md` and follow its guided intake (each one asks 1-3 questions and +confirms before anything billable runs). The use-case skills carry the build logic; this setup connects your account and chooses the next skill. diff --git a/skills/parallel-productivity-setup/references/PROFILE.example.md b/skills/parallel-productivity-setup/references/PROFILE.example.md new file mode 100644 index 0000000..ca51596 --- /dev/null +++ b/skills/parallel-productivity-setup/references/PROFILE.example.md @@ -0,0 +1,25 @@ +# Your productivity profile + +Captured once during setup (`parallel-productivity-setup`) and read by every skill, so you +don't re-enter your context on every run. Setup writes this to `PROFILE.md` (which is gitignored, +your details stay local and are never committed). Edit it anytime. + +Fill these in (setup does it for you, inferred from your product and confirmed with you): + +- **product:** +- **domain:** +- **product_type:** +- **surfaces:** +- **entities:** +- **latency_need:** +- **keep_current:** + +Example (illustrative, not a real product): + +- **product:** Cadence AI +- **domain:** cadence.example +- **product_type:** AI assistant / workspace with meeting notes +- **surfaces:** inline chat answers, auto-generated meeting briefs, and a per-account live feed +- **entities:** the companies and people in a user's accounts and calendar +- **latency_need:** sub-2s for inline answers; async for meeting briefs and feed updates +- **keep_current:** job changes, fundraises, and major announcements for the companies each user tracks diff --git a/skills/parallel-regulatory-monitoring/SKILL.md b/skills/parallel-regulatory-monitoring/SKILL.md new file mode 100644 index 0000000..10978b3 --- /dev/null +++ b/skills/parallel-regulatory-monitoring/SKILL.md @@ -0,0 +1,91 @@ +--- +name: parallel-regulatory-monitoring +description: Watch regulators, courts, and lists and get alerted the moment something changes, a new rule or rulemaking, an enforcement action, a docket/filing update, a sanctions or watchlist change, deduped so you only hear about real changes and each one structured and cited so it can route to the right person. Use when the user wants to "monitor for new regulations", "alert me when X files/gets sued/gets sanctioned", "track this docket", or set up change-based legal alerts. Runs on the user's own Parallel account via Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(curl:*) +metadata: + author: parallel +--- + +# Regulatory Monitoring + +Watch the sources that matter, regulators, courts, official registries, sanctions lists, and +get alerted the moment something changes: a new rule or rulemaking, an enforcement action, a +docket or filing update, a sanctions/watchlist change. Dedup is handled, so you only hear +about real changes, and each event is structured and cited so it can route straight to the +right attorney or workflow. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **CLI / build-on-top:** the installed **`parallel-monitor`** skill (`parallel-cli skills + install`) is the maintained path. +- Monitor is the stable `v1` API; the raw endpoint is included below for pipelines. + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its jurisdiction / priority framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Before creating monitors (each is a recurring, billable watch): +1. **Watch what?** The entities, dockets, regulators, or topics to track (one monitor per subject or per source). +2. **Which changes?** Default: new rules/rulemaking, enforcement actions, docket/filing updates, sanctions/watchlist changes. Trim to what you act on. +3. **Cadence?** Daily (`1d`) is the usual default; move to hourly only where latency matters (e.g. a live docket). + +Confirm, then create. + +## Run it + +The shape that works: run **one broad monitor per subject** (an entity, a docket, a regulator +feed) and classify the change downstream, not one monitor per change type. It's far cheaper +per record and dedups cleanly. A monitor runs on a schedule, catches new matches going +forward, and returns structured output. + +Output shape per detected change: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["change_type", "summary", "change_date", "source_url"], + "properties": { + "change_type": {"type": "string", "enum": ["new_rule", "rulemaking", "enforcement_action", "docket_update", "new_filing", "sanctions_change", "regulatory_guidance", "other"]}, + "subject": {"type": "string", "description": "the entity, docket, or topic this monitor watches"}, + "summary": {"type": "string", "description": "one-line factual summary of what changed"}, + "change_date": {"type": "string", "description": "ISO 8601 date"}, + "route_to": {"type": "string", "description": "who/what this should route to, e.g. the responsible attorney or matter"}, + "source_url": {"type": "string", "description": "resolving source; must load (regulator page, docket, official list)"} + } +} +``` + +Query per subject (substitute): + +> Notify me whenever {SUBJECT} has a concrete, sourced change: a new rule or rulemaking, an +> enforcement action, a docket or filing update, a change to its sanctions/watchlist status, +> or new regulatory guidance. Prioritize named, dated, officially-sourced changes from the +> regulator, court, or official list. Exclude commentary, rumor, and secondary summaries. + +## Config seams (build on top) + +1. **Subjects**: one monitor per entity, docket, or regulator feed you're tracking (loop your list). +2. **Change types**: edit the `change_type` enum + the query to what you act on. +3. **Cadence**: daily (`1d`) is the usual default; hourly costs ~24x for the same volume + over a day, cadence controls latency, not how much you catch. Use hourly only for live dockets. +4. **Routing**: `route_to` + an optional webhook push each change into your matter system. +5. **Processor**: `lite` is the cheap forward-watch default; `base` for heavier scans. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ `POST /v1/monitors` +(`type: event_stream`, `frequency`, `processor`, `settings.query`, `settings.output_schema`), +read hits at `GET /v1/monitors/{id}/events`, optional `webhook` to push. `event_stream` only +catches change **going forward**, seed the current state with a Task first if you need it now. +Auth via `x-api-key`, same key creates and reads. + +## Next + +- Pair with **entity-diligence** so a fresh change arrives already attached to a tear sheet. +- Feed subjects in from **exposure-discovery** (monitor the whole population). +- On a triggered change, pull the primary text → **source-grounded-research**. diff --git a/skills/parallel-signal-monitoring/SKILL.md b/skills/parallel-signal-monitoring/SKILL.md new file mode 100644 index 0000000..825bd63 --- /dev/null +++ b/skills/parallel-signal-monitoring/SKILL.md @@ -0,0 +1,87 @@ +--- +name: parallel-signal-monitoring +description: Watch your target accounts (or the open web) and get alerted the moment something noteworthy changes, new exec hires, funding rounds, product launches, job postings, competitive moves, deduped so you only hear about significant changes. Use when the user wants to "monitor my accounts", "alert me when X happens", "watch for buying signals", or set up signal-based outbound. Runs on the user's own Parallel account via Monitor. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(curl:*) +metadata: + author: parallel +--- + +# Signal Monitoring + +Watch your target accounts and get alerted the moment something noteworthy changes, a new +exec hire, a funding round, a product launch, a job posting, a competitive move. Dedup is +handled, so you only hear about significant changes, and each signal is structured and cited +so it can route straight to the right rep. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **CLI / build-on-top:** the installed **`parallel-monitor`** skill (`parallel-cli skills + install`) is the maintained path. +- Monitor is the stable `v1` API; the raw endpoint is included below for pipelines. + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its company / ICP / value framing (captured once at setup), don't re-ask it; only get the per-run specifics below. + +Before creating monitors (each is a recurring, billable watch): +1. **Which accounts?** The list to watch (one monitor per account). +2. **Which signals?** Default: exec hires, funding, launches, job postings, competitive moves. Trim to what your reps act on. +3. **Cadence?** Daily (`1d`) is the usual default. + +Confirm, then create. + +## Run it + +The shape that works: run **one broad monitor per account** (or per market) and classify the signal downstream, +not one monitor per signal type. It's far cheaper per record and dedups cleanly. A monitor +runs on a schedule, catches new matches, and returns structured output. + +Output shape per detected signal: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["signal_type", "summary", "signal_date", "source_url"], + "properties": { + "signal_type": {"type": "string", "enum": ["exec_hire", "funding", "product_launch", "job_posting", "competitive_move", "expansion", "other"]}, + "account": {"type": "string"}, + "summary": {"type": "string", "description": "one-line factual summary of what changed"}, + "signal_date": {"type": "string", "description": "ISO 8601 date"}, + "route_to": {"type": "string", "description": "who/what this should route to, e.g. the account owner"}, + "source_url": {"type": "string", "description": "resolving source; must load"} + } +} +``` + +Query per account (substitute): + +> Notify me whenever {ACCOUNT} shows a concrete, sourced buying signal: a new executive +> hire, a funding round, a product launch, a notable job posting, a competitive move, or an +> expansion. Prioritize named, dated, sourced facts. Exclude rumor and generic posts. + +## Config seams (build on top) + +1. **Accounts**: one monitor per account you're tracking (loop your list). +2. **Signal types**: edit the `signal_type` enum + the query to what your reps act on. +3. **Cadence**: daily (`1d`) is the usual default; hourly costs ~24x for the same volume + over a day, cadence controls latency, not how much you catch. +4. **Routing**: `route_to` + an optional webhook push each signal into your pipeline. +5. **Processor**: `lite` is the cheap forward-watch default; `base` for heavier scans. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ `POST /v1/monitors` +(`type: event_stream`, `frequency`, `processor`, `settings.query`, `settings.output_schema`), +read hits at `GET /v1/monitors/{id}/events`, optional `webhook` to push. `event_stream` only +catches change **going forward**, seed a populated feed with a Task first if you need history +now. Auth via `x-api-key`, same key creates and reads. + +## Next + +- Pair with **account-enrichment** so a fresh signal arrives already enriched. +- Feed new accounts in from **lead-discovery**. diff --git a/skills/parallel-source-grounded-research/SKILL.md b/skills/parallel-source-grounded-research/SKILL.md new file mode 100644 index 0000000..4b51bdd --- /dev/null +++ b/skills/parallel-source-grounded-research/SKILL.md @@ -0,0 +1,131 @@ +--- +name: parallel-source-grounded-research +description: Answer a legal question grounded in live authoritative sources, statutes, regulations, case law, agency guidance, including hard-to-crawl government, court, and international domains, with clean extracted text you can quote word-for-word and a resolving source for every passage. Use when the user wants to "find the actual statute/rule/case", "what does the regulation say", "cite the primary source", or research the law rather than a summary. Runs on the user's own Parallel account via Search + Extract. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(curl:*) +metadata: + author: parallel +--- + +# Source-Grounded Research (Search + Extract) + +Ask a legal question, get an answer built from the **primary sources themselves**, not a +model's stale memory of them. Parallel's retrieval reaches the authoritative and +hard-to-crawl corners (regulator sites, court dockets, government registries, international +and non-English domains) and extracts clean text you can **quote word-for-word**, with a +resolving source behind every passage. When the source can't be found, that's the answer, no +paraphrase stands in for a citation. + +This is the distinctive legal use case: the value is in *grounding on the real source and +quoting it exactly*, so feedback and drafting rest on what the law actually says. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +- **CLI / build-on-top:** the installed **`parallel-web-search`** and **`parallel-web-extract`** + skills (`parallel-cli skills install`) are the maintained path. Search finds and ranks the + authoritative sources; Extract pulls clean, quotable text from the exact pages. +- **Chat / co-work:** the Parallel Web Search MCP exposes the same `web_search` / `web_fetch`. + +If Parallel is not configured, run the relevant setup skill first. See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its jurisdiction framing (captured once at setup) to scope the search, don't re-ask it; only get the per-run specifics below. + +Before running: +1. **The question** in plain language, name the entity, statute, rule, or matter as precisely as you can. +2. **Jurisdiction + as-of.** Which legal system, and whether you need the currently-in-force version or the text as of a date. The law changes; grounding is only useful if it's the right version. +3. **Need verbatim text?** If you'll quote or draft from it, say so, that routes to Extract for word-for-word passages rather than summaries. + +Confirm, then run. + +## Run it + +The shape that works: **Search to find the authoritative sources, then Extract to pull the +exact text**, and quote from Extract, never from a summary. + +1. **Search** for the authoritative sources (prefer primary: the regulator, the court, the + official code, the registry): + + ``` + parallel-cli search "text of {STATUTE/RULE}, official source, {JURISDICTION}, in force {AS_OF}" --max-results 10 + ``` + + Bias toward `.gov`, official court, and official code domains; treat blogs and secondary + summaries as pointers to the primary source, not the source. + +2. **Extract** the exact pages so you can quote them verbatim: + + ``` + parallel-cli extract "https://" "https://" + ``` + + Pass the objective (the question) so Extract returns the passages that answer it. + +3. **Answer from the extracted text only.** Quote the operative language, attribute each + quote to its resolving URL, and note the version/date. If the primary source can't be + reached, say so and stop, do not substitute a paraphrase for a citation. + +Output shape to hold the answer (so it stays auditable): + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["question", "jurisdiction", "findings", "unresolved"], + "properties": { + "question": {"type": "string"}, + "jurisdiction": {"type": "string"}, + "as_of": {"type": "string", "description": "the version/date the answer reflects; empty if not constrained"}, + "findings": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["point", "quote", "source_url", "source_type"], + "properties": { + "point": {"type": "string", "description": "one line: what this establishes"}, + "quote": {"type": "string", "description": "verbatim text from the source; exact, not paraphrased"}, + "source_url": {"type": "string", "description": "resolving source the quote came from; must load"}, + "source_type": {"type": "string", "enum": ["statute", "regulation", "case_law", "agency_guidance", "official_registry", "docket", "other"]}, + "source_date": {"type": "string", "description": "publication / effective date if shown; empty otherwise"} + } + } + }, + "unresolved": { + "type": "array", + "description": "parts of the question no authoritative source could be found for; empty array if fully sourced", + "items": {"type": "string"} + } + } +} +``` + +**Read it:** each finding is a claim + the exact quote + a source you can open. The +`unresolved` list is not a failure, it's the honest edge of what's sourceable, and in legal +work that boundary is the most important part of the output. + +## Config seams (build on top) + +1. **Source allowlist**: bias Search toward the primary domains for your jurisdiction (the + official code, the regulator, the court system) and down-rank secondary summaries. +2. **Verbatim vs summary**: route to Extract whenever the text will be quoted or drafted + from; Search excerpts are fine for orientation, not for quoting. +3. **As-of / versioning**: thread the effective date through the query so you ground on the + in-force (or point-in-time) version, not whatever ranks highest. +4. **Multi-jurisdiction**: run one Search+Extract pass per jurisdiction and keep the answers + separate; don't let one jurisdiction's text bleed into another's finding. + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Search API: +`POST /v1beta/search` (returns ranked results with excerpts + URLs). Extract / fetch: pull +full clean content from specific URLs for verbatim quoting. Auth via `x-api-key`, server-side +only. Prefer the CLI/MCP so retrieval changes are absorbed on update. + +## Next + +- Turn the sourced facts about an entity into a tear sheet → **entity-diligence**. +- Watch for when the rule or case status changes → **regulatory-monitoring**. +- Roll the research into a full subject brief → **diligence-briefs**. diff --git a/skills/parallel-target-discovery/SKILL.md b/skills/parallel-target-discovery/SKILL.md new file mode 100644 index 0000000..8503ad7 --- /dev/null +++ b/skills/parallel-target-discovery/SKILL.md @@ -0,0 +1,84 @@ +--- +name: parallel-target-discovery +description: Describe your investment or sourcing criteria in plain language and get back a researched, source-cited pipeline of candidate companies, including the long-tail SMB targets not in a stale database export. Use when the user wants to "find companies like X", "build a target list", "find all Y matching Z", or source deals by criteria. Runs on the user's own Parallel account via FindAll. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *) +metadata: + author: parallel +--- + +# Target Discovery (FindAll) + +Describe your criteria in plain language, get back a **researched, cited pipeline of +candidates**, not a stale export. EBITDA or revenue range, vertical, geography, ownership, and +web signals of growth or distress, including the long tail of SMB targets that don't sit in an +existing database. Every match resolves to a source; noise and non-matches are filtered. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +FindAll is exposed through **`parallel-cli findall`** (installed by `parallel-cli skills +install`), this is the maintained path and what you should build on. FindAll is in +**public beta**, so the raw HTTP endpoints can change (30 days' notice); riding the CLI means +Parallel absorbs those changes on update. If Parallel is not configured, run the relevant setup skill first. Check [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its mandate / screening-criteria (captured once at setup), it seeds the criteria so you're not starting blank; confirm-or-tweak rather than re-ask. + +Before the paid run: +1. **Describe your criteria** in plain language, be specific about the entity type, the size band, the geography, and the ownership or signal filters. +2. **How many candidates?** Start around 25 (`-n 25`) to gauge quality, then extend. +3. **Preview first?** Run `ingest` (below) to see the parsed query before paying. + +Confirm, then run. + +## Run it + +Preview the parsed query before you pay: + +``` +parallel-cli findall ingest "" +``` + +Then run and poll results to disk: + +``` +parallel-cli findall run "US and Canadian cold-chain logistics companies, $20-80M EBITDA, founder- or family-owned with no PE sponsor, showing web signals of growth (new facilities, fleet, or headcount)" -g core -n 50 --no-wait --json +parallel-cli findall poll "" -o /tmp/targets.json --timeout 540 +``` + +Add fields to each candidate (optional): + +``` +parallel-cli findall enrich "" '{"properties":{"est_ebitda":{"type":"string"},"ownership":{"type":"string"},"hq_location":{"type":"string"},"growth_signal":{"type":"string"}}}' +``` + +Each candidate returns `name`, `url`, `description`, a `match_status` (`matched` is the +keeper), enriched fields under `output`, and per-field citations under `basis`. + +## Config seams (build on top) + +1. **The objective**: your criteria in plain language. This is the whole input; be specific + about the entity type, the size band, the geography, and the ownership or signal filters. +2. **Generator tier**: `-g core` default, `-g pro` for a comprehensive or sparse universe, + `-g preview` for a fast scan, skip `-g base` for real data. +3. **Count**: `-n` (5 to 1000); start small to gauge quality, then `parallel-cli findall + extend "" 50` for more. +4. **Enrichment fields**: the `properties` you add become columns; keys are yours to define + (est EBITDA, ownership, HQ, growth or distress signal). +5. **Exclude**: `--exclude '[{"name":"...","url":"..."}]'` to skip names already in your CRM. + +## Production (raw HTTP API): beta, verify before hardcoding + +_As of 2026-08; FindAll is public beta, confirm at [docs.parallel.ai](https://docs.parallel.ai)._ +`POST /v1beta/findall/ingest` → `POST /v1beta/findall/entity-search` (fast candidates) or the +full run → `GET /v1beta/findall/runs/{findall_id}/result` (returns `candidates[]` with +`output` + `basis`). Because it's `v1beta`, prefer `parallel-cli findall` so tier/shape changes +don't break your build. + +## Next + +- Profile the pipeline into full tear sheets → **company-profiles**. +- Watch the new names for the right moment → **portfolio-monitoring**. +- Screen a shortlisted target or its owners → **kyb-kyc**. diff --git a/skills/parallel-task-mcp-setup/SKILL.md b/skills/parallel-task-mcp-setup/SKILL.md new file mode 100644 index 0000000..ee22bfb --- /dev/null +++ b/skills/parallel-task-mcp-setup/SKILL.md @@ -0,0 +1,76 @@ +--- +name: parallel-task-mcp-setup +description: Install, authenticate, and verify Parallel Task MCP in Claude Code by running one fast, lightweight Task Group and returning its result. Use when the user asks to connect, activate, test, or smoke-test Parallel Task MCP. +allowed-tools: Bash(command:*), Bash(claude:*), Bash(script:*) +metadata: + author: parallel +--- + +# Parallel Task MCP Setup + +Configure `https://task-mcp.parallel.ai/mcp` and prove it works with one `lite-fast` task. Do not install Parallel CLI, use an API key, create Deep Research, use a local proxy, or provide a backup UI flow. + +## Workflow + +1. Check Claude Code: + + ```bash + command -v claude + claude --version + ``` + + Require version `>=2.1.172`. If Claude is missing or older, report it and stop; do not install or update it. + +2. Add the user-scoped server only if absent: + + ```bash + claude mcp list + claude mcp add --scope user --transport http "Parallel-Task-MCP" https://task-mcp.parallel.ai/mcp + ``` + +3. If the server is not connected, authenticate it in a hidden pseudo-terminal: + + ```bash + command -v script + /usr/bin/script -q /dev/null claude mcp login "Parallel-Task-MCP" + claude mcp list + ``` + + Let Claude open the browser and wait while the user approves access. Proceed only when `claude mcp list` reports `Parallel-Task-MCP` connected. If browser OAuth or `/usr/bin/script` fails, report it and stop. Do not ask the user to use a terminal or another setup path. + +4. Ensure the fresh child Claude process can authenticate: + + ```bash + claude auth status --json + ``` + + If `loggedIn` is not `true`, run: + + ```bash + /usr/bin/script -q /dev/null claude auth login --claudeai + claude auth status --json + ``` + + Wait for browser approval, then require `loggedIn: true`. This Claude login is separate from Parallel OAuth. Do not use Console billing or request an API key. + +5. Run exactly one lightweight Task Group in a fresh child session. Keep the prompt immediately after `-p` because `--allowedTools` consumes trailing arguments: + + ```bash + claude -p \ + "Use only Parallel-Task-MCP. Use ToolSearch if needed. Call createTaskGroup exactly once with exactly one input: United Nations. Use processor lite-fast and request exactly one output field: the founding date in MM-YYYY format. Follow the tool schema exactly. Save the task-group ID. Poll getStatus until terminal; honor a server-provided interval or run sleep 5 between checks. Do not ask the user for another message. On completion, call getResultMarkdown and return the ID, processor, final status, and full result. On failed, cancelled, canceled, or errored status, return the ID, status, and error. Never create Deep Research or a second task." \ + --no-session-persistence \ + --output-format json \ + --allowedTools "ToolSearch,Bash(sleep *),mcp__Parallel-Task-MCP__createTaskGroup,mcp__Parallel-Task-MCP__getStatus,mcp__Parallel-Task-MCP__getResultMarkdown" + ``` + + Keep the child running through polling. Report its ID, processor, final status, and result. Never retry the child automatically because it may already have created the task. + +## After completion + +Tell the user setup is complete. To start another task, they must open a new session in Claude Code, Claude chat, or Cowork so Task MCP loads at session start. Give them this example: + +```text +Use Parallel Task MCP to run this task: . Choose the lightest suitable processor, poll until complete, and return the final result. +``` + +Explain that their agent should handle polling and result retrieval autonomously. Do not start a second task in the setup session. diff --git a/skills/parallel-tech-deep-research/SKILL.md b/skills/parallel-tech-deep-research/SKILL.md new file mode 100644 index 0000000..383355a --- /dev/null +++ b/skills/parallel-tech-deep-research/SKILL.md @@ -0,0 +1,84 @@ +--- +name: parallel-tech-deep-research +description: Commission a structured, source-cited report on a technical decision, a migration path, a framework or library evaluation, an architecture trade-off, with every claim traced to a live source. Use when the user wants to "research this migration", "compare X vs Y for our stack", "should we adopt Z", or wants an engineering-grade cited write-up. Runs on the user's own Parallel account via Deep Research. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createDeepResearch, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Technical Deep Research + +Ask an open technical question, "what's the migration path from X to Y", "Postgres vs a hosted +alternative for our workload", "is this framework safe to adopt", and get back a **structured, +cited report** grounded in current docs, changelogs, RFCs, and real-world issue threads. Every +claim traces to a resolving source, and where the evidence is thin or the community is split, +the report says so instead of picking a side for you. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** `createDeepResearch`. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill + (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its stack framing (captured once at setup) to anchor the report +in your actual libraries and constraints, don't re-ask it. + +Two quick questions before running (deep research is a higher-tier, billable run): +1. **What's the decision?** One sharp question (a migration, a comparison, an adopt / don't). +2. **What must it cover?** Default sections: current state, options, trade-offs, migration effort / risks, and a recommendation. Add or drop. + +Confirm, then run. + +## Run it + +Deep research warrants a higher tier, default `pro` here. Give it the question and the sections +to cover. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +Prompt (substitute your question): + +> Produce a structured technical report answering: "{TECHNICAL_QUESTION}". Cite a resolving +> source URL for every claim, and prefer primary sources (official docs, changelogs, RFCs, +> release notes, and the primary GitHub issue) over blog commentary. Cover, in order: +> +> 1) **Current state:** where each option stands today, with versions and dates. +> 2) **Options:** the real choices, with what each is good and bad at, sourced. +> 3) **Trade-offs:** performance, maintenance, ecosystem maturity, lock-in. +> 4) **Migration effort and risks:** what moving actually takes and what tends to break. +> 5) **Recommendation:** a direct, evidence-weighted call for the stated constraints, with the +> key uncertainties named. +> +> Never invent a version, a benchmark, or a source. Where the evidence is thin or the community +> is split, show both sides rather than resolving it artificially. + +**Read it:** start with the recommendation and the two or three sourced facts that carry it, +then use current-state / options / trade-offs as the support, following the citations on +anything you'd put in an ADR or a migration plan. Where the report flags thin evidence, that's +a spike to run, not a gap to paper over. + +## Config seams (build on top) + +1. **The question**: one sharp technical decision; this is the whole input. +2. **Sections**: edit the section list to your ADR or RFC template (add cost, security, benchmarks). +3. **Tier**: `pro` default for a real report; `core2x` for a quicker read, `ultra` for the highest-stakes calls (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Deep Research runs on +the Task API (stable, `v1`): `POST /v1/tasks/runs` with a deep-research processor and +`task_spec.output_schema`, then `GET /v1/tasks/runs/{run_id}/result`; citations in +`output.basis`. Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw +control. + +## Next + +- Resolve the current versions the report references → **current-scaffolding**. +- Watch the options for changes while you decide → **dependency-monitoring**. +- Review the migration diffs against live docs → **doc-grounded-review**. diff --git a/skills/parallel-thesis-research/SKILL.md b/skills/parallel-thesis-research/SKILL.md new file mode 100644 index 0000000..8b642b2 --- /dev/null +++ b/skills/parallel-thesis-research/SKILL.md @@ -0,0 +1,86 @@ +--- +name: parallel-thesis-research +description: Commission a structured, source-cited research report on any sector, market, or investment question, every claim traced to a source excerpt. Use when the user wants to "research this thesis", "is X an attractive market", "size this market", "write me a deep report on Y", or wants an analyst-grade cited document. Runs on the user's own Parallel account via Deep Research. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__Parallel-Task-MCP__createDeepResearch, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Thesis Research (Deep Research) + +Ask an open question about a sector, a market, or an investment, get back a **structured, +cited report** in minutes. Market size and growth, the drivers, the risks, the players, and a +read on the question you asked, with every claim traced to a resolving source excerpt so it's +auditable. Nothing is fabricated; where the evidence is thin, the report says so instead of +filling the gap. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** `createDeepResearch`. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-deep-research`** skill + (`parallel-cli skills install`). + +If Parallel is not configured, run the relevant setup skill first. +Processor tier guidance: the tier guidance in this skill. + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its mandate framing (captured once at setup) to focus the +report on the sectors, geographies, and size band you care about; don't re-ask it. + +Two quick questions before running (deep research is a higher-tier, billable run): +1. **What's the question?** One clear thesis or market question, the sharper the better (a yes/no or a sizing question beats "tell me about X"). +2. **What must the report cover?** Default sections: market size and growth, drivers, risks, key players, and a verdict on the question. Add or drop. + +Confirm, then run. + +## Run it + +Deep research warrants a higher tier, default `pro` here. Give it the question and the +sections to cover. Poll `getStatus` until complete, then read with `getResultMarkdown`. + +Prompt (substitute your question): + +> Produce a structured research report answering: "{THESIS_OR_MARKET_QUESTION}". Cite a +> resolving source URL for every claim, and prefer primary sources (filings, regulator and +> industry data, company disclosures) over secondary commentary. Cover, in order: +> +> 1) **Market:** size, growth rate, and the segment structure, with figures and periods. +> 2) **Drivers:** what's growing or shrinking demand, sourced. +> 3) **Risks:** the things that would break the thesis (regulatory, cyclical, structural). +> 4) **Players:** who competes, their relative position, and any recent M&A or entrants. +> 5) **Verdict:** a direct, evidence-weighted read on the question, with the key uncertainties +> called out. +> +> Never invent a figure, a source, or a player. Where the evidence is thin or conflicting, say +> so and show both sides rather than resolving it artificially. + +**Read it:** start with the verdict and the two or three figures that carry it, then use the +market / drivers / risks sections as the support, following the citations on anything you'd +put in front of a committee. Where the report flags thin evidence, treat that as a research +to-do, not a gap to paper over. + +## Config seams (build on top) + +1. **The question**: one sharp thesis or market question; this is the whole input. +2. **Sections**: edit the section list to your memo template (add unit economics, comps, a + base/bull/bear, whatever your IC expects). +3. **Tier**: `pro` default for a real report; `core2x` for a quicker read, `ultra` for the + highest-stakes questions (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Deep Research runs on +the Task API (stable, `v1`): `POST /v1/tasks/runs` with a deep-research processor and +`task_spec.output_schema`, then `GET /v1/tasks/runs/{run_id}/result`; citations in +`output.basis`. Auth via `x-api-key`, server-side only. Prefer the CLI/MCP unless you need raw +control. + +## Next + +- Turn the players section into a live list → **target-discovery**. +- Profile the names the report surfaces → **company-profiles**. +- Watch the thesis for the events that would confirm or break it → **portfolio-monitoring**. diff --git a/skills/parallel-underwriting-risk-profiles/SKILL.md b/skills/parallel-underwriting-risk-profiles/SKILL.md new file mode 100644 index 0000000..b6dd974 --- /dev/null +++ b/skills/parallel-underwriting-risk-profiles/SKILL.md @@ -0,0 +1,115 @@ +--- +name: parallel-underwriting-risk-profiles +description: From an address, business, or applicant, build a structured P&C underwriting risk profile drawn from the open web, COPE data (construction, occupancy, protection, exposure), operations, adverse history, and the long tail of fields no database covers, each cited and confidence-scored. Use when the user wants to "underwrite this risk", "build a risk profile for this property/business", "pull COPE data", or triage a submission. Runs on the user's own Parallel account via Task and Extract. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), ToolSearch, mcp__claude_ai_Parallel_Web_Search_Paid__web_fetch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Underwriting Risk Profiles + +Start from an address, a business, or an applicant and receive a structured **P&C risk profile** +drawn from the open web: COPE data (construction, occupancy, protection, exposure), operations, +adverse history, and the long tail of fields no commercial database covers. Every field is cited +to a public record and confidence-scored, so quotes go out faster and submission-to-bind rises +without giving up the audit trail. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two ways to run, both maintained by Parallel so API changes are absorbed for you: +- **Chat / co-work:** the **Task MCP** (`createTaskGroup`), one input per risk. +- **CLI / build-on-top:** `parallel-cli` + the installed **`parallel-web-extract`** and + **`parallel-data-enrichment`** skills (`parallel-cli skills install`). + +Not set up yet? +If Parallel is not configured, run the relevant setup skill first. +See [docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its lines / jurisdictions framing (captured once at setup), don't +re-ask it; only get the per-run specifics below. + +Three quick questions before running (each risk profiled is a billable run): +1. **The risk?** An address, a business (name + location), or an applicant. +2. **Which fields?** Default is COPE + operations + adverse history. Add the long-tail fields your line needs (distance to coast, roof age, prior losses). +3. **Run how many now?** Start with a few to check quality, then batch the submission queue. + +Confirm, then run. + +## Run it + +One task per risk. Output shape: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["risk", "fields"], + "properties": { + "risk": {"type": "string", "description": "the address / business / applicant profiled"}, + "fields": { + "type": "object", + "additionalProperties": false, + "properties": { + "construction": {"type": "string", "description": "COPE: materials, year built; empty string if not found"}, + "occupancy": {"type": "string", "description": "COPE: use / operations of the premises"}, + "protection": {"type": "string", "description": "COPE: sprinklers, distance to fire service, alarms"}, + "exposure": {"type": "string", "description": "COPE: flood zone, wind / cat exposure, neighboring hazards"}, + "operations": {"type": "string", "description": "what the business does, scale, notable hazards"}, + "adverse_history":{"type": "string", "description": "OSHA citations, prior losses, violations; empty if none found"} + } + }, + "basis": { + "type": "array", + "description": "one entry per field: the public-record source and a confidence", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["field", "source_url", "confidence"], + "properties": { + "field": {"type": "string"}, + "source_url": {"type": "string", "description": "resolving public-record source; must load"}, + "confidence": {"type": "integer", "description": "0-100"} + } + } + } + } +} +``` + +Prompt (substitute the risk): + +> Build a P&C underwriting risk profile for {RISK}. Return COPE data (construction: materials and +> year built; occupancy; protection: sprinklers and distance to fire service; exposure: flood +> zone and wind / catastrophe), the operations, and any adverse history (OSHA citations, prior +> losses, violations). Draw from public records (county / assessor records, FEMA, OSHA, permits) +> and cite a resolving source with a 0-100 confidence for every field. Never invent a value, if a +> field isn't on a reachable record, return an empty string and say so. Prefer a smaller correct +> profile over a padded one. + +**Read it:** it's an underwriting worksheet, each COPE and history field clickable back to the +county or federal record behind it. Empty fields are "not in the public record," a prompt for a +question to the broker, not a value to assume. + +## Config seams (build on top) + +1. **Input:** an address / business / applicant; run one profile per submission, batch the queue. +2. **Fields:** edit the `fields` object to your line's rating factors (roof age, distance to coast, prior losses, protection class). +3. **Tier:** `core2x` default (long-tail public-record depth); `core` for a quick triage pass (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Task API (stable, +`v1`): `POST /v1/tasks/runs` with `task_spec.output_schema`, then +`GET /v1/tasks/runs/{run_id}/result`; per-field citations and confidence in `output.basis`. +Clean record text via the Extract endpoint. Auth via `x-api-key`, server-side only. Prefer the +CLI/MCP unless you need raw control. + +## Next + +- Verify the applicant behind the risk → **kyb-kyc**. +- Research the claims that follow → **claims-research**. +- Keep the risk under watch after bind → **book-risk-monitoring**. diff --git a/skills/parallel-workspace-agent/SKILL.md b/skills/parallel-workspace-agent/SKILL.md new file mode 100644 index 0000000..2789d12 --- /dev/null +++ b/skills/parallel-workspace-agent/SKILL.md @@ -0,0 +1,108 @@ +--- +name: parallel-workspace-agent +description: When something material changes about an entity your user tracks, act on it across the workspace, refresh the record, draft the follow-up, update the agenda, driven by a Monitor that detects the change and a Task that turns it into actions. Use when the user wants to "act when X changes", "keep my workspace in sync with the world", "trigger workflows on a signal", or build a proactive assistant. Runs on the user's own Parallel account via Monitor and Task. +allowed-tools: Bash(command:*), Bash(parallel-cli:*), Bash(sleep *), Bash(curl:*), ToolSearch, mcp__Parallel-Task-MCP__createTaskGroup, mcp__Parallel-Task-MCP__getStatus, mcp__Parallel-Task-MCP__getResultMarkdown +metadata: + author: parallel +--- + +# Workspace Agent + +The proactive pattern: when something **material changes** about an entity your user tracks, act +on it across the workspace, refresh the record, draft the follow-up, update the agenda, before +the user asks. A **Monitor** detects the change and a **Task** turns it into the right actions, +each grounded and cited so the action is based on a real, sourced event, not a hallucinated one. + +## Build on the maintained layer + +> Shared contract: Use the user's own Parallel account and the maintained CLI or MCP layer. Cite every returned field, and leave unverifiable fields empty instead of fabricating values. Choose one processor tier. If a run falls short, increase the tier once and rerun it, then route the user to a Parallel DE if it still falls short. Use the rest of this file for the use case. + +Two primitives, both maintained by Parallel so API changes are absorbed for you: +- **Detect (the trigger):** the installed **`parallel-monitor`** skill, Monitor is the stable + `v1` API. +- **Act (the follow-through):** the **Task MCP** (`createTaskGroup`), or `parallel-data-enrichment` + on the CLI, to turn the change into structured, grounded actions. + +The raw HTTP API is below for the server-side wiring. If Parallel is not configured, run the relevant setup skill first. See +[docs.parallel.ai](https://docs.parallel.ai). + +## Guided intake (ask first) + +If the current workspace contains a `PROFILE.md` file, use its product / surfaces / keep_current framing (captured once at +setup), don't re-ask it; only get the per-run specifics below. + +Three quick questions before wiring it up: +1. **Watch what?** The entities your users track (one monitor per entity, fan out per user). +2. **Act how?** The actions to take on a material change (refresh a record, draft a message, update an agenda), and which need a human's approval before they fire. +3. **What counts as material?** The threshold, so routine noise doesn't trigger workspace actions. + +Confirm, then wire it. + +## Run it + +Two stages. First a Monitor detects a material change (reuse the `parallel-knowledge-freshness` shape). +Then, on each event, a Task proposes the workspace actions: + +```json +{ + "type": "object", + "additionalProperties": false, + "required": ["trigger", "actions"], + "properties": { + "trigger": {"type": "string", "description": "the sourced change that fired this, one line"}, + "source_url": {"type": "string", "description": "resolving source for the change; must load"}, + "actions": { + "type": "array", + "items": { + "type": "object", + "additionalProperties": false, + "required": ["action", "target", "content", "needs_approval"], + "properties": { + "action": {"type": "string", "enum": ["refresh_record", "draft_message", "update_agenda", "create_task", "notify", "other"]}, + "target": {"type": "string", "description": "what in the workspace it touches (the account, the thread, the meeting)"}, + "content": {"type": "string", "description": "the drafted change / message, ready for the user to review"}, + "needs_approval": {"type": "boolean", "description": "true for anything user-facing or irreversible"} + } + } + } + } +} +``` + +Trigger query (Monitor) and action prompt (Task): + +> **Monitor:** Notify me when anything material changes about {ENTITY}: a funding round, an exec +> change, a major announcement. Return the change, its date, and a resolving source. +> +> **Task (on each event):** Given this sourced change: {EVENT}, propose the actions to take +> across the workspace, refresh the entity's record with the new facts, draft a short follow-up +> message referencing the change, and update any relevant meeting agenda. For each action give the +> target and the ready-to-review content, and set needs_approval=true for anything user-facing. +> Ground every action in the sourced change; never act on an unverified rumor. + +**Read it:** the Monitor is the always-on trigger; the Task output is a queue of proposed actions, +each tied to the sourced change. Auto-apply the safe ones (refresh a record) and hold +`needs_approval` actions (an outbound draft) for the user. Acting on a cited event, with a human +gate on anything outbound, is what keeps a proactive assistant trustworthy. + +## Config seams (build on top) + +1. **Trigger set:** one monitor per tracked entity; fan out per user from your DB. +2. **Action set:** edit the `action` enum + the prompt to the things your product can actually do. +3. **Approval gate:** `needs_approval` decides auto-apply vs human review, keep outbound and irreversible actions gated. +4. **Materiality threshold:** tune the monitor query so routine noise doesn't trigger workspace actions. +5. **Tiers:** `lite` Monitor for the watch, `core` Task for the action step (see the tier guidance in this skill). + +## Production (raw HTTP API): verify before hardcoding + +_As of 2026-08; confirm at [docs.parallel.ai](https://docs.parallel.ai)._ Monitor `POST +/v1/monitors` (`event_stream`) with a `webhook` that fires your action pipeline; on each event call +the Task API `POST /v1/tasks/runs` + `GET /v1/tasks/runs/{run_id}/result` (citations in +`output.basis`) to produce the actions. One `x-api-key`, server-side. This is the one skill you +wire directly against the API, so track the dated endpoints here. + +## Next + +- Just surface the change without acting → **knowledge-freshness**. +- Enrich the entity when its record refreshes → **entity-context**. +- Answer a user's question about the change → **productivity-quickstart**. diff --git a/tests/test_repository_layout.py b/tests/test_repository_layout.py index 891139c..14a00e6 100644 --- a/tests/test_repository_layout.py +++ b/tests/test_repository_layout.py @@ -35,6 +35,36 @@ def test_project_skill_links_resolve_to_matching_skill_directories(self): self.assertEqual(expected_target.resolve(), link.resolve()) self.assertTrue((link / "SKILL.md").is_file()) + def test_every_skill_has_a_project_discovery_link(self): + skill_names = { + directory.name + for directory in SKILLS_ROOT.iterdir() + if (directory / "SKILL.md").is_file() + } + link_names = {link.name for link in PROJECT_SKILLS_ROOT.iterdir()} + + self.assertEqual(skill_names, link_names) + + def test_relative_skill_links_resolve_within_the_skill(self): + markdown_link = re.compile(r"\]\(([^)]+)\)") + + for skill_file in sorted(SKILLS_ROOT.glob("*/SKILL.md")): + for raw_target in markdown_link.findall( + skill_file.read_text(encoding="utf-8") + ): + if raw_target.startswith(("#", "http://", "https://")): + continue + + relative_target = raw_target.split("#", 1)[0] + if not relative_target.lower().endswith(".md"): + continue + + target = (skill_file.parent / relative_target).resolve() + + with self.subTest(skill=skill_file.parent.name, target=raw_target): + self.assertTrue(target.is_file(), f"broken skill link: {raw_target}") + self.assertTrue(target.is_relative_to(skill_file.parent.resolve())) + def test_migration_skill_is_project_discoverable(self): link = PROJECT_SKILLS_ROOT / "migrate-to-parallel"