ICP Prompt Builder

Build a company-qualification prompt that reflects the user's actual judgment before it is applied at scale.

The skill tunes the decision rules. It does not build the company list, enrich contacts, validate emails, or launch outreach.

Required input

Collect:

• the company selling the offer;
• the offer being sold;
• a plain-language description of the ideal customer;
• examples of companies that clearly fit;
• examples of companies that clearly do not fit;
• hard exclusions;
• the fields available in the company data;
• the file or table containing the candidate companies.

If the user already has written ICP rules, use them. Do not replace them with generic industry assumptions.

Evidence rules

• Use only the supplied company fields and approved live research.
• Keep company fit separate from timing signals and contact roles.
• Do not treat industry labels, job titles, funding, or headcount as proof of need unless the user made that rule explicit.
• Missing evidence stays unknown.
• A confidence score never overrides a hard exclusion or missing required evidence.
• Do not spend data-provider credits or call an external scoring API without explicit approval.

Tuning loop

1. Write the first rule set

Turn the user's input into four sections:

1. required conditions;
2. preferred conditions;
3. hard exclusions;
4. evidence and missing-data rules.

Every rule must be testable against a named field or an approved source. Ask one question when a rule cannot be applied as written.

2. Select ten test companies

Choose a mixed batch:

• likely fits;
• likely non-fits;
• borderline cases;
• different sizes, industries, and locations when those dimensions matter.

Each row should include at least a domain or official website, company name, description, industry, and headcount when available.

3. Build the qualification prompt

Use this output contract:

{
  "company": "example.com",
  "qualified": true,
  "confidence": 0.0,
  "required_conditions": [
    {"rule": "string", "result": "pass|fail|unknown", "evidence": "string"}
  ],
  "hard_exclusions": [
    {"rule": "string", "result": "clear|matched|unknown", "evidence": "string"}
  ],
  "reason": "one concise sentence",
  "missing_information": ["string"]
}

The prompt must define:

• which fields the evaluator may use;
• what each rule means;
• which exclusions override all other findings;
• how unknown values affect the result;
• the exact JSON output;
• a requirement to quote or name the evidence behind each decision.

4. Evaluate the batch

Run the prompt on the ten companies.

Use parallel sub-agents only when the environment supports them and the user has not restricted delegation. Otherwise evaluate the batch in the current session.

Do not let one evaluator see the user's expected answer for a company before it produces its result.

5. Review with the user

Return a compact table:

Ask the user to identify:

• wrong decisions;
• correct decisions reached for the wrong reason;
• missing exclusions;
• rules that are too broad or too narrow;
• evidence that should not count.

Record every correction. Do not silently reinterpret it.

6. Revise and test a new batch

Update the prompt only from the user's corrections or new verified evidence. Show the exact rule changes.

Then test a new set of ten companies. Do not reuse the same examples as the main validation batch.

Any correction resets the clean-round count to zero.

7. Stop after two clean rounds

The prompt is ready only after two consecutive batches require zero corrections.

Do not auto-approve the prompt because the results look plausible. The user owns the qualification judgment.

If the prompt has not converged after five rounds, stop and identify the cause. Common causes are thin company data, conflicting rules, or an ICP definition that depends on information the list does not contain.

Save the result

Create two files in the user's chosen working folder:

icp-prompt.md

Include:

• the final prompt;
• input fields;
• required conditions;
• preferred conditions;
• hard exclusions;
• missing-data rules;
• JSON output contract;
• the approval date.

icp-prompt-tuning-log.md

Include:

• each test company;
• each original decision;
• every user correction;
• the rule change caused by that correction;
• the two clean validation rounds;
• unresolved data limitations.

Applying the prompt at scale

Scaling is a separate decision.

Before scoring the full list:

1. confirm the final prompt and input columns;
2. confirm the scoring tool or model;
3. estimate any API cost;
4. get approval for paid processing;
5. preserve the raw input and scored output;
6. manually review a sample of accepted and rejected companies.

Do not discard rejected rows. Keep the decision, evidence, and prompt version so the result can be audited.

Completion

The work is complete when:

• the final prompt has passed two clean rounds;
• the user approved it;
• the prompt and tuning log are saved;
• missing evidence and unresolved edge cases are documented;
• no large-scale or paid run occurred without approval.