Grasp

View saved version →

---
name: company-lookup
user-invocable: false
description: "Use when the current task is to resolve, validate, or analyze one specific company in Grasp: understanding a named target, buyer, reference, or sample company before a list, buyer, transaction, contact, or table workflow; fetching business, financial, ownership, employee, LinkedIn, deal, or similar-company profile sections; resolving ambiguous names/domains/org numbers; or checking whether a company exists in Grasp or may be missing from a table."
---

# Company Lookup

Use two tools together for one specific company: `grasp_search_companies` to resolve identity into a `company_id`, then `grasp_get_company` to fetch that entity. Neither is a general company-list tool.

## Use Cases

- Named-company context before a list workflow: target, buyer, reference company, or sample company that defines what to search for.
- One-company deep dives: business model, value chain, customers, competitive position, ownership, employees, financials, acquisition history, buyer capacity, or attractiveness.
- Ambiguous identity: company names/domains that may resolve to the wrong legal entity.
- Missing-company diagnosis: checking whether a company exists in Grasp or why it may be absent from a table.

For list, buyer, competitor, target, peer, or transaction requests, use this skill as a supporting step and then return to the `creating-tables` skill.

## Resolve Identity First

`grasp_get_company` accepts only a `company_id`. Resolve it before fetching:

1. If a table row already provides a company-id column, use that id directly and skip search.
2. Otherwise call `grasp_search_companies` with what the user gave: free-text `query` for names and/or website domains, `org_number` for organization/registration numbers, and `countries` to narrow when the country is known.
3. Read the candidates as legal entities, not interchangeable matches. The same brand often resolves to many entities across countries (operating companies, holdcos, country subsidiaries). Pick using name, url, org_number, country, and company_size together.
4. If candidates are ambiguous and the choice affects the answer, state the selected entity and ask for confirmation before deep work or table seeding. Do not silently pick.
5. If `total_hits` exceeds the returned candidates, refine the query, add `countries`, or use `org_number` before picking.
6. If search finds nothing, try reasonable brand, legal-name, domain, and org-number variants. Use available web context to find an official domain when needed.
7. Treat the returned `company_id`, URL/domain, and organization number as canonical for later Grasp calls in this session. Company ids are not stable long-term: resolve them fresh rather than reusing ids remembered from earlier sessions.

Org numbers are matched exactly (with spacing/casing tolerance) and are not globally unique; pair them with `countries` when possible. Do not invent canonical domains or organization numbers from memory.

## Depth And Output

Use shallow sections before table/list work. Request full sections only when needed for the user's question or next workflow.

- `output: "structured"`: use when the result feeds later tool calls, table creation, or analysis.
- `output: "text"`: use when the user only wants a readable one-company answer.
- `output: "both"`: use for deep dives where the user needs prose and the agent needs structured fields.
- `business`, `financials`, `employees`, `org_structure`: default partial sections are usually enough for mandate translation.
- `financials: "full"`: use for reported or estimated financial detail, evidence review, or acquisition-capacity analysis.
- `employees: "full"` or `linkedin: "partial" | "full"`: use for deeper headcount, LinkedIn, or geographic-presence analysis.
- `org_structure`, `shareholders`, `beneficial_owners`, `directors`: use for ownership, control, founder/family/PE/corporate status, or governance questions.
- `deals`: returns an acquisition-history summary only (total deal count, latest deal year). Use it to learn whether and how recently the company acquires. For the complete deal history of this company as a buyer, including deal values and valuation multiples, use the `grasp_get_buyer_deals` tool with the same company_id. For sector transaction comps driven by target type, use the `creating-tables` skill with transaction tables.
- `similar_companies`: use for profile-level peer hints or seed discovery, not as a substitute for a full company search.
- `contacts`: use only for company-profile contact records in a one-company deep dive when explicitly requested. For outreach/person search by role, use the `finding-contacts` skill.

Mark missing, estimated, stale, sparse, or converted fields as caveats.

## Buyer Deal History

For "what has X acquired", acquisition cadence, typical deal sizes, or multiples paid, call the `grasp_get_buyer_deals` tool with the company's company_id after resolving identity. This is a lookup with full recall over that buyer's recorded deals, returned newest first with pagination.

- Read the coverage summary first: deal sizes, enterprise values, and multiples exist only for a subset of deals. Distinguish deal-count evidence from valuation evidence.
- Multiples carry derivation types (Reported, Implied, Calculated); qualify valuation claims accordingly. Monetary values are USD.
- Deal records embed target identity, description, and key financials for in-context resolution. For deeper target detail when available — full financials, ownership, employees — call `grasp_get_company` with the deal's `target_company_id`.
- Deals have no stable ids. Reference them by target and year.
- Do not use transaction tables for one known buyer's history; they are semantic search by target type and do not guarantee complete recall for a single buyer.

## Answering

- For "what does X do?", cover business activity, products/services, geography, scale, ownership, and financials when returned.
- For fit, attractiveness, or buyer-capacity questions, separate returned facts from judgment.
- For comparisons, resolve and fetch each company separately and compare fields that were actually returned.
- For table/list setup, translate the company profile into a concise business activity, geography, scale, and canonical URL/domain for the next skill.

## Missing Company In A Table

Use this path when the user asks why an expected company is absent.

1. Resolve the company with `grasp_search_companies` using URL/domain, org number, or name plus country variants, then fetch it with `grasp_get_company`.
2. If the user did not provide an official URL/domain, search enough to find one before concluding the company is absent.
3. Try reasonable brand, legal-name, domain, org-number, and country variants.
4. Confirm whether the table's stated scope should include that company.
5. Use the `working-with-tables` skill to inspect table metadata, rows, filters, geography, source criteria, and semantic research columns.
6. Check likely causes before concluding:
   - already present under another name, URL, or parent
   - hidden by current filters or sort
   - outside geography, size, ownership, or activity scope
   - headquartered outside the scope while the table keeps only companies headquartered there (`grasp_get_table` shows `source_geography.include_multinational_companies: false`). This cannot be changed on an existing table; create a new table with `true`.
   - source criteria too narrow
   - missing from available Grasp company data
7. If it should be explicitly included in a new/corrected table, use the validated URL in `entities` when that matches the user's intent. Use `similar_companies` only for peer/similar-company seeding.

Do not claim Grasp has no record of a company unless URL, org-number, name, and country variants support that conclusion. Prefer "not found after these lookups" when evidence is limited.

## Follow-Up Routing

- Similar companies, peers, competitors, targets, or explicit company seeds: use the `creating-tables` skill.
- Existing table screening, qualification, prioritization, ranking, or shortlisting: use the `screening-and-shortlisting` skill.
- Existing table filtering or missing-row diagnosis after lookup: use the `working-with-tables` skill.
- Table columns or research about multiple companies: use the `table-enrichment` skill.
- Person-level outreach contacts: use the `finding-contacts` skill.

View saved version →

---
name: creating-tables
user-invocable: false
description: Use when the user wants to find, build, generate, source, map, or import a long list/source universe of companies, targets, peers, competitors, buyers, acquirers, investors, or M&A/deal transactions, including deal valuations, multiples and precedent transactions, and buy-and-build or roll-up themes, even when the user only wants to discuss the idea first. Read it before asking scope questions such as business type or geography. Creates or imports the initial Grasp table, then waits, inspects, and hands off to screening-and-shortlisting, table enrichment, table work, or contacts as needed.
---

# Creating Tables

Create the initial Grasp evidence set, wait for completion, inspect it, then hand off. Do not pack screening, filtering, ranking, enrichment, or research into the initial table unless the user explicitly asks for a narrow source.

For requests that span table creation plus screening, filtering, enrichment, ranking, prioritization, shortlisting, or contacts, use this skill for the table-creation step, then hand off to the relevant dedicated skill.

## General Workflow

1. Choose the table path below and translate the mandate into activity, geography, entity type, and optional seed companies.
2. When the request depends on a named target, buyer, reference company, or sample company, use the `company-lookup` skill first to understand the company's business, scale, geography, and canonical URL/domain, then return here to create the table.
3. If this table-building scope does not already have a `conversation_id`, or the user starts a new scope or asks for a new Grasp conversation, call `grasp_setup_conversation`; then create/import/compose the table with that `conversation_id` and wait for completion.
4. Inspect with the `grasp_get_table`, `grasp_get_table_rows`, and, when needed, `grasp_describe_table` tools.
5. For screening, qualification, prioritization, top-N, ranking, or shortlist presentation from the long list, use the `screening-and-shortlisting` skill.
6. For filtering, sorting, querying, exporting, or missing-row diagnosis without analyst selection, use the `working-with-tables` skill.
7. For source columns, estimated financials, research columns, computed fields, and table-facing contact requests, use the `table-enrichment` skill.
8. For person-level contacts, use the `finding-contacts` skill only after the target companies or buyers are clear.

The default table-creation sequence is the `grasp_setup_conversation` tool for a new table-building scope, the `grasp_create_table` tool with the returned `conversation_id`, the `grasp_check_job_status` tool to poll the async job if needed, the `grasp_get_table` tool, then row/describe/query inspection. Treat `grasp_get_table` previews as samples; do not make full-table, top-N, or coverage claims until rows, describe, query, or export support them. Do not call the `grasp_add_research_column` tool before that inspection.

## Conversation Context

New tables need a `conversation_id`. Set it once per table-building scope, not once per create/import/compose call.

- Before the first `grasp_create_table` or `grasp_import_table` call in a table-building scope, call `grasp_setup_conversation` once and reuse the returned `conversation_id` for every new table in that scope.
- If the user asks for separate tables that may later be compared, merged, deduped, or composed, create all of those source tables with the same `conversation_id`.
- For `grasp_compose_table`, use the `conversation_id` shared by the source tables. If those source tables were created in the current task, this is the setup ID. If they already exist, recover their `conversation_id` with `grasp_list_tables`, `grasp_get_table`, or `grasp_check_job_status`, and compose only tables from the same conversation.
- Use UUID `table_id` values returned by status/list/get tools. Do not pass `table_slug` as a tool handle; slugs are display, navigation, and SQL identifiers only.
- Existing-table update, research, enrichment, row-read, query, describe, and export tools derive conversation context from UUID `table_id` and do not take `conversation_id`.

## Company Universes

Use `grasp_create_table` with `entity_type: "company"` for targets, peers, competitors, vendors, service providers, and market maps.

- Use `business_activity` for the operating activity of the companies to find, e.g. "pest control services" or "industrial MRO distributors". Keep it to 10-15 words maximum: one business type with at most 1-2 essential qualifiers. Keep the activity terms the user gave, but don't add sub-services, products, or customer segments they didn't name; each added element narrows the search.
- Put countries or regions in the `geography` field.
- Multinationals: ask, don't default. Before creating a company table scoped to countries or regions, ask the user whether the list should include multinational companies (headquartered elsewhere, but operating in the scope geography) or only companies headquartered there. Give two options that name the scope, e.g. "Include multinationals: also companies headquartered elsewhere that operate in Denmark" or "HQ in Denmark only", with no recommendation. Ask it together with any other scope questions. Skip it only when the user already stated a preference (reuse it and restate it in the scope), or when the search is global, scoped to US states (they match HQ state, so the flag has no effect), or not a company search. Always pass `geography.include_multinational_companies` explicitly: `true` to include them, `false` for HQ only.
- Company searches apply only `value_chain_category` as a source filter. Don't put revenue, employee, ownership, or exclusion limits in `source_filters` or `business_activity`. After creation, check coverage, then filter revenue and employees with `workflow.view.filters` on the returned columns (company tables include the latest revenue and employee columns; rows with no value fall out of a range filter, see `screening-and-shortlisting`). Ownership starts empty: fill it with `grasp_run_table_outputs`, then filter type limits on `primary_ownership_type` or `primary_ownership_subtype` (use `owner_matches` only for same-owner conditions such as stake or owner name). Screening, shortlisting, and ranking are follow-up table work.
- Use validated company URLs in `similar_companies` when the user wants peers, competitors, targets, or similar companies around a seed.
- Use explicit `entities` only when the user wants specific companies included, not as a substitute for a broad market source.
- Prefer recall at creation, then refine with screening, filters, research, enrichment, or ranking.
- Inspect exact returned columns before filtering on employees, revenue, ownership, industry, or location.
- Add semantic research for fit questions such as specialization, product/service mix, commercial segment, or false-positive exclusion.
- For shortlists, top-N, prioritization, or ranked outputs, use `screening-and-shortlisting` after creation.

Example: "Find Nordic pest control providers for Anticimex, 10-75 employees, specializing in rodent control."

- `business_activity`: "Pest control services"
- `geography`: Sweden, Norway, Denmark, Finland
- Before creation: ask whether to include multinationals operating in the Nordics or only Nordic-headquartered companies, then pass `include_multinational_companies`.
- After creation: inspect available fields; add one narrow decision-evidence research column only when needed.
- If more qualitative evidence is needed, scope follow-up research to the narrowed set.

## Buyer Universes

Use `grasp_create_table` with `entity_type: "buyer"` for strategic buyers, financial buyers, acquirers, investors, and buyer universes.

- Use `business_activity` for the type of company the buyer should acquire or invest in. Do not describe buyer attributes there.
- Use `geography` for buyer geography: buyers headquartered in that geography or buyers with acquisition/investment history there.
- Leave buyer size, screening, ranking, and exclusions for supported source filters or follow-up table work after creation. The structured current Ownership classifier is not supported on buyer tables.
- If the user explicitly asks for buyers headquartered in X, create the buyer table, inspect returned buyer HQ/location columns, then filter after confirming exact columns.
- If the user cares about "Nordic exposure" or "European software acquisition history", use geography to capture that exposure rather than stuffing it into `business_activity`.
- Do not restrict buyer type by default. If requested, use `grasp_read_docs` to confirm the supported buyer-type filter; do not pass buyer type as a top-level create-table field.
- Use transaction tables when the user needs returned transaction evidence or wants acquirer activity independent of buyer-search ranking.
- After creation, inspect the buyer table before filtering, enrichment, screening, shortlisting, or ranking.
- If the user asks for buyer prioritization, top-N, rationale, or a buyer shortlist, use the `screening-and-shortlisting` skill. It will call `table-enrichment` when buyer-fit evidence is missing.
- Do not search contacts during buyer-table creation. If the user explicitly asks for outreach contacts after buyers are selected, use the `finding-contacts` skill.

## Transaction Universes

Use `grasp_create_table` with `entity_type: "transaction"` for semantic transaction discovery by target type: precedent transactions, sector acquisition activity, market consolidation, and transaction comps.

- Transaction tables are search, not lookup. For the complete deal history of one known buyer ("what has buyer X acquired"), use the `grasp_get_buyer_deals` tool with the buyer's company_id instead; search recall is not guaranteed complete for a single buyer.
- Use `business_activity` for the target company type in the transactions. Do not describe buyer/acquirer attributes there.
- Use `geography` for target-company geography in the transactions. It is not buyer/acquirer HQ geography.
- Transaction searches apply only `deal_year`, `buyer_type`, and `buyer_url` as source filters. Apply deal size and other limits after creation with `workflow.view.filters`; screening, ranking, and exclusions are follow-up table work.
- Use one transaction table for a coherent multi-region scope such as US and Europe when Grasp can express it. Split into separate tables only if the user asks for separate analyses, the tool cannot express the combined geography, or inspection shows caps/coverage require a follow-up split.
- If the user wants acquirers from a geography, create/query transaction rows first, inspect buyer/acquirer fields, then filter or aggregate after creation.
- Put year limits in a `deal_year` source filter as whole-year `>=`/`<=` bounds.
- Inspect target, buyer, year, country, deal status, value, and source fields before drawing conclusions.
- Use the `grasp_query_table` tool for buyer frequency, active acquirers, buyer-type mix, target countries, deal years, and available value coverage.
- For selected comps, precedent-transaction shortlists, top-N, or ranked deal outputs, use `screening-and-shortlisting` after creation.
- Do not create a buyer table just because the user asks about active buyers or buyer types in a transaction comparison workflow. Create a buyer table only when they ask for a standalone buyer universe, buyer outreach, or buyer profiles beyond the transaction evidence.
- Do not imply valuation coverage if values or multiples are sparse.
- Distinguish deal-count evidence from valuation evidence.

## User-Provided Lists

Use `grasp_import_table` when the user brings their own CSV/Excel/copied company rows, URLs, domains, organization numbers, or names.

- Call `grasp_setup_conversation` first, then pass the returned `conversation_id` to `grasp_import_table`.
- For CSV/Excel, read the file in the host environment and convert rows to objects.
- Preserve useful user columns as source context.
- Prefer URL/domain columns for matching when present.
- If no URL/domain exists, use organization/registration number with a country or country_iso2 column.
- If neither URL nor organization number exists, use company name with country/location hints.
- Pass explicit column_mapping values:
  - url for website/domain columns.
  - org_number plus country or country_iso2 for registration-number matching.
  - name plus optional country/location for name matching.
- Normalize obvious formatting issues without changing company meaning, such as whitespace, URL schemes, `www.` prefixes, trailing paths, casing, or registration-number punctuation.
- Name-based matching is weaker than URL/domain matching; after import, inspect match quality before filtering or shortlisting.
- Do not use the `grasp_create_table` tool for a user-owned list unless the goal is to create a new Grasp-sourced universe.
- After import, wait for completion, inspect match quality, then use `screening-and-shortlisting`, `working-with-tables`, `table-enrichment`, or `finding-contacts` as needed.

## Compose Existing Tables

Use `grasp_compose_table` when the user wants a merged, compared, deduplicated, or composed Grasp table from existing tables.

- Use the `grasp_list_tables` tool to find recent candidates when the user does not provide handles.
- Inspect each source with the `grasp_get_table` tool before composing.
- Use UUID `table_id` component handles and the shared source `conversation_id`; do not use `table_slug` handles.
- If source tables are in different conversations, do not compose them in MCP V1. Explain that they need to be recreated under one setup conversation before composition.
- Explain the composition logic: union, intersection, dedupe, comparison, or enrichment base.
- Preserve source identity when it matters for auditability.
- After composition, inspect rows before filtering, screening, shortlisting, or ranking.
- Use `screening-and-shortlisting` when the composed universe must be qualified, prioritized, ranked, or narrowed to a shortlist.

## Recreate Existing Configs

Use when a user wants another table like an existing table.

- Inspect the existing table with the `grasp_get_table` tool.
- Identify entity type, activity, geography, source columns, workflow steps, filters, sort, layout, and name/description.
- Use the `grasp_create_table` tool when the source universe changes.
- Use the `grasp_update_table` tool when only view, enrichment, filters, or naming changes.
- Do not copy stale filters or field names into a new table until the new table columns have been inspected.
- Use the `grasp_read_docs` tool if the existing workflow includes raw source filters, data columns, or research payloads you are not certain about.

## Scope And Guardrails

- Before calling the `grasp_create_table` tool, choose the matching entity path because `business_activity` and `geography` are interpreted differently for company, buyer, and transaction tables.
- If a scoped search returns zero rows, report that result. Do not silently broaden the mandate.
- Use the `grasp_read_docs` tool for exact source, filter, data-column, or workflow payload details when uncertain.
- Use one table for a clear, coherent scope when it can express the user's mandate. When one list spans distinct activities, such as HVAC, plumbing and roofing contractors, create one table per activity with the same `conversation_id`, then merge them with `grasp_compose_table`. Use separate or parallel `grasp_create_table` tool calls when the user asks for separate analyses or when docs, tool limits, or inspection show the combined search would be unsupported, capped, or misleading. Reuse the same `conversation_id` for separate tables created in one task, especially when they may later be composed.

View saved version →

---
name: finding-contacts
user-invocable: false
description: "Use when the user explicitly asks for person-level outreach contacts for a selected set of Grasp companies or buyers: work emails, phone numbers, person LinkedIn profiles, CEO/CFO/founder/owner contact details, corporate development or M&A people, decision-makers, or outreach lists."
---

# Finding Contacts

Use the dedicated contact lookup only after the company or buyer targets are clear. It is the outreach-grade workflow and is different from table fields, research columns, and one-company profile contacts.

Do not infer contact lookup from ranking, shortlist, acquisition-target, PE add-on, or buyer-universe requests. Use this skill only when the user explicitly asks for people, emails, person LinkedIn profiles, outreach, or contact routes.

## Contact Source Choice

- Outreach contacts for selected companies: use the `grasp_search_contacts` tool. Reserve it for selected domains where the user is likely to act on the result.
- Broad contact-like table fields: use the `table-enrichment` skill. Research columns can cover many companies, but they are not contacts lookup results.
- Reported/source fields: use the `table-enrichment` skill for company-level phone, website, generic email, or company LinkedIn fields when Grasp exposes them as table columns. These are not person-level outreach contacts.
- One-company profile contacts: use the `company-lookup` skill only for a one-company profile/deep-dive context. Do not use profile contacts as the default response to outreach requests.

## Guardrails

- Do not run contact lookup across a full long list by default. Reserve it for a trimmed set of companies planned for outreach.
- If the user asks for contacts for many companies, first narrow to a shortlist. If they insist on broad coverage across hundreds of companies, use research columns from the `table-enrichment` skill instead and state that they are not contact lookup results.
- Pull domains from inspected table rows or validated company profiles. Do not guess domains when using `grasp_search_contacts` tool.
- Respect the `grasp_search_contacts` tool's domain, title, and result limits.
- Founder-owned, owner-managed, PE-backed, family-owned, or management-owned target criteria are ownership criteria, not contact requests. Use `finding-contacts` only when the user asks for people or outreach details.

## Locked Emails and Unlocking

Contact emails from `grasp_search_contacts` may be locked (`email_locked: true` with `email: null`). Locked means the email exists but has not yet been revealed for the user.

- Never guess, fabricate, or substitute a locked email. Present the contact with the email marked as locked.
- To reveal locked emails, use the `grasp_unlock_contact_emails` tool with the contacts' `person_id` values. Contacts the user already unlocked are returned without re-fetching; contacts without a resolvable email come back as `not_found`.
- Only unlock contacts the user has explicitly selected, and confirm the selection with the user before calling. Never unlock an entire search result set unprompted.
- Re-running `grasp_search_contacts` returns real emails for contacts the user already unlocked (`email_unlocked: true`).

## Workflow

1. Identify the target companies or buyers.
   - From a table: use the `working-with-tables` skill to inspect rows and URL/domain columns.
   - From names: use the `company-lookup` skill to validate canonical domains.
2. Translate the outreach goal into role filters.
   - For specific roles such as CEO, CFO, Founder, Owner, Partner, Head of M&A, or Corporate Development, pass explicit `titles`.
   - Use `senior_only` only as a broad seniority hint when the user asks for senior decision-makers without naming specific roles.
   - Use `seniorities` only when the user asks for seniority classes rather than titles.
3. Call the `grasp_search_contacts` tool with selected domains, explicit titles/seniority when useful, and a concise `usage_rationale`.
4. Present contacts with company/domain, person, title, available contact fields (marking locked emails), and missing coverage.
5. If the user selects contacts whose emails are locked, confirm the selection, then call `grasp_unlock_contact_emails` with those `person_id` values.

Never invent emails, LinkedIn URLs, source links, or people. Treat absent results as coverage gaps, not proof that no relevant contact exists.

View saved version →

---
name: screening-and-shortlisting
user-invocable: false
description: Screens and shortlists Grasp tables/universes into qualified, prioritized, ranked, or top-N outputs across companies, buyers, targets, peers, competitors, acquirers, investors, or deals. Use when the user asks to screen, narrow, qualify, shortlist, prioritize, rank, select best/top candidates, find targets in a list or universe they already have, map a landscape, or produce recommendations from a Grasp long list. Enforces coverage checks, enrichment/research/proxies, table links, and transparent escalation.
---

# Screening And Shortlisting

Use this skill to turn a Grasp source universe or long list into a qualified universe, shortlist, prioritized shortlist, ranked list, selected comps, or final recommendation. This is a Grasp workflow skill: use Grasp table inspection, coverage checks, enrichment, research columns, estimated financials, company lookup, and table links to make the screening process auditable.

Base cuts on table evidence, not preview rows, familiar names, ad hoc slices, or general knowledge.

## When To Use

Use after `creating-tables` or on an existing Grasp table when the user asks to screen, qualify, narrow, filter, shortlist, prioritize, rank, score, tier, select top-N, identify best/most relevant/most likely candidates, map a competitor landscape, refine a buyer universe, select precedent transactions, or produce a target/peer/buyer/deal recommendation.

If no table exists yet, first use `creating-tables` to create a high-recall universe, then return here.

## Industry Terms

- Source universe / long list: the starting Grasp table.
- Screening criteria: the user's in/out requirements.
- Qualification: deciding whether a row is actually in scope.
- Qualified universe: rows that pass the defensible in-scope screen.
- Shortlist: selected rows from the qualified universe.
- Prioritization / ranking / scoring: ordering or tiering the shortlist.
- Deep dive / company profile: closer inspection of important rows.

## Workflow

1. Inspect the universe.
   - Use `working-with-tables` to inspect metadata, row count, columns, table version, links, preview, and row/query/export limits.
   - Treat `grasp_get_table` preview rows as samples only.
   - Use UUID `table_id` handles for tool calls; `working-with-tables` can recover recent table IDs and conversation IDs when needed.
   - Every output or escalation must include the current Grasp table link.

2. Translate the mandate into screening criteria.
   - Separate hard filters from soft criteria.
   - Hard filters define in/out eligibility, such as geography, activity, entity type, deal date, buyer type, current ownership, or size.
   - Soft criteria drive prioritization, such as strategic fit, specialization, acquisition likelihood, quality of evidence, buyer relevance, or attractiveness.
   - If multiple interpretations are plausible and change the screen materially, pause and offer concrete Grasp-backed alternatives.

3. Check coverage before applying hard filters.
   - Use `working-with-tables` to describe/query coverage, missingness, distributions, and exact field values.
   - For every hard filter, account for how many rows are known in scope, known out of scope, and missing/uncertain.
   - Do not silently exclude blanks or unknowns. If missing values remain after filtering, state that they were not fully tested.

4. Add Grasp evidence before semantic or sparse-data cuts.
   - Use `table-enrichment` for source columns, estimated financials, research columns, computed fields, or company-level contact-like fields.
   - If a company- or buyer-table screen depends on current ownership, use the table's existing structured output (`ownership` or `buyer_ownership`). Populate missing cells with `grasp_run_table_outputs`, then use its companion fields, owner-level SQL, or `owner_matches`; do not add research to parse ownership fields that already exist. Structured Ownership remains unsupported on transaction tables.
   - If the screen depends on semantic fit, specialization, customer segment, competitor relationship, buyer relevance, acquisition likelihood, likelihood to transact, or strategic rationale, add a narrow research column through `table-enrichment` before cutting.
   - If a financial screen depends on revenue, assets, employees, or headcount and coverage is sparse, use `table-enrichment` and its estimated-financials guidance before excluding rows.
   - Inspect enrichment results before filtering, scoring, or presenting.

5. Build the qualified universe.
   - Apply only defensible hard filters.
   - Keep uncertain rows in an explicit monitor/borderline bucket when data is incomplete but plausibly in scope.
   - Do not use keyword filters as a substitute for semantic fit research.
   - Do not select familiar names unless table evidence supports them.

6. Prioritize or rank only after qualification.
   - If the user supplies an already qualified set, start here after inspecting the row set, table link, and available evidence.
   - If eligibility is unresolved or new disqualifying concerns appear, return to qualification before final ranking.
   - Use simple, explainable dimensions derived from the mandate and table evidence.
   - Check legal entity and brand match, current parent or controlling owner when ownership matters, and scale versus mandate using returned or researched fields.
   - Separate clean fits, strategic exceptions, near misses, monitor rows, and excluded rows.
   - Label reported, estimated, researched, inferred, missing, and unverified evidence when it affects confidence.
   - Include concerns and near-miss reasons instead of hiding weak evidence behind a score.

7. Deep-dive important rows.
   - Use `company-lookup` for top candidates, expected-but-missing names, ambiguous identity, ownership checks, company profiles, financial detail, buyer capacity, or sanity checks.
   - For shortlisted buyers, use the `grasp_get_buyer_deals` tool with the row's buyer company_id to review the full deal history: acquisition cadence, typical deal sizes, and multiples paid where covered. Distinguish deal-count evidence from valuation evidence.
   - The model's own knowledge and web research may validate or challenge Grasp evidence, but must not replace Grasp table screening for the primary cut.
   - Use `finding-contacts` only after the company/buyer shortlist is clear and the user explicitly asks for people, emails, outreach, or contacts.

## Coverage And Escalation

Pause or ask the user before making the cut when:

- A decisive hard filter has poor coverage.
- A filter would exclude many rows only because values are blank or unknown.
- The user asks for a revenue band but reported revenue coverage is sparse and estimated financials or proxies have not been added yet.
- Estimated financials/proxies still leave too much uncertainty for the requested confidence level.
- The mandate has multiple plausible interpretations that materially change the shortlist.
- The result is based on a sample, capped query, or partial export but the user expects full-universe confidence.
- Expected companies are missing and identity, scope, source, or filter causes are unclear.
- Research outputs are contradictory, low confidence, or too thin to support the cut.

When escalating, provide practical alternatives grounded in Grasp data and tools. Do not just say the task cannot be done.

Example escalation shape:

```text
Reported revenue coverage is 22%, so filtering to EUR 10-50m would silently drop the rows with missing revenue. Options:
1. Add estimated revenue and re-run the size screen.
2. Use employee count or LinkedIn headcount as a size proxy, then deep-dive borderline names.
3. Keep missing-revenue rows in a monitor bucket and only exclude companies with evidence they are outside the band.

Grasp table: [link]
```

## Required Output

When presenting a shortlist, ranking, filtered result, caveat, or escalation, include:

- The Grasp table link.
- Whether the conclusion is based on the full table, filtered rows, query result, export, or sample.
- A funnel summary: initial universe, hard-filter results, missing/uncertain rows, researched/enriched rows, qualified universe, shortlist/prioritized shortlist.
- The criteria used and which were hard filters versus soft ranking criteria.
- Rank/tier when relevant, plus evidence, concern, confidence, and Grasp/source links for shortlisted rows when available.
- Clear caveats for missing, estimated, inferred, stale, capped, or unverified evidence.

Use entity-appropriate final labels: prioritized target shortlist, priority buyer list, screened peer set, competitor landscape, selected precedent transactions, or prioritized shortlist.

View saved version →

---
name: table-enrichment
user-invocable: false
description: "Use when the user wants to add, populate, enrich, fill, estimate, compute, classify, segment, or evaluate data on an existing Grasp table: financials, employees/headcount, current ownership, locations, LinkedIn data, buyer metadata, deal values, transaction details, research columns, computed fields, company-level phone/email/website fields, or fit notes."
---

# Table Enrichment

Enrich only after inspecting the table. Prefer structured Grasp data before research questions, and distinguish table columns from separate contact lookup results.

This is an evidence-building skill. If enrichment is needed to narrow, qualify, shortlist, prioritize, or rank a universe, use the `screening-and-shortlisting` skill as the orchestrator and return there after inspecting enrichment results.

Existing-table enrichment uses UUID `table_id` values and does not take `conversation_id`. Do not pass `table_slug` as a tool handle. If enrichment requires creating helper/source tables that may later be composed, use the `creating-tables` skill first so those new tables share one setup `conversation_id`.

## Workflow

1. Inspect the table with the `grasp_get_table` tool.
2. Use the `grasp_describe_table` or `grasp_query_table` tool to understand coverage.
3. Prefer reported/source columns when Grasp already stores the field.
4. For current ownership on company or buyer tables, follow the structured Ownership lifecycle below.
5. Use estimated financials only as labeled size proxies when reported coverage is thin.
6. Add research columns only for evidence that is not already structured and affects a decision.
7. Keep table contact-like fields separate from person-level outreach contacts.
8. Inspect enrichment results before filtering, scoring, or presenting.

Do not make enrichment coverage claims from a `grasp_get_table` preview alone; use rows, describe, or query to inspect the affected columns.

When research is needed, plan one `grasp_add_research_column` step, inspect coverage/results, then decide whether another is needed.

When several related qualitative criteria support one decision, prefer one decision-evidence research column over several separate upfront research columns.

## Tool Choice

- One explicit research column: use the `grasp_add_research_column` tool.
- Multiple table workflow changes, filters, sort, layout, or compute: use the `grasp_update_table` tool.
- Missing cells in existing research, compute, or Ownership outputs: use the `grasp_run_table_outputs` tool.
- Person-level outreach contact lookup: use the `finding-contacts` skill and keep contact lookup results separate from table fields in the answer.
- Schema uncertainty: use the `grasp_read_docs` tool.

Always include a short `version_summary` for table updates.

## Source Columns

Use source columns for fields Grasp already stores: financials, employees, locations, LinkedIn, buyer metadata, deal values, transaction details, company-level phone, website, generic email, or company LinkedIn fields. The structured current Ownership result is a deferred workflow output, not a source/data column.

- Inspect existing columns first.
- Use the `grasp_read_docs` tool before adding unfamiliar fields.
- Prefer reported structured fields over research columns when they answer the question.
- Check coverage before treating a field as a filter, screening criterion, shortlisting criterion, or ranking criterion.
- Do not guess currency suffixes or entity-specific field names.
- Company-level phone, generic email, website, or company LinkedIn fields are source data when Grasp documents them as data columns; they are not person-level outreach contacts.
- Use the `grasp_update_table` tool with `workflow.data_columns.add` when adding columns to a persisted table.

## Current Ownership

Current ownership has one structured route:

- Company tables: use the structured `ownership` workflow output. Inspect the table first. New company tables already contain the deferred output, so populate its missing cells with `grasp_run_table_outputs`; never add a duplicate step. Add `{ "type": "ownership", "config": { "output_column": "ownership" } }` only when a legacy company table genuinely lacks that output.
- Buyer tables: use the structured `buyer_ownership` workflow output. It classifies the buyer organization identified by `buyer_url`, not its funds, portfolio companies, representative target, or acquisition history. New buyer tables already contain the deferred output; add exactly one `ownership` step with `output_column: "buyer_ownership"` only when a legacy buyer table genuinely lacks it.
- Transaction tables: structured Ownership is unsupported. Do not add it and do not substitute a generic current-owner research column.

Narrow the current view with cheap structured filters before population when the user only needs a subset. After the job succeeds, check coverage: NULL means not researched; the `unknown` companion code means researched but unresolved. Then filter or analyze the structured result. Use `primary_ownership_type` and `primary_ownership_subtype` for organization-level categories, and query the actual structured output's `owners[]` or use an `owner_matches` view filter on that output for names, stakes, dates, relationships, joint ownership, and holding paths.

Never add generic research merely to parse fields already present in `ownership`. Targeted research is appropriate for facts outside its schema, such as previous owners, pending transactions, exact fund/vintage, owner domicile, platform/add-on status, external portfolio companies, or exit likelihood.

## Estimated Financials

Label estimates; check coverage before filtering.

- Inspect returned columns before using revenue, assets, employee, or currency fields.
- Prefer reported/latest available fields when returned.
- Use estimates only as a size proxy and label them as estimates.
- Keep currency suffixes visible in analysis.
- Check non-null coverage before filtering, screening, shortlisting, or ranking by financials.
- If coverage is thin, present the gap and consider employee count, ownership, or research as proxies.
- Use the `grasp_read_docs` tool with the relevant topic when exact data-column names are uncertain.

## Research Questions

Research questions answer evidence questions for companies in a table and add one column per question. Use them for evidence that is not already structured and affects a decision.

Good question shapes:

- Binary: "Does the company provide rodent control services?"
- Categorical: "What is the company's primary customer segment: residential, commercial, industrial, or mixed?"
- Extraction: "Which investment fund and vintage is associated with the current financial owner?"
- Free text: "Summarize the evidence for why this company fits the mandate."

Guidelines:

- Ask one narrow question per research column.
- When several related qualitative criteria support one decision, prefer one decision-evidence question over several separate upfront research columns.
- Prefer binary or categorical when the result drives filters.
- Use `where` to limit research to eligible rows when possible.
- Do not use research as a substitute for source columns.
- Treat research outputs as evidence to review, not automatic truth.
- Treat contact-like research as evidence to verify, not confirmed outreach contacts.

## Contact-Like Table Fields

Use only when the user wants contact-like information persisted as table columns. For person-level outreach contacts, stop and use the `finding-contacts` skill.

Do not treat a ranking, shortlist, PE add-on, acquisition-target, or buyer-universe request as a contact request unless the user explicitly asks for outreach contacts.

- Source columns can provide company-level phone, website, generic email, or company LinkedIn fields when Grasp documents them as available table columns.
- Research columns can provide broad public extraction at table scale when the user needs contact-like evidence across many companies.
- These are not contact lookup results and should not be presented as verified outreach contacts.
- If the user wants CEO/CFO/founder/owner/corporate-development people, work emails, phone numbers, person LinkedIn profiles, or outreach routes for selected companies, use the `finding-contacts` skill.
- If the user asks for contacts across a full long list, recommend narrowing first. If they still need table-wide coverage, use research columns and state that the result is contact-like evidence, not contact lookup data.
- Inspect exact URL/domain columns before adding any contact-like research column.
- Present missing values as missing coverage, not as proof that no relevant contact exists.

View saved version →

---
name: working-with-tables
user-invocable: false
description: Use when the user wants to inspect, search, filter, keep/remove/exclude rows, sort, query, describe coverage, read rows, export, or recover handles for an existing Grasp table.
---

# Working With Tables

Use table handles deliberately. Do not guess field names. Treat `grasp_get_table` previews as samples.

This is a table-mechanics skill. If the user wants to screen, qualify, shortlist, prioritize, rank, select top-N, map a competitor landscape, or turn a long list into a decision set, use the `screening-and-shortlisting` skill; call this skill only for the underlying inspection, coverage, query, filter, sort, export, or missing-row operations.

## Handles

- Use UUID `table_id` values as tool handles.
- Do not pass `table_slug` as a tool handle. Slugs are display, navigation, and SQL identifiers only.
- If the user refers to recent work, use the `grasp_list_tables` tool to recover the UUID `table_id` and, when needed for composition, `conversation_id`.
- If the user gives a recent async job, wait or check status to recover the UUID `table_id` and `conversation_id`.

## Workflow

1. Use the `grasp_get_table` tool for metadata, columns, version, row count, and links.
2. Use the `grasp_get_table_rows` tool for focused row reads, samples, top-N pulls, filters, and sorts.
3. Use the `grasp_describe_table` tool for missingness, top values, and distributions.
4. Use the `grasp_query_table` tool for read-only counts, aggregations, combined criteria, and computed comparisons. Results are capped, so export when the full result set matters.
5. Use the `grasp_export_table` tool when the user needs the full table or local analysis beyond query caps.

Use rows, describe, query, or export before making full-table, top-N, or coverage claims. When summarizing table/query results, state row counts and whether the result is a preview, sample, capped query, filtered row set, or full export.

## Filtering And Sorting

- Call the `grasp_get_table` tool before using a field name.
- Use the `grasp_describe_table` or `grasp_query_table` tool to check missingness, distributions, and categorical values before filtering.
- Do not filter on a field just because it exists in another table.
- Avoid keyword filters for semantic fit; add a narrow research column through the `table-enrichment` skill instead.
- Use the `grasp_get_table_rows` tool for simple filtered reads and top-N pulls.
- Use the `grasp_query_table` tool for counts, distributions, aggregations, and combined criteria.
- Use the `grasp_update_table` tool only when the user wants the filtered/sorted view persisted in Grasp, and include a short `version_summary`.
- If blanks remain after filtering, state that missing values were not fully tested.

## Missing Company In A Table

- Use the `company-lookup` skill first to validate the expected company and canonical URL/domain.
- Inspect whether the table scope, geography (`source_geography` from `grasp_get_table`, including whether multinationals were included), source criteria, filters, size constraints, ownership constraints, and semantic research columns should include it.
- Check whether it is present under another name, URL, or parent before calling it absent.
- If it is outside scope, explain the mismatch.
- If it appears to be a false negative, present it as a corrected-table/manual-add/watch item and explain the evidence gap.

Use the `grasp_read_docs` tool for SQL, filters, exports, or data-column details when uncertain.