Building from scratch

Building From Scratch: Orchestrator

What this is

This is the front door to a library of 15 foundational skills for producing high-quality work from almost nothing. You do not need to remember all 15. You use this skill to figure out where you are and which specific skill to load next, then you invoke that skill and follow it.

Core principle: Match the moment to the skill. At every point in a project there is a "current need", scope it, plan it, build it, debug it, verify it, document it. This orchestrator maps needs to skills.

How to use this orchestrator

1. Identify the current need using the routing table below (what is the user actually trying to do right now?).
2. Invoke the matching skill with the Skill tool. Do NOT try to recall the skill's contents from memory: load the actual skill so you follow it faithfully. Announce "Using <skill> to <purpose>."
3. Follow that skill, then return here to pick the next need as the work moves forward.
4. Chain naturally through the build arc (below). Most projects flow understand → plan → build → finish, with a few skills running continuously underneath.

One skill at a time. Load it, apply it, come back. You are routing, not doing everything at once.

Routing table: "which skill right now?"

The situation right now	Load this skill
A request is vague/broad; need a bounded goal and a first target	scoping-and-initialization
Not sure exactly what to build or how to test "done"	requirements-and-success-criteria
The work is big; need to break it into ordered steps	planning-and-decomposition
A real design/tool choice, a surprising result, or a decision to record	first-principles-reasoning
Ready to actually build; want to stay runnable and verified	implementation-strategy
Something is broken, wrong, or flaky	systematic-debugging
About to claim it's done / fixed / working	self-verification
It must survive bad inputs, failures, real-world usage	robustness-and-failure-modes
Need information you don't have; must not invent facts	research-and-synthesis
Keep losing track of the plan, decisions, or where you were	context-and-knowledge-management
Someone else (or future-you) must understand the work	documentation-and-knowledge-capture
Starting out, or about to do something risky/hard-to-undo	risk-identification-and-mitigation
Building something that must be easy to change later	maintainability-and-extensibility
A large project spanning many steps or sessions	long-horizon-project-management
Writing any response, doc, plan, or artifact and want it tight and clean	output-economy-and-communication

The build arc (typical order)

Phase 0: Understand (do not build yet). scoping-and-initialization → requirements-and-success-criteria. Reach for first-principles-reasoning at any real choice and research-and-synthesis for any knowledge gap. Exit when: one-sentence goal + testable "done" exist.

Phase 1: Plan and de-risk. planning-and-decomposition + risk-identification-and-mitigation. Slice the work small, start with a walking skeleton, and spike the biggest unknown first. Exit when: an ordered plan with risky items scheduled early.

Phase 2: Build in verified increments. implementation-strategy as the spine; systematic-debugging whenever something breaks; bake in robustness-and-failure-modes and maintainability-and-extensibility as you go, not after. Exit when: the thing works, built to last, verified step by step.

Phase 3: Finish properly. self-verification before claiming done; documentation-and-knowledge-capture to leave the knowledge behind. Exit when: verified against the criteria and documented.

Running underneath every phase: context-and-knowledge-management (externalize goal/plan/decisions so nothing is lost) and, for anything spanning multiple sessions, long-horizon-project-management (re-ground at each start, hand off cleanly at each stop, finish slices completely). Always active too: output-economy-and-communication (keep every output correct but tight: no em dashes, no filler, fewer tokens).

Scale to the task (do not over-process)

Match the ceremony to the stakes:

• Tiny / throwaway (minutes): a mental one-sentence goal (scoping-and-initialization) + actually run it (self-verification). Nothing more.
• Small feature (one sitting): scoping-and-initialization → light requirements-and-success-criteria → a 3–5 line plan → implementation-strategy → self-verification.
• Real project (days+): the full arc above, with context-and-knowledge-management, long-horizon-project-management, and output-economy-and-communication running underneath.

Over-processing a five-minute task wastes as much as under-processing a five-day one. Use judgment on how much; use the skills for how well.

Default action

If the user is clearly starting something new and you're unsure where to begin, load scoping-and-initialization first. Understanding the problem always precedes building it.

The eleven cross-cutting principles (true across all skills)

1. Understand before you act. 2. Define "done" before you start. 3. Reality beats assumption: always look. 4. Work in small, verified steps. 5. Verify; never assume success. 6. Be honest about what you know and did. 7. Simplest thing that works, then evolve. 8. Anticipate failure; design for the unhappy path. 9. Externalize your state; don't trust memory. 10. Front-load the risky and the unknown. 11. Say it once, cleanly: economical output, never economical substance (no em dashes, no filler), but never cut correctness, evidence, or safety to look brief.

Two governing attitudes: match effort to stakes, and quality is a process, not a final polish.