Start a new project with ak:bootstrap

Use ak:bootstrap to take a new project from an accepted outcome to running code. The Skill coordinates research, stack selection, design, implementation, testing, code review, UX/AI-experience enhancement, and onboarding instead of leaving you with an unexplained scaffold. There is no separate planning phase: the locked brainstorm contract goes straight to ak:cook, which sizes its own implementation plan.

Choose ak:bootstrap for a new project

Use ak:bootstrap when

• You are starting a project or full-stack setup from scratch.
• You can state the product outcome, constraints, non-goals, and observable acceptance criteria, or you want --ask to interview you until they are locked.
• You want stack and design decisions connected to a tested implementation.
• You are prepared for the selected mode to create project files and documentation.

Choose another workflow when

• You are changing an existing project with a known scope. Use ak:cook.
• You still need to compare product directions. Use ak:brainstorm first.
• You only need an implementation plan. Use ak:plan.
• You need to expose existing code as a CLI or MCP server. Use ak:agentize.

Prepare the project and runtime

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Open the directory that will own the new project.
• Decide whether Git may be initialized if the directory is not already a repository.
• State any required stack, compatibility, security, delivery, and licensing constraints before automatic selection begins.
• Keep credentials out of the request. Provide them later only through the project's approved setup flow.

See Runtime adapters before assuming that the same orchestration controls exist in every runtime.

Run the Skill

/ak:bootstrap "Create a private incident-response dashboard with SSO, an audit log, and no billing in v1" --full

/ak:bootstrap "Create a private incident-response dashboard with SSO, an audit log, and no billing in v1" --full

$ak:bootstrap "Create a private incident-response dashboard with SSO, an audit log, and no billing in v1" --full

If you omit a mode flag, the Skill uses --auto.

--ask is not a mode; it changes only how the opening brainstorm gate closes. It activates ak:advise to interview you one question at a time until the outcome, scope, constraints, non-goals, acceptance criteria, and definition of done are locked and confirmed, then continues in the selected mode. Without --ask, --auto decides each gap itself from your prompt, project instructions, and the existing workspace, and records each choice as an assumption; --full, --fast, and --parallel ask only about a decision that would materially change the product or safety.

--yagni composes with every mode. It opts into challenging and cutting scope that is not needed for the stated outcome; without it, the Skill scaffolds the full requested scope and adds nothing unrequested. The flag is passed through to ak:cook and ak:code-review so the choice survives each handoff.

--ultra composes with every mode, including --parallel. It makes the code review phase run /ak:code-review codebase --ultra (including the re-review after UX/AX enhancement), which uses code review's best-of-5 candidate dispatch, verification, and evidence-validated union finalizer. ak:cook and ak:enhance-ux-ax still run with their mode-appropriate flags. Never pair --ultra with code review's codebase parallel, which that Skill treats as a hard stop.

Describe the project clearly

A useful request includes:

• Outcome: State what a user can do when the project is running.
• Constraints: Name required technologies, platforms, compatibility, security rules, and delivery boundaries.
• Non-goals: Exclude adjacent features that should not enter the first implementation.
• Acceptance criteria: Give observable checks for the main path, failure behavior, and important edge cases.
• Authority boundary: State whether Git initialization, dependency installation, external research, asset generation, commits, publication, or deployment are allowed.
• Definition of done: Say whether the brief names a live target (production, a store, a registry); the project is done only after it is released there and verified the way a real user or client reaches it.

The incident-response example should also say who may view incidents, which events enter the audit log, what "private" means, and which validation proves the first usable release.

Understand the workflow

1. The Skill locks the project contract. It captures or reuses the outcome, constraints, non-goals, acceptance criteria, and definition of done, checking each surface the project has (web, mobile, CLI, API, MCP, WebMCP, library) against references/project-brief-checklist.md.
2. The Skill checks Git state. It inspects the actual destination and reuses an existing project and branch conventions rather than re-scaffolding or resetting it; it initializes Git only for a new project when the brief includes it.
3. The Skill researches and selects the setup. The depth, parallelism, and approval gates follow the chosen mode.
4. The Skill creates design evidence when applicable. It can produce design guidance, wireframes, screenshots, and generated assets through available design and media tools. A project without a visual interface designs its interface contract (commands, routes, tool schemas, public API) instead.
5. The Skill implements through ak:cook. There is no separate planning phase; the brainstorm contract plus the research, stack, and design outputs go straight to ak:cook with the mode-appropriate flag, and cook sizes its own implementation plan and runs the tests.
6. The Skill runs code review. ak:code-review reviews the new project (--ultra when bootstrap received it); blocking findings go back through ak:cook with the same mode flag until review passes.
7. The Skill enhances UX and AX for a web surface. When the project has a website or web app, ak:enhance-ux-ax --auto runs after code review passes and its changes are reviewed the same way; it is skipped and reported for a CLI, API, MCP server, or library.
8. The Skill releases and verifies live, when the contract calls for it. When the accepted contract includes a release or names a live target, the Skill provisions what the brief authorizes, releases through the pipeline, and verifies each surface the way a real user or client reaches it. Otherwise it reports the project as verified locally only.
9. The Skill finishes the project handoff. It evaluates documentation, updates plan state, guides onboarding, and reports changed files, checks, risks, and next actions.

Keep approval and safety with you

Automatic execution does not grant unrelated authority. External research, asset generation, dependency installation, credential use, commits, pushes, publication, and deployment still depend on the tools available and the scope you approved. The release and live-verification phase runs only when the contract calls for it, and provisioning, staging, and production release stay separate approval points within it.

Parallel mode requires exclusive file ownership and explicit dependencies. Separate workers or worktrees reduce edit collisions; they do not provide an operating-system sandbox or make conflicting changes safe to merge.

Verify the result

A complete run should provide:

• A runnable project that matches the accepted outcome and non-goals.
• Stack and design decisions recorded in the project's documentation where they materially affect future work.
• Real tests and project checks, with failures resolved or reported.
• A code-review result with no hidden critical finding.
• For a web surface, an ak:enhance-ux-ax result against its DONE contract, or an explicit note that the project has no web surface.
• Onboarding steps for configuration that still requires you.
• A concise final report with changed files, validation, remaining risks, the definition of done and whether it was met, and unresolved questions.

Treat generated wireframes or a passing build as intermediate evidence. The project is complete only when the acceptance criteria, tests, review, UX/AX enhancement (for a web surface), and onboarding path agree.

Troubleshoot or continue

Continue with Installing kits, the Engineer Kit overview, or ak:cook when the project already has an accepted implementation scope.

Know the current limits

• The Skill depends on the planning, implementation, testing, review, design, and media capabilities actually available in the active runtime.
• Dependency and asset tools may require network access or provider setup; the workflow cannot manufacture missing credentials or service availability.
• --fast reduces research overhead, not implementation verification.
• --parallel helps only when work can be split into independent ownership.
• UX/AX enhancement and live verification run only for the surfaces and release targets the accepted contract actually names.