agentleFS
teodstrteodstr/garage/skills/startup-roadmap/SKILL.md

startup-roadmap

Skill0 starsChanged 2 days agoMITView on GitHub

Diagnose where a startup or side project stands (idea, problem validated, solution validated, MVP, launch, growth), name its riskiest assumption, and turn it into a 30-day plan with weekly goals and the right garage skill for each step. Use when a founder asks where to start or what to do next, or shares an idea, a project or a business plan. Triggers: "startup idea", "I want to start a business", "where do I start", "next steps", "créer mon entreprise", "lancer ma startup", "par où commencer", "prochaines étapes", "emprender", "crear mi empresa", "por dónde empiezo", "próximos pasos".

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every few weeks, to check whether the project has reached the next stage.

    line 21
  2. Very specific:

    Not for a full strategy case or a business plan: use the boardroom skills (business-analysis, market-sizing, unit-economics) if they are …

    line 22
  3. Distinctive:

    Every weekly goal is measurable and fits the founder's real time.

    line 77

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Startup roadmap

Founders rarely lack ideas or tasks. What they lack is a clear view of which question to answer first. This skill finds the current stage of the project, names its biggest risk, and builds a short plan that tests it.

When to use

  • At the start of a conversation about a new project, or when the founder feels lost.
  • Every few weeks, to check whether the project has reached the next stage.
  • Not for a full strategy case or a business plan: use the boardroom skills (business-analysis, market-sizing, unit-economics) if they are installed.

Inputs

  1. The project in a few sentences: who has the problem, what the solution is, how it will make money.
  2. What already exists: conversations with customers, prototype, users, revenue, team, money, hours available per week.
  3. The founder's constraints and goal: side project or full time, budget, deadline, country.

Method

  1. Place the project on the stage ladder, using evidence rather than intentions:

    StageEvidence that it is done
    IdeaA written problem statement and a precise target customer
    Problem validatedA dozen or more conversations where people describe the problem and what they do about it today
    Solution validatedPeople commit something for the proposed solution: time, an email, a deposit, a letter of intent
    MVPA first version used by real customers, even if it runs by hand
    LaunchSign-ups or sales that keep coming from a channel, not only from the founder's network
    GrowthRetention and unit economics that justify spending to grow

    The "dozen conversations" is a rule of thumb, not a law: say so.

  2. Name the riskiest assumption of the current stage: the belief that kills the project if it is false (nobody has the problem, nobody pays, the channel costs too much, the product cannot be built).
  3. Pick the skills for the next 30 days:
    • Idea and problem stages: idea-validation, customer-interviews, desk-research, competitor-teardown.
    • Solution stage: mvp-scoping, landing-page, prototype-testing, survey-design.
    • MVP and launch: first-customers, brand-identity, financial-forecast, pitch-deck.
    • At any stage, when the question comes up: funding-options, support-programs, legal-setup.
  4. Build the 30-day plan: four weekly goals, each with one measurable result (for example "15 interviews done, notes shared"), the skill to use and the hours it needs. Check that the total fits the time the founder really has.
  5. Set a decision date. At the end of the 30 days, the founder continues, changes direction or stops, using criteria written now, before the results come in.
  6. Say what can wait. A logo, a company registration, fundraising and paid tools are often done too early. Name what to postpone and why.

Output

### Where the project stands
Stage: <stage> (evidence: <what proves it>)
Riskiest assumption: <the belief that kills the project if it is false>

### 30-day plan
| Week | Goal (measurable) | Skill | Hours |
|---|---|---|---|
| 1 | … | `customer-interviews` | … |

### Decision on <date>
Continue if … · Change direction if … · Stop if …

### Not now
<What to postpone, and why.>

Quality bar

  • The stage is backed by evidence, not by what the founder plans to do.
  • The plan tests the riskiest assumption first. It does not start with the logo, the registration or the app.
  • Every weekly goal is measurable and fits the founder's real time.
  • The decision criteria are written before the results come in.
  • Written in the user's language, with the terms below.

Terminology

EnglishFrançaisEspañol
StartupStartup, jeune pousseStartup, empresa emergente
FounderFondateur, fondatriceFundador, fundadora
Riskiest assumptionHypothèse la plus risquéeHipótesis más arriesgada
Minimum viable product (MVP)Produit minimum viable (MVP)Producto mínimo viable (PMV)
PivotPivotPivote
Product-market fitAdéquation produit-marchéEncaje producto-mercado

Sources

  • Blank, S. (2013). The Four Steps to the Epiphany (2nd ed.). K&S Ranch.
  • Ries, E. (2011). The Lean Startup. Crown Business.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.