New → research → plan → implement → review → archive. One change, six explicit steps.
SKILL LIBRARY // CATALOG
Every course skill in one catalog
The 10x-toolkit skills grouped by course module: 38 delivered in lessons plus two extras. Each card answers three questions - what the skill does, why it exists and what to keep in mind - and links to the module page, the skill page (when one exists) and the docs entry.
00PREWORK // GENERAL TOOLKIT
Module 0: the General Toolkit prompts
The prework ships the General Toolkit - a basket of cross-cutting prompts (including skill-explainer and mvp-check). They are prompts, so they have no cards in the library: you paste them into the agent conversation instead of installing them in a repository.
01MODULE 1 // FOUNDATION
Foundation: a project ready for an agent
Project preparation skills: idea check, context, requirements, stack, rules and infrastructure before the agent writes the first line of code.
/10x-idea-check
M1L1
What it does
A five-minute conversation about your course project idea: weighs it against your experience, learning goals, available time and the certification deadline, then recommends one next move.
Why it exists
Before investing in /10x-shape you know whether to shape this idea, a trimmed version of it, or clear a concrete obstacle first.
Keep in mind
Needs no repository or documents and asks at most three questions; it is not a submission audit or a PRD generator.
Runs a structured discovery conversation that turns an idea into shape-notes.md, the input to /10x-prd. Greenfield or brownfield mode is detected from the current repository.
Why it exists
Arrangements are settled before the PRD and the code, so later prompts do not undermine them.
Keep in mind
It precedes /10x-prd; the output is decision notes, and /10x-prd turns them into the requirements document.
Generates context/foundation/prd.md from shape-notes.md against a locked schema; it picks the greenfield (10 sections) or brownfield (11 sections) template on its own.
Why it exists
One requirements document in a fixed format, read by the next foundation skills: the stack selector, the roadmap and the test plan.
Keep in mind
Raw notes work as input too, but the best input is shape-notes.md from /10x-shape.
Assesses an existing project's stack against the 4 quality gates and writes stack-assessment.md: per-component scores, gaps and ready-to-paste CLAUDE.md/AGENTS.md entries.
Why it exists
Before an agent starts working in a brownfield, it pays to know where the stack will get in its way.
Keep in mind
The brownfield counterpart of the stack selector; in the brownfield chain it precedes /10x-health-check.
Scaffolds the project into the current directory after the stack is picked: reads tech-stack.md, runs the official starter's CLI and writes a verification log.
Why it exists
The project starts from an official, current starter, with a full log of what was created.
Keep in mind
The strict conflict policy always preserves the context/ directory; requires an existing tech-stack.md.
Audits an existing project: dependencies, security scan, test runner detection, CI/CD and missing configuration; writes health-check.md with prioritized fixes.
Why it exists
It ends with an agent-readiness verdict - you know what to fix before AI starts touching the code.
Keep in mind
In the brownfield chain it runs after /10x-stack-assess, before agent onboarding.
Appends one recurring rule to context/foundation/lessons.md in a fixed format: context, problem, rule, applies-to. The file bootstraps itself on first use.
Why it exists
A class of bug paid for once becomes a hard constraint for future plans, implementations and reviews.
Keep in mind
Append-only, existing entries are never edited; capture classes of problems - one-off fixes stay in commits.
A short interview plus parallel, bias-checked research of MVP deployment platforms; writes infrastructure.md with a scored comparison and a risk register.
Why it exists
The platform decision is made on evidence from current sources, before the project commits to a specific vendor.
Keep in mind
Runs after the PRD or the stack selection, before implementation; the deploy-readiness gate is /10x-deployment, later.
Runs interactive, skeptical planning: scales the number of questions to the complexity and the artifacts provided, writes plan.md with phases, success criteria and a Progress section, plus the plan-brief.md summary.
Why it exists
The key decisions are made before the code, where changing your mind costs a text edit.
Keep in mind
Every provided artifact (research, frame) means fewer questions; checkboxes live exclusively in the Progress section.
Reviews the plan across five dimensions: end-state alignment, lean execution, architectural fitness, blind spots and completeness; writes reviews/plan-review.md.
Why it exists
A plan flaw caught before implementation costs a document edit; caught in code, it costs a refactor.
Keep in mind
Re-running overwrites the report; the --quick flag limits the review to the document alone.
Audits and improves one view that already renders, as a normal 10x change: 3-5 charges (missing tokens, missing shared component, accidental architecture), the design-system contract first, the pixels second.
Why it exists
The next views inherit tokens and components instead of literals, and a rule in the agent file keeps the contract in later sessions.
Keep in mind
Works only on a view that already renders with real data; runs through /10x-research → /10x-plan → /10x-implement with a 7-state matrix and a screenshot gate.
Drives an approved plan test-first through the red-green-refactor cycle; it covers the phases that can be TDD-ed and routes the rest to /10x-implement.
Why it exists
The test's oracle comes from the requirements and the research, so the assertion genuinely fails on broken code.
Keep in mind
A hard budget of 15-20 tests total; no it.skip - a TDD test starts red.
Turns the quality gates from test-plan.md into working agent hooks (Claude Code, Cursor, Codex, Copilot): maps each gate to a moment - edit, end of turn, commit, push, CI - and generates the config and scripts.
Why it exists
A hook only helps when its message reaches the agent through the channel it actually reads - so every script is run against a deliberately broken file before hand-off.
Keep in mind
A per-edit hook checks only the edited file; existing config is merged, never clobbered. Git pre-commit/pre-push is only recommended.
A one-time, re-runnable Playwright setup: detects the stack, port and auth, writes playwright.config.ts with a webServer and a storageState sign-in, greens one seed test for a real risk and wires playwright-cli into the agent.
Why it exists
/10x-e2e gets ready infrastructure, and the seed is the model the agent copies for every later test.
Keep in mind
A second run on a finished project changes no files; it does not touch CI or commit anything. State is recorded in test-stack.md.
Audits the code for logic that hides production errors: swallowed exceptions, errors turned into redirects or 200s, lost stack traces, code paths outside the error tracker. Writes a dated report for the critical flows.
Why it exists
Answers one question: when this flow breaks in production, will anyone find out and be able to tell why - before an incident with no logs.
Keep in mind
Examines application code, not platform config; never modifies the audited code. Runtime proof (--runtime) happens only in an isolated copy.
Understanding a skill by watching it run, and a project map built from evidence: where to start in a repository nobody explained to you.
/10x-ray
M4L1
What it does
Teaches how a skill works by watching it run: maps its anatomy (steps, loops, fan-outs, human gates, branches), runs it in a subagent and reveals the map concept by concept as the run reaches each step.
Why it exists
Instead of scrolling through tool calls you understand why the author put each step there - and can carry those patterns into your own skills.
Keep in mind
The skill's questions reach you exactly as the skill would ask them; --mode html shows the same view on a live page in the browser.
Builds a Project Map (context/map/repo-map.md) of an unfamiliar or inherited repository in one run: business capabilities ranked by criticality × buzz, from four parallel evidence agents (history, discussion, structure, people).
Why it exists
Getting up to speed in a large repo starts from evidence, not from reading code: risk zones, a first-day reading list and explicit unknowns.
Keep in mind
Takes no target - breadth, not depth; a specific feature or question goes to /10x-research. Works on git alone, richer with the GitHub CLI.
The later lessons of the module rely on analytical prompts: research with the map, feature analysis, refactoring and DDD. The details live on the Legacy and Scaling pages.
05MODULE 5 // TEAMWORK
Teamwork: the system in a team
Idea validation, PR review in CI, a team AI package registry and autonomous implementation.
/10x-opportunity-map
M5L1
What it does
Turns recurring friction or an unmet need into a build / buy / complement / wait decision artifact, with one recommended candidate to try.
Why it exists
Classifying the pain before writing code protects you from building tools that already exist.
Keep in mind
Works for any idea - product, feature, internal tool, automation; the map carries a data-risk caveat.
The non-interactive CI twin of /10x-impl-review: discovers the plan from the PR, checks seven dimensions including test coverage, commits the report to the PR branch and leaves a summary comment.
Why it exists
The review lands on every PR automatically, as a pipeline step that runs without you.
Keep in mind
It reads source code without editing it; a REJECTED verdict fails the workflow unless the PR carries the impl-review-override label.
The autonomous sibling of /10x-implement under /goal: delegates phases to subagents, runs each through an automatic quality-gate stack and commits on green, with no human between phases.
Why it exists
The plan executes unattended - interactively under /goal or headless via claude -p.
Keep in mind
Ticks off Automated rows only; Manual rows come back as a human checklist. After two failed gate-fix attempts it halts with a STOP block.
A deployment-readiness gate for a PaaS target (Cloudflare, Vercel, Netlify, Fly.io, Railway, Render): a real preflight check, a readiness report, platform-native config and an optional CLI-driven deploy.
Why it exists
Deployment blockers surface on a real build, before the first deploy.
Keep in mind
Runs after the stack selection, before the first deploy; comparing the platforms themselves is /10x-infra-research, earlier.
