---
name: "Pattern of life from socials"
repo: https://github.com/useosint/skills
source: https://github.com/useosint/skills/blob/HEAD/skills/pattern-of-life-from-socials/SKILL.md
license: "MIT"
install: "npx skills add useosint/skills --skill pattern-of-life-from-socials"
page: https://100xlab.com/resources/agent-skills/useosint-skills--pattern-of-life-from-socials--fq0jtz
---

# Pattern of Life from Socials

Pattern-of-life analysis turns scattered public posts into a model of where
someone is, when, and with whom. It is the most abusable technique in this
repo: the same method produces a due-diligence report and a stalking dossier.
The difference is authorization and scope, not tradecraft. The beginner error
is collecting posts instead of analysing them — screenshots of a feed are not
intelligence. Work four layers: account metadata, network, content, temporal
behaviour. The first and last are the two everyone skips, and the two the
subject can't curate.

## Step 1 — Authorized scope

Read [../../ETHICS.md](../../ETHICS.md), then write down before opening a
single profile:

- **Subject** — the account(s) and the real-world entity you believe is behind
  them.
- **Objective** — the question that ends the investigation. "Pattern of life"
  is not one. "Does this vendor's EU lead actually live in the EU" is.
- **In / out of bounds** — explicitly. Minors, uninvolved family, home address,
  health, religion, sexuality and immigration status are out unless the
  objective requires them and you can defend that.
- **Posture** — observation only, or authorized interaction. Following, liking,
  messaging and viewing stories are all interaction.
- **Jurisdiction** — yours, the subject's, the platform's.
- **Stop condition** — you stop when the objective is answered, when the trail
  lands on an uninvolved third party, or when the only question left is "where
  do they sleep."

**Done when** all six are recorded in the case file.

## Step 2 — Choose a viewing identity, then preserve

Logged-out leaks less and sees less; logged-in sees more and leaks more.
Platforms variously report story views and profile visits to the subject, and
recommendation systems surface accounts that look at each other — so merely
viewing can put your research account in the subject's suggestions. Decide the
tradeoff using `investigate-without-getting-made`; never browse a subject from
a personal or employer account.

Then capture before you analyse. Accounts get locked or scrubbed
mid-investigation, often because someone noticed. Archive the profile and every
post you may cite via `read-deleted-pages`, and pull older snapshots — they
routinely show a previous bio, link, or handle. Save media locally.

**Done when** the viewing identity is recorded and everything you intend to
cite exists as an archive URL or a local file with a capture timestamp.

## Step 3 — Layer one: account metadata

Go after what the subject never chose. Full per-platform behaviour is in the
[platform disclosure matrix](reference/platform-disclosure.md).

- **Creation date.** Shown outright on some platforms, derivable on others.
  Snowflake-style 64-bit IDs encode a millisecond timestamp in their high bits,
  offset from a platform-specific epoch — the ID *is* the signup time. Plain
  sequential IDs give registration order, so you can bracket a date against
  accounts of known age.
- **The numeric ID.** It survives handle changes, so it — not the handle — is
  the durable selector. Record it.
- **Handle history.** Seldom a feature, usually recoverable from old mentions,
  inbound links, archived snapshots and abandoned cross-posts. A freed handle
  can be reclaimed by a stranger, so an old link proves nothing about current
  control.
- **Verification and linked accounts.** Whether a badge is paid or
  identity-checked changes what it's worth. Linked sites and business-account
  contact fields expose emails and phone numbers the personal profile wouldn't.

**Done when** ID, creation date, handle history and every linked selector are
recorded with sources.

## Step 4 — Layer two: network

A subject's OPSEC is nearly irrelevant if their relatives tag them.

- **Early followers.** The first accounts to follow a personal account are
  overwhelmingly family, school friends and coworkers — it spread by word of
  mouth before it had reach. Where follower ordering is observable, the oldest
  tail is the highest-value segment on the page.
- **Mutual-follow clusters.** Reciprocal edges map real-world communities:
  employer, school cohort, hometown, club. The cluster is the finding; a single
  edge isn't.
- **Tag direction.** Who the subject tags is curated. Who tags the subject is
  not. Inbound tags from an open-book cousin routinely deliver the birthday,
  the house, the car and the workplace the locked-down subject withheld.
- **Reply latency.** Accounts that reliably comment within minutes are the
  inner circle, regardless of follower counts.

Build this in `graph-the-network`, not as a list.

**Done when** the inner circle, one real-world cluster, and the third parties
who leak about the subject are identified and graded.

## Step 5 — Layer three: content

Read past the subject of each photo to the accidental content: reflections in
windows, mirrors, glasses and dark screens; laptop and phone displays in frame;
paperwork such as boarding passes, parcel labels and event badges; vehicles,
plates, dealer frames and parking permits. Repeated backgrounds are what
upgrade a room from "somewhere" to "home" or "workplace" — count occurrences
and note the date span.

Run `secrets-in-file-metadata` on everything you downloaded: platforms differ
in whether they strip EXIF, and the same platform may strip it from an inline
image while preserving it in a file attachment or an original-quality download.

Do the geolocation itself in `geolocate-from-pixels`. Sanity-check anything
that looks too convenient with `is-this-photo-real`.

**Done when** each location-bearing artefact is logged with post URL, date, and
a pointer to the geolocation work.

## Step 6 — Layer four: temporal behaviour

Extract every post timestamp into a table and plot hour-of-day and day-of-week.
The extraction schema is in the
[analytic checklist](reference/analytic-checklist.md).

A contiguous gap of roughly seven to nine hours is the sleep window, and its
position gives a UTC offset — enough to separate continents, not neighbours. A
weekday dip through business hours suggests employment with restricted device
access; the inverse suggests shift work or a job spent online. Sudden
multi-day offset shifts are travel.

What wrecks this: scheduling tools post at fixed wall-clock times regardless of
where the human is, so a scheduled account measures the scheduler; platforms
may render timestamps in the *viewer's* locale; edits can carry the edit time;
and cross-posting bridges or shared team accounts blend several humans into one
histogram. Establish that posting is manual before reading anything into shape.

**Done when** both distributions exist over a stated sample window, with an
explicit inferred UTC offset and its confidence.

## Step 7 — Consolidate and report

Link accounts on evidence: the same avatar file, the same link-in-bio target,
follower-set overlap, aligned histograms. Writing style alone is a lead, not a
link. Then run `write-the-intel-brief`. Every claim cites a post or archive URL
and a date; every temporal conclusion states sample window and sample size.

**Done when** no claim lacks a citation and no inference lacks a grade.

## Where this goes wrong

- **Sample bias.** You're reading a self-published subset of a life. Silence
  means "didn't post," never "wasn't there."
- **Backdating.** A post date is an upper bound on the event date. Photos get
  posted months late, reposted, or lifted from someone else entirely.
- **The account is not the person.** Handles are sold, inherited, hacked and
  recycled; a long history may have changed hands. Partners, assistants and
  agencies post as the subject — two behavioural signatures in one histogram
  usually means two humans.
- **Curated self-report.** Location, job title and relationship status are
  marketing copy, and a common name plus a matching city is a coincidence
  generator, not a match.
- **Rendering differences.** Timestamps, follower ordering and mutual
  indicators change with login state, and are often approximate ("2h", "last
  week") rather than exact.
- **Observation changes the subject.** One who locks down mid-case may have
  been tipped off by you.

## Grading a finding

- **Confirmed** — an authoritative record or the subject states it, or two
  independent artefacts of *different* types agree (an inbound tag from a
  separate account plus a geolocated background). Both archived.
- **Probable** — several consistent signals of the same type, or one strong
  signal with nothing contradicting it: a repeated background plus a temporal
  pattern consistent with living there.
- **Unconfirmed** — single-source, self-reported, style-based, or drawn from
  too small a sample. A timezone from a few dozen posts or fewer is
  unconfirmed, full stop.

Downgrade anything resting on an assumption you can't state in one sentence.

## Worked example

Objective: confirm a supplier's "EU operations lead" is in Europe, as the
contract requires.

Bio says Lisbon. The numeric ID decodes to a signup years before the company
existed — so the bio says nothing about the present. Four months of timestamps
cluster 14:00–05:00 UTC with a dead zone 06:00–13:00: a sleep window centred
near 09:00 UTC, wrong for Lisbon, consistent with the Americas. Dead end: no
geotags anywhere, and the platform stripped EXIF from every download.

The network layer breaks it. Early followers cluster around one US state
university, and a relative tags the subject at a named local restaurant on a
date the subject publicly claimed to be in Portugal; a repeated kitchen
background appears on both sides of that date. Graded **probable** — no
authoritative record places the subject anywhere, and a histogram can't
separate adjacent countries. Reported with the sample window stated.

## Pivots

| You now have | Take it to |
|---|---|
| Handle and variants | `hunt-a-handle` |
| Avatar, banner, posted photo | `find-the-original-image`, `is-this-photo-real` |
| Photo needing place or time | `geolocate-from-pixels` |
| Downloaded media files | `secrets-in-file-metadata` |
| Exposed email / phone | `what-an-email-reveals`, `whose-number-is-this`, `what-leaked-about-you` |
| Corroborated personal name | `find-anyone` |
| Employer, brand page, link-in-bio domain | `x-ray-a-company`, `recon-a-domain-passively` |
| Follower and mutual edges | `graph-the-network` |
| Deleted or edited posts | `read-deleted-pages` |
| Aircraft or vessel in posts | `track-planes-and-ships` |
| Wallet address or ENS name | `follow-the-crypto` |

## Legal and ToS

Automated collection of profile and follower data breaches the terms of service
of essentially every major platform and has been litigated as a computer-misuse
matter in some jurisdictions; manual viewing of public content generally has
not. Creating an account to view a subject is at minimum a ToS problem, and a
fraud problem if you misrepresent identity to gain access.

Under GDPR and comparable regimes "publicly available" is not itself a lawful
basis, and profiling a person's location and routine is high-risk processing.
Political opinion, health, religion, sexuality and union membership are special
categories — if they surface incidentally and aren't in scope, don't record
them. And the one that matters: sustained monitoring of an individual's
location and routine meets the statutory definition of stalking in many
jurisdictions, and sourcing it publicly is not a defence. Authorization, a
written objective and a stop condition are what make this work lawful.

---

## Supporting file: reference/analytic-checklist.md

# Pattern-of-life analytic checklist

Work top to bottom. Every line either produces a recorded artefact or gets
marked "not available" with a reason. A blank is not the same as a negative
finding, and six months later you won't remember which it was.

## Layer 0 — Case setup

- [ ] Subject, objective, in/out of bounds, jurisdiction and stop condition
      written down and dated.
- [ ] Viewing identity chosen and its exposure documented.
- [ ] Evidence store created: one folder per platform, capture log with
      UTC timestamps, hashes of downloaded media.
- [ ] Collection window declared (e.g. "posts from the last 18 months"). State
      it in the brief; every temporal conclusion depends on it.

## Layer 1 — Account metadata

- [ ] Profile URL, captured and archived.
- [ ] Handle, exactly as spelled, including case and separators.
- [ ] Display name, and any prior display names visible in archives.
- [ ] Numeric / immutable account ID.
- [ ] Creation date — stated, decoded from ID, or bracketed by ordering. Record
      the method.
- [ ] Handle history: prior handles plus the source for each (old mention,
      inbound link, archive snapshot, cross-post).
- [ ] Verification status and what kind of verification it is.
- [ ] Bio text verbatim, plus every link, including link-aggregator
      destinations expanded one level.
- [ ] Business/creator contact fields (email, phone, category, address).
- [ ] Profile and banner images downloaded, hashed, run through
      `find-the-original-image`.
- [ ] Pinned or featured content — usually the subject's own summary of what
      matters to them.
- [ ] Language, locale and script conventions used in the interface-facing
      fields.

## Layer 2 — Network

- [ ] Follower and following counts, with capture date.
- [ ] Follower list ordering determined (insertion order vs affinity-ranked)
      using a control account.
- [ ] Earliest-cohort followers captured, where ordering allows. These are the
      family-and-close-friends layer.
- [ ] Mutual follows enumerated and clustered.
- [ ] Clusters labelled with the real-world community they appear to represent
      (employer, school, hometown, congregation, hobby) and the evidence for
      that label.
- [ ] Inbound tags and mentions collected separately from outbound ones.
- [ ] Accounts that appear in comments within minutes, repeatedly — the inner
      circle.
- [ ] Accounts that leak about the subject: relatives, colleagues and friends
      whose own accounts are open. Note which specific facts each one leaks.
- [ ] Third-party minors and uninvolved parties identified and excluded per the
      scope gate. Record the exclusion.
- [ ] Graph exported to `graph-the-network`.

## Layer 3 — Content

For each post in the collection window:

- [ ] Post URL, archive URL, post ID.
- [ ] Timestamp, normalised to UTC, with the source of the timestamp.
- [ ] Text verbatim.
- [ ] Media downloaded and hashed.
- [ ] Location claims: geotag, check-in, place name in text, place name in
      hashtags.
- [ ] Inadvertent disclosure sweep, per image:
  - [ ] Reflections — windows, mirrors, glasses, screens, glossy surfaces,
        vehicle paint, cutlery.
  - [ ] Screens in frame — laptop, phone, TV, monitors, ATMs, departure boards.
  - [ ] Paper — boarding passes, parcel labels, receipts, prescriptions, event
        badges, name plates, whiteboards, calendars, post.
  - [ ] Vehicles — plates, dealer frames, inspection stickers, parking permits,
        toll transponders, distinctive damage.
  - [ ] Building detail — house numbers, intercom panels, letterboxes, utility
        markings, street furniture, signage, language of signage.
  - [ ] Uniform, badge, lanyard, branded clothing.
  - [ ] Pets, children's school uniforms, sports club kit. Note that these are
        commonly out of bounds; record only if the objective requires.
- [ ] Repeated-background register: assign each recurring interior or view an
      ID, count appearances, record first and last seen dates and the times of
      day. Repetition plus timing is what distinguishes home from workplace
      from a friend's house.
- [ ] EXIF extracted via `secrets-in-file-metadata`, recording which upload
      path the file came from.
- [ ] Any image worth geolocating handed to `geolocate-from-pixels` with the
      specific question you want answered.
- [ ] Any suspiciously convenient image checked with `is-this-photo-real`.

## Layer 4 — Temporal

Extraction schema — one row per post, CSV or equivalent:

```
post_id, platform, timestamp_utc, timestamp_source, local_hour_assumed_utc,
weekday, post_type, has_media, is_reply, client_or_source_label, notes
```

Then:

- [ ] Sample size and window recorded. Under a few dozen manual posts, do not
      draw a timezone conclusion at all.
- [ ] Hour-of-day histogram in UTC.
- [ ] Day-of-week histogram.
- [ ] Hour-by-weekday heat map — this separates work schedule from sleep, which
      the two one-dimensional plots cannot.
- [ ] Sleep window identified: the longest contiguous low-activity block,
      typically seven to nine hours.
- [ ] Inferred UTC offset, stated as a range, with the reasoning.
- [ ] Weekday-versus-weekend difference characterised.
- [ ] Offset shifts flagged as candidate travel, with dates.
- [ ] Automation check completed before any of the above is believed:
  - [ ] Are post times suspiciously round (top of the hour, fixed minutes)?
  - [ ] Is the interval between posts unnaturally regular?
  - [ ] Does the platform expose a client or source label indicating a
        scheduler or API client?
  - [ ] Do replies — which are hard to schedule — show a different distribution
        from top-level posts? If they do, trust the replies.
  - [ ] Is there evidence of cross-posting from another platform, which would
        make this histogram a copy of that one?
- [ ] Multi-operator check: does the distribution look like one human or like
      two overlapping schedules?

## Layer 5 — Consolidation

- [ ] Every cross-platform link listed with its evidence type and grade.
- [ ] Every location claim listed with grade and the artefacts supporting it.
- [ ] Contradictions listed explicitly. A contradiction you found and explained
      is a strength; one the reader finds is a failure.
- [ ] Coverage gaps stated: platforms not examined, date ranges with no posts,
      content types not accessible.
- [ ] Out-of-scope material identified and deleted, with the deletion recorded.
- [ ] Handoff to `write-the-intel-brief`.

## Analytic conclusions worth making explicit

Write these as sentences in the brief, or say you couldn't establish them:

- Home location, at the resolution you can actually defend — country, region,
  city, neighbourhood. Do not report a resolution finer than your evidence
  supports.
- Work location and employer, and whether the two are separable in the data.
- Daily rhythm: wake window, work window, sleep window.
- Weekly rhythm: which days differ and how.
- Travel events with dates and, where possible, destinations.
- Inner circle: who, and the basis for calling them that.
- Community memberships.
- Devices and platforms used, from client labels and media characteristics.
- What changed over the collection window — a shift in rhythm, location, or
  network is often the actual finding.

---

## Supporting file: reference/platform-disclosure.md

# Per-platform public disclosure matrix

What an observer can see without a relationship to the subject, described by
mechanism rather than by menu location. UI moves constantly; the mechanisms
below change slowly. Verify current behaviour on a control account you own
before relying on any row.

Three observer postures matter throughout:

- **Logged out** — no account, no cookies. Lowest exposure, most gating.
- **Minimally authenticated** — a research account with no history, no
  followers, no profile photo. Sees more, but is itself a signal: brand-new
  empty accounts are what platforms and cautious subjects both watch for.
- **Established research persona** — an aged account with plausible activity.
  Sees the most, costs the most to build, and loses the most when burned. See
  `investigate-without-getting-made`.

## The disclosure axes

For each platform, ask the same seven questions:

1. Can the profile be read at all while logged out, or is there an auth wall?
2. Is the follower/following list enumerable, and in what order?
3. Are exact post timestamps exposed, or only relative ("3h ago")?
4. Is there a stable numeric ID, and does it encode a creation time?
5. Does the platform tell the subject that you viewed them?
6. Is EXIF stripped from uploaded media, and does that differ by upload path?
7. Does the platform expose an engagement graph (likes, reactions, comments)
   to non-connections?

## Cross-cutting mechanisms

**Auth walls are partial and inconsistent.** Most large platforms gate *some*
surfaces (search, follower lists, media tabs) while leaving the base profile
readable to crawlers, because they want search-engine indexing. That gap is the
reason a site's own search may show you nothing while a web search operator
scoped to the site shows you plenty — see `google-like-a-spy`. Search-engine
caches and archives also preserve the pre-gate version of a profile; see
`read-deleted-pages`.

**Numeric IDs outlive handles.** Platforms need an immutable primary key.
Where the ID is exposed in API responses, page source, or media URLs, capture
it: it survives renames, and it's how you prove a renamed account is the same
account.

**Snowflake-style IDs leak the signup time.** A 64-bit ID whose high bits are a
millisecond counter since a platform epoch decodes directly to a creation
timestamp. Where a platform uses plain auto-increment integers instead, the ID
gives you *ordering*, which you convert to a date range by finding accounts
with known creation dates on either side.

**Follower list ordering is an implementation detail with intelligence value.**
Where a platform returns followers in insertion order (oldest first or newest
first), the tail of the list is the earliest cohort. Where it returns them
ranked by an affinity model, ordering tells you about the *viewer*, not the
subject. Determine which you're looking at using a control account before
drawing conclusions.

**Relative timestamps defeat temporal analysis; absolute ones enable it.**
Where the UI shows "5h", the exact value is usually still present in the page
source or in the API response backing the view. Where it isn't, you can bracket
it by observing the same post repeatedly. Also check whether the rendered time
is localised to *your* session timezone — if it is, your histogram silently
measures your own offset unless you normalise to UTC.

**Read receipts and view telemetry.** Ephemeral content (stories, fleeting
posts) generally reports viewers to the poster by design, because that's the
product. Professional networks often report profile visits, sometimes with an
opt-out that also blinds you to who visited you. Ordinary feed posts generally
do not report views individually, but liking, following, saving or replying
always does. Assume any interaction is attributable and any ephemeral-content
view is logged.

**Recommendation feedback.** Even pure viewing feeds the graph. Repeatedly
loading one subject's profile can cause the platform to suggest your research
account to them, or them to your other accounts, because co-viewing is a
similarity signal. Separate personas across separate browser profiles, separate
egress IPs, and separate devices where the stakes justify it.

**EXIF handling differs by upload path, not just by platform.** The common
pattern: images posted through the normal media pipeline are re-encoded and
stripped; the same file sent as a generic file attachment or document is stored
byte-for-byte and retains everything. Profile pictures and banners are often
processed differently from feed media. Always test the specific path rather
than assuming "platform X strips EXIF."

## Platform-family notes

**Microblogging / short-post platforms.** Historically the most open to
logged-out reading; increasingly gated behind authentication, with the depth of
gating varying by surface and by region. Snowflake-style IDs are common, so
account age is derivable from the post or user ID even when the profile hides
it. Post IDs are also snowflakes, which means a post's ID gives you its
creation time independently of the displayed timestamp — useful when the
displayed time is relative or when the post was edited.

**Photo and short-video platforms.** Base profile and post grid frequently
readable logged-out; follower lists, tagged-media tabs and search usually
gated. Stable numeric user IDs are exposed in API responses and sometimes in
media URLs; the handle is mutable, the ID isn't. Ephemeral story viewing is
always attributable. Media is aggressively re-encoded, so EXIF is generally
gone, but the *filename and CDN path* can still carry structure worth reading.

**Full social networks with bidirectional friendship.** Friend lists are
commonly restricted, but the restriction is one-sided: a locked-down subject
appears in the *open* friend lists, tagged photos and public check-ins of their
less careful contacts. Mutual-friend enumeration from the outside in is often
the only route. Public pages, groups, marketplace listings and event RSVPs
under the same account are frequently far more open than the personal profile.

**Professional networks.** Employment history, education, and skills are
self-reported and semi-verified at best, but the *timeline* is high-value: date
ranges bracket where someone lived. Profile-view telemetry is a first-class
feature here — use the privacy mode that anonymises you, and understand it is a
platform-controlled promise, not a technical guarantee. Connection-degree
labels leak network structure even when the connection list is hidden.

**Pseudonymous discussion platforms.** Handles are the identity, real names are
rare, and the intelligence is in aggregate posting behaviour: subreddit or
board membership maps interests and geography, and a full comment history is
usually enumerable and timestamped, which makes these the best possible source
for temporal analysis. Usernames are typically immutable, which makes them
excellent selectors for `hunt-a-handle`. Deleted comments frequently survive in
third-party mirrors and archives.

**Messaging platforms with public surfaces.** Public channels, groups and
username lookups expose far more than users assume: joining a public channel is
usually not reported to other members, but posting is, and member lists may be
enumerable depending on group type and size. User IDs are numeric and broadly
increasing, so a raw ID brackets registration order. File-send paths commonly
preserve original metadata intact.

**Community chat platforms.** Snowflake IDs throughout, so account and message
creation times are derivable. Server membership is the network layer, and
membership overlap across servers is a strong linkage signal. Presence,
activity status and voice-channel occupancy are real-time pattern-of-life data
if you're already in the server — which is interaction, not observation, and
needs authorization.

## Recording template

For each platform in scope, record:

```
platform:
observer posture used:
profile readable logged-out:      yes / partial / no
numeric ID:                        value
ID encodes creation time:          yes / no / derived-by-ordering
creation date:                     value + how obtained
handle history observed:           values + sources
follower list enumerable:          yes / no / partial; ordering =
exact timestamps available:        yes / no; source = UI / page source / API
timestamps rendered in:            UTC / viewer locale / poster locale
view telemetry to subject:         none / stories / profile visits / unknown
EXIF retained on tested path:      yes / no; path tested =
```

Keep the "how obtained" column populated. In six months you will not remember,
and an unsourced creation date is not evidence.

---

## Supporting file: ETHICS.md

# Ethics, Legality & Authorized Scope

OSINT is powerful. These skills are built for **lawful, authorized, defensive
work**: threat intelligence, fraud investigation, due diligence, journalism,
missing-persons research, penetration-test reconnaissance, and personal digital
self-defense.

Every workflow skill opens with an **authorized scope** gate. Honor it.

## The rules

1. **Passive by default.** Prefer observation over interaction. Never log in to,
   probe, exploit, or send traffic to a target's private systems without written
   authorization. Reading a public profile is OSINT; brute-forcing a login is a
   crime.
2. **Stay legal in your jurisdiction.** Computer-misuse, wiretap, stalking,
   harassment, and data-protection laws (GDPR, CCPA, etc.) all apply to
   research. When unsure, stop and get counsel.
3. **No harassment, doxxing, or stalking.** Do not use these skills to locate,
   intimidate, or expose private individuals for harm. Aggregating someone's
   personal data to threaten them is abuse, full stop.
4. **Minimize and protect data.** Collect only what the objective requires.
   Store case data encrypted, share on need-to-know, and delete when done.
5. **Corroborate before you conclude.** A single selector match is a lead, not a
   fact. Attribution requires multiple independent, corroborating sources.
6. **Respect terms of service and rate limits.** Automated scraping can be
   illegal or get you banned. Use official APIs where they exist.

## Not for

Stalking, harassment, doxxing, unauthorized access, or any activity prohibited
by law. If your objective is to harm a person, these skills are not for you.

By using this repository you accept full responsibility for how you apply it.
The authors provide it "as is" with no warranty (see [LICENSE](LICENSE)).