← Volver al listado de tecnologías ← Índice de Goose

10. Recipes

10 de mayo de 2026 Por: Artiko

gooserecipescookbookautomationmarketplace

10. Recipes

Un recipe es un archivo YAML que describe una tarea reutilizable: prompt parametrizado, herramientas requeridas, validación de output y permisos.

Los recipes son el segundo pilar de productividad con Goose después de las extensions. Permiten convertir “le pido al agente que haga X cada vez” en “corro goose run X --param ...”.

Anatomía de un recipe

# my-recipe.yaml
name: generate-changelog
description: Genera CHANGELOG.md desde los últimos N commits
version: 1.0.0
author: artiko

parameters:
  - name: tag_from
    type: string
    description: Tag o ref desde donde empezar
    required: true
  - name: tag_to
    type: string
    default: HEAD
  - name: format
    type: string
    enum: [keepachangelog, conventional, simple]
    default: keepachangelog

extensions:
  required:
    - developer  # necesita filesystem y shell

prompt: |
  Generá un archivo CHANGELOG.md a partir de los commits entre {{ tag_from }} y {{ tag_to }}.

  Pasos:
  1. Corré `git log --oneline {{ tag_from }}..{{ tag_to }}` para listar commits.
  2. Agrupalos por tipo según el formato {{ format }}.
  3. Escribí el resultado en CHANGELOG.md (sobreescribiendo).
  4. Mostrame un resumen de qué generaste.

  Formato {{ format }}:
  - keepachangelog: secciones Added / Changed / Deprecated / Removed / Fixed / Security
  - conventional: agrupado por feat / fix / chore / docs
  - simple: lista plana ordenada cronológicamente

output:
  schema:
    type: object
    properties:
      file: { type: string, const: CHANGELOG.md }
      entries_count: { type: integer }
      categories: { type: array, items: { type: string } }
    required: [file, entries_count]

permissions:
  filesystem:
    write:
      - CHANGELOG.md
  shell:
    allowed_commands:
      - "git log"
      - "git tag"

Componentes clave:

Sección	Función
`parameters`	Variables que el usuario provee al ejecutar
`extensions.required`	Extensions que deben estar habilitadas
`prompt`	Template Jinja-like con los parámetros
`output.schema`	JSON Schema que valida el output del agente
`permissions`	Lista blanca de operaciones permitidas

Ejecutar un recipe

goose run my-recipe.yaml \
  --param tag_from=v1.0.0 \
  --param tag_to=v1.2.0 \
  --param format=keepachangelog

O con shorthand:

goose run my-recipe.yaml -p tag_from=v1.0.0 -p format=conventional

Si te falta un parámetro required, Goose te lo pide interactivamente (a menos que pases --no-interactive):

? tag_from (required): v1.0.0
? format [keepachangelog]:

Crear recipes

Manualmente

goose recipe new my-recipe
# crea ~/.config/goose/recipes/my-recipe.yaml con plantilla
goose recipe edit my-recipe

Con el Recipe Generator

goose recipe generate

Wizard que te pregunta:

¿Qué tarea querés automatizar? (descripción libre).
¿Qué inputs necesita?
¿Qué extensiones querés permitir?

Y genera un recipe template basado en eso. Podés editarlo después.

Ejemplo: recipe simple sin parámetros

# daily-standup.yaml
name: daily-standup
description: Resume los commits de ayer y los issues abiertos a mí asignados

extensions:
  required: [developer, github]

prompt: |
  Hacé estas tres cosas:

  1. Listá mis commits del último día con git log --author="$(git config user.name)" --since="1 day ago"
  2. Listá issues asignados a mí abiertos en este repo (usá la extension de github)
  3. Generá un mensaje para Slack tipo standup con:
     - Ayer: [resumen de commits]
     - Hoy: [issues asignados a trabajar]
     - Bloqueos: [si hay alguno detectado]

  El mensaje debe entrar en 5 líneas. Sin emojis.

Uso:

goose run daily-standup.yaml

Recipe Cookbook

Hay un repositorio público con recipes mantenidos por la comunidad: Goose Cookbook.

Categorías típicas:

Code Quality: code review, lint fix, doc generation.
Git workflows: PR description, changelog, release notes.
Testing: generate tests, fix flaky tests, coverage improvement.
Refactoring: extract function, rename, type migration.
DevOps: terraform plan analysis, dockerfile optimization.

Instalar uno desde el cookbook:

goose recipe install code-review-strict
goose recipe install changelog-keepachangelog

Los descarga a tu ~/.config/goose/recipes/.

Recipe Marketplace

Más allá del cookbook oficial, existen marketplaces internos en empresas:

# .goose/recipe-sources.yaml
sources:
  - name: empresa-internal
    url: https://recipes.empresa.com/v1
    auth:
      bearer_token_env: RECIPE_REGISTRY_TOKEN
  - name: cookbook-oficial
    url: https://cookbook.goose-docs.ai

goose recipe search auth         # busca en todas las fuentes
goose recipe install empresa-internal/migrate-from-mongo

Deeplinks

Compartir un recipe con un compañero sin tener que mandarle el archivo:

goose recipe deeplink my-recipe
# Output: goose://recipe/install?source=local&content=base64url...

El compañero clickea ese link en su Goose Desktop o lo pega en CLI:

goose recipe install "goose://recipe/install?source=..."

Útil para compartir recipes ad-hoc sin pasar por el marketplace.

Prompt Library

Versión “lite” de los recipes: solo prompts con parámetros, sin schema de output ni permisos. Para tareas chicas y exploratorias.

goose prompt new investigate-error

# ~/.config/goose/prompts/investigate-error.yaml
name: investigate-error
parameters:
  - name: error_message
    type: string

prompt: |
  Tengo este error: {{ error_message }}

  Hacé:
  1. Buscá ese error en el repo
  2. Identificá si es código nuestro o de una dependencia
  3. Sugerí 2-3 hipótesis de causa raíz

goose prompt run investigate-error -p error_message="ECONNREFUSED localhost:5432"

Diferencia con recipes: prompts son invocaciones puntuales sin guardar state ni validar output. Un par a recipes ligeros.

Recipes con sub-tasks

Para flujos largos podés componer recipes:

name: full-release
description: Hace todo el flujo de release

extensions:
  required: [developer, github]

prompt: |
  Hacé el release completo:

  ## Step 1: Generar changelog
  Ejecutá el recipe `changelog-conventional` para los commits desde el último tag.

  ## Step 2: Bump de versión
  Actualizá package.json con el siguiente version según semver:
  - feat → minor
  - fix → patch
  - feat! → major

  ## Step 3: Tag y push
  - git tag v{{ new_version }}
  - git push --tags

  ## Step 4: Crear release en GitHub
  Usá el changelog generado en step 1 como descripción.

parameters:
  - name: new_version
    type: string
    required: false  # si no se da, lo decide el agente

permissions:
  shell:
    allowed_commands: ["git tag", "git push"]
  filesystem:
    write: [CHANGELOG.md, package.json]

El agente lee el recipe, ejecuta cada step en orden, y respeta los permisos definidos.

Validación de output con schema

Si tu recipe pretende generar JSON / YAML estructurado, el output.schema lo valida:

output:
  schema:
    type: object
    properties:
      severity:
        type: string
        enum: [critical, high, medium, low]
      findings:
        type: array
        items:
          type: object
          properties:
            file: { type: string }
            line: { type: integer }
            description: { type: string }
    required: [severity, findings]

Si el agente devuelve algo que no matchea, Goose:

Le da el error de validación al modelo.
Le pide que corrija.
Revalidación.
Si después de N intentos sigue fallando, sale con exit code 4.

Esto vuelve los recipes confiables para integrar con pipelines de CI.

CI: usar recipes en GitHub Actions

# .github/workflows/pr-review.yml
name: AI Review

on: pull_request

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Goose
        run: curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash
      - name: Run review recipe
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          goose run .goose/recipes/pr-review.yaml \
            --param pr_number=${{ github.event.pull_request.number }} \
            --output review.json
      - name: Comment PR
        run: gh pr comment ${{ github.event.pull_request.number }} --body-file review.json
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Tres ventajas sobre soluciones específicas (Copilot Review, etc.):

Tu recipe, tu prompt, tu lógica.
Cambias provider sin refactorear el workflow.
Versionado en git como cualquier otro código.

Best practices

Recipes chicos son mejores. Un recipe que hace 8 cosas es 8 oportunidades de fallar. Compone recipes chicos.
Permisos al mínimo. Solo allow las operaciones que el recipe realmente necesita.
Validación de output siempre que se pueda. Schema previene que un recipe roto pase silente.
Versioná los recipes. Field version: 1.2.3 en cada uno; cuando rompés compatibilidad, bumpeás major.
Documentá inputs. Que cada parameter tenga description para que goose recipe show sea útil.

¿Qué viene?

Tenés recipes que ejecutan tareas atómicas. En el próximo capítulo llevamos esto un nivel más alto: subagents que pueden trabajar en paralelo a tu sesión principal sin contaminarla.