GistHubs project story writing
Write a specific project story from verified evidence. The reader should understand what changed, why it matters and what the real product feels like.
Inputs
Require:
- the project evidence brief;
- intended audience and publishing context;
- the real stage of the project;
- any human tone, length or claim constraints.
If evidence is missing, ask or qualify. Do not repair uncertainty with generic AI prose.
Choose a narrative
Select the smallest structure that fits the material. Common directions include:
- problem → constraint → working solution → proof;
- release change → before/after → how to try it;
- builder story → difficult decision → tradeoff → result;
- tutorial → concrete goal → steps → observed outcome;
- technical deep dive → system boundary → mechanism → verification.
Create multiple variants only when the underlying angle changes. Renaming the same outline is not a variant.
Write
- Lead with the most concrete consequence, not a ceremonial introduction.
- Use continuous prose and meaningful headings; do not force every paragraph into a form field or template slot.
- Prefer real nouns, actions, constraints and outcomes over adjectives.
- Keep claims inside the evidence scope.
- Mention limitations when they change the reader's decision.
- Remove stock phrases, repeated conclusions and fake enthusiasm.
Deliver a title, optional subtitle, excerpt, tags and complete Markdown body. When working inside gisthubs-agent-draft@1, place the result in a coherent Story and preserve evidence references for substantive claims. The human will refine wording in Studio, so do not lock prose into unnecessary micro-blocks.
Self-review
Read the draft once for facts, once for rhythm and once at mobile width. Cut any sentence that only announces what the next sentence will say. Confirm the opening, visuals and ending describe the same project rather than three different pitches.