linkedin-post-skillSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

/linkedin-post idea      # or: story / take / recap   (or just describe what you want)

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: linkedin-post
description: Use when Chan Meng wants to turn a thought into a post for LinkedIn, X (Twitter), or both — "write a LinkedIn post about...", "tweet this", "make this an X thread", "post about what I just read", "recap the meetup I went to". Four modes — story (something that happened and what it changed), idea (a claim she can back), take (a reaction to an article or release), recap (an event, crediting people). Writes in a voice system built from two writers she admires, writes each platform's post separately for its own audience, adds a Mermaid diagram or an HTML-rendered image when the content has a shape worth seeing, and hands back ONE markdown file. Chan posts it herself; the skill never opens LinkedIn or X.
---

# Post writer for LinkedIn and X (Chan Meng / Caldera brand)

Take one of Chan's ideas and turn it into a post that is credible to specialists, plain enough for
anyone who follows her, and worth reading to the end. Write it for LinkedIn, for X, or for both,
and hand it back as **one markdown file** she can copy from.

## Hard boundary: you never drive a browser

**This skill has no browser step.** Do not call `claude-in-chrome`, Playwright-as-automation,
chrome-devtools, or any other page-driving tool. Do not open LinkedIn or X. Do not open a composer,
type into one, resolve mention chips, attach files, or click Post, not even "to stage a draft".

This is deliberate. LinkedIn's editor cannot be driven reliably (it swallows the space after a
mention chip, lands backspaces in the wrong place, and exposes no usable file input), and a post
published under Chan's name is hers to send. She pastes, tags, attaches and publishes. Your whole
deliverable is a file that makes that take a minute.

Still allowed, because they aren't browser automation:
- **WebSearch / WebFetch** for research and verification.
- **The render scripts**, which screenshot local HTML with headless Chromium. No live site is
  involved.

## Reference docs

| File | Read |
|------|------|
| `references/voice.md` | **every run.** The writing system: two registers, openers, closers, the "Never" list, the plain-language pass |
| `references/platforms.md` | **every run.** LinkedIn against X: audience, mechanics, shapes per mode, how to translate |
| `references/brand.md` | every run. Who Chan is, who she writes for, vocabulary, visual tokens |
| `references/hashtag-bank.md` | when a LinkedIn post takes hashtags |
| `references/recap-playbook.md` | recap mode: research, verification, photos, mentions |
| `references/visuals.md` | at Step 4: which visual route, and the render recipes |
| `examples/post.md` | a worked handoff file: one idea, both platforms, with a visual |

## Workflow

### Step 0 — Mode, platforms, and the real material

**Mode**, from the `/linkedin-post <mode>` argument, else inferred, else asked once:

| Mode | Use when |
|------|----------|
| **story** | something happened to her and it changed how she thinks |
| **idea** | she has a claim and something to back it: a build, a number, a method |
| **take** | she read or watched something and has a view on it |
| **recap** | she went to an event and wants to credit the people and say what stuck |

**Platforms**: `linkedin`, `x`, or `both`. If she named one, use it. **The default is both**:
when she doesn't name a platform, write both and say so. `platforms.md` lists the cases where a mode doesn't suit a platform; skip those and say why.

**The real material.** The voice depends on true specifics, so gather them before drafting. Ask
only for what is missing, in one message:

- **story**: what happened, when and where, what was said (her words or theirs), what she expected,
  what she thinks now.
- **idea**: the claim in a sentence, what she built or measured that supports it, any numbers with
  the numbers they replaced, links.
- **take**: the URL (fetch it and read it; never react to a headline), her view, and whether she
  agrees, extends or disagrees.
- **recap**: event name, date, venue, link; who to credit and for what; one or two things that
  stuck; **and whether she has photos** (paths, or "no").

Never invent an anecdote, a quote, a number or a detail of Chan's experience. If the draft needs
one she hasn't given, ask. If she doesn't have it, write without it. (`voice.md`, first section.)

Don't block on completeness. One round of questions, then draft with what there is and list the
gaps in the handoff.

### Step 1 — Research and verify

- **take**: read the source. Note the author and publication, and what it claims in a sentence or
  two. Check any figure you plan to repeat.
- **recap**: follow `recap-playbook.md`. Confirm each name's spelling, current title and employer.
  For X, find a handle only from the person's own site or profile, or the event's page.
- **idea / story**: verify any outside fact the post leans on (a release date, what a tool does).

Never invent a profile or a handle. A wrong tag points Chan at a stranger in public.

### Step 2 — Find the spine, pick the register

Before writing, state to yourself in one sentence what the post says. If it takes two sentences,
there are two posts; pick one and offer Chan the other for later.

Then choose the register from `voice.md`: **Story** when the material is a moment, **Operator**
when it is a claim with evidence. Recaps use a Story spine with Operator facts.

### Step 3 — Draft, one platform at a time

1. **Draft the first platform** using its shape from `platforms.md` and the register from
   `voice.md`. LinkedIn first when writing both, unless it's a take on fresh news, which goes to X
   first.
2. **Write the second platform from the idea, not from the first draft.** Different reader,
   different opening, different length. `platforms.md` → "What changes in translation".
3. **Run the plain-language pass** (`voice.md`, last section) on both.
4. **Write the drafts into `post.md`** (format in Step 5) and run
   `node scripts/count.mjs output/<date>-<slug>

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

declared (2 observation(s))

Network

none-observed

Shell

declared (3 observation(s))

Dependencies

not all pinned

Secrets in source

none-found

Findings (1)

@mermaid-js/mermaid-cli, playwright

Gates applied: no_behavioural_pass.