fstack — the simple stack

fstack is a small collection of agent skills. Ten of them, exactly. Each one has a plain name and one job.

You invoke them as slash commands in Cursor, Claude Code, Codex, or any coding agent that reads markdown skills. /roast stress-tests a product idea. /interview records the business context. /align clarifies a task. /plan writes a short plan. /build implements it one step at a time. /check reviews the result. /ship gets it out the door.

The whole thing installs with one command:

                                npx skills@latest add flaviocopes/fstack
                              

No dependencies, no build step, no config. Markdown files in folders. You can read every skill in a few minutes, and that is intentional.

The signature idea: one skill, /simplify, exists only to remove things. Every other stack reviews for bugs, security, and scope. fstack is the only one with a skill whose entire job is asking: can this be less?

fstack is free and MIT licensed. The source lives on GitHub.

Skill collections keep growing. Thirty skills, personas, pipelines, voice triggers. You install one, feel productive for a day, then realize you only remember four commands. You cannot hold the rest in your head, so you stop using it.

There is a second problem. Most stacks push toward long autonomous runs: the agent plans, builds, reviews, and ships while you watch. Then you get a mountain of output to review at the end, when your context is coldest and the cost of a wrong turn is highest.

fstack bets the other way. The agent works in small steps. You approve; it executes. Decisions surface when they happen, not in a summary afterwards.

It distills four excellent skill collections — gstack, pstack, Compound Engineering, and Matt Pocock’s skills — through one filter: simplicity. That filter is not decoration. It is the product.

One command:

                                npx skills@latest add flaviocopes/fstack
                              

This copies ten folders of markdown into your agent’s skills directory. Nothing runs in the background. Nothing touches your PATH. There is no setup script because there is nothing to set up.

It works with Cursor, Claude Code, Codex, and any agent that supports the SKILL.md format. The skills are agent-agnostic on purpose: they say “run the tests”, never “use this specific tool”.

Want to check what you are installing first? Read the files on GitHub. All ten skills together are about 520 lines of markdown.

The five main skills form a loop you run for each piece of work:

                                align → plan → build → check → ship
                              

• /align — make sure the agent understands the task before any work starts.
• /plan — write a short plan you approve before building.
• /build — implement the plan one small step at a time.
• /check — review the finished work with three questions.
• /ship — run tests, commit, push, open a PR.

Two skills run before the loop. /roast, for when you have a product idea and want honest pushback before writing any code. And /interview, which asks about the business behind the project — demand, customer, pricing, risks — and records the answers in AGENTS.md so every future session starts informed.

Two skills you sprinkle in anywhere: /simplify when something feels bloated, and /learn when something is worth remembering.

And when you do not know where to start, /fstack is the front door. Describe what you want in plain words and it picks the right skill.

You do not have to run the full loop every time. A small fix might only need /build and /check. A messy file might only need /simplify. The loop is there when the work is big enough to deserve it.

Here is a full cycle on a real task: adding dark mode to a site. This is what working with fstack actually looks like.

You start at the front door:

The agent reads the relevant parts of the codebase, then asks its questions. All of them at once, five at most:

You confirm. The agent stops — /align never starts planning on its own. You invoke /plan and it writes a plan file:

                                # PLAN.md

## What we're doing

Add a dark mode toggle to the site header. The preference
persists in localStorage and applies on every page without
a flash of the wrong theme on load.

## Steps

1. Add a blocking inline script that reads the stored theme
   and sets a class on <html> before first paint.
2. Add the toggle button to the header.
3. Wire the toggle to switch the class and save the choice.
4. Add dark values for the existing CSS custom properties.

## What we're NOT doing

- No theme customization beyond light/dark
- No per-page theme overrides
- No settings page — just the header toggle

## How we'll know it works

- Toggle the switch, refresh, theme persists.
- Hard-reload on a dark-mode profile: no light flash.
                              

Notice the “What we’re NOT doing” section. It is mandatory and can never be empty. Naming the tempting extras is how they stay out of the diff.

You approve the plan and say build. The agent takes one step at a time, and pauses when a step involves a real choice:

When all steps are done, /check reviews the work. Three questions, with evidence, and a one-line verdict:

That simplicity flag is worth a detour. You run /simplify, it proposes deletions, you approve two of them. Then /ship runs the tests, shows you a one-paragraph summary, and — after you confirm — commits, pushes, and opens the PR.

One last thing. The theme-flash fix was non-obvious, so you run /learn:

                                ## 2026-07-11 — Theme flash on load
The theme must be set in a blocking inline script, not in React.
Anything set after hydration flashes the wrong theme.
                              

Three lines in LEARNED.md. The next session starts smarter.

The router. You describe what you want in plain words; it picks the right skill and starts it. Use it when you do not know, or do not care, which skill fits.

The routing map is simple:

• Product idea, not sure it’s worth building → /roast
• New project, the agent lacks business context → /interview
• Vague or new idea for this project → /align
• Idea is clear, no plan exists → /plan
• Plan exists and is approved → /build
• Feels bloated or too complex → /simplify
• Work is done, needs review → /check
• Something worth remembering just happened → /learn
• Reviewed and ready to go out → /ship

It says which skill it picked and why, in one sentence. Then it runs that one skill and stops. It never chains skills into a pipeline.

If the request is truly ambiguous, it asks one clarifying question — one, not a questionnaire. Still ambiguous after that? It routes to /align. That is what /align is for.

The most expensive mistake in software is not a bug. It is spending three months building something nobody needs. /roast exists to catch that before any code gets written.

You bring a product idea. The skill asks up to five hard questions, all in one message, picked for that specific idea:

• Who is the one person who needs this most? Describe them, specifically.
• What do they do today to solve this, even badly? What does that cost them?
• What is the strongest evidence someone wants this? Someone who would be upset if it vanished, not someone who said “cool”.
• What is the smallest version someone would pay for this week?
• How will the first 100 people find it?

Then it stops and waits for your answers. A vague answer gets one follow-up push, not an interrogation.

The roast itself comes in three parts. What is real: the parts backed by evidence or a lived problem. What is wishful: the parts held up by hope, said plainly. The wedge: the smallest version worth building — shippable in days, not months. It ends with one verdict line: build the wedge, shrink it, or don’t build it.

Behind the questions sits a short list of principles about how small software products actually get built. The status quo is the real competitor — if people solve the problem with “nothing”, the pain is probably not real. Small and shipped beats big and planned. Charge real money, simply. Build for one specific person, and it is fine if that person is you. A demo is not a product. Distribution is part of the product. Boring tech ships.

What it must not do: flatter, kill ideas for sport, invent numbers or fake research, or start planning. Every roast ends with the best small version of the idea, even when the verdict is harsh. And the skill ends at the verdict — building is a separate decision, made by you.

Agents make product decisions all day — what to name things, what to simplify, what edge case matters. Without context, they guess. /interview fixes that once: it asks you about the business behind the project, then records the answers in AGENTS.md (or CLAUDE.md), so every future session starts informed.

It starts by reading the project — README, existing context files, the code — and never asks something the project already answers. Then it interviews you in rounds of 3 to 5 questions, not a wall of twenty. The questions are written for your specific project, never copied from a fixed questionnaire. It draws from areas like:

• Demand — Is there enough customer demand? Are people already searching for this, and where? How easy is it to get someone to sign up?
• Customer — Who exactly is this for? Who pays, and is that the same person who uses it?
• Business model — Can price times realistic volume produce revenue worth the effort? One-time or recurring, and why?
• Founder fit — Is this an industry you want to be in for years? What is your unfair advantage here?
• Status quo — What do people use today instead? What would make them switch?
• Distribution — How will the first 100 people find it?
• Risks — Which single assumption, if wrong, ends the project?
• Success — What does “working” look like in six months? What number would tell you to stop?

“I don’t know” is a valid answer. It gets recorded as an open question, not pushed past twice.

The output is a short Product context section — one line per answer — that the skill shows you before writing anything:

                                ## Product context

- **Product:** one line on what this is.
- **Customer:** who it is for, specifically.
- **Demand:** the evidence, in one line.
- **Business model:** pricing and why it can work.
- **Status quo:** what it replaces.
- **Distribution:** how people find it.
- **Not doing:** what is deliberately out of scope.
- **Open questions:** everything answered “I don’t know”.
                              

It never deletes what is already in the file, and it never judges the idea — that is /roast’s job. Roast decides whether to build. Interview makes sure the agent knows what it is building.

The most common failure in agent work is not bad code. It is good code for the wrong task. /align exists to catch that before any work starts.

How it behaves:

1. Reads your request and the relevant parts of the codebase.
2. Asks at most 5 questions, all in one message. Only what it genuinely cannot infer.
3. Waits for your answers. No planning or coding in the meantime.
4. Replies with a 3-line summary: what we’re building, the one constraint that matters most, and what success looks like.
5. Asks you to confirm the summary. It does nothing else until you do.

The question cap has a second use: it is a task-size detector. If the agent has 8 genuine questions, the task is too big — and instead of asking them all, it says so and suggests splitting the work.

What it refuses to do: ask questions whose answers are already in the codebase or the conversation, and start planning or coding. The skill ends at the confirmed summary.

Turns a confirmed understanding into a plan you approve before building. The plan is a file — PLAN.md in the project root — not a message that scrolls away. Long-lived state belongs in the repo, not in chat memory.

The plan has exactly four sections. No others are allowed:

• What we’re doing — 2–4 sentences, plain language.
• Steps — a numbered list, max 7. Each step small enough to finish and verify in one sitting.
• What we’re NOT doing — mandatory, never empty. The tempting extras that are out of scope.
• How we’ll know it works — 1–3 plain checks you can actually try.

The whole plan fits on one page. If it does not, the task needs splitting into multiple plans. If any step feels big, it gets split or cut — never nested into sub-steps.

The “NOT doing” section is the one people copy into other workflows. Scope creep does not announce itself; it slips in as “while we’re here”. Writing the exclusions down turns them into something you can point at.

The skill ends at approval. It never starts implementing.

Executes the approved plan one step at a time. The rhythm is always the same:

1. Take the first unfinished step from PLAN.md.
2. Implement it with the smallest change that works.
3. Verify it — run it, run the test, load the page, whatever fits.
4. Report in 2–3 sentences: what changed, how it was verified.
5. Mark the step done in PLAN.md.

Before moving to the next step, one check: does it involve a real choice? A library, an API shape, naming that leaks into the public surface. If yes, the agent stops and asks, with a recommendation and a reason. If no, it continues.

What it refuses to do:

• Work that is not in the plan. Discovered work gets added to PLAN.md and asked about first.
• Refactoring surrounding code “while you’re there”.
• Batching multiple steps into one big change.
• Skipping verification on any step.

This is the tracer-bullet style: a thin, verified, end-to-end change at every step. You always know exactly where the work stands, because PLAN.md says so.

The signature skill. Point it at a plan, a diff, a file, or a folder, and it hunts for unnecessary complexity. It proposes deletions and reductions. Only those — it is not allowed to propose additions.

It looks for six specific smells:

• Abstractions with one caller
• Config options nobody asked for
• Dependencies that replace 10 lines of code
• Error handling for situations that can’t happen
• Files, helpers, or layers that exist “for the future”
• Words in docs or comments a beginner wouldn’t know

Each proposal is one line: what to remove, and what you would lose. Usually: nothing.

Nothing gets applied without your approval. And it never rewrites working code to a different style — simpler, not different.

Run it on code, but also on plans before you build them, and on docs before you publish them. The fstack README itself went through it.

Reviews finished work before it ships. Exactly three questions, in order, each answered with evidence:

1. Does it work? Prove it by running it — tests, the dev server, the actual command. “It should work” is not an answer. The real output gets pasted in.
2. Does it match the plan? Diff the work against PLAN.md. Flag anything built that wasn’t planned, and anything planned that wasn’t built. Then check the blast radius: what else could this change affect — callers, styles, routes, configs — and is each one fine?
3. Is it simple? A quick pass with the /simplify smell list. If something smells, it says so and suggests running /simplify — it never runs it automatically.

It ends with one verdict line: “Ready to ship” or “Not ready: [reason]”.

The important constraint: /check reports and stops. It never fixes what it finds. Review and repair are different jobs, and mixing them is how “small fixes” turn into unreviewed rewrites. You decide what happens next.

It also refuses to add review dimensions. No security theater, no style nits. Three questions only.

After a piece of work, capture the single most useful lesson so future sessions start smarter. One lesson, not several. Three lines, not an essay.

Entries go in LEARNED.md in the project root, in this exact format:

                                ## 2026-07-11 — Theme flash on load
The theme must be set in a blocking inline script, not in React.
Anything set after hydration flashes the wrong theme.
                              

The bar for an entry: would this save future-you real time? Routine facts do not qualify. “Added a component” is not a lesson. “The webhook fires twice on retries, so the handler must be idempotent” is.

The skill checks the file for duplicates first, appends, and shows you what it added. It is the one fstack skill with no approval gate — appending three lines to a log is cheap, and friction here means lessons never get captured.

This is the compound step: each cycle of work leaves the project a little easier to work on than before. Agents read LEARNED.md at the start of a session and skip the potholes you already hit.

Gets reviewed work out the door. The steps:

1. Run the project’s test suite, or the closest thing it has. Anything fails — stop and report. Nothing ships.
2. Write a one-paragraph summary of what is being shipped.
3. Show you the summary and wait for your go-ahead.
4. Commit with a plain one-line message.
5. Push to the current branch.
6. If the project uses pull requests, open one with the summary as the body.
7. Suggest /learn if anything from the cycle is worth keeping.

Where it stops matters as much as what it does. Shipping ends at the push or the PR. It never deploys — that is your call, on your platform, on your schedule.

It also refuses the shortcuts that cause incidents: no force-pushes, no skipped hooks, no amending commits that are already on the remote, and no shipping when /check has not said “Ready to ship”.

fstack keeps project state in two plain files, committed to the repo like everything else. Chat history is a terrible database. Files survive sessions, agents, and machines.

PLAN.md is the current piece of work. Written by /plan, updated by /build as steps complete, diffed against by /check. When the work ships, the next plan replaces it.

LEARNED.md is the project’s memory. Appended by /learn, three lines at a time. A healthy one after a few months looks like this:

                                ## 2026-05-02 — Paddle webhooks retry
The purchase webhook fires again on timeout. The handler
must be idempotent on the transaction id.

## 2026-06-14 — Astro static routes win
A static page file beats the [slug] dynamic route at the
same path. No config needed, but easy to forget it exists.

## 2026-07-11 — Theme flash on load
The theme must be set in a blocking inline script, not in React.
Anything set after hydration flashes the wrong theme.
                              

That is the whole state model. Two files, both readable in under a minute, both diffable in code review. No dashboards, no databases, no session storage.

Every fstack skill is written against these rules. They are also decent rules for anything you write — docs, plans, commit messages.

1. Short sentences. One idea per sentence.
2. Short paragraphs, then a blank line.
3. No jargon. If a plumber wouldn’t understand the word, find a simpler one.
4. No personas. Skills describe steps, not characters. No “you are a senior architect”.
5. One job per skill. A skill that does two things is two skills.
6. Prefer deletion. When something can be shorter, make it shorter.
7. Every skill fits in ~150 lines. Over the cap means the skill is doing too much.
8. The human drives. Skills pause at decision points and ask. No long autonomous pipelines.
9. Agent-agnostic. Plain markdown, no hardcoded tool names.
10. Plain-English tone. Like explaining to a friend. No hype.

The line cap deserves a note. It is not about saving tokens. It is a forcing function: a skill you can read in two minutes is a skill you actually understand, and a skill you understand is a skill you can trust with your codebase.

fstack did not appear from nothing. It distills four collections, keeping the ideas and dropping the machinery.

From gstack (Garry Tan): the full lifecycle idea — think, plan, build, review, ship — the scope-reduction instinct of “strip to essentials”, and office hours, which /roast distills into five questions and a verdict. Left behind: the 30+ skill count, the personas, deploy orchestration, canary monitoring, iOS tooling, voice triggers.

From pstack (Lauren Tan): design before code, blast-radius thinking — know what your change touches before you ship it — and the router pattern of one entry point that picks the right skill. Left behind: parallel candidate arenas, depth-first ceremony, anything requiring worktrees.

From Compound Engineering (Every): the plan file as an artifact, the compound step of capturing one lesson after each piece of work, and the human-approves-the-plan checkpoint. Left behind: long autonomous runs and multi-agent review panels. fstack keeps the question those reviewers ask, not the roleplay.

From Matt Pocock’s skills: grilling — asking clarifying questions before work starts — the two-axis review (does it work / is it right), and the small, composable skill shape. Left behind: the full grill-with-docs machinery and TDD as a mandatory gate.

And the one thing none of the sources has: a skill whose only job is asking “can this be less?”. That is /simplify, and it is why fstack exists as its own thing rather than a fork.

Do I need all 10 skills?
No. The loop is there for work big enough to deserve it. Plenty of tasks only need /build and /check. /simplify is useful entirely on its own.

Which agents does it work with?
Cursor, Claude Code, Codex, and anything else that reads SKILL.md files. The skills never reference agent-specific tools, so they degrade gracefully across hosts.

How is this different from gstack or pstack?
Those are bigger and do more — browser QA, deploy pipelines, security audits, parallel candidates. fstack is deliberately the small one: 10 skills, no personas, no pipelines, and a bias toward deleting things. If you want a virtual engineering team, use gstack. If you want a calm loop you can hold in your head, use fstack.

Can I edit the skills?
Yes, and you should. They are markdown files in your skills folder. If a rule does not fit how you work, change it. MIT licensed.

Does it send data anywhere?
No. There is no telemetry, no server, no account. It is text files that your agent reads.

Why the hard caps — 5 questions, 7 steps, 150 lines?
Caps are how simplicity survives contact with real work. Without them, questions multiply, plans nest, and skills bloat. Each cap doubles as a signal: hitting it means the task is too big, not that the cap is too small.

What happens when the plan turns out to be wrong mid-build?
The agent adds the discovered work to PLAN.md and stops to ask. You decide: amend the plan, or finish the current scope and plan the rest separately. What never happens is silent scope drift.

fstack exists because of the stacks it distills: gstack by Garry Tan, pstack by Lauren Tan, Compound Engineering by Every, and Matt Pocock’s skills. Go look at all four — they are generous, thoughtful work.

fstack is MIT licensed. Source, issues, and contributions: github.com/flaviocopes/fstack.