Goose — Prompts
Prompt 1: .goosehints (Project Context Injection)
Source: .goosehints at repo root
Technique: Project knowledge document injected as context — the equivalent of CLAUDE.md but named .goosehints. Goose-specific naming convention signals which agent it's targeted for.
This is a rust project with crates in the crates dir:
goose: the main code for goose, contains all the core logic
goose-bench: bench marking
goose-cli: the command line interface, use goose crate
goose-mcp: the mcp servers that ship with goose. the developer sub system is of special interest
goose-server: the server that supports the desktop (electron) app. also known as goosed
ui/desktop has an electron app in typescript.
non trivial features should be implemented in the goose crate and then be called from the goose-cli crate for the cli.
for the desktop, you want to add routes to goose-server/src/routes.
you can then run `just generate-openapi` to generate the openapi spec which will modify the ui/desktop/src/api files.
once you have that you can call the functionality from the server from the typescript.
tips:
- can look at unstaged changes for what is being worked on if starting
- always check rust compiles, cargo fmt etc and `cargo clippy --all-targets -- -D warnings` (as well as run tests in files you are working on)
- in ui/desktop, look at how you can run lint checks and if other tests can run
Note: The .goosehints file is explicitly architectural — it explains the crate structure and which crate to implement features in, preventing the common error of implementing in the wrong layer.
Prompt 2: Agent Loop (from agent.rs)
Source: crates/goose/src/agents/agent.rs
Technique: Structured tool categorization and response handling. The agent loop categorizes tools into Shell/Read/Write/Other and handles them differently.
From source:
fn categorize_tool(tool_name: &str) -> ToolCategory {
let local = tool_name.rsplit("__").next().unwrap_or(tool_name);
match local {
"shell" | "bash" | "exec" | "run" => ToolCategory::Shell,
"read" | "view" | "cat" | "read_file" => ToolCategory::Read,
"write" | "edit" | "patch" | "write_file" | "edit_file" => ToolCategory::Write,
_ => ToolCategory::Other,
}
}
Technique: Tool-category-based routing for approval and logging.
Prompt 3: COMPACTION_THINKING_TEXT
Source: crates/goose/src/agents/agent.rs
const COMPACTION_THINKING_TEXT: &str = "goose is compacting the conversation...";
Technique: User-visible transparency about internal state transitions. When context compaction runs, the user sees this message — preventing confusion about delays.
Source: goose-self-test.yaml (repo root)
Technique: Declarative agent configuration as a shareable YAML recipe.
name: goose-self-test
description: A self-test recipe for Goose
instructions: |
Run a series of self-tests to verify Goose is working correctly.
...
extensions:
- developer
model: claude-3-5-sonnet-20241022
Recipes are the "reusable agent configuration" primitive in Goose — equivalent to sharing a system prompt + extension list as a portable unit.
Prompting Techniques Used
- Project knowledge injection —
.goosehints for codebase-specific instructions
- Tool categorization — tools classified as Shell/Read/Write/Other for different handling
- State transparency — compaction events visible to users
- Recipe-based configuration — shareable YAML agent definitions
- Security-first inspection — adversarial content detection runs on all tool responses
- Max turns enforcement — 1000-turn limit with explicit termination