Blueprint Equity Developer Guide

Set up agentic SDLC projects with Goose.

This guide turns the Living Knowledge experiment into a repeatable workflow: install Goose, configure it safely, give it bounded project instructions, verify the output, and only then publish a repo.

Source skill: goose-project-bootstrap Status: exported from pending proposal Last updated: July 8, 2026

Overview

Goose is useful when you treat it like a capable but supervised CLI agent. It can run shell commands, write files, and inspect project state. It is not, by default, a complete product manager, architect, or release engineer.

What Goose should do

Create a bounded scaffold, write useful docs, verify its work, and report gaps plainly.

What you must provide

Target path, scope, quality bar, allowed files, provider auth, and verification requirements.

What to distrust

Generic one-paragraph docs, skipped verification, missing auth state, and vague “done” reports.

Install Goose

First check whether Goose already exists. If it does not, install the stable CLI release.

command -v goose && goose --version
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash
Known installer behavior: the binary may install successfully and then fail during interactive configuration with a /dev/tty error. If that happens, keep going with manual config.

Configure Provider Auth

Keep secrets out of project files. Prefer passing credentials through the environment or using Goose’s own credential flow when an interactive approval route is available. 

mkdir -p ~/.config/goose
cat > ~/.config/goose/config.yaml <<'YAML'
GOOSE_PROVIDER: google
GOOSE_MODEL: gemini-2.5-flash
extensions:
  developer:
    enabled: true
    name: developer
    type: builtin
YAML

When loading an existing key from a local .env, extract only the variable you need.

GEMINI_FROM_ENV=$(awk -F= '$1=="GEMINI_API_KEY" {print substr($0, index($0,"=")+1); exit}' /path/to/.env)
GOOGLE_API_KEY="$GEMINI_FROM_ENV" GOOSE_PROVIDER=google GOOSE_MODEL=gemini-2.5-flash goose info --check
Do not source arbitrary .env files. A single unquoted & or shell metacharacter can break the run or execute something unexpected.

Recommended Workflow

1PreflightCheck Goose, auth, target path, and repo state.
2Bound ScopeName allowed files and forbid outside edits.
3BootstrapRun Goose with enough turns and clear outputs.
4InspectRead docs, check line counts, and reject placeholders.
5PublishCommit, push, and verify privacy/default branch.
GOOGLE_API_KEY="$GEMINI_FROM_ENV" \
GOOSE_PROVIDER=google \
GOOSE_MODEL=gemini-2.5-flash \
goose run --no-session --with-builtin developer --max-turns 80 \
  --text "$(cat prompt.txt)"

Bootstrap Prompt Template

The prompt is the difference between a real starter repo and placeholder docs. Be annoyingly specific.

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.

Project context:
- Intended users:
- Main problem:
- Non-goals:
- Expected stack, if known:

Rules:
- Do not add secrets.
- Do not modify files outside ABSOLUTE_PATH.
- Initialize git only if no repo exists.
- Do not claim completion until verification passes.

Verification:
- Run find . -maxdepth 3 -type f | sort
- Run git status --short --branch
- Report what changed and what remains missing.

Quality Bar

Required files

  • README.md: purpose, status, setup notes, next decisions.
  • docs/PROJECT.md: goals, non-goals, users, assumptions, open questions.
  • docs/ARCHITECTURE.md: components, data flow, unresolved design choices.
  • docs/ROADMAP.md: phases, milestones, acceptance criteria.
  • TODO.md: concrete next actions.
  • AGENTS.md: operating rules for future agents.

Rejection signs

  • Every file is only one paragraph.
  • Docs say “more details soon” instead of making decisions.
  • No open questions are captured.
  • No verification commands were run.
  • GitHub privacy or remote tracking was not checked.
  • Goose reports success after hitting an action cap.

Publish to GitHub

Only publish after local verification. For a private repo, commit first, then create and push with GitHub CLI.

git status --short --branch
git add .
git commit -m "Initial PROJECT_NAME scaffold"
gh repo create PROJECT_NAME --private --source=. --remote=origin --push
gh repo view OWNER/PROJECT_NAME --json name,visibility,url,defaultBranchRef,pushedAt,isEmpty
git status --short --branch

Expected verdict: visibility is PRIVATE, default branch is main, the repo is not empty, and local main tracks origin/main.

Troubleshooting

Installer fails on /dev/tty

The binary may still exist at ~/.local/bin/goose. Check with ~/.local/bin/goose --version, then write config manually.

Provider check says unregistered caller

The API key did not reach Goose. Pass GOOGLE_API_KEY explicitly in the same command invocation.

Goose stops early

Increase --max-turns and continue with a narrower prompt focused on the unfinished verification or cleanup step.

Goose wrote placeholders

Run a second pass that explicitly forbids placeholder language and requires concrete decisions, open questions, and acceptance criteria.

Skill Export

This guide was exported from the goose-project-bootstrap Skill Workshop proposal. The raw proposal export is available at goose-project-bootstrap.md.

Name: goose-project-bootstrap
Description: Bootstrap projects with Goose without placeholder docs.
Proposal ID: goose-project-bootstrap-20260708-0d34df5471
Status at export: pending

Verdict from first run:
Goose is good enough for supervised bootstrapping, but not yet fire-and-forget.
It needs explicit auth, bounded scope, a strong prompt, and independent verification.