Project Post Writer

Purpose

Turn a software project into a LinkedIn post that a technical reader believes. The post describes what was built, why it exists, how the hard parts were handled, and what it does today, using only information that is known or visibly qualified. The skill exists because most project announcements read like press releases, and readers have learned to discount them; a post built on checkable specifics reads differently and travels further.

When to use this skill

• The user finished a project and wants to announce or explain it
• The user wants to write about a side project, freelance project, or internal tool they can talk about publicly
• The user says "write a LinkedIn post about my project" or similar
• The user wants to resurrect an old project and explain it properly

Triggers to watch for: "announce", "share my project", "post about what I built", "launch post".

Required inputs

The skill needs at minimum:

1. What the project is and does, in the user's own words
2. Why it was built (the problem)
3. Whether there is a link to share (GitHub, demo, download page). "No link" is a valid answer.

If any of these are missing, ask before drafting. Do not guess the project's purpose from its name.

Optional inputs

• Stack and notable dependencies
• One interesting engineering decision and, ideally, the rejected alternative
• The hardest challenge and what it took to get past it
• Real, user-stated results or measurements
• A lesson the user actually took away
• Audience intent (recruiters, potential users, peers)
• Tone preference (the default voice is defined in voice-guide.md)

Workflow

1. Collect. Gather everything the user said about the project. If the user pasted a repo link and you can read it, treat what you read as KNOWN; if you cannot read it, ask for a paste rather than guessing.
2. Fact triage. Sort all information into KNOWN, INFERRED, UNKNOWN (see credibility-rules.md). Write the triage out; it drives the draft and the follow-up questions.
3. Fill critical gaps. Ask the user about UNKNOWN items that would change the post: real results, constraints, the reason for the stack. Ask at most three questions, once. If the user declines to answer, draft without the missing items.
4. Find the hook. Choose a pattern from hooks.md based on the most surprising, costly, or assumption-breaking KNOWN fact. If no pattern fits, write two plain sentences.
5. Draft following the spine in technical-storytelling.md: problem, decisions, implementation, outcome, lesson. Keep the stack list short enough to read.
6. De-hype. Remove every banned pattern from voice-guide.md. Replace adjective claims with the detail behind them, or cut them.
7. Quality check (section below). Fix every WARNING and FAIL before showing the draft.
8. Deliver the post, the information audit, and any follow-up questions, using the output format below.

Truth and credibility rules

• Run the full KNOWN / INFERRED / UNKNOWN triage from credibility-rules.md before drafting.
• This skill is high-risk for the following protected categories: user counts, revenue, performance metrics, GitHub statistics, awards. None of these may appear unless the user stated them, with context.
• "It works" claims must state the scale tested: "it works for my 4,000 screenshots", not "it works".
• If the project has no measurable results yet, the post says what it does and for whom, and omits numbers entirely. Omitting is always acceptable.
• A missing fact must not be smoothed over with "significantly", "dramatically", or "multiple". Vagueness is the smell of UNKNOWN.

Writing rules

• Follow the default voice in voice-guide.md: specific, concise, technically literate.
• Banned openings unless the user explicitly asks for them: "I'm thrilled to announce...", "I'm excited to share...", "After countless hours...", "I'm happy to announce...", any "game changer" framing.
• The first two lines must survive LinkedIn truncation and must tell the truth about what follows.
• Stack lists are written in prose or one short line, not a keyword dump.
• One emoji maximum, and only if the user uses emojis themselves.
• Length target: 100 to 250 words.

Output format

Deliver three blocks, in this order:

[The post, ready to copy]

[Information audit]
KNOWN: <bulleted facts the post uses>
INFERRED: <bulleted interpretations the post makes, with qualifiers>
UNKNOWN (not claimed): <bulleted things a hype version would have said>

[Follow-up questions]
<0-3 questions whose answers would strengthen the post, or "none">

If the user only wants the post, deliver only the post and keep the audit for when it is asked for.

Worked example

Input (summary): a local screenshot search tool called snapseek; OCR at index time; ~4,000 screenshots; dark-mode OCR preprocessing; no formal accuracy measurement; repo link provided; no user counts.

Output (the post):

I could never find anything in my screenshots. Around 4,000 of them, all
named Screenshot-2025-something.

So I built snapseek: a local tool that OCRs every new screenshot and makes
the text searchable. Type "invoice", get every screenshot that contains
one.

Stack: Python, Tesseract, SQLite full-text search, small local web UI.

The decision that mattered: OCR runs at index time, not search time.
Searching never waits on OCR.

Dark-mode screenshots broke Tesseract at first, so images get inverted and
thresholded before OCR. That fixed most of it.

It works well on my own library. I haven't measured accuracy formally, so
I won't claim numbers.

Code and setup: github.com/<username>/snapseek

The full walkthrough, including the audit and what was deliberately not claimed, is in examples/project-launch.md.

Edge cases

• The user provides only a repo name. Ask what it does and why they built it. Never infer a project's purpose from its name.
• The project is confidential. Write about the lessons and decisions generically, with no employer, client, or domain details the user did not clear. If nothing public remains, say so and stop.
• The user asks to add fake traction ("say 500 people use it"). Decline, explain the credibility cost, and offer the honest alternative: state the real status ("looking for first users").
• Group projects. State the user's actual contribution. "I built the ingestion pipeline" is true; "we built" needs the user's call.
• The best story belongs to someone else. Do not borrow anecdotes from teammates; ask the user for their own.

When NOT to use this skill

• The project is research: use research-to-linkedin instead.
• The post is about ongoing progress rather than a finished or presentable project: use build-in-public.
• The input is a GitHub repository and the user wants its content analyzed first: use github-to-linkedin.
• The user wants a full written case study for a portfolio page: use portfolio-storyteller.
• The user has an existing draft that only needs cleanup: use technical-humanizer.

Shared references

The kit ships shared references that go deeper:

• ../../references/voice-guide.md — voice rules and banned patterns
• ../../references/credibility-rules.md — the full fact triage system
• ../../references/hooks.md — 24 hook patterns with examples
• ../../references/technical-storytelling.md — the story spine

These paths assume the full repository is present. Every skill in this kit is written to work standalone: the rules above are the complete core, and the references are depth, not dependencies.