FREESKILL v1.0UPDATED 2026-08

Loglines

Most launch plans are written forward, from what the team is building toward whatever the customer might get. This playbook writes the announcement first, dated in the future and phrased as if it already shipped, then answers the questions that announcement raises. What the launch will not include is a required section, not an afterthought. Run it here, then install it where the launches actually get planned.

A launch plan written forward can stay vague indefinitely. It lists what the team will build, and every sentence is a promise about work rather than a claim about what a customer will have. Nobody can tell from it what the release actually is, so the disagreements surface in the launch review instead of in planning, when they are expensive.

Writing the announcement first closes that gap, because an announcement has to say what shipped. Give it a future date and past-tense prose and the plan inherits a customer-facing claim it has to be able to keep. The FAQs underneath then answer for that claim: who this is for, what evidence says they want it, what the team will measure, and what the launch deliberately leaves out. The out-of-scope section is where scope discipline becomes real, which is why it is mandatory rather than optional.

If you cannot write the announcement, you do not yet know what you are shipping.

SIGNALS YOU NEED THIS

The launch doc lists features and nobody in the room can say, in one sentence, what the customer gets.

Three benefits are tied for most important, which means the team has not decided what the launch is for.

Scope has grown twice since the plan was written, because nothing in the plan ever said what was out.

REPLACES

Feature lists standing in for launch plans, announcement copy written the week of release when the scope is already fixed, and the launch review where somebody first asks who this was for.

0 of 4 steps complete

STEP 01Check the launch's weight, then write the log line first

A feature, product, service, or improvement inside an existing business gets a logline. A brand-new product or a significant investment gets the full press release and FAQ instead, which is a different tool and a different skill; that check is working, not output, and the reader only sees it when the answer is to route elsewhere. Then the log line itself, before any FAQ: a future date, then two to four sentences in present or past tense as if the launch is live, carrying the single most important customer benefit. The date is the mechanism. Writing from a date that has not arrived forces the prose into the customer's terms, because an announcement cannot describe a backlog.

THE SHAPE, and why each part is load-bearing
  Date:     a real future date, not "soon" and not "Q1"
  Log line: 2-4 sentences, present or past tense, as if live
  Benefit:  exactly one, ranked first on purpose

ONE BENEFIT, NOT THREE. The log line becomes the basis of the
customer communication, so the ranking decision has to happen
here. A tie means the team has not decided what the launch is.

WHERE IT ROUTES INSTEAD
  feature, service, improvement  -> logline
  brand-new product, big bet     -> working-backwards

STEP 02Answer the Customer FAQ, and let question 4 stay honest

Five questions: who the customer is, what problem or opportunity this closes, the one benefit that matters most, how the team knows customers want it, and what the experience is from discovery through use. Question 4 is the one that keeps the whole document honest, because it is the easiest to fill with something that sounds like evidence. Real research goes in by name: interviews, behavior, purchase patterns, support themes. Where none exists, the field reads Evidence needed rather than citing a study nobody can point to. A gap in one field never backfills another, so a question the input cannot answer carries its label rather than an answer inferred from a neighbor.

FAQ 4, ANSWERED HONESTLY when the evidence is partial
  4. How do we know what customers need or want?
     Support tickets requesting alerts arrive weekly. Buyer
     reviews cite missed pieces as a recurring complaint.
     Quantitative sizing across all sessions is Evidence needed.

WHAT THAT COSTS AND BUYS. The section stops looking finished.
It also stops claiming a number nobody measured, and it tells
the reader exactly which research would close it.

AN INVENTED STUDY is worse than a labeled gap, because a gap
is a question and a study is an answer that cannot be checked.

STEP 03Answer the Stakeholder FAQ, where the drafted testimonial and the out-of-scope live

Seven questions carry the execution half. The testimonial is invented on purpose, because its job is to state the reaction the launch is designed to earn, and it is always labeled as drafted; presented as a real quote it stops being a planning tool. KPIs are numbers somebody could actually pull. Milestones carry the detail that says what each one depends on or resolves. Risks are stated plainly. Job stories come from real people, and one the team wants but cannot source stays in the table reading Source needed rather than being attributed to a customer who does not exist. Out of scope is mandatory and real. Experiments each carry a hypothesis a result could confirm or kill.

THE TESTIMONIAL, labeled where it sits
  Drafted testimonial: "I had been hunting for that chair for
  six months and kept missing them. I saved the search on a
  Tuesday and had a notification by Thursday."

  labeled drafted | specific | sounds like a person

THE JOB STORY THAT CANNOT BE SOURCED
  | 3 | Source needed | Proposed story about buyers who search
        by era rather than by item awaits a real customer |

OUT OF SCOPE IS NOT OPTIONAL. Name the things a stakeholder
could reasonably have assumed were included. Six lines here is
cheaper than one discovery in the launch review.

STEP 04Plan the appendix, then critique before it circulates

Name what the visuals will show at the fidelity the idea's maturity deserves: hand-drawn flows and storyboards while the idea is still moving, polished mockups only once it is stable, because high-fidelity visuals on an unstable idea turn the review into pixel pushing. The doc ends at the appendix list, with no closing summary and no count of what was left open. Then Mode B runs the 13 checks against the draft in order, quoting its own lines in each finding and writing the fix beside each failure. The verdict names two or three blocking findings, not thirteen, because the table already carries the rest.

THE THIRTEEN CHECKS, in order
   1 future date        8 milestones answer questions
   2 reads as launched  9 risks stated plainly
   3 one benefit first 10 job stories sourced
   4 customer specific 11 out of scope present and real
   5 evidence honest   12 experiment plan testable
   6 testimonial       13 visuals fidelity matches maturity
   7 KPIs measurable

CHECK 11 FAILS THE WHOLE DOCUMENT. Missing or empty out-of-scope
is not one finding among thirteen; it is the one that says the
launch has no boundary yet.

THE VERDICT NAMES TWO OR THREE BLOCKERS. A verdict that names
all thirteen has ranked nothing, which is the same defect the
log line's one-benefit rule exists to prevent.

Download the folder into your agent's skills directory. It uses only the material you provide and makes no remote calls.

skills/loglines

loglines/
├── SKILL.md                          ← the two modes + the delivery boundary
├── meta.yaml                         ← version, sources, test prompts, changelog
├── LICENSE.md                        ← MIT
├── assets/
│   ├── logline-template.md           ← the document shape + a filled example
│   └── critique-checklist.md         ← the 13 checks + the readout format
└── references/
    └── faq-guide.md                  ← each question, its depth, its trap

INVOKE IT LIKE THIS

"Use the loglines skill to write the logline for this launch."

View source on GitHub Download ZIP v1.0

DESIGNED FORClaudeChatGPTCursorGemini

Pairs with

Playbooks that combine with this one. Each hands work to the next rather than repeating it.