Creating effective security detections in Panther traditionally requires deep knowledge of detection logic, testing frameworks, and development workflows. The detection engineering team at Block has streamlined this process by building Goose recipes that automate the entire detection creation lifecycle from initial repository setup to pull request creation.
This blog post explores how to leverage Goose's [recipe](https://block.github.io/goose/docs/guides/recipes/) and [sub-recipe](https://block.github.io/goose/docs/guides/recipes/sub-recipes) system to create new detections in Panther with minimal manual intervention, ensuring consistency, quality, and adherence to team standards.
This blog post explores how to leverage Goose's [recipe](https://block.github.io/goose/docs/guides/recipes/) and [subrecipe](https://block.github.io/goose/docs/guides/recipes/subrecipes) system to create new detections in Panther with minimal manual intervention, ensuring consistency, quality, and adherence to team standards.
<!-- truncate -->
@@ -60,7 +60,7 @@ prompt: |
</details>
The detection creation recipe demonstrates the power of this approach by coordinating six specialized sub-recipes, each handling a specific aspect of detection development:
The detection creation recipe demonstrates the power of this approach by coordinating six specialized subrecipes, each handling a specific aspect of detection development:
1. [**workflow_setup**](#1-workflow_setup-foundation-first) - Repository preparation and environment validation
2. [**similar_rule_analyzer**](#2-similar_rule_analyzer-learning-from-existing-patterns) - Finding and analyzing existing detection patterns
@@ -88,22 +88,22 @@ This centralized approach through `AGENTS.md` becomes the foundation for our rec
## The Architecture
### Design Principles
1.**Single Responsibility**: Each sub-recipe has one clear job
1.**Single Responsibility**: Each subrecipe has one clear job
2.**Explicit Data Flow**: No hidden state or implicit dependencies
3.**Fail-Fast**: Stop immediately when critical steps fail
4.**Graceful Degradation**: Continue with reduced functionality when possible
5.**Comprehensive Testing**: Validate everything before deployment
### Why Sub-Recipes Matter
### Why Subrecipes Matter
The traditional approach to AI-assisted detection creation often involves a single, monolithic prompt (AKA “single-shot prompting”) that tries to handle everything at once. This leads to several problems:
- **Context confusion**: The AI loses focus when juggling multiple responsibilities
- **Inconsistent outputs**: Without clear boundaries, results vary significantly (e.g. one sub-recipe may try to complete the task that we're expecting another sub-recipe to accomplish)
- **Inconsistent outputs**: Without clear boundaries, results vary significantly (e.g. one subrecipe may try to complete the task that we're expecting another subrecipe to accomplish)
- **Difficult debugging**: When something fails, it's hard to identify the specific issue
- **Poor maintainability**: Changes to one aspect affect the entire workflow
The sub-recipe architecture solves these problems through strict separation of concerns, setting boundaries and providing exit criteria.
The subrecipe architecture solves these problems through strict separation of concerns, setting boundaries and providing exit criteria.
Each sub-recipe operates in isolation with:
Each subrecipe operates in isolation with:
- Clearly defined inputs and outputs
- Specific scope boundaries (what it MUST and MUST NOT do)
- Standardized JSON response schemas
@@ -130,7 +130,7 @@ Workflow visualized
</details>
## Data Flow and State Management
Since sub-recipes currently run in isolation, data must be explicitly passed between them. The main recipe orchestrates this flow:
Since subrecipes currently run in isolation, data must be explicitly passed between them. The main recipe orchestrates this flow:
Example of how this would be defined in the recipe:
```
@@ -192,7 +192,7 @@ The workflow makes intelligent decisions based on results from previous steps:
This sub-recipe serves as the critical quality gate, executing the mandatory testing pipeline that ensures every detection meets production standards.
This subrecipe serves as the critical quality gate, executing the mandatory testing pipeline that ensures every detection meets production standards.
**Key responsibilities**:
- Execute all mandatory testing commands from `AGENTS.md` (e.g. linting, formatting and both unit and pytests)
@@ -384,7 +384,7 @@ This sub-recipe serves as the critical quality gate, executing the mandatory tes
These checks ensure detections meet our standards, preventing subpar code from being merged. Should a check fail, the LLM will iterate, identifying and implementing necessary changes until compliance is achieved as part of the same recipe run.
**Intelligent failure analysis**: The sub-recipe doesn't just run tests - it analyzes failures and provides specific guidance:
**Intelligent failure analysis**: The subrecipe doesn't just run tests - it analyzes failures and provides specific guidance:
This sub-recipe handles the final workflow step with full adherence to team standards:
This subrecipe handles the final workflow step with full adherence to team standards:
**Key responsibilities**:
- Git branch management and commits
@@ -461,13 +461,13 @@ This sub-recipe handles the final workflow step with full adherence to team stan
}
```
_Quality assurance_: This sub-recipe includes comprehensive error handling for git failures, PR creation issues, and template population problems, providing clear fallback instructions when automation fails.
_Quality assurance_: This subrecipe includes comprehensive error handling for git failures, PR creation issues, and template population problems, providing clear fallback instructions when automation fails.
## Error Handling and Fail-Fast Design
This workflow implements sophisticated error handling with intelligent stopping points:
### Standardized Response Schema
Every sub-recipe uses a consistent JSON response format:
Every subrecipe uses a consistent JSON response format:
```json
{
"status": {
@@ -481,7 +481,7 @@ Every sub-recipe uses a consistent JSON response format:
```
### Failures
This workflow distinguishes between different types of failures. For example, each sub-recipe’s response has an `error_code` field. When a failure occurs, the LLM categorizes the type of error encountered and surfaces this information to the main recipe so it can make a determination on what to do next.
This workflow distinguishes between different types of failures. For example, each subrecipe’s response has an `error_code` field. When a failure occurs, the LLM categorizes the type of error encountered and surfaces this information to the main recipe so it can make a determination on what to do next.
As an example, `rule_creator` is configured with these error categories:
```
@@ -500,7 +500,7 @@ response:
...
```
If this sub-recipe returns `file_creation_failed`, we shouldn’t move on to the `testing_validator` or `pr_creator` steps.
If this subrecipe returns `file_creation_failed`, we shouldn’t move on to the `testing_validator` or `pr_creator` steps.
This fail-fast approach prevents wasted effort on meaningless subsequent steps.
@@ -528,7 +528,7 @@ goose run --recipe recipe.yaml --interactive \
The recipe system ensures compliance with team standards through:
### Automated Standards Extraction
The `workflow_setup` sub-recipe extracts key requirements from `AGENTS.md`:
The `workflow_setup` subrecipe extracts key requirements from `AGENTS.md`:
- File naming conventions (`ai_` prefix for AI-created rules)
- Required Python functions and error handling patterns
- Testing requirements and validation commands
@@ -542,7 +542,7 @@ The `workflow_setup` sub-recipe extracts key requirements from `AGENTS.md`:
- **Consistency**: Standardized file structures and naming
### Pull Request Automation
The `pr_creator` sub-recipe follows team standards:
The `pr_creator` subrecipe follows team standards:
- Proper branch naming (e.g. `ai/<description>`)
- Template-based PR descriptions
- Draft mode for review
@@ -575,7 +575,7 @@ For Organizations
- **Compliance**: Adherence to security and development standards
## Conclusion
Goose's recipe and sub-recipe system represents a significant advancement in AI-assisted security detection development. By breaking complex workflows into specialized, composable components, teams can achieve:
Goose's recipe and subrecipe system represents a significant advancement in AI-assisted security detection development. By breaking complex workflows into specialized, composable components, teams can achieve:
- **Higher quality detections** through automated testing and validation
- **Faster development cycles** with intelligent optimization
- **Better consistency** through standardized processes
title: "How PulseMCP Automated Their Newsletter Workflow with Goose"
description: PulseMCP used Goose recipes, subagents, and sub-recipes to automate the boring parts of their newsletter workflow
description: PulseMCP used Goose recipes, subagents, and subrecipes to automate the boring parts of their newsletter workflow
authors:
- rizel
---
@@ -21,7 +21,7 @@ Every week, the PulseMCP team faced the same time-consuming workflow: sourcing r
## The Solution: Why Sequential Beats Monolithic
Instead of building one massive "do-everything" agent (which inevitably fails on complex tasks), PulseMCP broke their workflow into six distinct phases. Each phase gets handled by focused [recipes](/docs/guides/recipes/session-recipes), [sub-recipes](/docs/guides/recipes/sub-recipes) and [subagents](/docs/experimental/subagents) with clear inputs, outputs, and a single job.
Instead of building one massive "do-everything" agent (which inevitably fails on complex tasks), PulseMCP broke their workflow into six distinct phases. Each phase gets handled by focused [recipes](/docs/guides/recipes/session-recipes), [subrecipes](/docs/guides/recipes/subrecipes) and [subagents](/docs/experimental/subagents) with clear inputs, outputs, and a single job.
This approach has three main benefits: debugging becomes easier when agents have single responsibilities, results become more predictable with clear handoffs between stages, and humans stay in control of the editorial process while automating the tedious work.
@@ -81,11 +81,11 @@ The PulseMCP implementation proves we're past the demo phase of AI agents. Real
<meta property="og:title" content="How PulseMCP Automated Their Newsletter Workflow with Goose" />
<meta property="og:description" content="PulseMCP used Goose recipes, subagents, and sub-recipes to automate the boring parts of their newsletter workflow" />
<meta property="og:description" content="PulseMCP used Goose recipes, subagents, and subrecipes to automate the boring parts of their newsletter workflow" />
<meta name="twitter:title" content="How PulseMCP Automated Their Newsletter Workflow with Goose" />
<meta name="twitter:description" content="PulseMCP used Goose recipes, subagents, and sub-recipes to automate the boring parts of their newsletter workflow" />
<meta name="twitter:description" content="PulseMCP used Goose recipes, subagents, and subrecipes to automate the boring parts of their newsletter workflow" />
@@ -77,7 +77,7 @@ The [Memory extension](https://block.github.io/goose/docs/mcp/memory-mcp) stores
**4. Recipes**
[Recipes](https://block.github.io/goose/docs/guides/recipes/) package complete task setups into reusable configurations, eliminating the need to provide lengthy instructions repeatedly. Instead of consuming tokens explaining complex workflows in every session, recipes contain all necessary instructions, extensions, and parameters upfront. This is particularly valuable for repetitive tasks where you'd otherwise spend significant tokens on setup and explanation. And if your recipe starts to feel overly lengthy, you can break the tasks up into [sub-recipes](https://block.github.io/goose/docs/guides/recipes/sub-recipes).
[Recipes](https://block.github.io/goose/docs/guides/recipes/) package complete task setups into reusable configurations, eliminating the need to provide lengthy instructions repeatedly. Instead of consuming tokens explaining complex workflows in every session, recipes contain all necessary instructions, extensions, and parameters upfront. This is particularly valuable for repetitive tasks where you'd otherwise spend significant tokens on setup and explanation. And if your recipe starts to feel overly lengthy, you can break the tasks up into [subrecipes](https://block.github.io/goose/docs/guides/recipes/subrecipes).
Remember when you first learned to cook? You probably started with simple recipes like scrambled eggs or toast. But eventually you wanted to make something more complex, like a full dinner with multiple dishes. That's how subrecipes work in goose: each recipe can run stand-alone for a dedicated task, and a main recipe can orchestrate how they run.
Let's explore [goose subrecipes](/docs/tutorials/sub-recipes-in-parallel) together! You're about to learn know how to orchestrate multiple AI models, coordinate tasks, and build workflows that will turn you into a "head chef" user with goose.
Let's explore [goose subrecipes](/docs/tutorials/subrecipes-in-parallel) together! You're about to learn know how to orchestrate multiple AI models, coordinate tasks, and build workflows that will turn you into a "head chef" user with goose.
When you're working on complex projects with goose, you'll often need to break work into multiple tasks and run them with AI agents. Goose gives you two powerful ways to do this: [subagents](/docs/experimental/subagents/) and [subrecipes](/docs/tutorials/sub-recipes-in-parallel/). Both can run multiple AI instances in parallel, but they work differently. Picking which one to use can be confusing, so we're going to guide you to a decision.
When you're working on complex projects with goose, you'll often need to break work into multiple tasks and run them with AI agents. Goose gives you two powerful ways to do this: [subagents](/docs/experimental/subagents/) and [subrecipes](/docs/tutorials/subrecipes-in-parallel/). Both can run multiple AI instances in parallel, but they work differently. Picking which one to use can be confusing, so we're going to guide you to a decision.
I've been using both approaches, and the choice between them depends on what you're trying to accomplish. Let me break down when to use each method and show you real examples.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
dianed-square