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, planning, implementation, testing, review, documentation, and onboarding instead of leaving you with an unexplained scaffold.

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.
• You want stack and design decisions connected to a tested implementation.
• You are prepared for the selected mode to create project files, plans, 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 flag, the Skill uses --full.

--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:plan and ak:cook so the choice survives each handoff.

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.

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, and acceptance criteria before any setup work.
2. The Skill checks Git state. In --full, it asks before initializing Git. In --auto, --fast, and --parallel, the workflow initializes a missing repository through its Git workflow.
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.
5. The Skill creates a plan. It invokes ak:plan with the mode-appropriate planning behavior and preserves the accepted contract.
6. The Skill implements through ak:cook. The plan is handed to ak:cook; testing and code review follow that workflow rather than direct untracked edits.
7. 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 final Git action remains a separate question.

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.
• A plan with current phase state and acceptance criteria.
• 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.
• Onboarding steps for configuration that still requires you.
• A concise final report with changed files, validation, remaining risks, and unresolved questions.

Treat generated wireframes or a passing build as intermediate evidence. The project is complete only when the acceptance criteria, tests, review, 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.
• Stable and beta contain the same ak:bootstrap workflow and mode behavior.