story
Synthesize your project journey into a publishable narrative — tutorial, case study, blog post, or launch story. Pulls from git history, artifacts, and your decision log. Use when you want to write about how you built something.
What this skill does
# Story: $ARGUMENTS
You are synthesizing the CEO's project journey into a publishable narrative.
## Format Selection
If `$ARGUMENTS` specifies a format, use it:
- **tutorial** — Step-by-step guide someone can follow to reproduce the work
- **case study** — Before/after transformation with metrics and outcomes
- **blog post** — Narrative about the journey, emphasizing pivots and decisions
- **launch story** — Product announcement framed as the founder's story
If no format is specified, infer from the content:
- Heavy on technical steps with clear sequence → **tutorial**
- Clear before/after with measurable outcomes → **case study**
- Interesting pivots, rejected ideas, or lessons learned → **blog post**
- Product is ready to ship or just shipped → **launch story**
If `$ARGUMENTS` provides a title, topic, or focus area, use it to narrow scope.
## Source Material
Gather material from three sources (in order of storytelling value):
### 1. Decision Log (CEO's voice — most valuable)
Read `.solopreneur/observer-log.md`. These entries capture the CEO's actual decisions — what they chose, what options they rejected, and why. This is the raw material that makes a story authentic. If the log is sparse or empty, that's fine — the other sources compensate. Also check `.solopreneur/observer-archives/` for older entries if a longer history is needed.
### 2. Git History (timeline + milestones)
```bash
git log --oneline --stat
```
Commit messages show what was accomplished and when. The `--stat` output shows scope (which files, how much changed). Use this to build the narrative timeline and identify milestones.
### 3. Artifacts (substance)
Read files from `.solopreneur/` directories:
- `discoveries/` — What ideas were explored, what was validated
- `specs/` — What was planned, what requirements were set
- `designs/` — What the UX looks like, what design decisions were made
- `plans/` — Implementation plans and what was built
- `releases/` — What was shipped
These provide the concrete details that give the story substance.
## Process
1. **Gather sources** — Read the decision log, run git log, scan `.solopreneur/` for artifacts. Note what's available and what's sparse.
2. **Identify the arc** — Every project has a story: starting point → challenges → decisions → outcome. Map the material to this arc. The CEO's decisions (from the observer log) are the most compelling parts.
3. **Select format** — Choose based on `$ARGUMENTS` or infer from content (see above). Tell the CEO which format you're using and why.
4. **Delegate to `@content-strategist`** with the gathered material and the format-specific template below.
5. **Save** to `.solopreneur/stories/{date}-{slug}.md` (create the directory if needed).
6. **Present** to the CEO for review. Note where they should add real screenshots or personal anecdotes.
## Format Templates
Pass the appropriate template to `@content-strategist`:
### Tutorial
```markdown
# [Title]
## What We're Building
[Context — what and why, 2-3 paragraphs]
## Prerequisites
- [Tools, knowledge, setup]
## Step N: [Description]
**What we did**: [Action]
**Why**: [Rationale — pull from decision log entries]
**Code/Commands**:
...
**Result**: [What happened]
[IMAGE: description of what to screenshot]
## Key Takeaways
- [3-5 lessons from the process]
```
### Case Study
```markdown
# [Title]
## The Problem
[Starting situation — what wasn't working]
## The Approach
[Strategy chosen and alternatives considered]
## What We Built
[Solution overview with key decisions]
## Results
[Outcomes, metrics if available, before/after]
## Lessons Learned
- [What worked, what didn't, what we'd do differently]
```
### Blog Post
```markdown
# [Title]
[Hook — the most interesting moment, decision, or surprise]
## How It Started
[Origin — the idea, the motivation]
## The Journey
[Narrative of key decisions, pivots, and surprises. Use the CEO's actual words from the decision log where possible.]
## What I Learned
[Reflections and takeaways]
## What's Next
[Where the project goes from here]
```
### Launch Story
```markdown
# [Title]
## Why I Built This
[Personal motivation — what problem the CEO wanted to solve]
## How It Works
[Product overview — clear, benefit-focused]
## The Building Process
[Brief journey highlights — most interesting decisions or challenges]
## Try It
[CTA — how to use it, where to find it]
```
## Content Strategist Guidance
Tell the `@content-strategist`:
- Write in the CEO's voice (first person)
- Decision log entries are gold — weave the CEO's actual choices and reasoning into the narrative
- Git history provides the timeline, but don't list every commit — pick milestones
- Insert `[IMAGE: description]` placeholders where visuals would help
- Keep tone conversational and authentic — this is a founder telling their story, not a technical manual
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.