1 · When to use it

You need to understand an organisation before a pitch, a negotiation, a partnership or a competitive review.

Organisations only. Do not point this at a private individual. Building a compiled file on a person who is not a public figure is a different activity with different consequences, and this skill is not for it.

2 · Required inputs and access

Inputs

• The organisation, named unambiguously, with domain and jurisdiction
• The questions the dossier must answer, in priority order
• Depth: quick read or full workup
• Any known internal history with them

Access

• Web and news search
• Company registries and filings where available
• Your own CRM and document store, for internal history
• Any subscription data source you hold

3 · Sequence of work

1. Establish identity precisely. Legal entity, group structure, domain, jurisdiction. Confusing two similarly named entities invalidates everything downstream.
2. Pull internal history first. What you already know is cheaper and more reliable than what you can find.
3. Structure: what they do, how they make money, ownership and structure, leadership, scale, recent developments, strategic direction, apparent pressures.
4. For every claim, capture the source and the date, and mark confidence as confirmed, reported or inferred.
5. Answer the stated priority questions explicitly, in order. If a question cannot be answered, say so rather than answering a nearby one.
6. Identify what is not knowable from public sources. This section is often the most useful.
7. Note conflicting accounts where sources disagree, rather than picking one.
8. Assemble the dossier.

4 · How to validate the result

• Entity identity is verified against a registry or filing, not inferred from a website
• Every claim carries a source, a date and a confidence marker
• Inferred claims are never presented as confirmed
• Priority questions are answered in order, including the ones answered with “not determinable”
• Conflicts between sources are shown, not resolved silently

5 · What to return

A dossier in /workspace, summarised in the conversation: Identity (entity, structure, jurisdiction, verified against what), Priority questions (each answered or explicitly marked undetermined), Profile (business model, scale, leadership, ownership), Recent developments (dated, sourced), Read (strategic direction and apparent pressures, marked as inference), Gaps (what public sources cannot tell you), Conflicts (where sources disagree). A source table at the end.

6 · What requires approval

• Contacting the organisation or anyone in it
• Sharing the dossier outside the team
• Using anything in it in a client-facing document
• Any paid data purchase

7 · No-data and stale-data policy

If a registry or filing source is unavailable, mark structural claims as reported rather than confirmed. Do not upgrade a website’s own description of itself to confirmed.

Anything older than 12 months is marked with its date and treated as historical rather than current.

Save it

Save this as a skill called “DEEP-DOSSIER”. Include the requirement to verify entity identity against a registry before anything else, the requirement that every claim carries source, date and confidence marker, the rule that inference is never presented as confirmation, the requirement to show source conflicts rather than resolve them, the restriction to organisations rather than private individuals, and the rule that all external sharing requires my approval.

Run it as a routine

Run on demand against a named organisation. Do not schedule.

1 · When to use it

You compete on visible pricing and want to know when someone moves. Use this where pricing is published.

Where pricing is quoted rather than published, this will not work and RATE-CARD-CHECK is the better tool.

2 · Required inputs and access

Inputs

• Competitor pricing page URLs, exact
• What to capture per page: tiers, prices, currencies, included limits, add-ons
• Where to store the price history
• Materiality threshold for a change

Access

• Web, browser
• Storage in /workspace for the price history file

3 · Sequence of work

1. Load the stored price history. If none exists, this run establishes the baseline and reports nothing else.
2. Fetch each pricing page. Record the timestamp and the currency shown.
3. Extract the full structure: tier names, prices, billing periods, included limits, overage rates, add-ons.
4. Diff against the previous capture. Detect four kinds of change: price moved, tier added or removed, included limits changed, packaging restructured.
5. Note that a repackaging that leaves headline prices identical is often the more significant move. Check limits and inclusions, not only the numbers.
6. Apply the materiality threshold to price movements. Structural changes are always material.
7. Calculate the change as both absolute and percentage, and note the direction of travel over the last four captures.
8. Append to the history and produce the report.

4 · How to validate the result

• Currency is captured per page. A price that appears to have jumped 20% is usually a currency or region switch
• Included limits and inclusions are diffed, not just the headline numbers
• The history appended rather than overwrote
• Every change carries the capture date on both sides of the diff
• Pages that failed to load are marked, not skipped silently

5 · What to return

On a change: Competitor | Tier | Was | Now | Change | % | Type of change | Captured

Below it, a four-capture trend per competitor showing direction of travel. On no change: a one-line confirmation with the page count and timestamp.

6 · What requires approval

• Changing your own pricing
• Sharing the analysis outside the commercial team
• Signing up for any competitor account or trial

7 · No-data and stale-data policy

If a page fails to load, mark it [uncaptured] and do not write to the history for that competitor. Writing a null capture would show a false change on the next run.

If a page has not been successfully captured for three consecutive runs, flag it prominently — the page has probably moved.

Save it

Save this as a skill called “PRICE-WATCH”. Include the exact URLs, the fields to capture, the materiality threshold, the requirement to capture currency per page, the rule that inclusions and limits are diffed alongside prices, the rule that failed captures never write to the history, and the requirement to show a four-capture trend.

Run it as a routine

Every Monday at 06:00 Europe/Paris, run PRICE-WATCH across the competitor pricing pages. Post the report in this conversation, including on weeks with no change. Change nothing on our own pricing.

1 · When to use it

You operate under regulation that moves and you are currently finding out from LinkedIn.

This is a monitoring tool, not legal advice. Anything material goes to a qualified adviser. The value here is timeliness and filtering, not interpretation.

2 · Required inputs and access

Inputs

• Jurisdictions in scope
• Regulatory bodies and their official publication sources
• Topic areas that affect you
• What counts as material to your operations
• Who receives escalations

Access

• Official regulator sites and publication feeds
• Legal or industry news sources
• Storage in /workspace for the change log

3 · Sequence of work

1. Check official sources first, before any commentary. The primary document is the fact; everything else is opinion about the fact.
2. Pull anything published or updated since the last run across each source. Record dates.
3. Filter to the stated topic areas and jurisdictions.
4. For each item, capture: what instrument, what changed, effective date, consultation or in force, and who it applies to.
5. Assess materiality against the stated definition. Be conservative — over-flagging here is cheaper than missing something.
6. Separate primary sources from commentary clearly. Never blend a regulator’s text with an analyst’s reading of it.
7. Note effective dates and any consultation deadlines. Deadlines are the actionable part.
8. Append to the change log and produce the report.

4 · How to validate the result

• Every item links to the primary source, not to a news article about it
• Commentary is labelled as commentary and attributed
• Effective dates and deadlines are captured and correct
• Nothing is characterised as a requirement unless the primary text says so
• No interpretation of application to your specific circumstances appears anywhere

5 · What to return

A change report: Jurisdiction | Body | Instrument | What changed | Status | Effective / deadline | Material? | Primary source

Below it, commentary in a clearly separate section, attributed. At the top: anything with a deadline inside 60 days, and anything assessed as material. A standing line at the end: material items require review by a qualified adviser before any action.

6 · What requires approval

• Any compliance action or change to a process
• Sharing outside the team
• Any external statement about compliance position
• Responding to a consultation

7 · No-data and stale-data policy

If an official source is unreachable, report it explicitly. Believing a regulator has published nothing when the page simply failed to load is the exact failure this skill must not have.

Never substitute commentary for a primary source that could not be reached.

Save it

Save this as a skill called “REG-WATCH”. Include the jurisdictions, the official sources, the topic areas, the materiality definition, the rule that primary sources are checked before commentary and never blended with it, the rule that no interpretation of application is offered, the standing adviser-review line, and the rule that all compliance action requires my approval.

Run it as a routine

Every Monday at 07:00 Europe/Paris, run REG-WATCH across the official sources. Post the change report in this conversation. Take no compliance action. If an official source is unreachable, say so explicitly rather than reporting no change.

1 · When to use it

You want to know where a competitor, a client or a target is actually investing. Job postings are a leading indicator and they are published because they have to be.

Companies only. This reads organisational intent from public postings. It is not for tracking individuals.

2 · Required inputs and access

Inputs

• Target companies
• Their careers page URLs plus any job boards they use
• Signal categories: which functions and seniorities matter to you
• Where to store the posting history

Access

• Web, browser
• Job boards
• Storage in /workspace for the posting history

3 · Sequence of work

1. Load the stored posting history. First run establishes the baseline only.
2. Pull current open roles per company. Capture title, function, seniority, location, and posting date.
3. Diff against the previous capture: new roles, filled or withdrawn roles, roles reposted.
4. Aggregate by function and location. Volume by function is the signal; individual roles rarely are.
5. Identify direction: which functions are growing, which have gone quiet, which locations are opening.
6. Read the job descriptions of senior and newly created roles. A first-ever hire in a function is a strategic statement.
7. Note any role naming a technology, market or capability that is new for them.
8. Produce the read, with confidence marked.

4 · How to validate the result

• Volume changes are compared against the same company’s baseline, not against other companies
• A repost is not counted as a new role
• Every inference is labelled as inference
• Location aggregation accounts for remote postings, which distort location signal
• The history appended rather than overwrote

5 · What to return

A signal read per company: Company | Function | Open now | Change vs last | Locations | Signal

Below it: newly created roles and first-ever hires in a function, with the relevant line from the job description. At the end, a two-sentence read per company, explicitly marked as inference.

6 · What requires approval

• Contacting any company or any individual
• Sharing outside the team
• Any recruitment activity based on the findings

7 · No-data and stale-data policy

If a careers page cannot be loaded, mark it [uncaptured] and do not write to the history. A missing capture would read as every role being withdrawn.

If postings carry no date, note that volume comparison is less reliable for that company.

Save it

Save this as a skill called “HIRING-SIGNAL”. Include the target companies and sources, the signal categories, the rule that reposts are not counted as new roles, the requirement to label every inference as inference, the rule that failed captures never write to the history, and the restriction to organisational reading rather than individual tracking.

Run it as a routine

On the first Monday of each month at 08:00 Europe/Paris, run HIRING-SIGNAL across the target companies. Post the signal read in this conversation. Contact nobody.