From idea to the launch rampthe first deployment

The head of the bootstrap chain: it turns "I have an idea" (greenfield) or "I want to change this system" (brownfield) into structured notes from which /10x-prd generates a PRD conforming to the locked schema. The skill is a facilitator, not a generator - it never writes vision, requirements or business rules the user did not state; its value is the shape and order of the questions.

Input: an idea in free form - inline, a file with notes or a conversation. Output: context/foundation/shape-notes.md with a checkpoint in the frontmatter (current phase, completed phases, number of collected requirements), so a session can be interrupted and resumed from the next phase instead of from zero. At the end, the /10x-prd command lands in the clipboard.

Every discovery phase runs the same loop:

• the phase opens with one open-ended question - the first version of the content comes from the user,
• 3-5 "gray areas" as decisions with real options and trade-offs,
• one option marked as recommended, plus an "I don't know" option always on the table,
• the decision confirmed in a single sentence, and only then is the phase written to disk.

The mode is detected automatically from the directory, based on three levels of signals: git history (strong), lockfile (strong), the manifest alone (ambiguous - it may be a fresh npm init). Brownfield adds a section about the existing system and the question "what must NOT break", and the confirmed context_type drives the further routing of /10x-prd.

Three hard rules: it does not generate content the user did not state; it never prejudges the stack (framework, database, hosting - those are decisions for the steps after /10x-prd); it requires an initialized context/foundation/ - if it is missing, it delegates the scaffold to /10x-init.

The tail of the bootstrap chain (/10x-shape → /10x-prd → /10x-tech-stack-selector → /10x-bootstrapper). One job: turn the saved tech-stack handoff into a project scaffolded from a starter in the current directory, with a verification log to review. It only consumes the starter registry - starters are defined by /10x-tech-stack-selector.

Input: context/foundation/tech-stack.md - a hard precondition. Without that file the skill refuses and points back to /10x-tech-stack-selector; not even a stack discussed earlier in the conversation can replace it - the contract is the file on disk. Output: project files from the official starter plus context/changes/bootstrap-verification/verification.md as an audit trail of the run.

Four steps:

• replaying the loaded handoff for confirmation or correction,
• a light starter freshness test (package version, last repo push) - it warns, it does not block,
• running the official CLI command template using one of three directory strategies,
• a post-scaffold dependency audit split into CRITICAL / HIGH / MODERATE / LOW.

context/ is always preserved - the scaffold never overwrites it. Existing files in conflict get a sibling .scaffold file, and .gitignore is merged by appending. A non-zero CLI exit code is a hard stop: the temporary directory stays for inspection, and a partial verification log lands on disk.

It does not generate AGENTS.md / CLAUDE.md (that is the agent onboarding topic), does not run git init, does not auto-fix audit findings - it informs, the decision belongs to the human.

Generates AGENTS.md - an onboarding document for AI agents working in the repository. Short, project-specific and ordered by impact: the heaviest rules and the most-used commands at the top, so a fresh agent reads it once and stays unblocked.

Input: the repo itself - the manifest, README, lint/test configs, directory layout and the last 30 commits (that is where the commit message convention comes from). Output: an AGENTS.md with a budget of 200-400 words (120-250 for the directory variant), with @path/to/file references instead of pasted configuration.

When the file already exists, the skill does not overwrite. It dates it via git log, compares the repo state since the last edit and classifies every line: KEEP / UPDATE / REMOVE / MISSING. Then it edits surgically - after the user approves the change list - instead of rewriting from scratch.

Five hard gates before saving:

• the length budget - too short means no specifics, too long means filler,
• zero multi-line snippets - a file reference instead,
• every rule checkable against a diff ("clean code" and "best practices" are out),
• zero knowledge the model picked up in training anyway,
• critical rules in the first third of the file.

It does not invent facts about the project - every sentence must be backed by an inspected file, command or commit. It does not repeat framework defaults or language tutorials; only project-specific knowledge earns a line.

A deployment-readiness gate for PaaS (Cloudflare, Vercel, Netlify, Fly.io, Railway, Render). It takes a working repo, classifies it, picks a platform and runs it through a real preflight - before the first deploy collides with platform limits in production.

Input: the repo (always the source of truth) plus hints from tech-stack.md and prd.md if they exist - when a document diverges from the code, the code wins and the divergence goes into the report. Output: context/foundation/deploy-readiness.md plus a minimal platform-native config (wrangler.toml, fly.toml, Dockerfile, a GHA workflow - depending on the track).

The repo lands in one of six tracks (static, edge-js, node-server, container, job, hybrid) based on signals from the code, not the user's declaration. A framework adapter can veto a platform choice (a config for a different one simply would not work), and platform limits are fetched from its documentation at run time - with a cited URL and a timestamp.

Every check ends as pass / warn / block, and any block stops config emission. Universally: .gitignore covers .env, a scan for git-tracked secrets, environment variable coverage against .env.example. Per track: the build passes, bundle or image size versus the limit, forbidden Node APIs in an edge bundle, a healthcheck in the container.

It is a document and config generator, not a deployer - it does not push images, does not set secrets in the repo, does not fire a deploy behind your back. Guided mode (CLI or MCP) executes steps only with per-step confirmation, and secret values never pass through the skill's memory or any saved file.