explore

Explore, Frame & Lock the Content

Sharpen the raw idea in $ARGUMENTS into something worth publishing, before a single platform post is written. The job here is not to format what was handed over — it's to make the idea sharper, decide the strongest way to tell it, and produce a locked master content that every platform will later render.

This skill owns Phase 1 of the pipeline and the approval gate: no LinkedIn/Substack/Medium asset is generated until the person confirms the content is good.

Work the passes in order.

Pass 0 — Assumptions & clarification (do this first, every time)

Before sharpening anything, surface what you're assuming and what you're unsure about. Readers and authors lose time when an unspoken assumption turns out wrong.

• State assumptions explicitly. List the things you're taking as given — audience, platform(s), level (beginner vs expert), tone (optimistic vs critical), length, whether it's part of a series, and any technical premise you're trusting. Flag each as an assumption, not a fact.
• Ask only the questions that change the output. If something genuinely forks the work (e.g. "is this for a general audience or engineers?"), ask it now rather than guessing. Keep it to the few that matter; don't interrogate.
• Offer sensible defaults. For anything non-blocking, pick the obvious default, say what you picked, and move on — let the person correct it.

Present the assumptions and questions, and let the person respond before going deep.

Pass 1 — Technical accuracy

Read the claims as a knowledgeable peer would. Gently correct anything imprecise, and strengthen the argument rather than merely fact-checking it. Frame it collaboratively — "you're right, with N precision tweaks" — never as a takedown. A wrong technical detail in a published post is a real credibility cost, so this pass matters. If the person invited correction, lean in confidently.

Pass 2 — Framing

Find the single strongest angle and surface it explicitly. The raw framing is often weaker than what the material can support. Watch for three traps:

• Self-undercutting framing — a hook that contradicts the thesis (e.g. calling something "the same story repeated" when the whole point is that the last step breaks the pattern).
• Loss-framed when it could be forward-looking — a negative/ominous angle where an evolutionary, momentum-forward one is truer to intent. Default to optimistic unless the person wants critique or warning — but confirm, don't impose.
• Pedantry-bait — hard dates, exact figures ("70 years"), contestable specifics that invite "well, actually" replies. Strip them unless load-bearing; timeless framing ("always," "every leap") is stronger and unarguable.

Output: the spine + the locked content

End with two things:

1. The spine — one or two sentences capturing the thesis arc, the through-line every later asset will share. A useful shape: "Every step in X traded A to gain B; the newest step is the boldest version of that move; and we're already maturing it."
2. The master content — the finalized, platform-neutral substance: the key beats in order, the one running example to use throughout, any code/figures, and (if part of a series) the call-back to the previous piece and the tease for the next. This is the single source of truth all platforms render from.

Pick one concrete running example and note it explicitly — every platform and every code snippet must reuse the same example so the package feels coordinated.

The approval gate (do not skip)

State clearly that this is the content-finalization phase, then stop and get explicit approval before any platform post is generated. Only once the person says the content is good do the write-linkedin, write-substack, and write-medium skills render it.

If the person later asks to change the content (even after posts exist), come back here: update the master content, re-confirm, then have every platform asset regenerated so they stay in sync. Never let a content change live in only one platform.