mirror of
https://github.com/block/goose.git
synced 2026-04-29 12:09:38 +00:00
docs: lowercase goose in remaining topics (#5861)
Some checks are pending
Canary / bundle-desktop (push) Blocked by required conditions
Canary / bundle-desktop-linux (push) Blocked by required conditions
Canary / bundle-desktop-windows (push) Blocked by required conditions
Canary / Prepare Version (push) Waiting to run
Canary / build-cli (push) Blocked by required conditions
Canary / Upload Install Script (push) Blocked by required conditions
Canary / Release (push) Blocked by required conditions
CI / changes (push) Waiting to run
CI / Check Rust Code Format (push) Blocked by required conditions
CI / Build and Test Rust Project (push) Blocked by required conditions
CI / Lint Rust Code (push) Blocked by required conditions
CI / Check OpenAPI Schema is Up-to-Date (push) Blocked by required conditions
CI / Test and Lint Electron Desktop App (push) Blocked by required conditions
Deploy Documentation / deploy (push) Waiting to run
Live Provider Tests / check-fork (push) Waiting to run
Live Provider Tests / changes (push) Blocked by required conditions
Live Provider Tests / Build Release Binary (push) Blocked by required conditions
Live Provider Tests / Smoke Tests (push) Blocked by required conditions
Documentation Site Preview / deploy (push) Waiting to run
Publish Docker Image / docker (push) Waiting to run
Some checks are pending
Canary / bundle-desktop (push) Blocked by required conditions
Canary / bundle-desktop-linux (push) Blocked by required conditions
Canary / bundle-desktop-windows (push) Blocked by required conditions
Canary / Prepare Version (push) Waiting to run
Canary / build-cli (push) Blocked by required conditions
Canary / Upload Install Script (push) Blocked by required conditions
Canary / Release (push) Blocked by required conditions
CI / changes (push) Waiting to run
CI / Check Rust Code Format (push) Blocked by required conditions
CI / Build and Test Rust Project (push) Blocked by required conditions
CI / Lint Rust Code (push) Blocked by required conditions
CI / Check OpenAPI Schema is Up-to-Date (push) Blocked by required conditions
CI / Test and Lint Electron Desktop App (push) Blocked by required conditions
Deploy Documentation / deploy (push) Waiting to run
Live Provider Tests / check-fork (push) Waiting to run
Live Provider Tests / changes (push) Blocked by required conditions
Live Provider Tests / Build Release Binary (push) Blocked by required conditions
Live Provider Tests / Smoke Tests (push) Blocked by required conditions
Documentation Site Preview / deploy (push) Waiting to run
Publish Docker Image / docker (push) Waiting to run
This commit is contained in:
dianed-square
GitHub
parent
b357e99b30
commit
e7eb18b67a
37 changed files with 306 additions and 306 deletions
|
|
@ -3,6 +3,6 @@
|
|||
"position": 4,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"description": "How to use Goose in various ways"
|
||||
"description": "How to use goose in various ways"
|
||||
}
|
||||
}
|
||||
|
|
@ -1,18 +1,18 @@
|
|||
---
|
||||
title: Advanced Cognee Usage with Goose
|
||||
description: Advanced patterns for using Cognee knowledge graph with Goose for enhanced memory and automation
|
||||
title: Advanced Cognee Usage with goose
|
||||
description: Advanced patterns for using Cognee knowledge graph with goose for enhanced memory and automation
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
# Advanced Cognee Usage with Goose
|
||||
# Advanced Cognee Usage with goose
|
||||
|
||||
This tutorial covers advanced usage patterns for the Cognee extension with Goose, including automated memory management, knowledge graph optimization, and various integration strategies.
|
||||
This tutorial covers advanced usage patterns for the Cognee extension with goose, including automated memory management, knowledge graph optimization, and various integration strategies.
|
||||
|
||||
## Overview
|
||||
|
||||
While the basic [Cognee MCP setup](../mcp/cognee-mcp.md) gets you started, this tutorial explores how to make Goose autonomously use the knowledge graph and optimize your workflow.
|
||||
While the basic [Cognee MCP setup](../mcp/cognee-mcp.md) gets you started, this tutorial explores how to make goose autonomously use the knowledge graph and optimize your workflow.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ You are an LLM agent with access to a Cognee knowledge graph for memory.
|
|||
- Only process files returned by `rg --files`
|
||||
````
|
||||
|
||||
Start Goose with instructions:
|
||||
Start goose with instructions:
|
||||
```bash
|
||||
goose run -i ~/.config/goose/cognee-instructions.md -s
|
||||
```
|
||||
|
|
@ -96,7 +96,7 @@ goose run -i ~/.config/goose/cognee-instructions.md -s
|
|||
</TabItem>
|
||||
<TabItem value="method2" label="Method 2">
|
||||
|
||||
### Goosehints File
|
||||
### goosehints File
|
||||
|
||||
For faster startup with higher token usage, add to your `.goosehints` file:
|
||||
|
||||
|
|
@ -139,14 +139,14 @@ Combine with the [Memory MCP extension](../mcp/memory-mcp.md) for hybrid approac
|
|||
For software development projects:
|
||||
|
||||
```bash
|
||||
# Start Goose with Cognee
|
||||
# Start goose with Cognee
|
||||
goose session
|
||||
|
||||
# In Goose, analyze your codebase
|
||||
> Goose, please codify this repository and then help me understand the architecture
|
||||
# In goose, analyze your codebase
|
||||
> goose, please codify this repository and then help me understand the architecture
|
||||
```
|
||||
|
||||
Goose will:
|
||||
goose will:
|
||||
1. Run `cognee-mcp__codify` on your repository
|
||||
2. Build a code knowledge graph
|
||||
3. Answer architecture questions using the graph
|
||||
|
|
@ -157,7 +157,7 @@ For research and documentation:
|
|||
|
||||
```bash
|
||||
# Cognify research documents
|
||||
> Goose, please cognify the contents of these research papers: paper1.pdf, paper2.pdf, paper3.pdf
|
||||
> goose, please cognify the contents of these research papers: paper1.pdf, paper2.pdf, paper3.pdf
|
||||
|
||||
# Later, query relationships
|
||||
> What are the connections between the methodologies in these papers?
|
||||
|
|
@ -215,10 +215,10 @@ Monitor and manage your knowledge graph:
|
|||
|
||||
```bash
|
||||
# Check status
|
||||
> Goose, what's the status of the cognify pipeline?
|
||||
> goose, what's the status of the cognify pipeline?
|
||||
|
||||
# Selective pruning (if needed)
|
||||
> Goose, can you help me identify outdated information in the knowledge graph?
|
||||
> goose, can you help me identify outdated information in the knowledge graph?
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
|
@ -240,8 +240,8 @@ tail -f ~/.local/share/cognee/logs/cognee.log
|
|||
curl http://localhost:8000/health
|
||||
|
||||
# Verify knowledge graph status
|
||||
# In Goose session:
|
||||
> Goose, run cognify_status and codify_status
|
||||
# In goose session:
|
||||
> goose, run cognify_status and codify_status
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
|
@ -251,10 +251,10 @@ curl http://localhost:8000/health
|
|||
1. **Use nodesets** for organizing different types of information:
|
||||
```bash
|
||||
# Developer rules
|
||||
> Goose, add these coding standards to the 'developer_rules' nodeset
|
||||
> goose, add these coding standards to the 'developer_rules' nodeset
|
||||
|
||||
# Project-specific info
|
||||
> Goose, cognify this project documentation with nodeset 'project_alpha'
|
||||
> goose, cognify this project documentation with nodeset 'project_alpha'
|
||||
```
|
||||
|
||||
2. **Regular maintenance**:
|
||||
|
|
@ -274,7 +274,7 @@ curl http://localhost:8000/health
|
|||
|
||||
```bash
|
||||
# Setup
|
||||
> Goose, codify this repository and remember that I prefer: functional programming patterns, comprehensive tests, and clear documentation
|
||||
> goose, codify this repository and remember that I prefer: functional programming patterns, comprehensive tests, and clear documentation
|
||||
|
||||
# Usage
|
||||
> Review this pull request and check it against my coding preferences
|
||||
|
|
@ -284,7 +284,7 @@ curl http://localhost:8000/health
|
|||
|
||||
```bash
|
||||
# Before meeting
|
||||
> Goose, cognify the agenda and participant backgrounds from these documents
|
||||
> goose, cognify the agenda and participant backgrounds from these documents
|
||||
|
||||
# During/after meeting
|
||||
> Based on the knowledge graph, what are the key action items and how do they relate to our previous discussions?
|
||||
|
|
@ -294,10 +294,10 @@ curl http://localhost:8000/health
|
|||
|
||||
```bash
|
||||
# Literature review
|
||||
> Goose, cognify these 10 research papers and create a knowledge graph of the relationships between their methodologies
|
||||
> goose, cognify these 10 research papers and create a knowledge graph of the relationships between their methodologies
|
||||
|
||||
# Synthesis
|
||||
> What are the emerging patterns in the research and what gaps exist?
|
||||
```
|
||||
|
||||
This advanced usage guide should help you maximize the potential of Cognee with Goose for sophisticated knowledge management and automation workflows.
|
||||
This advanced usage guide should help you maximize the potential of Cognee with goose for sophisticated knowledge management and automation workflows.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: Benchmarking with Goose
|
||||
sidebar_label: Benchmark with Goose
|
||||
title: Benchmarking with goose
|
||||
sidebar_label: Benchmark with goose
|
||||
---
|
||||
|
||||
The Goose benchmarking system allows you to evaluate goose performance on complex tasks with one or more system
|
||||
The goose benchmarking system allows you to evaluate goose performance on complex tasks with one or more system
|
||||
configurations.<br></br>
|
||||
This guide covers how to use the `goose bench` command to run benchmarks and analyze results.
|
||||
|
||||
|
|
@ -193,7 +193,7 @@ RUST_LOG=debug goose bench bench-config.json
|
|||
|
||||
### Tool Shimming
|
||||
|
||||
Tool shimming allows you to use a non-tool-capable models with Goose, provided Ollama is installed on the
|
||||
Tool shimming allows you to use a non-tool-capable models with goose, provided Ollama is installed on the
|
||||
system.
|
||||
|
||||
See this guide for important details on [tool shimming](/docs/experimental/ollama).
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: CI/CD Environments
|
||||
description: Set up Goose in your CI/CD pipeline to automate tasks
|
||||
description: Set up goose in your CI/CD pipeline to automate tasks
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Goose isn’t just useful on your local machine, it can also streamline tasks in CI/CD environments. By integrating Goose into your pipeline, you can automate tasks such as:
|
||||
goose isn’t just useful on your local machine, it can also streamline tasks in CI/CD environments. By integrating goose into your pipeline, you can automate tasks such as:
|
||||
|
||||
- Code reviews
|
||||
- Documentation checks
|
||||
|
|
@ -15,11 +15,11 @@ Goose isn’t just useful on your local machine, it can also streamline tasks in
|
|||
- Rollbacks and recovery processes
|
||||
- Intelligent test execution
|
||||
|
||||
This guide walks you through setting up Goose in your CI/CD pipeline, with a focus on using GitHub Actions for code reviews.
|
||||
This guide walks you through setting up goose in your CI/CD pipeline, with a focus on using GitHub Actions for code reviews.
|
||||
|
||||
|
||||
## Using Goose with GitHub Actions
|
||||
You can run Goose directly within GitHub Actions. Follow these steps to set up your workflow.
|
||||
## Using goose with GitHub Actions
|
||||
You can run goose directly within GitHub Actions. Follow these steps to set up your workflow.
|
||||
|
||||
:::info TLDR
|
||||
<details>
|
||||
|
|
@ -28,7 +28,7 @@ You can run Goose directly within GitHub Actions. Follow these steps to set up y
|
|||
```yaml title="goose.yml"
|
||||
|
||||
|
||||
name: Goose
|
||||
name: goose
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
|
|
@ -46,7 +46,7 @@ env:
|
|||
|
||||
jobs:
|
||||
goose-comment:
|
||||
name: Goose Comment
|
||||
name: goose Comment
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check out repository
|
||||
|
|
@ -65,14 +65,14 @@ jobs:
|
|||
gh pr diff $PR_NUMBER
|
||||
} > changes.txt
|
||||
|
||||
- name: Install Goose CLI
|
||||
- name: Install goose CLI
|
||||
run: |
|
||||
mkdir -p /home/runner/.local/bin
|
||||
curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh \
|
||||
| CONFIGURE=false GOOSE_BIN_DIR=/home/runner/.local/bin bash
|
||||
echo "/home/runner/.local/bin" >> $GITHUB_PATH
|
||||
|
||||
- name: Configure Goose
|
||||
- name: Configure goose
|
||||
run: |
|
||||
mkdir -p ~/.config/goose
|
||||
cat <<EOF > ~/.config/goose/config.yaml
|
||||
|
|
@ -81,7 +81,7 @@ jobs:
|
|||
keyring: false
|
||||
EOF
|
||||
|
||||
- name: Create instructions for Goose
|
||||
- name: Create instructions for goose
|
||||
run: |
|
||||
cat <<EOF > instructions.txt
|
||||
Create a summary of the changes provided. Don't provide any session or logging details.
|
||||
|
|
@ -96,7 +96,7 @@ jobs:
|
|||
- name: Test
|
||||
run: cat instructions.txt
|
||||
|
||||
- name: Run Goose and filter output
|
||||
- name: Run goose and filter output
|
||||
run: |
|
||||
goose run --instructions instructions.txt | \
|
||||
# Remove ANSI color codes
|
||||
|
|
@ -128,11 +128,11 @@ Create a new file in your repository at `.github/workflows/goose.yml`. This will
|
|||
Configure the action such that it:
|
||||
|
||||
- Triggers the workflow when a pull request is opened, updated, reopened, or labeled
|
||||
- Grants the necessary permissions for Goose to interact with the repository
|
||||
- Grants the necessary permissions for goose to interact with the repository
|
||||
- Configures environment variables for your chosen LLM provider
|
||||
|
||||
```yaml
|
||||
name: Goose
|
||||
name: goose
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
|
|
@ -149,20 +149,20 @@ env:
|
|||
```
|
||||
|
||||
|
||||
### 3. Install and Configure Goose
|
||||
### 3. Install and Configure goose
|
||||
|
||||
To install and set up Goose in your workflow, add the following steps:
|
||||
To install and set up goose in your workflow, add the following steps:
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- name: Install Goose CLI
|
||||
- name: Install goose CLI
|
||||
run: |
|
||||
mkdir -p /home/runner/.local/bin
|
||||
curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh \
|
||||
| CONFIGURE=false GOOSE_BIN_DIR=/home/runner/.local/bin bash
|
||||
echo "/home/runner/.local/bin" >> $GITHUB_PATH
|
||||
|
||||
- name: Configure Goose
|
||||
- name: Configure goose
|
||||
run: |
|
||||
mkdir -p ~/.config/goose
|
||||
cat <<EOF > ~/.config/goose/config.yaml
|
||||
|
|
@ -178,10 +178,10 @@ Replace `REPLACE_WITH_PROVIDER` and `REPLACE_WITH_MODEL` with your LLM provider
|
|||
|
||||
### 4. Gather PR Changes and Prepare Instructions
|
||||
|
||||
This step extracts pull request details and formats them into structured instructions for Goose.
|
||||
This step extracts pull request details and formats them into structured instructions for goose.
|
||||
|
||||
```yaml
|
||||
- name: Create instructions for Goose
|
||||
- name: Create instructions for goose
|
||||
run: |
|
||||
cat <<EOF > instructions.txt
|
||||
Create a summary of the changes provided. Don't provide any session or logging details.
|
||||
|
|
@ -194,12 +194,12 @@ This step extracts pull request details and formats them into structured instruc
|
|||
EOF
|
||||
```
|
||||
|
||||
### 5. Run Goose and Clean Output
|
||||
### 5. Run goose and Clean Output
|
||||
|
||||
Now, run Goose with the formatted instructions and clean the output by removing ANSI color codes and unnecessary log messages.
|
||||
Now, run goose with the formatted instructions and clean the output by removing ANSI color codes and unnecessary log messages.
|
||||
|
||||
```yaml
|
||||
- name: Run Goose and filter output
|
||||
- name: Run goose and filter output
|
||||
run: |
|
||||
goose run --instructions instructions.txt | \
|
||||
# Remove ANSI color codes
|
||||
|
|
@ -215,7 +215,7 @@ Now, run Goose with the formatted instructions and clean the output by removing
|
|||
|
||||
### 6. Post Comment to PR
|
||||
|
||||
Finally, post the Goose output as a comment on the pull request:
|
||||
Finally, post the goose output as a comment on the pull request:
|
||||
|
||||
```yaml
|
||||
- name: Post comment to PR
|
||||
|
|
@ -224,7 +224,7 @@ Finally, post the Goose output as a comment on the pull request:
|
|||
gh pr comment $PR_NUMBER --body-file pr_comment.txt
|
||||
```
|
||||
|
||||
With this workflow, Goose will run on pull requests, analyze the changes, and post a summary as a comment on the PR.
|
||||
With this workflow, goose will run on pull requests, analyze the changes, and post a summary as a comment on the PR.
|
||||
|
||||
This is just one example of what's possible. Feel free to modify your GitHub Action to meet your needs.
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ This is just one example of what's possible. Feel free to modify your GitHub Act
|
|||
|
||||
## Security Considerations
|
||||
|
||||
When running Goose in a CI/CD enviroment, keep these security practices in mind:
|
||||
When running goose in a CI/CD enviroment, keep these security practices in mind:
|
||||
|
||||
1. **Secret Management**
|
||||
- Store your sensitive credentials (like API keys) as GitHub Secrets.
|
||||
|
|
@ -242,4 +242,4 @@ When running Goose in a CI/CD enviroment, keep these security practices in mind:
|
|||
- Grant only the necessary permissions in your workflow and regularly audit them.
|
||||
|
||||
3. **Input Validation**
|
||||
- Ensure any inputs passed to Goose are sanitized and validated to prevent unexpected behavior.
|
||||
- Ensure any inputs passed to goose are sanitized and validated to prevent unexpected behavior.
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
title: Building Goose in Docker
|
||||
sidebar_label: Goose in Docker
|
||||
title: Building goose in Docker
|
||||
sidebar_label: goose in Docker
|
||||
---
|
||||
|
||||
:::info Tell Us What You Need
|
||||
There are various scenarios where you might want to build Goose in Docker. If the instructions below do not meet your needs, please contact us by replying to our [discussion topic](https://github.com/block/goose/discussions/1496).
|
||||
There are various scenarios where you might want to build goose in Docker. If the instructions below do not meet your needs, please contact us by replying to our [discussion topic](https://github.com/block/goose/discussions/1496).
|
||||
:::
|
||||
|
||||
|
||||
You can build Goose from the source file within a Docker container. This approach not only provides security benefits by creating an isolated environment but also enhances consistency and portability. For example, if you need to troubleshoot an error on a platform you don't usually work with (such as Ubuntu), you can easily debug it using Docker.
|
||||
You can build goose from the source file within a Docker container. This approach not only provides security benefits by creating an isolated environment but also enhances consistency and portability. For example, if you need to troubleshoot an error on a platform you don't usually work with (such as Ubuntu), you can easily debug it using Docker.
|
||||
|
||||
To begin, you will need to modify the `Dockerfile` and `docker-compose.yml` files to suit your requirements. Some changes you might consider include:
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ To begin, you will need to modify the `Dockerfile` and `docker-compose.yml` file
|
|||
|
||||
- **Optional:** Changing the base image to a different Linux distribution in the `Dockerfile`. This example uses Ubuntu, but you can switch to another distribution such as CentOS, Fedora, or Alpine.
|
||||
|
||||
- **Optional:** Mounting your personal Goose settings and hints files in the `docker-compose.yml` file. This allows you to use your personal settings and hints files within the Docker container.
|
||||
- **Optional:** Mounting your personal goose settings and hints files in the `docker-compose.yml` file. This allows you to use your personal settings and hints files within the Docker container.
|
||||
|
||||
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ Next, run the container and connect to it using the following command:
|
|||
docker-compose -f documentation/docs/docker/docker-compose.yml run --rm goose-cli
|
||||
```
|
||||
|
||||
Inside the container, run the following command to configure Goose:
|
||||
Inside the container, run the following command to configure goose:
|
||||
|
||||
```bash
|
||||
goose configure
|
||||
|
|
@ -40,7 +40,7 @@ goose configure
|
|||
|
||||
When prompted to save the API key to the keyring, select `No`, as you are already passing the API key as an environment variable.
|
||||
|
||||
Configure Goose a second time, and this time, you can [add any extensions](/docs/getting-started/using-extensions) you need.
|
||||
Configure goose a second time, and this time, you can [add any extensions](/docs/getting-started/using-extensions) you need.
|
||||
|
||||
After that, you can start a session:
|
||||
|
||||
|
|
@ -48,4 +48,4 @@ After that, you can start a session:
|
|||
goose session
|
||||
```
|
||||
|
||||
You should now be able to connect to Goose with your configured extensions enabled.
|
||||
You should now be able to connect to goose with your configured extensions enabled.
|
||||
|
|
@ -1,17 +1,17 @@
|
|||
---
|
||||
title: Using Goose in Headless Mode for Automation
|
||||
description: Goose Headless Mode
|
||||
title: Using goose in Headless Mode for Automation
|
||||
description: goose Headless Mode
|
||||
---
|
||||
|
||||
# Automate Development Tasks with Goose Headless Mode
|
||||
# Automate Development Tasks with goose Headless Mode
|
||||
|
||||
*Run AI-powered engineering workflows in CI/CD pipelines, servers, and batch processing scenarios*
|
||||
|
||||
The ability to automate complex engineering tasks without human intervention has been huge, but let's take it to the next level with AI. Goose's "headless" mode enables developers to harness the full power of AI automation in server environments, CI/CD pipelines, and batch processing scenarios where interactive sessions simply aren't feasible.
|
||||
The ability to automate complex engineering tasks without human intervention has been huge, but let's take it to the next level with AI. goose's "headless" mode enables developers to harness the full power of AI automation in server environments, CI/CD pipelines, and batch processing scenarios where interactive sessions simply aren't feasible.
|
||||
|
||||
## What is Headless Mode?
|
||||
|
||||
Headless mode is Goose's non-interactive execution environment, designed for automated scenarios where human intervention isn't available (or wanted).
|
||||
Headless mode is goose's non-interactive execution environment, designed for automated scenarios where human intervention isn't available (or wanted).
|
||||
|
||||
Unlike the interactive desktop app or CLI sessions, headless mode processes instructions and exits automatically, making it perfect for integration into existing development workflows.
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ Always check exit codes and handle failures gracefully in your automation script
|
|||
```bash
|
||||
#!/bin/bash
|
||||
if ! goose run --no-session -t "Run security audit and fix critical issues"; then
|
||||
echo "Goose automation failed - manual intervention required"
|
||||
echo "goose automation failed - manual intervention required"
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
|
@ -142,7 +142,7 @@ Use `--no-session` for one-off tasks to avoid cluttering your session history, b
|
|||
|
||||
## Recipe Execution in Headless Mode
|
||||
|
||||
[Recipes](/docs/guides/recipes/) are Goose's powerful way to define reusable, parameterized workflows. In headless mode, recipes become even more valuable as they enable sophisticated automation scenarios.
|
||||
[Recipes](/docs/guides/recipes/) are goose's powerful way to define reusable, parameterized workflows. In headless mode, recipes become even more valuable as they enable sophisticated automation scenarios.
|
||||
|
||||
### Recipe Requirements for Headless Mode
|
||||
|
||||
|
|
@ -213,9 +213,9 @@ While headless mode is incredibly powerful, it's important to understand its con
|
|||
|
||||
### 1. No User Interaction Capability
|
||||
|
||||
**What this means**: Goose cannot ask for clarification, approval, or additional input during execution. If it's unsure of what to do, the prompt result will usually show you a question like "How should I proceed?".
|
||||
**What this means**: goose cannot ask for clarification, approval, or additional input during execution. If it's unsure of what to do, the prompt result will usually show you a question like "How should I proceed?".
|
||||
|
||||
**Impact**: If instructions are ambiguous or if unexpected situations arise, Goose will make its best judgment based on available context, which might not always align with your intentions.
|
||||
**Impact**: If instructions are ambiguous or if unexpected situations arise, goose will make its best judgment based on available context, which might not always align with your intentions.
|
||||
|
||||
**Mitigation**: Provide extremely detailed instructions, especially on what to do if it runs into a problem, and **test your automation thoroughly in non-production** environments first.
|
||||
|
||||
|
|
@ -237,7 +237,7 @@ goose run -t "Fix the TypeScript compilation errors in src/components/, ensure a
|
|||
|
||||
### 3. Tool Permission Dependencies
|
||||
|
||||
**What this means**: Goose cannot prompt for permission to use potentially risky tools or operations.
|
||||
**What this means**: goose cannot prompt for permission to use potentially risky tools or operations.
|
||||
|
||||
**Impact**: Operations requiring approval will either use default permissions or fail, potentially blocking automation workflows.
|
||||
|
||||
|
|
@ -250,7 +250,7 @@ export GOOSE_MODE=auto # Automatically approve safe operations
|
|||
|
||||
### 4. Context Decision Automation
|
||||
|
||||
**What this means**: When conversation context limits are reached, Goose automatically applies the configured strategy without user input.
|
||||
**What this means**: When conversation context limits are reached, goose automatically applies the configured strategy without user input.
|
||||
|
||||
**Impact**: Important context might be lost if summarization isn't perfect, or execution might be interrupted if context clearing is too aggressive.
|
||||
|
||||
|
|
@ -311,13 +311,13 @@ export GOOSE_ALLOWLIST=https://company.com/allowed-extensions.json
|
|||
|
||||
## The Future of Automated Development
|
||||
|
||||
Goose's headless mode represents more than just a feature -- it's a shift toward truly automated development workflows powered by AI. We can remove human intervention in routine tasks so teams can focus on high-value work while AI handles the repetitive, time-consuming operations that slow us down.
|
||||
goose's headless mode represents more than just a feature -- it's a shift toward truly automated development workflows powered by AI. We can remove human intervention in routine tasks so teams can focus on high-value work while AI handles the repetitive, time-consuming operations that slow us down.
|
||||
|
||||
Whether you're looking to streamline your CI/CD pipelines, automate server maintenance, or handle bulk operations across multiple repositories, Goose's headless mode provides the foundation for building sophisticated, reliable automation workflows.
|
||||
Whether you're looking to streamline your CI/CD pipelines, automate server maintenance, or handle bulk operations across multiple repositories, goose's headless mode provides the foundation for building sophisticated, reliable automation workflows.
|
||||
|
||||
**Start your automation journey today:**
|
||||
|
||||
1. **Install Goose** and configure your environment variables
|
||||
1. **Install goose** and configure your environment variables
|
||||
2. **Create your first recipe** with clear prompts and detailed instructions
|
||||
3. **Test in a safe environment** before deploying to production
|
||||
4. **Integrate with your existing workflows** and watch your productivity soar
|
||||
|
|
|
|||
|
|
@ -5,12 +5,12 @@ title: Isolated Development Environments
|
|||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This guide shows you how to set up isolated development environments using the **[Container Use MCP](https://github.com/dagger/container-use)** with Goose. With this setup, your development work will be isolated to both git branches and containers, allowing you to experiment freely without affecting your main system state.
|
||||
This guide shows you how to set up isolated development environments using the **[Container Use MCP](https://github.com/dagger/container-use)** with goose. With this setup, your development work will be isolated to both git branches and containers, allowing you to experiment freely without affecting your main system state.
|
||||
Note that the container-use MCP is very new and emerging, but offers powerful ways to do isolated development which are very agent friendly (build on tools like Docker, copy on write filesystems and more)
|
||||
|
||||
## Overview
|
||||
|
||||
The **[Container Use MCP](https://github.com/dagger/container-use)** server provides containerized development environments that integrate seamlessly with Goose. This allows you to:
|
||||
The **[Container Use MCP](https://github.com/dagger/container-use)** server provides containerized development environments that integrate seamlessly with goose. This allows you to:
|
||||
|
||||
- Work on changes isolated to git branches
|
||||
- Run code in containers without affecting your local machine
|
||||
|
|
@ -22,7 +22,7 @@ The **[Container Use MCP](https://github.com/dagger/container-use)** server prov
|
|||
|
||||
- Docker ([Podman](https://docs.dagger.io/ci/integrations/podman), [NerdCtl](https://docs.dagger.io/ci/integrations/nerdctl/) or [Container](https://docs.dagger.io/ci/integrations/apple-container/)) installed and running on your system
|
||||
- Git installed and configured
|
||||
- Goose installed and configured
|
||||
- goose installed and configured
|
||||
|
||||
## Installation
|
||||
|
||||
|
|
@ -30,20 +30,20 @@ The **[Container Use MCP](https://github.com/dagger/container-use)** server prov
|
|||
|
||||
Head on over to the [Container Use README](https://github.com/dagger/container-use/blob/main/README.md) for up-to-date install instructions for this fast moving project.
|
||||
|
||||
## Adding to Goose
|
||||
## Adding to goose
|
||||
|
||||
### Method 1: Quick Setup Link
|
||||
|
||||
Click this link to automatically add the extension to Goose:
|
||||
Click this link to automatically add the extension to goose:
|
||||
|
||||
**[Add Container-Use to Goose](goose://extension?cmd=cu&arg=stdio&id=container-use&name=container%20use&description=use%20containers%20with%20dagger%20and%20git%20for%20isolated%20environments)**
|
||||
**[Add Container-Use to goose](goose://extension?cmd=cu&arg=stdio&id=container-use&name=container%20use&description=use%20containers%20with%20dagger%20and%20git%20for%20isolated%20environments)**
|
||||
|
||||
### Method 2: Manual Configuration
|
||||
|
||||
<Tabs groupId="interface">
|
||||
<TabItem value="ui" label="goose Desktop" default>
|
||||
|
||||
1. Click `...` in the top right corner of the Goose Desktop.
|
||||
1. Click `...` in the top right corner of the goose Desktop.
|
||||
2. Select `Advanced Settings` from the menu.
|
||||
3. Under `Extensions`, click `Add custom extension`.
|
||||
4. Fill in the details:
|
||||
|
|
@ -96,17 +96,17 @@ extensions:
|
|||
|
||||
## Usage
|
||||
|
||||
Once the extension is enabled in Goose, you can:
|
||||
Once the extension is enabled in goose, you can:
|
||||
|
||||
### Starting Isolated Development
|
||||
|
||||
Simply mention in your conversation with Goose that you want to work in an isolated environment:
|
||||
Simply mention in your conversation with goose that you want to work in an isolated environment:
|
||||
|
||||
```
|
||||
"I want to experiment with adding a new feature, but I want to do it in an isolated environment so I don't affect my main codebase."
|
||||
```
|
||||
|
||||
Goose will automatically:
|
||||
goose will automatically:
|
||||
1. Create a new git branch for your work
|
||||
2. Set up a containerized environment
|
||||
3. Ensure all changes are isolated from your host system
|
||||
|
|
@ -136,15 +136,15 @@ Goose will automatically:
|
|||
|
||||
### Feature Development
|
||||
|
||||
1. Start a conversation with Goose about a new feature
|
||||
1. Start a conversation with goose about a new feature
|
||||
2. Request isolated development environment
|
||||
3. Goose creates branch and container
|
||||
3. goose creates branch and container
|
||||
4. Develop and test the feature
|
||||
5. If successful, merge the branch; if not, discard it
|
||||
|
||||
### Dependency Exploration
|
||||
|
||||
1. Ask Goose to explore a new library or tool
|
||||
1. Ask goose to explore a new library or tool
|
||||
2. Work in isolated container with the dependency
|
||||
3. Test compatibility and functionality
|
||||
4. Decide whether to integrate into main project
|
||||
|
|
@ -182,6 +182,6 @@ If you encounter issues:
|
|||
|
||||
## Next Steps
|
||||
|
||||
With container-use enabled in Goose, you're ready to develop with confidence. Try starting a conversation about a project you've been hesitant to experiment with, and let Goose set up a safe, isolated environment for your exploration.
|
||||
With container-use enabled in goose, you're ready to develop with confidence. Try starting a conversation about a project you've been hesitant to experiment with, and let goose set up a safe, isolated environment for your exploration.
|
||||
|
||||
Remember: with isolated environments, there's no such thing as a failed experiment - only learning opportunities that don't affect your main codebase.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
description: Integrate Goose with Langfuse to observe performance
|
||||
description: Integrate goose with Langfuse to observe performance
|
||||
---
|
||||
|
||||
# Observability with Langfuse
|
||||
|
||||
This tutorial covers how to integrate Goose with Langfuse to monitor your Goose requests and understand how the agent is performing.
|
||||
This tutorial covers how to integrate goose with Langfuse to monitor your goose requests and understand how the agent is performing.
|
||||
|
||||
## What is Langfuse
|
||||
|
||||
|
|
@ -15,9 +15,9 @@ This tutorial covers how to integrate Goose with Langfuse to monitor your Goose
|
|||
|
||||
Sign up for Langfuse Cloud [here](https://cloud.langfuse.com) or self-host Langfuse [Docker Compose](https://langfuse.com/self-hosting/local) to get your Langfuse API keys.
|
||||
|
||||
## Configure Goose to Connect to Langfuse
|
||||
## Configure goose to Connect to Langfuse
|
||||
|
||||
Set the environment variables so that Goose (written in Rust) can connect to the Langfuse server.
|
||||
Set the environment variables so that goose (written in Rust) can connect to the Langfuse server.
|
||||
|
||||
```bash
|
||||
export LANGFUSE_INIT_PROJECT_PUBLIC_KEY=pk-lf-...
|
||||
|
|
@ -28,13 +28,13 @@ export LANGFUSE_URL=https://cloud.langfuse.com # EU data region 🇪🇺
|
|||
# https://localhost:3000 if you're self-hosting
|
||||
```
|
||||
|
||||
## Run Goose with Langfuse Integration
|
||||
## Run goose with Langfuse Integration
|
||||
|
||||
Now, you can run Goose and monitor your AI requests and actions through Langfuse.
|
||||
Now, you can run goose and monitor your AI requests and actions through Langfuse.
|
||||
|
||||
With Goose running and the environment variables set, Langfuse will start capturing traces of your Goose activities.
|
||||
With goose running and the environment variables set, Langfuse will start capturing traces of your goose activities.
|
||||
|
||||
_[Example trace (public) in Langfuse](https://cloud.langfuse.com/project/cloramnkj0002jz088vzn1ja4/traces/cea4ed38-0c44-4b0a-8c20-4b0b6b9e8d73?timestamp=2025-01-31T15%3A52%3A30.362Z&observation=7c8e5807-3c29-4c28-9c6f-7d7427be401f)_
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ import TabItem from '@theme/TabItem';
|
|||
|
||||
# Lead/Worker Multi-Model Setup
|
||||
|
||||
Goose supports a lead/worker model configuration that lets you pair two different AI models - one that's great at thinking and another that's fast at doing. This setup tackles a major pain point: premium models are powerful but expensive, while cheaper models are faster but can struggle with complex tasks. With lead/worker mode, you get the best of both worlds.
|
||||
goose supports a lead/worker model configuration that lets you pair two different AI models - one that's great at thinking and another that's fast at doing. This setup tackles a major pain point: premium models are powerful but expensive, while cheaper models are faster but can struggle with complex tasks. With lead/worker mode, you get the best of both worlds.
|
||||
|
||||
<details>
|
||||
<summary>Lead/Worker Mode Walkthrough</summary>
|
||||
|
|
@ -21,13 +21,13 @@ Goose supports a lead/worker model configuration that lets you pair two differen
|
|||
></iframe>
|
||||
</details>
|
||||
|
||||
The lead/worker model is a smart hand-off system. The "lead" model (think: GPT-4 or Claude Opus) kicks things off, handling the early planning and big picture reasoning. Once the direction is set, Goose hands the task over to the "worker" model (like GPT-4o-mini or Claude Sonnet) to carry out the steps.
|
||||
The lead/worker model is a smart hand-off system. The "lead" model (think: GPT-4 or Claude Opus) kicks things off, handling the early planning and big picture reasoning. Once the direction is set, goose hands the task over to the "worker" model (like GPT-4o-mini or Claude Sonnet) to carry out the steps.
|
||||
|
||||
If things go sideways (e.g. the worker model gets confused or keeps making mistakes), Goose notices and automatically pulls the lead model back in to recover. Once things are back on track, the worker takes over again.
|
||||
If things go sideways (e.g. the worker model gets confused or keeps making mistakes), goose notices and automatically pulls the lead model back in to recover. Once things are back on track, the worker takes over again.
|
||||
|
||||
## Turn-Based System
|
||||
|
||||
A **turn** is one full interaction - your prompt and the model's response. Goose switches models based on turns:
|
||||
A **turn** is one full interaction - your prompt and the model's response. goose switches models based on turns:
|
||||
|
||||
- **Initial turns** (default: 3) go to the lead model
|
||||
- **Subsequent turns** use the worker model
|
||||
|
|
@ -37,7 +37,7 @@ A **turn** is one full interaction - your prompt and the model's response. Goose
|
|||
|
||||
## Quick Example
|
||||
|
||||
You might configure Goose like this:
|
||||
You might configure goose like this:
|
||||
|
||||
```bash
|
||||
export GOOSE_LEAD_MODEL="gpt-4o" # strong reasoning
|
||||
|
|
@ -45,17 +45,17 @@ export GOOSE_MODEL="gpt-4o-mini" # fast execution
|
|||
export GOOSE_PROVIDER="openai"
|
||||
```
|
||||
|
||||
Goose will start with `gpt-4o` for the first three turns, then hand off to `gpt-4o-mini`. If the worker gets tripped up twice in a row, Goose temporarily switches back to the lead model for two fallback turns before trying the worker again.
|
||||
goose will start with `gpt-4o` for the first three turns, then hand off to `gpt-4o-mini`. If the worker gets tripped up twice in a row, goose temporarily switches back to the lead model for two fallback turns before trying the worker again.
|
||||
|
||||
## Configuration
|
||||
|
||||
:::tip
|
||||
Ensure you have [added the LLMs to Goose](/docs/getting-started/providers)
|
||||
Ensure you have [added the LLMs to goose](/docs/getting-started/providers)
|
||||
:::
|
||||
|
||||
<Tabs groupId="interface">
|
||||
<TabItem value="ui" label="goose Desktop" default>
|
||||
1. Click the model name at the bottom of the Goose Desktop window
|
||||
1. Click the model name at the bottom of the goose Desktop window
|
||||
2. Click **Lead/Worker Settings**
|
||||
3. Check the box to **Enable lead/worker mode**
|
||||
4. Select your **Lead Model** and **Worker Model** from the dropdown menus
|
||||
|
|
@ -67,7 +67,7 @@ Ensure you have [added the LLMs to Goose](/docs/getting-started/providers)
|
|||
```bash
|
||||
export GOOSE_LEAD_MODEL="gpt-4o"
|
||||
```
|
||||
That's it. Goose treats your regular `GOOSE_MODEL` as the worker model by default.
|
||||
That's it. goose treats your regular `GOOSE_MODEL` as the worker model by default.
|
||||
|
||||
For more control, you can also set these optional environment variables:
|
||||
|
||||
|
|
@ -83,13 +83,13 @@ Ensure you have [added the LLMs to Goose](/docs/getting-started/providers)
|
|||
|
||||
## What Counts as a Failure?
|
||||
|
||||
Goose is smart about detecting actual task failures, not just API errors. The fallback kicks in when the worker:
|
||||
goose is smart about detecting actual task failures, not just API errors. The fallback kicks in when the worker:
|
||||
|
||||
- Generates broken code (syntax errors, tool failures, missing files)
|
||||
- Hits permission issues
|
||||
- Gets corrected by the user ("that's wrong", "try again", etc.)
|
||||
|
||||
Technical hiccups like timeouts, authentication issues, or service downtime don't trigger fallback mode. Goose retries those quietly.
|
||||
Technical hiccups like timeouts, authentication issues, or service downtime don't trigger fallback mode. goose retries those quietly.
|
||||
|
||||
## Reasons to Use Lead/Worker
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ Technical hiccups like timeouts, authentication issues, or service downtime don'
|
|||
If you're just getting started, the default settings will work fine. But here's how to tune things:
|
||||
|
||||
- Bump up `GOOSE_LEAD_TURNS` to 5–7 for heavier planning upfront
|
||||
- Lower `GOOSE_LEAD_FAILURE_THRESHOLD` to 1 if you want Goose to correct issues quickly
|
||||
- Lower `GOOSE_LEAD_FAILURE_THRESHOLD` to 1 if you want goose to correct issues quickly
|
||||
- Choose a fast, lightweight worker model (Claude Haiku, GPT-4o-mini) for day-to-day tasks
|
||||
|
||||
For debugging, you can see model switching behavior by turning on this log:
|
||||
|
|
@ -113,7 +113,7 @@ export RUST_LOG=goose::providers::lead_worker=info
|
|||
```
|
||||
|
||||
## Planning Mode Compatibility
|
||||
The lead/worker model is an automatic alternative to the [Goose CLI's `/plan` command](/docs/guides/multi-model/creating-plans). You can assign separate models to use as the lead/worker and planning models. For example:
|
||||
The lead/worker model is an automatic alternative to the [goose CLI's `/plan` command](/docs/guides/multi-model/creating-plans). You can assign separate models to use as the lead/worker and planning models. For example:
|
||||
|
||||
```bash
|
||||
export GOOSE_PROVIDER="openai"
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Planning Complex Tasks"
|
||||
description: "Learn how to use Goose's Plan feature to break down complex tasks into manageable, executable steps."
|
||||
description: "Learn how to use goose's Plan feature to break down complex tasks into manageable, executable steps."
|
||||
---
|
||||
|
||||
# Planning Complex Tasks
|
||||
|
|
@ -8,15 +8,15 @@ description: "Learn how to use Goose's Plan feature to break down complex tasks
|
|||
*Transform overwhelming tasks into systematic, step-by-step execution plans*
|
||||
|
||||
|
||||
Using Goose for large, complex tasks can feel overwhelming, especially when you're unsure of exactly how you want to approach it in advance. I experienced this when I needed to set up a complex development environment for an [API course](https://github.com/LinkedInLearning/java-automated-api-testing-with-rest-assured-5989068) I published. Between Docker configurations, database initialization, devcontainer setup, and GitHub Codespaces integration, there are dozens of moving pieces that need to work together perfectly. One missing configuration or incorrect dependency can derail the entire process.
|
||||
Using goose for large, complex tasks can feel overwhelming, especially when you're unsure of exactly how you want to approach it in advance. I experienced this when I needed to set up a complex development environment for an [API course](https://github.com/LinkedInLearning/java-automated-api-testing-with-rest-assured-5989068) I published. Between Docker configurations, database initialization, devcontainer setup, and GitHub Codespaces integration, there are dozens of moving pieces that need to work together perfectly. One missing configuration or incorrect dependency can derail the entire process.
|
||||
|
||||
This tutorial shows you how to use Goose's [Plan feature](/docs/guides/multi-model/creating-plans) to transform a complex devcontainer setup into a systematic, executable roadmap. You'll learn how to brainstorm with Goose, refine your requirements, and let Goose create both a detailed plan and implementation checklist.
|
||||
This tutorial shows you how to use goose's [Plan feature](/docs/guides/multi-model/creating-plans) to transform a complex devcontainer setup into a systematic, executable roadmap. You'll learn how to brainstorm with goose, refine your requirements, and let goose create both a detailed plan and implementation checklist.
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
By the end of this tutorial, you'll understand how to:
|
||||
|
||||
- Use Goose's Plan feature to break down complex technical projects
|
||||
- Use goose's Plan feature to break down complex technical projects
|
||||
- Brainstorm and refine requirements through AI-assisted conversation
|
||||
- Transform high-level goals into detailed, executable steps
|
||||
- Create comprehensive checklists for validation and quality assurance
|
||||
|
|
@ -37,23 +37,23 @@ This involves coordinating multiple technologies: Docker, MySQL, PHP, Java, devc
|
|||
|
||||
## Step 1: Initial Brainstorming Session
|
||||
|
||||
Let's start by having a brainstorming conversation with Goose to clarify our requirements.
|
||||
Let's start by having a brainstorming conversation with goose to clarify our requirements.
|
||||
|
||||
:::info Planning in Desktop vs CLI
|
||||
The Goose Desktop doesn't have a `/plan` keyword like the CLI. In Desktop, you need to explicitly ask Goose to create a plan:
|
||||
The goose Desktop doesn't have a `/plan` keyword like the CLI. In Desktop, you need to explicitly ask goose to create a plan:
|
||||
|
||||
```
|
||||
"Hey Goose, can you create a plan to set up my GitHub repo for Codespaces with automatic Docker startup? Please don't start the actual work yet."
|
||||
"Hey goose, can you create a plan to set up my GitHub repo for Codespaces with automatic Docker startup? Please don't start the actual work yet."
|
||||
```
|
||||
|
||||
In the CLI, you can enter plan mode with `/plan` and Goose will ask clarifying questions before generating the plan. Unless you specifically ask Goose Desktop to "create a plan", it might jump straight into implementation.
|
||||
In the CLI, you can enter plan mode with `/plan` and goose will ask clarifying questions before generating the plan. Unless you specifically ask goose Desktop to "create a plan", it might jump straight into implementation.
|
||||
:::
|
||||
|
||||
### Starting the Conversation
|
||||
|
||||
**You:** _"I need help setting up a GitHub repository for automated API testing. Students should be able to open it in GitHub Codespaces and immediately start writing tests without any manual setup. Can you help me think through what's needed?"_
|
||||
|
||||
**Goose:** _"I'd be happy to help you design this automated setup! Let me ask some clarifying questions to understand your requirements better:_
|
||||
**goose:** _"I'd be happy to help you design this automated setup! Let me ask some clarifying questions to understand your requirements better:_
|
||||
|
||||
1. What type of API are you working with? (REST, GraphQL, etc.)
|
||||
2. What testing framework do you want students to use?
|
||||
|
|
@ -65,7 +65,7 @@ In the CLI, you can enter plan mode with `/plan` and Goose will ask clarifying q
|
|||
|
||||
**You:** _"It's a REST API built in PHP that students will test using Rest Assured in Java. They need a real MySQL database with actual test data so they can practice realistic scenarios. The API has endpoints for managing products and categories in an e-commerce system."_
|
||||
|
||||
**Goose:** _"Perfect! That gives me a clear picture. A few more questions to ensure we design this correctly:_
|
||||
**goose:** _"Perfect! That gives me a clear picture. A few more questions to ensure we design this correctly:_
|
||||
|
||||
1. Do you already have the PHP API code, or do we need to create it?
|
||||
2. What version of Java should the environment support?
|
||||
|
|
@ -77,7 +77,7 @@ In the CLI, you can enter plan mode with `/plan` and Goose will ask clarifying q
|
|||
|
||||
## Step 2: Creating the Detailed Plan
|
||||
|
||||
Now that we've clarified the requirements, let's ask Goose to create a comprehensive plan.
|
||||
Now that we've clarified the requirements, let's ask goose to create a comprehensive plan.
|
||||
|
||||
### Requesting the Plan
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ Now that we've clarified the requirements, let's ask Goose to create a comprehen
|
|||
|
||||
### The Generated Plan
|
||||
|
||||
Goose will generate a comprehensive plan similar to this:
|
||||
goose will generate a comprehensive plan similar to this:
|
||||
|
||||
<details>
|
||||
<summary>GitHub Codespaces API Testing Environment Setup Plan</summary>
|
||||
|
|
@ -295,15 +295,15 @@ Create a GitHub repository that automatically provisions a complete development
|
|||
|
||||
## Step 3: Detailed Implementation Planning
|
||||
|
||||
Now let's ask Goose to create the specific implementation prompt that will guide the execution.
|
||||
Now let's ask goose to create the specific implementation prompt that will guide the execution.
|
||||
|
||||
### Creating the Implementation Prompt
|
||||
|
||||
**You:** _"This plan looks comprehensive! Can you now create a detailed implementation prompt that I can use to execute this plan? I want something specific enough that Goose can follow it step-by-step without needing additional clarification."_
|
||||
**You:** _"This plan looks comprehensive! Can you now create a detailed implementation prompt that I can use to execute this plan? I want something specific enough that goose can follow it step-by-step without needing additional clarification."_
|
||||
|
||||
### The Implementation Prompt
|
||||
|
||||
Goose will generate a detailed prompt like this:
|
||||
goose will generate a detailed prompt like this:
|
||||
|
||||
<details>
|
||||
<summary>Detailed Prompt</summary>
|
||||
|
|
@ -370,11 +370,11 @@ With our detailed plan and implementation prompt ready, we can now execute the s
|
|||
|
||||
**You:** _"Perfect! Now let's implement this plan. Here's the detailed prompt we created: [paste the implementation prompt]"_
|
||||
|
||||
Goose will now work through each step of the plan, creating the necessary files and configurations.
|
||||
goose will now work through each step of the plan, creating the necessary files and configurations.
|
||||
|
||||
### Monitoring Progress
|
||||
|
||||
As Goose implements the plan, you can verify each deliverable against the checklist we created:
|
||||
As goose implements the plan, you can verify each deliverable against the checklist we created:
|
||||
|
||||
1. **File Creation**: Check that each required file is created in the correct location
|
||||
2. **Configuration Accuracy**: Verify that configurations match the specifications
|
||||
|
|
@ -408,11 +408,11 @@ If issues arise during implementation or testing, use the plan as a reference to
|
|||
- **Permission Problems**: Update Dockerfile with proper permissions
|
||||
- **Configuration Errors**: Verify environment variables and connection strings
|
||||
|
||||
## Best Practices for Planning with Goose
|
||||
## Best Practices for Planning with goose
|
||||
|
||||
1. Start with brainstorming. Don't jump straight to asking for a plan. Have a conversation to clarify requirements and explore options.
|
||||
2. Be specific about deliverables. Ask for concrete deliverables, file names, and validation criteria for each step.
|
||||
3. Ask Goose to identify potential issues and provide mitigation strategies.
|
||||
3. Ask goose to identify potential issues and provide mitigation strategies.
|
||||
4. Generate detailed implementation prompts that can guide execution without additional clarification.
|
||||
5. Include specific ways to verify that each step worked correctly.
|
||||
|
||||
|
|
@ -424,7 +424,7 @@ For very complex projects, break the plan into phases and tackle them incrementa
|
|||
**You:** _"This plan is quite comprehensive. Can you break it into smaller phases that I can implement and test independently?"_
|
||||
|
||||
### Dependency Mapping
|
||||
Ask Goose to identify dependencies between tasks:
|
||||
Ask goose to identify dependencies between tasks:
|
||||
|
||||
**You:** _"Which of these tasks can be done in parallel, and which have dependencies on other tasks?"_
|
||||
|
||||
|
|
@ -435,7 +435,7 @@ Explore different implementation strategies:
|
|||
|
||||
## Conclusion
|
||||
|
||||
Goose's Plan feature transforms complex technical challenges from overwhelming problems into systematic, executable roadmaps. By following this tutorial's approach:
|
||||
goose's Plan feature transforms complex technical challenges from overwhelming problems into systematic, executable roadmaps. By following this tutorial's approach:
|
||||
|
||||
1. **Brainstorm** to clarify requirements and explore options
|
||||
2. **Plan** to break down complexity into manageable steps
|
||||
|
|
@ -445,13 +445,13 @@ Goose's Plan feature transforms complex technical challenges from overwhelming p
|
|||
|
||||
You can tackle any complex development environment setup with confidence, knowing that you have a clear path forward and specific criteria for success.
|
||||
|
||||
The key is treating Goose as a planning partner, not just a code generator. Give it the full context of what you're trying to achieve, and let it help you think through the complexity before diving into implementation.
|
||||
The key is treating goose as a planning partner, not just a code generator. Give it the full context of what you're trying to achieve, and let it help you think through the complexity before diving into implementation.
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Try this approach with your own complex setup challenges
|
||||
- Experiment with different types of planning prompts
|
||||
- Share your planning successes with the [Goose community](https://discord.gg/goose-oss)
|
||||
- Share your planning successes with the [goose community](https://discord.gg/goose-oss)
|
||||
- Explore how planning integrates with [Lead/Worker mode](/docs/tutorials/lead-worker) or [Subagents](/docs/guides/subagents) for even more sophisticated workflows
|
||||
|
||||
Remember, the goal is to get the right approach, in the right order, with the right safeguards. That's what makes the difference between a quick fix and a robust, maintainable solution.
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
description: Learn how to create and use Goose recipes with this comprehensive tutorial covering prompts, parameters, and MCP servers
|
||||
description: Learn how to create and use goose recipes with this comprehensive tutorial covering prompts, parameters, and MCP servers
|
||||
---
|
||||
|
||||
# Goose Recipes
|
||||
# goose Recipes
|
||||
|
||||
Goose Recipes are files that contain all the details to allow Goose to do one specific task. Since they are contained in just one file, they are easy to share through all the normal ways we share files, including version management systems like git. Let's get started with the simplest recipe possible.
|
||||
goose recipes are files that contain all the details to allow goose to do one specific task. Since they are contained in just one file, they are easy to share through all the normal ways we share files, including version management systems like git. Let's get started with the simplest recipe possible.
|
||||
|
||||
## The Simplest Recipe
|
||||
|
||||
|
|
@ -32,9 +32,9 @@ goose run --recipe trip.yaml
|
|||
|
||||
## Extensions
|
||||
|
||||
Goose recipes have a section where you can specify which [extensions](/docs/guides/recipes/recipe-reference#extensions) Goose can use during execution. Goose will only use the ones you specify.
|
||||
goose recipes have a section where you can specify which [extensions](/docs/guides/recipes/recipe-reference#extensions) goose can use during execution. goose will only use the ones you specify.
|
||||
|
||||
Let's say we want to make sure we have good weather during our Europe trip. We can just add a weather extension (this example uses the [weather-mcp-server](https://github.com/TuanKiri/weather-mcp-server) by TuanKiri under the MIT License) to our recipe, modify the prompt a bit and now Goose will check the weather before adding a city to our trip.
|
||||
Let's say we want to make sure we have good weather during our Europe trip. We can just add a weather extension (this example uses the [weather-mcp-server](https://github.com/TuanKiri/weather-mcp-server) by TuanKiri under the MIT License) to our recipe, modify the prompt a bit and now goose will check the weather before adding a city to our trip.
|
||||
|
||||
```yaml
|
||||
title: Trip planner
|
||||
|
|
@ -82,7 +82,7 @@ goose run --recipe trip.yaml --params destination=Africa --params duration=14
|
|||
|
||||
## Settings
|
||||
|
||||
By default, Goose uses the `temperature` and `model` you've already chosen, which usually works just fine. But sometimes you might want more control. For example, when performing a subjective task like planning a trip, it can help to turn up the `temperature` setting. Think of temperature like a creativity dial - the higher it is, the more varied and unexpected the results. If the first suggestion isn't quite right, the user can just run the recipe again to get a new one.
|
||||
By default, goose uses the `temperature` and `model` you've already chosen, which usually works just fine. But sometimes you might want more control. For example, when performing a subjective task like planning a trip, it can help to turn up the `temperature` setting. Think of temperature like a creativity dial - the higher it is, the more varied and unexpected the results. If the first suggestion isn't quite right, the user can just run the recipe again to get a new one.
|
||||
|
||||
You can also specify which AI provider and model to use for a specific recipe:
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ The available settings are:
|
|||
- `goose_model`: The specific model name
|
||||
- `temperature`: Controls creativity/randomness (0.0-1.0, higher = more creative)
|
||||
|
||||
These settings will override your default Goose configuration when this recipe runs.
|
||||
These settings will override your default goose configuration when this recipe runs.
|
||||
|
||||
## External Files
|
||||
|
||||
|
|
@ -282,4 +282,4 @@ This itinerary offers a perfect blend of history, culture, and cuisine across th
|
|||
:::
|
||||
|
||||
## Learn More
|
||||
Check out the [Goose Recipes](/docs/guides/recipes) guide for more docs, tools, and resources to help you master Goose recipes.
|
||||
Check out the [Recipes](/docs/guides/recipes) guide for more docs, tools, and resources to help you master goose recipes.
|
||||
|
|
@ -4,7 +4,7 @@ sidebar_label: Subrecipes In Parallel
|
|||
description: Run multiple subrecipes instances concurrently with real-time progress tracking
|
||||
---
|
||||
|
||||
Goose recipes can execute multiple [subrecipe](/docs/guides/recipes/subrecipes) instances concurrently using isolated worker processes. This feature enables efficient batch operations, parallel processing of different tasks, and faster completion of complex workflows.
|
||||
goose recipes can execute multiple [subrecipe](/docs/guides/recipes/subrecipes) instances concurrently using isolated worker processes. This feature enables efficient batch operations, parallel processing of different tasks, and faster completion of complex workflows.
|
||||
|
||||
:::warning Experimental Feature
|
||||
Running subrecipes in parallel is an experimental feature in active development. Behavior and configuration may change in future releases.
|
||||
|
|
@ -18,7 +18,7 @@ Here are some common use cases:
|
|||
|
||||
## How It Works
|
||||
|
||||
Parallel subrecipe execution uses an isolated worker system that automatically manages concurrent task execution. Goose creates individual tasks for each subrecipe instance and distributes them across up to 10 concurrent workers.
|
||||
Parallel subrecipe execution uses an isolated worker system that automatically manages concurrent task execution. goose creates individual tasks for each subrecipe instance and distributes them across up to 10 concurrent workers.
|
||||
|
||||
| Scenario | Default Behavior | Override Options |
|
||||
|----------|------------------|------------------|
|
||||
|
|
@ -27,7 +27,7 @@ Parallel subrecipe execution uses an isolated worker system that automatically m
|
|||
|
||||
### Different Subrecipes
|
||||
|
||||
When running different subrecipes, Goose determines the execution mode based on:
|
||||
When running different subrecipes, goose determines the execution mode based on:
|
||||
1. **Explicit user request** in the prompt ("in parallel", "sequentially")
|
||||
2. **Sequential execution by default**: Different subrecipes run one after another unless explicitly requested to run in parallel
|
||||
|
||||
|
|
@ -42,21 +42,21 @@ prompt: |
|
|||
|
||||
### Same Subrecipe
|
||||
|
||||
When running the same subrecipe with different parameters, Goose determines the execution mode based on:
|
||||
When running the same subrecipe with different parameters, goose determines the execution mode based on:
|
||||
1. **[Recipe-level configuration](#choosing-between-execution-modes)** (`sequential_when_repeated` flag) - when set to true, this forces sequential execution
|
||||
2. **User request** in the prompt ("sequentially" to override default parallel behavior)
|
||||
3. **Parallel execution by default**: Multiple instances of the same subrecipe run concurrently
|
||||
|
||||
If your prompt implies multiple executions of the same subrecipe, Goose will automatically create parallel instances:
|
||||
If your prompt implies multiple executions of the same subrecipe, goose will automatically create parallel instances:
|
||||
|
||||
```yaml
|
||||
prompt: |
|
||||
get the weather for three biggest cities in Australia
|
||||
```
|
||||
|
||||
In this example, Goose recognizes that "three biggest cities" requires running the weather subrecipe multiple times for different cities, so it executes them in parallel.
|
||||
In this example, goose recognizes that "three biggest cities" requires running the weather subrecipe multiple times for different cities, so it executes them in parallel.
|
||||
|
||||
If you wanted to run them sequentially, you can just tell Goose:
|
||||
If you wanted to run them sequentially, you can just tell goose:
|
||||
|
||||
```yaml
|
||||
prompt: |
|
||||
|
|
@ -211,4 +211,4 @@ sub_recipes:
|
|||
```
|
||||
|
||||
## Learn More
|
||||
Check out the [Goose Recipes](/docs/guides/recipes) guide for more docs, tools, and resources to help you master Goose recipes.
|
||||
Check out the [Recipes](/docs/guides/recipes) guide for more docs, tools, and resources to help you master goose recipes.
|
||||
Loading…
Add table
Add a link
Reference in a new issue