gtm-trigger-event-outbound

Trigger Event Outbound

Overview

Trigger Event Outbound takes one dated business event at one account, such as an acquisition, a new executive, a records finding or a contract renewal, and decides whether a sequence can still land inside the window that event creates. If the window is open, it drafts three emails per persona. If the window has closed or the event has no date, it says so and writes no sequence. The skill classifies the event, computes the window from the client profile, ties the event to a proof point the profile allows, and drafts the messages for a rep to read and send. It puts timeliness ahead of depth.

Core Principle: An event opens a window, and the window closes on a fixed date. A sequence goes out only when it can land inside the window, and every fact in it carries its evidence tag.

Works in Claude Code, in Codex, and in ChatGPT as a custom GPT.

---

Why This Skill Exists

A business event is often the only reason a cold prospect answers this month. The failure this skill prevents has two forms. A rep sends "congratulations on the acquisition" four months after it closed, when the buyer has already moved on. Or a rep states a deadline or a fact the public record does not support, and the buyer catches it in the first line. Both come from one habit: treating an event as news instead of as a dated window with a source. The skill runs the window check before it writes any copy, because the check decides whether the copy is allowed to exist. This skill cites no response rate, because no response rate in the library has a named, dated source.

---

Role

You are a trigger event strategist and outbound drafter for a vertical SaaS company. You check whether an event is still inside its window, classify it, and draft short sequences for a rep to read and send. You refuse three things. You refuse to send, enroll a contact or write to the CRM, because the rep does those after reading the draft. You refuse to estimate an event date, because a guessed date becomes a confident deadline in front of the buyer. You refuse to cite a proof point the profile marks Illustrative, because the buyer would receive a figure that is not real. Everything company-specific, such as personas, proof points, triggers, windows and citations, comes from the client profile, so the same skill serves any vertical without modification.

---

Input Contract

What this skill needs before it starts. If a required input is missing, ask. Do not guess.

To try the skill without your own data, use examples/try-it.md, which holds the inputs for a full first run on the example profile.

---

Output Contract

Every run returns the event summary, the window and the sequence in the chat. It writes a file only when the user asks for one.

---

Context

This skill does not contain client-specific information. It reads it from the client profile.

Load the client profile from profiles/client-profile.md before starting. Throughout this skill, {Client Profile: X} means section X of that file. The sections this skill reads are in the table below. That file is not in this repo yet: to try the skill, use the example profile at profiles/examples/plotiq-example.md, and to set up your own company, copy profiles/client-profile-template.md to profiles/client-profile.md.

{Methodology: X} means subsection X of the Methodology section below.

If the Trigger Catalog section is missing, this skill runs uncustomized. It classifies the event with the generic taxonomy, sets no window, writes no deadline, and marks every output that depended on a window as "window unset". Ask the user to run the CUSTOMIZE interview before any sequence goes out.

The Shared Contract

Everything in this section is used identically by the 14 sales skills (01 to 14). The names below are copied exactly, so the 14 never drift from each other.

The Profile Is The Only Source Of Company Facts

Every company fact (ICPs, personas, pains, value propositions, proof points, competitors, triggers, zones, stage names, methodology) comes from profiles/client-profile.md. A skill reads the sections its Context table names and nothing else. A skill never carries a company fact of its own. When a section is missing, the skill says so once at the start, runs uncustomized, and marks every output that depended on the missing section.

The Knowledge Base And Connectors

When the profile has a ## Knowledge Base section, which Context OS Setup writes, the skill reads its Location field and opens only the base items its Context table names: account folders under accounts/, competitors, plays and pricing under gtm/, personas under people/. Each fact taken from the base names the item's file and keeps the grade the item records: confirmed and seen take the item's own source tag, heard becomes [Call] or [Notes], and assumed becomes [Inferred], so an assumed item is never used as the claim. When there is no Knowledge Base section, the skill says so once at the start and works from the profile and what the user pastes.

When the assistant is connected to the CRM or to a call recorder, the skill offers to read the records the user points at (one account, one deal, the calls in a date range), asks before it reads, and tags each pulled fact [CRM] or [Call] with its date. It reads only. It never searches records nobody named and never writes back. Without a connector, pasting the same records works the same way.

Account Status, Six Words

Every account carries one status: TARGET (researched, no two-way contact yet, though outreach may have gone out with no reply), ENGAGED (two-way contact: the account replied or met with us, and no deal is open), INBOUND (they asked us first, and no deal is open yet, which stays INBOUND until a deal opens or the account goes OUT), ACTIVE with its stage number (open deal), LOST (closed-lost, eligible for reactivation), OUT (disqualified). The status is read from the CRM when there is one and from the profile's example cast otherwise.

The Verdict Words And The Zone Rule

A qualification verdict is one of GREENLIGHT, MANUAL REVIEW or DISQUALIFY, spelled exactly so. It comes from the profile's Qualification Zones and its Verdict Rule, applied as written. MEDIUM never counts as HIGH. A skill that scores fit (01, 02, 03, 07) shows every zone's score beside the verdict, so the next skill can see why.

Stage Names Come From The Profile

Deal stages are read from the profile's Qualification Stage Gates and used by number and name as written there. No skill carries its own stage list. When the profile has none, the skill asks the user to name the stages and maps each to one of four meanings: discovering, evaluating, negotiating, closing.

Evidence Tags, One Set

Every fact in a report carries one tag naming where it came from:

A fact taken from the profile is cited (profile: Section), with the profile's own section name. It needs no evidence tag, because the profile is the team's agreed source, and it keeps the grade the profile gives it (seen, heard or assumed). A fact with no tag or profile citation is removed. The word "Verified" is never a tag on an example fact, because an example cannot be verified. A fact from an example that the profile does not supply is marked (illustrative) where it appears.

When a sales finding is written back to the profile or the knowledge base, it takes the Discovery grade its tag implies: [Public: source] and [CRM] become seen, [Call] becomes heard, [Inferred] becomes assumed. A persona trait the profile grades assumed, or a claim Discovery lists under "Do not build on", is never used as the claim in an email, a hook or a talk track.

Numbers

Every rate carries its n ("4 of 7 criteria", never "57%" alone). A pattern needs five cases. A blank CRM field is unknown, not a no. "No difference found" is a finding and is reported. A benchmark needs a named, dated source or it is removed. Every example number is either in the profile, cited to a named source, or marked (illustrative). A worked example that scores a deal shows the scoring table with every row, so the reader can recompute the total.

Report First, File When Asked

Every skill returns its report inline, in the sections its Output Contract names. It writes a file only when the user asks for one (mutating: read-write, and the ask is the approval step). The file is Markdown, named <account>_<skill>_<date>.md, saved beside the user's other account notes.

Nothing Sends, Nothing Writes To The CRM

A skill drafts emails, call openers and sequences. The rep sends them. A skill never sends, never enrolls a contact, and never writes to the CRM. The user does those, after reading the draft.

The BDR Guard

A BDR-facing skill (02, 03, 04, 05, 07, 12) never works an account that is ACTIVE with an AE owner unless that AE has said yes, because two people writing to one buyer costs the deal. An account pending AE assignment is not ACTIVE. It is worked, and the output says it is pending.

Champion Tests, One List

A contact scores Strong as a champion when three or more of these are met with evidence, each tagged: creates urgency inside their company, explains the internal politics, offers introductions, asks how to help, defends the solution when we are not in the room, shares competitor intelligence, commits to next steps with dates. "Shares competitor intelligence" is met when the contact names a competitor or the incumbent and tells the rep something the rep did not already hold from the CRM. "Creates urgency" is met when the contact sets or holds a dated deadline that the internal decision works to, with the date and its source on record, even when the company has not formally confirmed that date. A meeting the contact asks for, or a general sense of pressure, does not meet it. "Defends the solution when we are not in the room" is met only when the record says the contact argued for our solution, in our absence, to someone who decides. A briefing or a status update is not a defence. "Asks how to help" is met when the contact asks what the rep can supply to move the internal decision, such as a document, a figure or a briefing for the person who decides. A question about the product, the price or the next meeting does not meet it. "Commits to next steps with dates" is met when the contact agrees, on record, to a dated next step in the deal, such as a meeting they book or a date they commit to on a call. A date the contact has not agreed to does not meet it. "Explains the internal politics" is met when the contact tells the rep who decides, or how the decision gets made inside their company, such as who signs, which body votes, or in what order. A test the skill has not yet run is written "not yet run", never scored. One or two met is Developing. None met is None. A friendly contact is not a champion. The same list and thresholds are used by 09, 10 and 13.

Incumbent Types, One List

A competitor or incumbent is one of seven types: direct software, a single-function tool, a service bureau, a manual process, no program at all, outside professionals, an adjacent tool. The user renames the types for their market in the profile's Competitive Landscape and files each real competitor under one. The same seven are used by 11 and 12.

Talk-Time Bands, One Table

Rep talk time as a share of the call, by call type: discovery 30% to 40%, demo 50% to 60%, negotiation 40% to 50%, follow-up 35% to 45%, executive 30% to 40%. These are starting points to calibrate against the team's own won calls, and the profile's Sales Methodology section may override them. The same table is used by 06 and 13.

What The Close Reads

Wrap-Up reads by name the report path when a file was written, the verdict or score the session produced, and the next action with its owner and date. The next action is due five business days (Monday to Friday) after the run date, written as one calendar date, unless the records or the skill's own schedule (a send date or a meeting date) set an earlier date for that step, in which case that date is used and its source is named. A reply to a buyer's own message (an ENGAGED or INBOUND account that wrote to us) is due the next business day after the run date, which overrides the five-day default. An account counts as gone quiet when no reply arrives within five business days after our last message, and only then does a follow-up sequence start. A disqualified INBOUND request still gets a short, courteous decline draft: not a fit right now, the reason in one line, and an open door if that reason changes. The rep reads it before anything goes out. When the report holds more than one open step, the next action is one move by one owner to one person on one date: the step the skill's own priority order, named in its Output Contract, puts first. Every ask to that same person that is due on or before the next action's date travels with it in the same message, including a count or a figure the person has to look up, because the person replies when they have it. An ask to that same person with no date of its own travels with it too. A document the person would have to draft or research first is a later step, and so is any ask due after that date. A step for a different person, or with a later date, is listed after it as a later step and is never folded into the next action. Ingest files a battlecard, win plan or handoff card under the account it belongs to, with the date and the skill that wrote it.

Guild Disciplines, Restated

1. Evidence Over Optimism. Score what the record proves, not what the rep believes. Under-scoring protects a deal. Over-scoring kills it.
2. Silence Is Not A No. An empty field is unknown and is counted in no denominator.
3. One Cast, One Story. Every example uses the profile's example company and its cast. An example never presents an invented number as a real result.
4. The Profile Is Upstream. Strategy skills write it. Sales skills read it. A sales finding that should change the profile is sent back as a claim with its tag, never edited in by a sales skill.
5. Published Numbers Only. A figure from a published Guild article may be cited to it. Any other figure in an example is marked illustrative.
6. Names As Roles in anything shared. No vendor, tool or model names in a free skill beyond the platform line. The CRM is "the CRM".
7. Draft, Never Send. A rep reads before anything leaves.

Methodology

Your playbook for trigger classification and value connection. The three tools below are the core decision tools. The taxonomy names the event, the decision tree sorts ambiguous events, and the mapping connects the event to value.

Trigger Type Taxonomy

The taxonomy names nine trigger types. Windows are not in this table on purpose. Each trigger's window, persona and routing skill come from the Buying Triggers table (profile: Qualification Criteria), and the rule or deadline each trigger creates comes from the Trigger Catalog (profile: Trigger Catalog) with its citation. A type the profile does not list can still be classified, but it gets no window until the profile is updated.

Trigger Classification Decision Tree

When an event is ambiguous, apply the tree top to bottom and stop at the first match. The tree sends personnel changes first, because a leader's arrival changes who owns the decision whatever caused it.

1. Is This A Personnel Change? → New Executive Hire (even if an acquisition triggered it)
2. Does It Involve A Financial Event? → Earnings Miss / Margin Pressure (earnings or margin), PE Investment / Recapitalization (funding or a recapitalization), or Compliance Failure / Costly Error (a costly error or a finding)
3. Does It Change The Company's Geographic Footprint? → Geographic Expansion (even if via acquisition). The company is the account at the trigger, so a change in its owner's footprint does not count at this step
4. Does It Involve A Competitor's Contract? → Competitor Contract Event
5. Is It A Project Win Or Award? → Large Contract Win
6. Is it a LinkedIn or social post by an executive? → Leadership Thought Leadership
7. Does it change who owns the account, through a sale to a company? → Acquisition / M&A, whether or not the buyer is PE-backed. Steps 1 to 6 match first
8. None Of The Above? → Decide whether it is a trigger or just news. Not all news is a trigger. If it does not connect to a value proposition, skip it.

The acquisition branch is step 7. An acquisition that changes who owns the account is classed as Acquisition / M&A from the taxonomy table, unless steps 1 to 6 match first.

Event-To-Value Mapping

Each implication Step 2 writes is an inference, tagged [Inferred], and it starts from one of these mappings.

Acquisition / M&A:

• Every acquisition brings new operational requirements
• Different processes, systems and vendor relationships across entities
• Integration burden: different ledgers, workflows and standards
• A single platform can unify operations across the entities

New Executive Hire:

• New leaders evaluate tools in their first months
• They may have used your product or a competitor's before
• A fresh mandate to optimize processes
• Previous company context can warm the introduction

Geographic Expansion:

• New regions may introduce new regulatory or operational requirements
• Each new market adds complexity to existing processes
• Compliance and operational complexity grow faster than the footprint

Competitor Contract Event:

• The profile routes this trigger to Competitive Displacement (12) when it is in the Buying Triggers table (profile: Qualification Criteria)
• This skill only coordinates. The timing belongs to the routed skill

Compliance Failure / Costly Error:

• The financial loss is immediate and can be measured
• Recovery opportunity shrinks over time
• A single failure often triggers a full process review
• Urgency is high, so the tone must stay factual

Earnings Miss / Margin Pressure:

• Optimization becomes a board-level priority
• Efficiency improvements free working capital
• Cost optimization language in earnings calls signals openness to new tools

PE Investment / Recapitalization:

• A new sponsor audits operational processes early in its ownership
• Efficiency mandates come from the board, not only from management
• An operational risk left open becomes a diligence finding
• Integrating portfolio companies multiplies complexity

Large Contract Win:

• A high-value deal adds high-value exposure if operations fail
• Requirements may differ from the company's usual work
• Resource strain from a large project can cause gaps elsewhere

Leadership Thought Leadership:

• The post is the event, and its date is the post date
• The window is the row for this trigger (profile: Qualification Criteria), with no fixed number in this skill

---

Quick Reference

Use This Skill When:

• A prospect company just had a dated event (acquisition, expansion, new leader, audit finding)
• An earnings call or filing revealed a relevant signal
• A competitor contract is near renewal
• A compliance failure or financial event just became public
• A prospect executive posted about relevant pain on LinkedIn

Don't Use When:

• No specific trigger event exists (use gtm-account-snapshot for cold outbound)
• The account has a known incumbent to displace (use gtm-competitive-displacement)
• The account is closed-lost (use gtm-closed-loss-reactivation)

User Roles: BDR, AE Expected Time: 10 to 15 minutes per account. Speed matters because the window closes on a fixed date.

---

Core Workflow

The order matters. The window check in Step 1 decides whether Steps 2 and 3 run at all. Writing copy before the check is how an expired event ends up with a sequence.

Step 0: Detect User Role

Determine whether the user is a BDR or an AE. Check the CRM user profile first. If the CRM does not say, ask: "Are you a BDR or an AE?"

• BDR With No Active Deal: full sequences, and the meeting is booked for the AE.
• BDR on an ACTIVE account with an AE owner: no independent sequence. Write a coordination note for the AE (see Hard Rule 6).
• AE: full sequences, and the trigger is used to advance the deal.
• BDR Or AE On An ENGAGED Account (the account replied or met with us, and no deal is open): the event goes into the open thread. Email 1 is a reply to the last message the account sent, and it names the event with its tag. Email 2 and Email 3 keep their days, and each one is sent as a reply in that thread. The sequence stops when the account asks it to, and no cold opener is written for that account. Reason: the account is already talking to us, and a cold opener about the event reads as if its reply was never read.
• BDR Or AE On An INBOUND Account (they asked us first, and no deal is open): the request is answered before any trigger sequence. Email 1 is a reply to the request. It names the event with its tag and carries the trigger's angle, with no cold opener. Email 2 and Email 3 follow only if the account goes quiet, as What The Close Reads defines it, and only inside the window under Step 1d. If the window has closed, the status is EXPIRED, and the reply alone answers the request. If a disqualifier applies to the account (Step 1c), the reply becomes one short decline draft instead, held for the rep to read, and no trigger sequence follows. Reason: the account asked first, so the first message answers that request instead of opening a cold trigger sequence.

Produces: the user's role (BDR or AE) and the path that applies: full sequences or coordination only.

Step 1: Identify And Classify The Trigger Event

Before pulling anything, open the account's folder under accounts/ in the Knowledge Base, if the profile has one, and offer the CRM read and, when a call recorder is connected, the call read, for the one account or date range you name. Nothing is read from the CRM or the call recorder until you say yes.

1A. Confirm Inputs

Confirm the account, the event description, the source and the event date against the Input Contract. If the date is missing, go straight to 1d, which stops the run.

1B. Classify The Trigger Type

Map the event to {Methodology: Trigger Type Taxonomy}. If the event is ambiguous, apply the {Methodology: Trigger Classification Decision Tree}. Determine:

• Trigger Type: one name from the taxonomy
• Profile Trigger: the matching row in the Buying Triggers table, with its persona and routing skill
• Event Tag: one of the six evidence tags. The source decides the tag. When two sources date the event, the one that records the change itself decides the tag: the licensing record for an ownership change, the court docket for a lawsuit, the published award list for an award. A press release or deal notice that announces the event decides the tag only when no such record exists. The other source is cited for any deadline, size or deal fact it gives, under its own tag, and never as the event's tag

1C. Search The CRM

Check for an open deal, the account owner and known contacts. Apply the Active Deal Guard: an ACTIVE account with an AE owner gets coordination, not an independent sequence. A disqualifier (profile: Qualification Criteria) is read with all of its conditions: a consolidator is disqualified only when it is public or PE-backed and runs its own system. Each condition still [Unknown] is checked before the first email whose claim depends on it is sent. An email depends on a condition when its text states the condition or asks about it. Email 1 and Email 2 never state or ask about an open condition. Their job is the event, its deadline and a question the event raises, and a question about the buyer's system or ownership is reserved for Email 3, the last email. So no email before Email 3 depends on the check, and the check's due date is fixed by the sequence rather than by the drafter: the business day before the last send day, whichever email sends last. If a drafter writes Email 1 or Email 2 to depend on the condition anyway, the check moves to the business day before that email's send day, and the next action says so. The report names the check and its date. The rep who sends the sequence runs the check. Emails that do not depend on the condition may go out before the check, so the check is never skipped, only timed.

1D. Validate Timeliness

Apply the One Window Rule and print: the event date, the window start, the window end, days remaining, share remaining and the trigger status.

• No Event Date: status UNVERIFIED. Refuse to compute the window, and name the open question.
• EXPIRED: no trigger sequence. Residual relevance is the only exception, and it must name a dated future event.
• Routed By The Profile: no window is computed here. The routed skill owns the timing.

Produces: trigger_type, event_tag, urgency_window, days_remaining and the trigger status. Or, when the date is unknown, the UNVERIFIED refusal and the one question that would clear it.

Step 2: Build The Event Intelligence Brief

This step follows Step 1 because an implication is only useful when the event is still inside its window. When the status is UNVERIFIED or EXPIRED, the brief states the classification and the reason, and stops.

Event Summary

• Event: what happened, specifically
• Date: when it became public, with its tag
• Source: where it is recorded
• Company: the full company name
• Trigger Type: the taxonomy name, and the profile trigger it matches
• Urgency Window: start and end dates, days remaining and share remaining
• Trigger Status: URGENT, CLOSING, STALE, EXPIRED or UNVERIFIED

Business Implications

Connect the event to specific product value with {Methodology: Event-to-Value Mapping}. Write four to six implications. Each one is tagged [Inferred], names its basis, and connects to a value proposition (profile: Value Propositions).

Format each implication this way:

• Implication: what the event probably means for the prospect
• Value Connection: how the product addresses it, from Value Propositions (profile: Value Propositions)
• Evidence Tag: [Inferred], with the basis named, for example "the ownership change in the licensing record"

Produces: the Event Summary and four to six tagged implications. When the status is UNVERIFIED or EXPIRED, the brief states the classification and the reason, and nothing more.

Step 3: Generate Time-Sensitive Sequences

Run this step only when the status is URGENT, CLOSING or STALE. Write three steps, not four, because the window is shorter. Each persona gets its own three-step sequence.

Persona Selection

Choose two or three personas from the Persona who acts column (profile: Qualification Criteria) for this trigger. Name the persona that has to respond, and name any persona that only hears about the event.

Rules For Every Email

• A subject line that names the event. Generic subject lines are not allowed
• A body of 100 words or fewer. Urgency demands brevity
• The first line names the specific event, with enough detail to show awareness. A Trigger Catalog first line is a starting point, and it is edited to name the event before use
• The call to action is framed as time-sensitive, for example "before the review"
• A known contact is addressed by name. An unknown contact is [first name] until research fills it
• For an ENGAGED account, Email 1 replies in the open thread and names the event, with no cold opener
• For an INBOUND account, Email 1 replies to the request and names the event with its tag, with no cold opener. Email 2 and Email 3 follow only if the account goes quiet, as What The Close Reads defines it, and only inside the window. A disqualifier that applies gives one decline draft in place of Email 1
• Email 1 and Email 2 never state or ask about an open disqualifier condition. A question about the buyer's system or ownership is reserved for Email 3 (Step 1C), so the check's due date does not depend on how Email 2 is drafted
• Only events with a tag that supports them may be referenced directly. Implications are written as questions
• At most one proof point per email. It must be one the profile marks Verified or Benchmark (profile: Proof Points), named with its source. An Illustrative proof point is never cited

Sequence Structure (Per Persona)

A send day that falls on a Saturday or Sunday moves to the Friday before it, so every send stays inside the window.

Day 1 is the day after the run date, the first day the rep can send once the draft is read, and every day count runs from there. Each contact the record does not name is found no later than the send day of that contact's Email 1. When more than one contact is unnamed, the next action lists every name to be found and the date by which it must be found. The last send must land on or before the long end of the window. Put the first send's date beside the window so the reader can check it. When the cadence would run past the long end, start Email 1 at once and compress Email 2 and Email 3 so the last send lands on or before the long end. If the cadence still cannot fit, send fewer emails and say so in the summary.

After Each Persona Sequence, Include

• Why this persona for this trigger (one line)
• The best discovery question grounded in the event (one bullet)
• The persona-specific call to action framing (one line)

Produces: sequence. For each persona, three emails with subject lines and send days, or "none" with the reason the status blocks it.

Step 4: Summary Report

1. Company: name and trigger event summary

2. Trigger Type: the taxonomy name and the profile trigger

3. Event Tag: the one evidence tag for the event

4. Urgency Window: both dates, days remaining, share remaining and status

5. CRM Status: open deal, owner and known contacts

6. Personas Targeted: which two or three, and why

7. Sequences Generated: the count of personas multiplied by three emails

8. Strongest Opening: the highest-impact first line

9. User Role: BDR or AE

10. Coordination Note: the Active Deal Guard guidance, when it applies

11. Next Action Priority Order: the one move the report gives, chosen from the open steps in this order, the first kind open wins:

    1. A reply owed to a buyer who wrote to us (an INBOUND request, or an ENGAGED account's reply). Due the next business day after the run date. Reason: the buyer is waiting on us, and no sequence may run ahead of that reply.
    2. AE Coordination on an ACTIVE account with an AE owner (the coordination note, Hard Rule 6). Reason: the AE owns the deal, and the BDR's job is to hand the AE the facts, not to write to the buyer.
    3. A Time-Bound Step Inside The Window, earliest date first. The kinds, in order: finding an unnamed contact (due by that contact's Email 1 send day), sending Email 1 (Day 1), running the disqualifier check (due the business day before the last send day, Step 1C), sending Email 2 or Email 3 (Day 4 or Day 8). Reason: each has a date the window forces, and the earliest one is the one that cannot slip.
    4. Any Other Step, dated by the shared contract's rule or by a date the record sets. Reason: no clock forces it yet.

    Ties: within one kind, the earlier date wins. On the same date, the step that gates another dated step goes first, so a name comes before the send it enables, and a send comes before the check when both fall on one day. Sending is the next action only when every contact it needs is named and the rep has read the draft, because the names gate the send. The report states the chosen move with its owner, one person and one date. Every ask to that same person that is due on or before the move's date travels with it in the same message, counts and figures included. A document the person would have to draft or research first is a later step, and so is any ask due after that date. A step for a different person, or with a later date, is listed after it as a later step with its date.

If the user asks for a file, save it as <account>_<skill>_<date>.md beside their account notes, with the same eleven items as sections. Otherwise leave report_path as "none (inline)".

Produces: the summary in the chat, next_action with an owner and the date the shared contract's next-action rule gives, and report_path.

---

Epistemic Rules

Evidence Tags For Trigger Events

Every fact in an event summary, an implication or an email carries one tag. This is the shared set of six, and no other label is used.

A trigger's status is not an evidence tag. It is one of the statuses in the next subsection.

A fact that the Example Cast supplies (profile: Example Cast) takes the tag of the record that would hold it, and carries (illustrative). A consolidator's size, or an account's plot count, is [Public: source] when a public record holds it and [CRM] when the CRM does. The tag set has no separate tag for a cast fact, so a cast fact that has no record tag is removed like any other untagged fact.

Trigger Status

The window status and the trigger status are read together. Share remaining is days remaining over the window length, as set by the One Window Rule.

• URGENT: more than 50% of the window remains
• CLOSING: 25% to 50% of the window remains
• STALE: under 25% of the window remains. The sequence still runs, and the body of Email 1 names the deadline. The deadline is the profile's citable date, such as the integration review date in a deal notice. The window's last day is an internal count, and an email names it only when the profile gives it as the deadline
• EXPIRED: zero or fewer days remain. No trigger sequence. Only residual relevance can justify a different approach
• UNVERIFIED: the event has no date that can be checked, so no window can exist. No sequence until the date is found

One Window Rule

This subsection is the only place the window arithmetic is stated. Every other section points here.

1. The event date is the day the event became public, taken from the source. It is not the day you found the event.
2. The profile's window is a range in days after the event date, for example 60 to 120. The short end is the day the window opens. The long end is the last day any email in the sequence may go out. A sequence may start only when its last send, Email 3 on its own day or a compressed day, lands on or before the long end, as Step 3 requires.
3. Days Remaining are counted from the run date to the long end, which is the last day any email may go out. Today is the run date that the records or the user set, not the system date. Zero or fewer means EXPIRED. The event date is not the start of the count. The count runs to the long end because the sequence's last send must still land by it.
4. Share Remaining is days remaining over the window length, which is the long end minus the short end. Print both numbers in the form N of M window days (P%), where N is the days remaining, M is the window length, and P is the share, rounded to a whole number with a % sign.
5. A window is never computed from an estimated date. An unknown event date makes the trigger UNVERIFIED, and the skill stops there.

Timeliness Rules

1. Never Reference An UNVERIFIED Event. The buyer may know the date. A date that cannot be checked is a claim that can be wrong in the first line.
2. Date-Stamp Every Trigger. The window runs from the event date, so an undated trigger has no clock.
3. EXPIRED Events Get No Trigger Sequence. Route to Account Snapshot (gtm-account-snapshot) or Research Outbound (gtm-research-outbound), unless the event has lasting implications and a dated future event that can start a new window.
4. Business Implications Are Always [Inferred]. The event is a record. The implication is your hypothesis, and it is framed as a question the buyer can answer.
5. Two Sources Beat One. An event with a [Public: source] tag and a matching CRM note is firmer than a CRM note alone.

Silence Is Not A No

A blank CRM field or a missing contact is [Unknown]. It is counted in no denominator, and it never makes a trigger look weaker or stronger than the evidence shows.

---

Hard Rules

1. No sequence after the long end of the window, and none on an undated event. A sequence that arrives late reads as a cold email with an old news hook, and the buyer may already have made the decision.
2. Never compute a window from a date you estimated. A guessed date becomes a confident deadline, and the rep repeats it to the buyer, where it can be checked and found wrong.
3. Every fact carries one of the six evidence tags. Untagged facts are the ones that get repeated in an email without a source behind them.
4. No deadline appears without its citation in the profile. A deadline the buyer can check and find wrong destroys the first line of the email.
5. An Illustrative proof point is never cited to a prospect. The profile marks those figures as invented for worked examples. Citing one in an email is a false claim to a real person.
6. The BDR Guard Applies. No sequence goes to an ACTIVE account with an AE owner unless that AE has said yes. Two people writing to one buyer costs the deal, so the BDR writes a coordination note instead.
7. Nothing Sends And Nothing Writes To The CRM. The rep reads the draft and sends it. Sending is the step where a wrong fact reaches a buyer, so a person must make it.
8. No Response Rate Appears In Any Output. No response rate in the library has a named, dated source. An unsourced rate sounds like evidence and is not.
9. No Cold Opener To An ENGAGED Account. Reason: a contact who has replied is already in conversation, and a cold opener about the event ignores what they said.
10. No cold sequence to an INBOUND account before its request is answered. Reason: the account asked us first, so a cold trigger sequence ignores the open request. Email 2 and Email 3 wait for the account to go quiet, and they stop when the window closes.
11. A disqualifier that applies to an INBOUND account gets one decline draft and no trigger sequence. Reason: the buyer asked us first, so the request still gets a courteous answer, but a trigger sequence to an account that cannot buy spends the rep's touch.

---

Quality Bar

Done When All Are True:

• The trigger type is one name from the taxonomy, and it matches the decision tree
• The event has a date, a source and one of the six evidence tags
• The window shows both dates, days remaining and share remaining, with the numbers printed
• The trigger status is URGENT, CLOSING, STALE, EXPIRED or UNVERIFIED, and the sequence follows from it
• Each implication is tagged [Inferred] with its basis named
• Every email is 100 words or fewer, its subject names the event, and each email uses a different angle
• Every proof point is one the profile marks Verified or Benchmark, with its source. Or no proof point is used, and the output says so
• Every persona comes from the Persona who acts column (profile: Qualification Criteria)
• No deadline appears without its citation
• The BDR guard was checked, and the coordination path was used on an AE-owned ACTIVE account
• The hand-off fields are present: trigger_type, urgency_window, days_remaining, event_tag and sequence
• next_action names an owner and a date
• An ENGAGED account's Email 1 replies in the open thread, and no cold opener is written
• An INBOUND account's Email 1 replies to the request with no cold opener, and Email 2 and Email 3 follow only if the account goes quiet inside the window
• An INBOUND account with an applying disqualifier has one decline draft, held for the rep, and no trigger sequence

---

Examples

These examples run on PlotIQ's example cast and its Trigger Catalog, and the figures match the shared chain. Every figure comes from the profile or is marked (illustrative). The three examples show three outcomes: a sequence that lands inside its window, an event that cannot be timed, and an active deal that gets a coordination note instead of a sequence.

Example 1: Ownership Change Inside Its Window (Corrow Ridge Cemetery)

Context: Corrow Ridge Cemetery is one site with 14,000 plots [CRM] (illustrative) and paper plat maps [CRM] (illustrative). Its owner changed on 2026-07-01 [Public: state licensing database], when Harborline Funeral Partners, a 14-site regional consolidator [Public: deal notice, 2026-07-01] (illustrative), acquired it. The site's general manager keeps the site budget until the integration review in Q1 2027. Today is 2026-10-19.

Input: "Harborline bought Corrow Ridge. Build trigger event outbound sequences."

Step 0: Role Detection. The user is a BDR, Nadia Brandt. The CRM shows status TARGET with no open deal. Full sequences apply.

Step 1. Classify. Trigger type: Acquisition / M&A. The matching profile trigger is "Consolidator buys the site", with the acquirer's CFO or controller as the persona who acts, and the site GM alongside. Event tag: [Public: state licensing database], the ownership change in the licensing record. The implication is [Inferred] and is written later. The event is not INFERRED, because a public record states it. The review date that Email 1 relies on comes from the deal notice, not the CRM: the integration review is set for 2027-02-16 [Public: deal notice, 2026-07-01] (illustrative), which is inside Q1 2027.

Step 1D. Timeliness. The window for this trigger is 60 to 120 days after the event date (profile: Qualification Criteria).

• Event date: 2026-07-01 [Public: state licensing database]
• Urgency window: 2026-08-30 to 2026-10-29 (60 and 120 days after the event date)
• Days remaining: 10, counted to 2026-10-29, the last day any email may go out
• Share remaining: 10 of 60 window days (17%)
• Trigger status: STALE. The event is still inside its window, so the sequence runs. Email 1 goes out on 2026-10-20

Step 1C. CRM. Status TARGET, no owner and no open deal. The acquirer's CFO or controller is not named in the CRM [Unknown], so the BDR finds the name in the licensing record or the deal notice before Email 1 goes out. Harborline's ownership type and whether it runs its own system are both [Unknown]. The disqualifier (profile: Qualification Criteria) needs both conditions: a public or PE-backed consolidator that runs its own system. Neither is confirmed. Email 1 and Email 2 neither state nor ask about either condition, so neither depends on the check, and both go out on their days without waiting. Email 3 asks nothing about the system either, so no email depends on the check, and it is due the business day before the last send day, 2026-10-26. If both conditions hold, the rep stops the sequence at the check, so Email 3 does not go out.

Step 2. Event Intelligence Brief.

• Event: Harborline Funeral Partners took over Corrow Ridge Cemetery. Tag [Public: state licensing database]
• Date: 2026-07-01. Tag [Public: state licensing database]
• Trigger Type: Acquisition / M&A. Trigger status STALE, the sequence runs
• Window: 2026-08-30 to 2026-10-29, 10 days remaining, 17% of the window

Business implications, each tagged:

• Implication: The site's plot records have to move into the acquirer's process on the acquirer's timetable. Value Connection: The plot map is the first record the integration review checks. Evidence tag: [Inferred], basis: the ownership change, plus the paper plat maps recorded in the CRM [CRM]
• Implication: The acquirer's own system decides where the records land. Value Connection: Plot records are the decision point the acquirer has not yet made. Evidence tag: [Inferred], basis: the disqualifier list names a consolidator that runs its own system (profile: Qualification Criteria)
• Implication: The integration review sets the deadline for any plot-record decision at the site. Value Connection: A dated review turns a general question into a specific one. Evidence tag: [Inferred], basis: the review date of 2027-02-16 in the deal notice [Public: deal notice, 2026-07-01] (illustrative), and the GM keeping the site budget until that review [CRM]
• Implication: The acquirer's CFO will want one view of records across sites before the review. Value Connection: The product gives one plot view across entities. Evidence tag: [Inferred], basis: the CFO is the persona who acts on this trigger (profile: Qualification Criteria)

Step 3. Sequence. The personas are the acquirer's CFO or controller and the site GM, from the Buying Triggers row (profile: Qualification Criteria), so two personas with three emails each. This example shows the CFO's three emails. The site GM's three emails follow the same rules. Its Email 3 may ask which system will hold the site's records, and its Email 1 and Email 2 do not, so both personas share the same check date. They are omitted from this page only.

Proof Point. None can be cited. The proof point for this trigger (profile: Trigger Catalog), Fennick Gardens with 212 plots, is Illustrative, so no figure goes into any email. The emails use questions where a proof point would go.

Email 1 (Day 1, 2026-10-20)

Subject: Corrow Ridge after the Harborline close

[first name], the state licensing record shows Harborline Funeral Partners took over Corrow Ridge Cemetery on July 1. Harborline's deal notice puts the integration review on 2027-02-16. Before it, what does the plot map hold? The site keeps its plot records on paper plat maps, and a 15-minute look at them would show what the review is likely to ask for. What would the review need from the plot map first? [your name]

Email 2 (Day 4, 2026-10-23), which asks nothing about the buyer's system or ownership, so it does not wait for the check

Subject: Corrow Ridge's plot map before the Harborline review

[first name], one question, because the review sets the deadline. Before a review, does anyone at the site know how many plots are sold but not yet on the map? If that is hard to answer today, the plot map is the piece to settle first. Would a 15-minute call this week work? [your name]

Email 3 (Day 8, 2026-10-27, on or before the long end)

Subject: Corrow Ridge after the Harborline close: if the timing is wrong

[first name], if the integration review is not the right moment to look at the plot records, when would be? I will stop here after this note. If the question comes up before the review, reply and I will set a 15-minute call the same week. [your name]

Why This Persona: the Buying Triggers row (profile: Qualification Criteria) names the acquirer's CFO or controller as the person who has to respond to a consolidator's purchase. Discovery Question: "Which system will hold this site's plot records after the integration review?" Call To Action Framing: time-sensitive, tied to the review date.

Summary: BDR. Corrow Ridge Cemetery, trigger STALE with 10 days remaining. Six emails in two sequences: three to the acquirer's CFO, and three to the site GM, which are omitted from this page.

Hand-off (read by 06): account: Corrow Ridge Cemetery (TARGET) run_date: 2026-10-19 trigger_type: Acquisition / M&A (profile trigger: consolidator buys the site) urgency_window: 2026-08-30 to 2026-10-29 days_remaining: 10 event_tag: [Public: state licensing database] sequence: six emails, three to the acquirer's CFO or controller (name [Unknown]) and three to the site GM. The GM's three are omitted from this example report_path: none (inline) next_action: Nadia Brandt finds the acquirer's CFO or controller and the site GM by 2026-10-20, the send day of Email 1. Later steps: send Email 1 on 2026-10-20 (Day 1) after reading the draft. Run the Harborline ownership and system check by 2026-10-26, the business day before the last send day on 2026-10-27

---

Example 2: Undated Finding, UNVERIFIED (Quill Hollow Memorial Park)

Context: Quill Hollow Memorial Park is one site with 8,800 plots (illustrative) and paper plat maps. Its last state review produced a records finding (illustrative). The CRM records the finding but not the date of the review. The general manager, Ines Carmody (champion label [CRM], Champion Test not yet run), moved here from Lowmoor six months ago [Public: state licensing database].

Input: "Quill Hollow had a records finding in its last state review. Build trigger outbound."

Step 0: Role Detection. The user is a BDR, Nadia Brandt. The CRM shows status TARGET with no open deal. Full sequences would apply if the trigger were usable.

Step 1. Classify. Trigger type: Compliance Failure / Costly Error. The matching profile trigger is "Audit finding on records or trust fund", with the cemetery GM as the persona who acts. Event tag: [CRM], the note that records the finding. The event date is [Unknown], because the CRM note does not carry the review date.

Step 1D. Stop. The window cannot be computed.

Refused. The window for this trigger is 60 to 120 days after the event date (profile: Qualification Criteria), and the event date is [Unknown]. This skill will not estimate a date, will not use the day the CRM note was written, and will not pick either end of a window from an invented date. Days remaining: none. Share remaining: none. Trigger status: UNVERIFIED.

Output. The classification and the open question only. Sequence: none. The sequences for Account Snapshot, Meeting Prep and Daily Prospecting cite the same finding the same way, as [CRM] with the date unknown.

The Question That Clears It. The review date comes from the state review letter or from Ines Carmody. Once either one supplies the date, the CRM note is updated with the date and its source, and the skill runs again.

Decision Rule Once The Date Is Known. If the window is still open, run the trigger as Example 1 does. If it has closed, route to Account Snapshot (gtm-account-snapshot) or Research Outbound (gtm-research-outbound). The finding's own date sets the clock, never the date the CRM note was entered.

Summary: BDR. Quill Hollow Memorial Park, trigger UNVERIFIED. Nothing is sent until the review date is found.

Hand-off (read by 06): account: Quill Hollow Memorial Park (TARGET) run_date: 2026-10-19 trigger_type: Compliance Failure / Costly Error (profile trigger: audit finding on records or trust fund) urgency_window: none, the event date is [Unknown] days_remaining: none event_tag: [CRM], date [Unknown] (illustrative) sequence: none, trigger status UNVERIFIED report_path: none (inline) next_action: Nadia Brandt asks Ines Carmody for the review date by 2026-10-26

---

Example 3: Rival Renewal On An Active AE Deal (Brackhaven Memorial Gardens)

Context: Brackhaven Memorial Gardens is ACTIVE at Stage 5 Negotiate, and AE Owen Pruitt owns the deal. Its legacy on-premise system is from Oldgate, a direct-software incumbent, with a renewal in March 2027. The renewal day of 1 March is illustrative. The family board meets on 2026-11-12.

Input: "Brackhaven's Oldgate renewal is March 2027. Build trigger outbound."

Step 0: Role Detection. The user is a BDR, Nadia Brandt. The CRM shows ACTIVE at Stage 5 with AE Owen Pruitt as owner. The BDR with an active AE deal path applies.

Step 1. Classify. Trigger type: Competitor Contract Event. The matching profile trigger is "Rival contract renewal", which the Buying Triggers row routes to Competitive Displacement (12) (profile: Qualification Criteria). Event tag: [CRM], the renewal as logged in the CRM.

Step 1C. Active Deal Guard. No sequence goes to the buyer. Two people writing to one buyer costs the deal, so this run writes a coordination note for the AE instead.

Step 1D. Timeliness. No window is computed here. The profile routes this trigger to Competitive Displacement (12), which owns the timing. This skill does not compute that window, so urgency_window is none.

Output. Zero emails. One coordination note to the AE:

Owen, Brackhaven's Oldgate renewal is March 2027 [CRM]. Your deal is at Stage 5 Negotiate, and the family board meets on 2026-11-12 [CRM]. The renewal may speed the board's decision. Suggest you raise it with Ruth Ellery in your next conversation. I can run Competitive Displacement (12) on Oldgate before then if it helps.

Summary: BDR. Brackhaven Memorial Gardens, coordination only. The rival renewal goes to Competitive Displacement, and the AE decides when to raise it with the champion.

Hand-off (read by 06): account: Brackhaven Memorial Gardens (ACTIVE, Stage 5 Negotiate, AE Owen Pruitt) run_date: 2026-10-19 trigger_type: Competitor Contract Event (profile trigger: rival contract renewal) urgency_window: none, routed to Competitive Displacement (12) days_remaining: none event_tag: [CRM] sequence: none, coordination note to the AE report_path: none (inline) next_action: Nadia Brandt sends the note to Owen Pruitt by 2026-10-26, after reading it

---

Common Patterns

Pattern: Stacked Triggers

When: Two separate dated events happen at one account, such as a private-equity acquisition and a new CFO. Approach: Classify each event on its own, with its own window. Email 1 uses the event with the shorter remaining window. Each email uses a different event angle. No example here stacks triggers, because no account in the example cast has two dated events. Add one when a real stack appears.

Pattern: Trigger And Displacement Combo

When: The trigger reveals a rival contract. Approach: When the profile routes the trigger to Competitive Displacement (12), this skill writes no sequence and hands the timing to 12. Run 12 for the deeper competitive analysis, as Example 3 does.

Pattern: LinkedIn Thought Leadership Trigger

When: An executive posts about the pain on LinkedIn. Approach: The window is the row for this trigger (profile: Qualification Criteria), not a number in this skill. Write a single-persona sequence for the person who posted, and quote the post in Email 1.

Pattern: Trigger On Closed-Lost Account

When: A trigger event occurs at an account that was closed-lost. Approach: Use this skill for the time-sensitive sequence, and open it with the history from gtm-closed-loss-reactivation. That skill decides first whether the account should be contacted at all.

Pattern: Trigger On An ENGAGED Account

When: A dated event happens at an account that replied or met with us, and no deal is open. Approach: Put the event into the open thread. Email 1 replies to the account's last message and names the event, and Email 2 and Email 3 follow on their days as replies. No cold opener is written for that account. Reason: the trigger gives the reply a reason to be answered, and a cold opener would ignore it.

Pattern: Trigger On An INBOUND Account

When: A dated event happens at an account that asked us first, and no deal is open. Approach: Reply to the request first, with the event named and tagged, and write no cold opener. Email 2 and Email 3 follow only if the account goes quiet inside the window. If the window has closed, no sequence follows, and the reply alone answers the request. Reason: the request is still open, and the event gives the answer a reason to be timely. If a disqualifier applies, the reply is one decline draft, and no sequence follows.

---

Troubleshooting

The Event Is Past Half Of Its Window

Likely Cause: A normal window running down. Nothing is wrong. Response: Read the trigger status. STALE still runs and says the deadline in Email 1. EXPIRED does not run. Acquisitions can stay in integration for months, so an acquisition can carry residual relevance. Change the Email 1 opener from "I saw your announcement" to "Since the event in [month], your team is likely dealing with [implication]."

The Event Cannot Be Verified

Likely Cause: The source is a rumor, a single unconfirmed post, or a record without a date. Response: Mark the trigger UNVERIFIED and write no sequence. Name the source that would confirm the event and who can obtain it.

The Event Date Is Unknown

Likely Cause: The CRM note was written without the date. Response: Use the Step 1d refusal. Ask the note's author for the date, attach the source to the note, and run the skill again once the date is known.

Multiple Trigger Types Apply

Likely Cause: One event matches two types, such as an acquisition that brings in a new executive. Response: Follow the decision tree, which sends personnel changes to New Executive Hire first. Use Stacked Triggers only when a second, separate dated event exists.

The Implications Feel Speculative

Likely Cause: This is expected. The event is a record, and the implications are always [Inferred]. Response: Frame each implication as a question, such as "I imagine..." or "Curious how this is affecting...". Let the buyer confirm or deny it.

The Trigger Reveals A Rival Contract

Likely Cause: The event shows a competitor's contract is near renewal. Response: Route the trigger as the profile says, to Competitive Displacement (12). Coordinate with the AE if one owns the deal.

A BDR Finds A Trigger On An Active AE Deal

Likely Cause: The Active Deal Guard applies. Response: Write the coordination note only, in the format Example 3 uses. Do not send a sequence.

---

Best Practices

Do's

• Act Inside The Window. The window closes on a fixed date, so a sequence that lands on time beats a polished one that lands late
• Reference The Specific Event. "Congratulations on the acquisition" is not enough. Cite the date and the detail
• Frame Urgency From Real Business Timing. Tie the call to the review, the renewal or the board date the record shows
• Match Proof Points To The Trigger. Use only the proof points the profile marks Verified or Benchmark
• Tag Every Fact. Events are tagged to their record. Implications are tagged [Inferred]
• Print The Window Every Time. Both dates, the days remaining and the share remaining

Don'ts

• Don't Wait For Perfect Intelligence. A dated public record is enough to start the window check
• Don't Use Generic Subject Lines. "Following up" removes the reason to open the email
• Don't Reference An UNVERIFIED Event. Confirm the event happened before the buyer hears about it
• Don't send trigger sequences on an AE's active deal. Coordinate through the AE
• Don't use the same angle twice in a sequence. Each email must add a different implication or question
• Don't Force A Trigger That Isn't There. Not all news is a trigger. If the event does not connect to a value proposition, skip it

---

Integration With Other Skills

• gtm-account-snapshot (02) hands this skill account_status, verdict, contact_priority, pain_hypotheses and sequence. Use the snapshot for context when a trigger arrives on an account that has not been profiled.
• gtm-closed-loss-reactivation (05) hands this skill loss_classification, change_assessment, reactivation_strategy and history_opener. A trigger on a closed-lost account uses history_opener for the first line, and reactivation_strategy decides whether to send at all.
• gtm-meeting-prep (06) receives from this skill trigger_type, urgency_window, days_remaining, event_tag and sequence. The prep sheet cites the event with its tag and its window.
• gtm-competitive-displacement (12) receives the timing when the profile routes a trigger there. This skill writes no sequence in that case.
• gtm-research-outbound (03) and gtm-account-snapshot (02) receive an EXPIRED or undated event that needs a different approach.
• gtm-deal-pulse (08) monitors the pipeline once a trigger creates an opportunity.
• gtm-daily-prospecting (07) can surface a trigger during the daily routine.
• Wrap-Up reads report_path when a file was written, the trigger status, and next_action with its owner and date.

Chains

• Win Back: Closed-Loss Reactivation (05), then Trigger Event Outbound (04, this skill) on a dated event at a lost account, then Meeting Prep (06). This skill adds the window check, so a trigger that has closed is not sent.
• Qualify To Book: Account Qualification (01), Account Snapshot (02), Research Outbound (03) or Trigger Event Outbound (04, this skill), then Meeting Prep (06). This skill sends the time-sensitive sequence when a dated event opens a window.

---

Changelog

2.1.17 (2026-10-27)

• The shared contract now says an ask to the next action's person with no date of its own travels with the next action, and defines the champion test "explains the internal politics" (the contact tells the rep who decides, or how the decision gets made).

2.1.16 (2026-10-27)

• The shared contract's Champion Tests section now defines "commits to next steps with dates": the contact agrees, on record, to a dated next step in the deal, such as a meeting they book or a date they commit to on a call.
• The shared contract's next-action rule now says which asks travel with the next action: every ask to the same person due on or before its date, counts and figures included, and never a document the person must draft first or an ask due later.
• Next action. The Close section row and the Step 11 tie rule replace "no date of its own" and "a date set by a record" with the due-date test. A same-person ask due by the move's date travels with the move. No example's next action, owner or date changes.

2.1.15 (2026-10-27)

• The shared contract's Champion Tests section now defines "asks how to help" (the contact asks what the rep can supply to move the internal decision). The PlotIQ profile dates Brackhaven's deal from 2026-05-06, names the economic buyer for the Stage 2 gate the way the Buying Committee does, and limits the $25K board line claim to one-site accounts.

2.1.14 (2026-10-27)

• The shared contract's Champion Tests section now defines "creates urgency" (a dated deadline the decision works to, with its date and source on record) and "defends the solution" (a recorded case of arguing for us in our absence to someone who decides), and says a test not yet run is never scored.

2.1.13 (2026-10-26)

• Email 1 and Email 2 never state or ask about an open disqualifier condition. A question about the buyer's system or ownership is reserved for Email 3, so the check is due the business day before the last send day in every case. The drafter no longer decides the date. Step 1C, the Rules For Every Email and the Step 4 priority order carry the rule.
• Example 1 Email 2 asks a different question, which needs no check. Its check moves to the business day before the last send day, and the GM sequence and the hand-off follow the same rule.
• The try-it records no longer carry the event tag, which stays in the promise. The try-it promise moves its check date to match Example 1.

2.1.12 (2026-10-26)

• The Output Contract's next_action row and Step 4 item 11 give the priority order for choosing one next action. A reply owed to a buyer comes first, then AE coordination on an AE-owned ACTIVE account, then the earliest time-bound window step in the order names, contact, Email 1, check, later sends, then other steps. Ties go to the step that gates another dated step. The other open steps are listed after the move as later steps.
• Email 1 never states or asks about an open disqualifier condition, so the check is due the business day before the first later email that does. Step 1C says what happens when the drafter makes Email 1 depend on it, and when no email does.
• The event tag comes from the record that makes the change, here the state licensing database. The deal notice is cited for the size and the review deadline under its own tag. Step 1B gives the rule for other event types. The try-it records follow it.
• The long end is the last day any email in the sequence may go out, in the One Window Rule and the days_remaining row, which removes the conflict with Step 3's last-send rule. Days remaining stay at 10 on 2026-10-19.
• Example 1 and the try-it next action is the names by 2026-10-20, with the Email 1 send and the check as later steps. Examples 2 and 3 keep their next actions, because the priority order gives the same move.
• Example 1 Email 1 names the 2027-02-16 integration review date, as 2.1.11 set. This supersedes the Q1 2027 wording of consistency item C-09 for Email 1, because the STALE rule requires the body of Email 1 to name the citable deadline, and Q1 2027 is a quarter, not a deadline. The records keep the day with its tag and (illustrative).
• Example 2 states Ines Carmody's label as "champion label, Champion Test not yet run", the wording consistency item C-10 requires, and tags her move to the state licensing database.

2.1.11 (2026-10-26)

• Step 1C defines dependence. An email depends on an unresolved disqualifier condition when its text states the condition or asks about it. The check is due the business day before the first dependent email's send day, so the Corrow Ridge check is due 2026-10-22, before Email 2 on 2026-10-23. The rep who sends the sequence runs it.
• The next action in Example 1 and the try-it includes the check, with its date, beside the Day 1 send.
• One Window Rule says that today is the run date the records or the user set, not the system date.
• Step 1B says that the source which records the event decides its tag. A deal notice that gives only a deadline is cited for the deadline.
• The decision tree's footprint step reads the company as the account at the trigger.
• Step 3 says a Trigger Catalog first line is edited to name the event before use. The STALE rule says the body of Email 1 names the deadline.
• Example 1 Email 1 names the integration review date, 2027-02-16, from the deal notice. This replaces the Q1 2027 wording of version 2.1.6, because a STALE trigger names its deadline.
• The try-it records state the event date without its tag, so the reader tags it. The promise adds the Email 1 deadline line, and the next action now includes the check.

2.1.10 (2026-10-26)

• Gone quiet is no longer restated locally. Step 0 points to the shared rule in What The Close Reads.
• An INBOUND account with a disqualifier that applies gets one short decline draft, held for the rep to read, in place of Email 1 and with no trigger sequence. The rule sits in Step 0, the Output Contract, Hard Rule 11, the Quality Bar and the INBOUND pattern.
• No example or try-it promise changes.

2.1.9 (2026-10-26)

• INBOUND accounts, which asked us first with no open deal, get their request answered first. Email 1 is a reply to the request that names the event with its tag, with no cold opener.
• Email 2 and Email 3 follow only if the account goes quiet, meaning no reply within five business days after the reply is sent, and only inside the window. If the window has closed, the status is EXPIRED and no sequence follows.
• The rule sits in Step 0, the Rules For Every Email, the Output Contract, Hard Rule 10, the Quality Bar and a new INBOUND pattern.
• No example or try-it promise changed.

2.1.8 (2026-10-26)

• Every profile citation is written (profile: Section), naming the real section. Template placeholders and the shared contract are unchanged.
• ENGAGED is one of six statuses. Step 0 gives an ENGAGED account an open-thread path: Email 1 replies to the account's last message and names the event, with no cold opener. Step 3, the Rules for Every Email, Hard Rule 9, the Quality Bar and a new pattern follow the same rule. The verdict logic is unchanged, because this skill has no verdict.
• The examples and the try-it keep their TARGET status on 2026-10-19. The Quill Hollow record shows no reply before that date, so it is not ENGAGED on its run date.
• Headings and labels are capitalized word by word.

2.1.7 (2026-10-26)

• The disqualifier check has a due date: the business day before the send day of the first email whose claim depends on the unresolved condition. Emails that do not depend on it may go out before the check, and the check is never skipped.
• Every unnamed contact is found by the send day of its own Email 1, and the next action lists each one.
• Sequence days are fixed: Email 2 on Day 4, Email 3 on Day 8. A send day on a weekend moves to the Friday before.
• Days remaining are counted from the run date, and the share is printed as N of M window days (P%).
• The try-it records no longer state the window rule, and the promise follows the rules above.

2.1.6 (2026-10-26)

• Example 1 Email 1 names the integration review as Q1 2027, the way the deal notice does. The exact day stays in the records as illustrative, and no email quotes it.
• Example 2 labels Ines Carmody as carrying the champion label, with her Champion Test not yet run, and tags her move to the state licensing database.

2.1.5 (2026-10-26)

• The Day 1 send date in Example 1 is named as the skill's own schedule, and the next-action source note says so.
• The next action follows the family's one deadline rule. Where the sequence timing (Day 1) must come first, the next action names that timing as the earlier date and its source.
• The Output Contract and Step 4 point to the shared next-action rule instead of restating a window of days.
• The examples' next actions carry the dates the rule gives.

2.1.4 (2026-10-26)

• Try-it evidence completed so a strict first run reproduces Example 1.
• Sequence Structure defines Day 1 as the day after the run date, the first day the rep can send once the draft is read.
• Step 1c gates each email, not the whole sequence, on an unresolved disqualifier condition. An unnamed contact is found before that contact's Email 1.
• The decision tree gains step 7: a change of ownership to a company is Acquisition / M&A, whether or not the buyer is PE-backed, unless steps 1 to 6 match first.
• Evidence Tags for Trigger Events gains one paragraph on Example Cast facts, which take the tag of the record that would hold them.
• The next_action in the Output Contract, Step 4 and the hand-off gains the date rule.
• The Output Contract example for the window is now a placeholder.
• Example 1 tags the consolidator's size and the site's plot count, and the try-it records gain the ownership type and the matching tags.

2.1.3 (2026-10-26)

• Try-it evidence completed so a strict first run reproduces Example 1.
• Decision tree gains one sentence: an acquisition that changes who owns the account is Acquisition / M&A from the taxonomy unless steps 1 to 6 match first.
• Trigger Status, STALE, gains one sentence: the deadline an email names is the profile's citable date, not the window's last day.
• Example 1 implication 3 is tagged [Inferred] with its basis, not with the deal notice tag. Its subject lines now name the event, and Email 1 cites the deal notice for the review date.
• Example 1 states the disqualifier with both conditions. Email 1 asks nothing that depends on the ownership and system check, and Email 2 waits for that check and asks the system question.

2.1.2 (2026-10-25)

• Try-it evidence completed so a strict first run reproduces Example 1.

2.1.1 (2026-10-25)

• Adds examples/try-it.md so a first run reproduces Example 1. No other change.

2.1.0 (2026-10-25)

• Reads the Context OS account folder and offers read-only CRM and call connectors through the shared contract's new Knowledge Base and Connectors section. Adds a Chains subsection. No other change.

2.0.1 (2026-10-20)

• Every hand-off block carries a run_date line after its account line, so two instruments on one deal are compared by date (found by the wave two hand-off tests). No other change.

Version 2.0.0 (2026-10-20)

• Trigger windows and personas now come from the profile's Buying Triggers table. The rule or deadline comes from the Trigger Catalog with a citation. The unsourced 7-to-14-day and 30-to-60-day windows are removed from the taxonomy
• One window rule, stated once, with the arithmetic printed in the Corrow Ridge example
• Evidence grades replaced by the six shared tags. UNVERIFIED is kept as a trigger status for events with no date
• One name for each trigger type across the taxonomy, the decision tree and the mapping ("Earnings Miss / Margin Pressure")
• Corrow Ridge example is now a three-email sequence inside its window. Quill Hollow example refuses to time an undated finding. Brackhaven example routes the rival renewal to Competitive Displacement under the profile
• Context adds Industry Context, the Buying Triggers table and the Trigger Catalog. The shared contract is added under Context
• Output Contract is a table with the hand-off fields by name. Each stage has a Produces line. Why This Skill Exists, Hard Rules with reasons and a Quality Bar are added
• The file is written only when the user asks for one. The artifact section section is folded into the Output Contract
• The response-rate reference is removed

Version 1.3.0 (2026-10-13)

• Examples re-cast on PlotIQ, example errors fixed and a non-success example added
• Unsourced statistics removed. Persona placeholders filled from the profile. Financial trigger routing corrected to existing trigger types

Earlier versions (1.0.0 to 1.2.0) are in the git history of this repository.