CtrlK
BlogDocsLog inGet started
Tessl Logo

set-qualification-rules

Use when converting supplied ICP criteria, exclusions, consent requirements, or evidence standards into deterministic eligibility rules.

68

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Set Qualification Rules

Purpose

Create a reusable ruleset and decision algorithm. Separate rule authoring from record evaluation and scoring.

Required inputs

  • Supplied account and contact inclusion criteria
  • Explicit exclusions and terminal consent rules
  • Required evidence for each criterion
  • Optional record for a requested example evaluation

If a required rule or evidence standard is missing, record it as missing rather than inventing one.

Workflow

  1. Reject criteria based on protected traits or unnecessary sensitive personal data, even when supplied. Do not encode or infer them.
  2. Convert each lawful, relevant inclusion criterion into an independently checkable rule with PASS and FAIL conditions.
  3. Convert each valid exclusion into a hard-disqualification rule whose FAIL forces INELIGIBLE.
  4. Define missing, stale, ambiguous, or conflicting required evidence as FAIL and record the missing field.
  5. Write the decision algorithm: evaluate hard disqualifiers first; return ELIGIBLE only when every inclusion rule passes and none applies; otherwise return INELIGIBLE.
  6. Evaluate only an explicit record when requested. Label it Optional example; otherwise produce no aggregate decision. Normally route direct or batch evaluation to match-icp.
  7. Define scoring, if requested, as a later process available only after an ELIGIBLE record decision.

Output format

Rule IDEligibility or scoringObservable checkPASSFAILEvidence requiredHard disqualifier
[ID]Eligibility[single check][condition][condition][source field]Yes / No

Then state:

  • Decision algorithm: [ordered reusable logic]
  • Rejected criteria: [unsafe or invalid supplied rules and reason]

Only when an explicit record is supplied and evaluation is requested, add:

  • Optional example — Decision: ELIGIBLE | INELIGIBLE
  • Failed rules: [IDs and supplied evidence]
  • Missing evidence: [required record facts not supplied]

Guardrails

  • Use observable conditions, not vague fit, enthusiasm, or model judgment.
  • Reject protected-trait targeting and unnecessary sensitive-data collection or inference, including health or family-status details.
  • Use only lawful, necessary, relevant business criteria. Require human and legal review for jurisdiction-sensitive rules.
  • Never let a score, reply, or apparent intent offset a failed eligibility rule.
  • Do not invent alternate titles, equivalencies, thresholds, exceptions, or evidence.
  • Keep facts, inferences, and missing information distinct.
  • Do not research, score live records, send outreach, or mutate external systems.

Quality check

Confirm rules return PASS or FAIL independently; unsafe criteria are rejected; jurisdiction-sensitive rules require human and legal review; one hard disqualifier or required missing evidence yields INELIGIBLE; and no decision appears without a record.

Example invocation

Use set-qualification-rules on the Northstar Relay fixture. Encode the company, size, operating-function, employer, role, competitor, and opt-out gates as a reusable ruleset without evaluating a record.

Repository
llaskin/AI-SDR-Skill-Pack
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.