Goose Local Directive Transcript

Yes. The prompt you pasted is the actual current built-in Goose system prompt template. It lives in Goose source at:

crates/goose/src/prompts/system.md

Goose now has a proper prompt-template registry. The registered built-ins include:

system.md
compaction.md
compaction_summary.md
subagent_system.md
apps_create.md
apps_iterate.md
permission_judge.md
tiny_model_system.md
session_name.md

and Goose looks for user overrides in its config prompts/ directory before falling back to those built-ins. (GitHub)

That means you do not need to fork Goose just to make Goose behave like Bluefly. You can customize the prompt layer cleanly.

Also important: Goose now supports runtime system-prompt replacement/appending over ACP. The ACP schema explicitly supports setting or appending session system prompt text. (GitHub)

That is ideal for Gas City because it means:

Gas City role
→ launches Goose
→ appends Bluefly common runtime contract
→ appends role-specific instructions
→ executes Bead

rather than maintaining a private Goose fork.

Goose also has reusable Recipes that can carry instructions, extensions, parameters, and subrecipes, which gives you another upstream-native layer before writing any custom integration. (Block)

So I would give your setup agent this exact directive.

# BLUEFLY GOOSE INTEGRATION DIRECTIVE
## Configure Goose as the execution harness under Gas City

You are setting up Goose for the Bluefly Factory.

The goal is NOT to create another orchestration system.

The architecture is:

Gas City
= orchestration authority

Beads / Dolt
= durable work authority

Events
= observations

Orders
= repeated reactions

Formulas
= repeatable multi-step work

Packs
= reusable Factory configuration

Mail
= durable coordination

Sling
= work routing

Goose
= execution harness only

LiteLLM
= model gateway

LM Studio / local inference
= model runtime

GitLab
= source authority

Do not build around Gas City.
Do not replace Gas City primitives with Goose features.
Do not fork Goose unless an upstream extension point is proven insufficient.

---

# 1. USE UPSTREAM GOOSE CUSTOMIZATION FIRST

Before modifying Goose source, use these upstream surfaces:

1. user prompt templates
2. ACP system-prompt append/set
3. Goose Recipes
4. Goose Extensions / MCP
5. Goose configuration
6. Goose permissions
7. Goose provider configuration
8. Goose CLI/API

Only modify Goose source after proving none of these can satisfy the requirement.

CUSTOM_GOOSE_FORK=NO by default

---

# 2. LOCATE GOOSE CONFIG AND PROMPT OVERRIDES

Goose's built-in prompt templates are registered in:

crates/goose/src/prompt_template.rs

Built-in system prompt:

crates/goose/src/prompts/system.md

User overrides are loaded from Goose's config prompts directory.

Resolve the actual config directory on this installation.

Record:

GOOSE_VERSION=
GOOSE_BINARY=
GOOSE_CONFIG_DIR=
GOOSE_PROMPTS_DIR=
GOOSE_RECIPE_DIR=
GOOSE_EXTENSION_CONFIG=
GOOSE_PROVIDER_CONFIG=

Do not guess paths.

Use Goose's own config/path commands or inspect the installed source/binary behavior.

---

# 3. DO NOT REPLACE THE ENTIRE GOOSE SYSTEM PROMPT UNLESS NECESSARY

Prefer:

BASE GOOSE PROMPT
+
BLUEFLY COMMON PARTICIPATION CONTRACT
+
ROLE-SPECIFIC DELTA

This preserves upstream behavior.

Use ACP prompt append where supported.

Target:

Goose built-in system.md
→ Additional Instructions: Bluefly common runtime
→ Additional Instructions: DRUPAL / WITNESS / etc.

Avoid maintaining a complete copied `system.md` unless there is a concrete incompatibility.

---

# 4. CREATE ONE BLUEFLY COMMON GOOSE PROMPT

Create a reusable prompt fragment such as:

bluefly-factory-runtime.md

It should contain ONLY the universal participation contract:

ON START
- check Gas City Mail
- inspect routed Bead
- inspect dependencies
- claim eligible work

ON WORK
- execute only the claimed effect
- use existing source authority
- search upstream before custom code
- preserve evidence
- update Bead

ON DISCOVERY
- search existing Beads first
- do not create duplicate work
- route new bounded work through Gas City

ON HANDOFF
- resolve next owner
- update Bead
- use GC Mail / Sling
- record next expected event

ON WAIT
- use Gas City Event / Wait
- do not model-poll

ON COMPLETE
- update Bead
- source deliver if applicable
- request Witness where required
- send GC Mail
- sleep/exit

NEVER
- ask Thomas what normal work comes next
- create another scheduler
- create another work graph
- create another message bus
- bypass Gas City
- claim DONE without evidence

This common prompt should stay small.

Do not paste hundreds of lines of doctrine into every Goose session.

---

# 5. ROLE-SPECIFIC PROMPTS ARE DELTAS ONLY

Create small role prompt fragments:

blu.md
mayor.md
drupal.md
refinery.md
forge.md
sentinel.md
harbormaster.md
witness.md
deacon.md

Example:

DRUPAL:
- use Drupal core/contrib/recipes first
- no direct contrib edits
- no fake module state
- use canonical Bluefly recipes
- use SDC/Canvas/Views/entities
- no page-by-page HTML building
- visual proof required

WITNESS:
- read-only by default
- verify effect, not assertion
- classify PASS/PARTIAL/DEGRADED/FALSE/NOT_ESTABLISHED
- do not self-fix the implementation

HARBORMASTER:
- source delivery
- MR/CI/merge/release
- no architecture invention

Keep these concise.

Common behavior lives in the shared prompt.

---

# 6. USE ACP FOR ROLE INJECTION

Goose ACP supports setting/appending session system prompts.

Use that capability so Gas City can launch one Goose harness and inject:

COMMON_BLUEFLY_RUNTIME
+
ROLE_PROMPT
+
BEAD_CONTEXT

Target sequence:

Gas City launches Goose
→ Goose ACP session created
→ append common Bluefly runtime
→ append role delta
→ inject Bead context
→ execute
→ capture result/evidence
→ session exits

Do not create nine separately forked Goose distributions.

---

# 7. MODEL PROVIDER CONFIGURATION

Configure Goose to use LiteLLM as the default provider.

Do not hardcode specific physical model hosts in Agent prompts.

Expose stable model groups from LiteLLM:

bluefly-code
bluefly-fast
bluefly-reasoning
bluefly-review

Map those internally to:

Mac LM Studio
NAS inference
Oracle inference

Example topology:

Goose
→ LiteLLM
   → LM Studio on blu.tailcf98b3.ts.net
   → NAS model runtime
   → Oracle model runtime

The Agent should request a capability tier, not a machine-specific model ID.

---

# 8. FALLBACK MODEL POLICY

Default local/free path:

FAST
→ small local model

CODE
→ Qwen coder / Devstral / equivalent

REASONING
→ GPT-OSS / Qwen reasoning / Nemotron as available

Paid provider fallback:

DISABLED by default

or

explicitly budget-gated

No silent fallback to Claude/OpenAI paid endpoints.

A local-model outage must not automatically incur cloud spend.

---

# 9. INSTALL GOOSE ON EACH HOST

MAC:
- native Goose CLI/Desktop if useful
- LM Studio local provider available
- operator use
- optional bounded execution worker
- NOT Gas City authority

ORACLE:
- Goose CLI/headless
- primary Gas City execution worker host
- LiteLLM client
- repo worktrees
- bounded fresh sessions

NAS:
- Goose CLI/container only if execution is justified
- primarily inference/storage
- NOT source authority
- NOT Gas City authority

Do not turn every machine into another City.

---

# 10. GOOSE RECIPES

Use Goose Recipes only for harness-local execution patterns.

Good Goose Recipe examples:

- inspect repository
- run deterministic coding workflow
- perform bounded review
- gather diagnostics
- execute repeatable tool sequence

Do NOT move Gas City Formula responsibilities into Goose Recipes.

Rule:

GAS CITY FORMULA
= cross-Agent durable workflow

GOOSE RECIPE
= execution behavior inside one harness/session

If the workflow needs:
- durable Beads
- dependencies
- multiple owners
- Events
- Orders
- Witness

it belongs in Gas City, not Goose.

---

# 11. EXTENSIONS / MCP

Enable only extensions needed for the role.

Examples:

GitLab
filesystem
shell
QMD
code intelligence
Drupal tooling
browser where justified

Do not load 70 extensions into every session.

Role-based extension sets:

DRUPAL
- shell
- filesystem
- GitLab
- Drupal-specific tools
- QMD/code search

WITNESS
- shell read/test
- browser
- GitLab
- no mutation tools unless explicitly needed

HARBORMASTER
- GitLab
- shell/git
- no random browser/tool sprawl

Reduce context/tool noise.

---

# 12. QMD / CODE RETRIEVAL

Goose should not ingest entire repositories into context.

Before broad file reads:

QMD for documentation
chosen code intelligence tool for source

Retrieve surgically.

Target:

CONTEXT_OVER_150K=EXCEPTION

Long-running sessions are prohibited by default.

---

# 13. SESSION POLICY

Goose sessions should be disposable.

Default:

ONE_BEAD_PER_SESSION=YES
FRESH_SESSION=YES
SESSION_SLEEP_ON_WAIT=YES
SESSION_EXIT_AFTER_HANDOFF=YES

Do not preserve hours of context as Factory memory.

Beads, Mail, Events, and evidence are the memory.

---

# 14. PERMISSION MODEL

Configure Goose permissions per role.

Examples:

WITNESS
- filesystem read
- test execution
- git diff/status
- no commit
- no push
- no destructive shell

DRUPAL
- project edit
- test/run Drupal
- no direct push unless role explicitly owns delivery

HARBORMASTER
- git commit/push/MR delivery
- source operations

SENTINEL
- read/security inspection
- tightly scoped mutation

Do not rely solely on prompt instructions for permissions.

Use Goose's native permission controls where possible.

---

# 15. INSTALL A BLUEFLY GOOSE PROFILE

Create one governed configuration source in Git.

Suggested source authority:

AgenticTools or BluCity-Packs
depending on whether this is reusable harness config or Factory-specific composition.

Do not maintain:
~/.config/goose
manually on every host.

Target:

canonical Goose config
→ deployment/projection
→ Mac
→ Oracle
→ optional NAS

Host-specific values should be overlays:

endpoint
workspace root
available extensions
local inference endpoint

Common policy remains shared.

---

# 16. NO PERSONAL SECRETS

Provider/API credentials:

1Password reference
or
service identity

Never:

personal token in prompt
personal token in goose config committed to Git
personal token inside container

LiteLLM should shield most provider credentials from Goose.

Goose receives only the gateway credential it actually needs.

---

# 17. GOOSE + GAS CITY CONTRACT

Create a minimal provider/session adapter only if Gas City does not already support Goose/ACP directly.

Search first.

Desired interface:

START:
gc routes Bead
→ Goose session starts

INPUT:
Bead ID
role
workspace
prompt fragments

OUTPUT:
RESULT=
EVIDENCE=
FILES_CHANGED=
TESTS=
BLOCKERS=
NEXT_ACTION=

Then:

update Bead
emit Event
send Mail
exit

Do not build a custom Goose orchestrator.

---

# 18. PROVE WITH THREE REAL BEADS

Do not declare Goose integrated after "hello world."

Run:

TEST 1
DRUPAL bounded change

TEST 2
REFINERY slop/convergence review

TEST 3
WITNESS independent verification

For each:

GAS_CITY_ROUTED=YES
BEAD_CLAIMED=YES
COMMON_PROMPT_INJECTED=YES
ROLE_PROMPT_INJECTED=YES
LOCAL_MODEL_USED=YES
PAID_MODEL_USED=NO
FILES_CHANGED=
TESTS=
EVIDENCE=
GC_MAIL_HANDOFF=YES
SESSION_EXITED=YES
THOMAS_RELAY=0

---

# 19. COMPARE AGAINST CLAUDE

Record:

HARNESS=Goose
MODEL=
BEAD=
WALL_TIME=
INPUT_TOKENS=
OUTPUT_TOKENS=
CONTEXT_PEAK=
TOOL_FAILURES=
UNRELATED_CHANGES=
QUALITY_GATE=
WITNESS=
COST=

The goal is not "Goose works."

The goal is:

Goose can replace paid persistent Claude workers for ordinary Factory execution.

---

# 20. DO NOT FORK GOOSE YET

A Goose source fork is allowed only if a proven requirement cannot be achieved through:

prompt override
ACP prompt injection
Recipes
Extensions/MCP
permissions
provider config
CLI/API

If source modification is still required:

UPSTREAM_GAP=
ISSUE=
WHY_EXTENSION_POINT_FAILS=
MINIMUM_PATCH=
UPSTREAM_CONTRIBUTION_PATH=

Prefer upstream contribution over permanent private fork.

---

# REQUIRED END STATE

GOOSE_MAC_INSTALLED=
GOOSE_ORACLE_INSTALLED=
GOOSE_NAS_DECISION=

COMMON_BLUEFLY_PROMPT_ACTIVE=
ROLE_PROMPTS_ACTIVE=
ACP_PROMPT_INJECTION_ACTIVE=

LITELLM_DEFAULT_PROVIDER=
LOCAL_MODEL_DEFAULT=YES
PAID_FALLBACK_DEFAULT=NO

GAS_CITY_ROUTING_PROVEN=
ONE_BEAD_PER_SESSION=
FRESH_SESSION_DEFAULT=
SESSION_EXIT_PROVEN=

DRUPAL_GOOSE_PROOF=
REFINERY_GOOSE_PROOF=
WITNESS_GOOSE_PROOF=

CUSTOM_GOOSE_FORK=NO

THOMAS_MESSAGE_RELAY=0
THOMAS_QUEUE_MANAGEMENT=0

The most important part is do not edit the built-in prompt file in Goose source first.

Goose deliberately supports user prompt overrides, and its prompt loader checks the user's prompts directory before using the built-in template. (GitHub) That means you can keep Goose upgradeable.

I would structure your prompt stack as:

Goose built-in system.md
        +
bluefly-factory-runtime.md
        +
role/drupal.md
        +
current Bead context

And I would use ACP prompt append for the last three whenever Gas City starts the session. Goose's ACP schema explicitly supports appending additional system instructions to an active session, keyed so the same logical instruction can be replaced later rather than endlessly duplicated. (GitHub)

That gives you what you wanted all along: one upstream Goose, many Bluefly Agents, Gas City controls the lifecycle, and the Agent identity comes from projected context rather than maintaining another pile of custom harnesses.