---
name: "goose-project-bootstrap"
description: "Bootstrap projects with Goose without placeholder docs."
status: proposal
version: "v1"
date: "2026-07-08T23:28:23.480Z"
proposal_id: "goose-project-bootstrap-20260708-0d34df5471"
---

# Goose Project Bootstrap

Use this skill when asked to install Goose, use Goose to create a new project, or evaluate whether Goose successfully bootstrapped a repo.

## Intent

Make Goose useful as a supervised project bootstrapper instead of letting it create thin placeholder files.

## Preflight

1. Check whether `goose` exists with `command -v goose && goose --version`.
2. If missing, install with the official stable CLI installer.
3. Run `goose info --check` with an explicit provider/model/key environment.
4. Prefer loading existing keys from local `.env` by extracting only the needed variable. Do not source arbitrary `.env` files that may contain unquoted shell metacharacters.
5. Do not duplicate API keys into Goose config unless the user explicitly asks for persistent Goose credentials.

## Bootstrap Prompt Pattern

When asking Goose to create a project, give it a bounded, quality-focused prompt:

- Absolute target path.
- Allowed files/directories.
- Explicit product context and intended audience if known.
- Required outputs beyond placeholders.
- Verification commands it must run.
- Instruction not to modify anything outside the target directory.
- Sufficient `--max-turns`, usually 60 or higher for scaffolding.

Example prompt shape:

```text
Set up PROJECT_NAME under ABSOLUTE_PATH. Build a useful starter scaffold, not placeholder docs. Create or update only these files: README.md, AGENTS.md, TODO.md, docs/PROJECT.md, docs/ARCHITECTURE.md, docs/ROADMAP.md, .gitignore. Each document must include concrete decisions, open questions, next steps, and acceptance criteria where relevant. Do not add secrets. Do not modify files outside ABSOLUTE_PATH. Run find . -maxdepth 3 -type f | sort and git status --short, then report what changed and what remains missing.
```

## Quality Bar

A Goose-created project is incomplete if it only has generic one-paragraph docs. Require at least:

- README with purpose, current status, setup notes, and next decisions.
- PROJECT doc with goals, non-goals, users, assumptions, and open questions.
- ARCHITECTURE doc with proposed components, data flow, and unresolved design choices.
- ROADMAP with phases and acceptance criteria.
- TODO with concrete next actions.
- AGENTS with operating rules for future agents.
- `.gitignore` appropriate to the expected stack.

## Verification

After Goose runs:

1. Inspect file tree and line counts.
2. Read key docs for placeholder language.
3. Run `git status --short --branch`.
4. If a GitHub repo is requested, verify `visibility`, default branch, pushed timestamp, and remote tracking with `gh repo view` and `git status --short --branch`.
5. Report gaps honestly. Use a verdict such as: `good for supervised bootstrap`, `needs product definition`, or `not sufficient yet`.

## Known Pitfalls

- Goose installer may place the binary successfully and then fail on interactive `/dev/tty` configuration.
- Goose may fail auth if the shell lacks `GOOGLE_API_KEY`; pass it explicitly for each run if credentials are not persisted.
- Low `--max-turns` can stop before verification.
- Goose may create generic docs unless the prompt explicitly forbids placeholders and defines a quality bar.