# Cook

> Feature development with guardrails. Plan → Review → Code → Ship.

- **Type:** Skill
- **Install:** `agentstack add skill-pjuniszewski-cook-cook`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [PJuniszewski](https://agentstack.voostack.com/s/pjuniszewski)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [PJuniszewski](https://github.com/PJuniszewski)
- **Source:** https://github.com/PJuniszewski/cook/tree/main/skills/cook

## Install

```sh
agentstack add skill-pjuniszewski-cook-cook
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# cook skill
..cook.md",
  content=""
)
```

**BLOCKED ACTIONS until artifact exists:**
- ❌ Read (any file)
- ❌ Glob/Grep (any search)
- ❌ Task/Explore (any agent)
- ❌ Bash (any command)

**ONLY ALLOWED first action:** Write artifact file.

A PreToolUse hook will BLOCK other tools until artifact exists.

```markdown
# Cooking Result

## Dish

## Status
raw

## Cooking Mode
well-done

## Current Phase
Step 0.0 - Artifact Created

## Ownership
- Decision Owner: _TBD_
- Reviewers: _TBD_
- Approved by: _TBD_

---

# Phase 0 - Project Policy & Context

## Sources Scanned
| File | Status | Key Rules |
|------|--------|-----------|
| CLAUDE.md | _Pending_ | |
| README.md | _Pending_ | |
| .claude/agents/*.md | _Pending_ | |

## Hard Rules (must not be violated)
_Pending..._

## Preferred Patterns
_Pending..._

## Detected Conflicts
_Pending..._

## Policy Alignment Risk
_Pending..._

---

# Step 1 - Read the Order

## Feature Summary
_Pending..._

## Affected Modules/Components
| Module | Impact | Risk Level |
|--------|--------|------------|
| | | |

## Dependencies
_Pending..._

## Microwave Blocker Check
_Pending..._

---

# Step 2 - Ingredient Approval (Product Review)

## Product Decision
_Pending: Approved / Rejected / Deferred_

## Scope

### In Scope
- _Pending..._

### Out of Scope
- _Pending..._

### Non-goals
- _Pending..._

## User Value
_Pending..._

## Assumptions
- _Pending..._

---

# Step 3 - Presentation Planning (UX Review)

## UX Decision
_Pending: Required / Not Required_

## User Flow
_Pending..._

## UI Components Affected
| Component | Change Type | Notes |
|-----------|-------------|-------|
| | | |

## Accessibility Considerations
_Pending..._

---

# Step 4 - Implementation Plan

## Architecture Decision

### Selected Approach
_Pending..._

### Alternatives Considered
| Option | Pros | Cons | Decision |
|--------|------|------|----------|
| Option A | | | Rejected: _reason_ |
| Option B | | | **Selected**: _reason_ |

### Trade-offs
- Sacrificing: _what we give up_
- Gaining: _what we get_

## Patch Plan

### Files to Modify
| File | Change | Risk |
|------|--------|------|
| | | |

### Commit Sequence
1. _commit message_
2. _commit message_

### High-risk Areas
- _area needing extra attention_

---

# Step 5 - QA Review

## Test Plan

### Test Cases
| # | Scenario | Given | When | Then |
|---|----------|-------|------|------|
| 1 | Happy path | | | |
| 2 | Edge case | | | |
| 3 | Error case | | | |

### Edge Cases
- _edge case 1_
- _edge case 2_

### Acceptance Criteria
- [ ] Given _context_, when _action_, then _result_
- [ ] Given _context_, when _action_, then _result_

### Regression Checks
- _existing feature to verify_

---

# Step 6 - Security Review

## Security Status
- Reviewed: _yes/no_
- Risk level: _low/medium/high_

## Security Checklist
| Check | Status | Notes |
|-------|--------|-------|
| Input validation | _Pending_ | |
| Auth/authz | _Pending_ | |
| Data exposure | _Pending_ | |
| Injection vectors | _Pending_ | |

## Issues Found
_Pending..._

---

# Step 7 - Documentation

## Documentation Updates
| File | Change Needed |
|------|---------------|
| | |

## New Documentation Needed
_Pending..._

---

# Risk Management

## Pre-mortem (3 scenarios required)
| # | What Could Go Wrong | Likelihood | Impact | Mitigation |
|---|---------------------|------------|--------|------------|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |

## Rollback Plan
1. _step 1_
2. _step 2_

## Blast Radius
- Affected users/modules: _list_
- Feature flag: _yes/no (name)_
- Rollout strategy: _immediate/gradual/canary_

---

# Decision Log

| Date | Phase | Decision | Rationale |
|------|-------|----------|-----------|
|  | Step 0.0 | Artifact created | Starting cook flow |
```

**DO NOT:**
- Read CLAUDE.md first
- Explore codebase first
- Run any searches first
- Use Task/Explore agents first

**FIRST action = Create artifact file. No exceptions.**

---
========
>>>>>>>> feature/dry-run-validation-cook:.claude/skills/cook/SKILL.md

## Purpose
Cook features through a structured, multi-phase development flow.

The goal is not speed, but correctness, safety, and product discipline.
Every dish must be properly prepared before serving.

---

## Inputs

- **feature_description** (string, required)
  Plain-language description of the feature or change (the order).

- **instruction_file** (string, optional)
  Related specification or requirements file (the recipe).

- **mode** (enum: well-done | microwave, default: well-done)
  Determines cooking thoroughness and review phases.

- **dry-run** (boolean, default: false)
  Preview mode - shows what would happen without executing.

- **validate** (string, optional)
  Path to existing artifact to validate without re-cooking.
  Example: `/cook --validate cook/feature.cook.md`

- **no-validate** (boolean, default: false)
  Skip auto-validation after artifact generation.

- **interactive** (boolean, default: false)
  Launch interactive menu for artifact management.
  Example: `/cook --interactive`

---

## Interactive Mode

Use `--interactive` to launch the artifact management menu:

```
/cook --interactive
```

### What Interactive Mode Does

1. **Scans for artifacts** in `cook/*.cook.md`
2. **Presents a picker** with available artifacts
3. **Shows action menu**:
   - Validate artifact
   - Compare artifacts (diff)
   - View status summary
4. **Executes selected action**

### Interactive Flow

```
/cook --interactive
   |
   v
┌─────────────────────────────────────┐
│  Select artifact:                   │
│  > dry-run-validation.2026-01-10    │
│    user-auth.2026-01-09             │
│    payment-flow.2026-01-08          │
└─────────────────────────────────────┘
   |
   v
┌─────────────────────────────────────┐
│  Select action:                     │
│  > Validate                         │
│    Compare with another artifact    │
│    View status summary              │
└─────────────────────────────────────┘
   |
   v
[Executes selected action]
```

### Actions Available

| Action | Description | Command Equivalent |
|--------|-------------|-------------------|
| Validate | Run validation checks | `cook-validate ` |
| Compare | Diff two artifacts | `cook-diff  ` |
| Status | Show artifact summary | Quick view of status, mode, owner |

---

## Dry-Run Mode

Use `--dry-run` to preview the cooking process without producing artifacts.

```
/cook  --dry-run
```

### What dry-run does

1. **Checks prerequisites**
   - Is CLAUDE.md present?
   - Are project-specific chefs configured?
   - Which system chefs will be used as fallback?

2. **Shows cooking plan**
   - Lists all phases that would execute
   - Shows which chefs will be consulted
   - Identifies microwave blockers (if applicable)

3. **Validates inputs**
   - Parses feature description
   - Checks for instruction file (if specified)
   - Identifies potential issues early

### Dry-run output

```markdown
# Dry-Run: /cook preview

## Feature

## Mode
well-done | microwave

## Prerequisites Check
- CLAUDE.md: found | NOT FOUND (will use defaults)
- Project chefs:  | none (will use system chefs)
- System chefs available: 

## Cooking Plan
1. Phase 0 - Project Policy & Context
   - Chef: 
2. Step 1 - Read the Order
3. Step 2 - Ingredient Approval (well-done only)
   - Chef: product_chef
4. Step 3 - Presentation Planning (if UI changes)
   - Chef: ux_chef
5. Step 4 - Cooking
   - Chef: engineer_chef, architect_chef
6. Step 5 - Taste Testing
   - Chef: qa_chef
7. Step 6 - Safety Inspection
   - Chef: security_chef
8. Step 7 - Recipe Notes (if needed)
   - Chef: docs_chef

## Microwave Blockers (if --microwave)
-  | none

## Potential Issues
-  | none detected

## Ready to Cook
yes | no (reason: )
```

### When to use dry-run

- First time using `/cook` on a project
- Verifying chef configuration
- Checking if microwave mode is allowed
- Understanding what phases will run

---

## Cooking Modes

### well-done (default)
Full governance cooking. No shortcuts, no raw ingredients.

Cooking phases:
- Product scope check (ingredient approval)
- UX/Design review (presentation planning)
- Implementation (cooking)
- QA review (taste testing)
- Security review (safety inspection)
- Documentation (recipe notes)

Blocking allowed: YES

---

### microwave
Speed-optimized cooking for low-risk changes.

Cooking phases:
- Implementation (quick heat)
- QA review (light taste test)
- Security review (only if API/auth touched)

Blocking allowed: YES (security only)

Rules:
- No scope expansion (no adding ingredients)
- No architecture changes (no changing the recipe)
- Should be followed by well-done cooking for verification

---

## Cooking Statuses

Every feature progresses through these stages:

| Status | Meaning |
|--------|---------|
| `raw` | Feature requested, not yet evaluated |
| `cooking` | /cook in progress, review phases running |
| `blocked` | Specific blocker identified (requires owner + next step) |
| `needs-more-cooking` | Rejected, incomplete, or killed (+ reason field) |
| `well-done` | Approved and ready to implement |
| `ready-for-merge` | Post QA/Security, ready for merge |
| `plated` | Shipped to production |

**Note:** `killed` is NOT a separate status. Use `needs-more-cooking` with `reason: killed - `

---

## Microwave Blockers

Microwave mode is **BLOCKED** for these topics. Use `--well-done` instead:

- **auth / permissions / crypto / network security** - any authentication, authorization, encryption, or security-related changes
- **schema / migrations / storage** - database schema changes, migrations, storage layer modifications
- **public API contracts** - any changes to public-facing API signatures or behavior
- **UI flow changes** - even small changes to user flows or navigation
- **payments / purchase / paywall** - anything touching billing, payments, or monetization

If microwave mode is requested for a blocked topic, automatically escalate to well-done.

---

## Definition of Done

### Well-Done Mode Requirements
Reference: `~/.claude/templates/well-done-checklist.md`

**MUST include:**
- Scope definition (in/out)
- Risks + mitigations (min 3)
- Test plan (min 3 test cases)
- Security checklist (all items addressed)
- Rollout/rollback plan
- Pre-mortem (3 failure scenarios)
- Trade-offs documented
- Ownership assigned

### Microwave Mode Requirements
Reference: `~/.claude/templates/microwave-checklist.md`

**MUST include:**
- Problem statement + reproduction steps
- Minimal fix plan
- Tests (1-2)
- "Why safe" (1 sentence)
- Pre-mortem (1 failure scenario)

---

## Stop Rules (Kill Switch)

In Step 2 (Ingredient Approval), automatically set status to `needs-more-cooking` with `reason: killed` if:

1. **No measurable effect** - feature has no clear, testable outcome
2. **Risk > value** - implementation risk outweighs user benefit
3. **No owner** (well-done mode) - no one assigned as Decision Owner
4. **No testable AC** - acceptance criteria cannot be verified

When killed, document the specific reason and stop processing.

---

## MANDATORY FIRST STEP: Create Artifact File

**BEFORE ANY OTHER ACTION**, you MUST create the artifact file with skeleton structure.

### Why Artifact-First?

1. **Progress visibility** - User can see cooking progress in real-time
2. **Interrupt safety** - Partial results are preserved if execution stops
3. **Phase enforcement** - Each phase MUST write to artifact before proceeding
4. **State machine** - Artifact tracks which phases are complete

### Step 0.0 - Create Artifact Skeleton (REQUIRED)

**DO THIS IMMEDIATELY UPON /cook INVOCATION:**

1. Generate artifact filename: `cook/..cook.md`
   - `` = kebab-case of feature description (max 40 chars)
   - `` = today's date

2. Create file with this skeleton:

```markdown
# Cooking Result

## Dish

## Status
raw

## Cooking Mode

## Current Phase
Phase 0 - Starting...

---

## Phase 0 - Project Policy & Context
_Pending..._

## Step 1 - Read the Order
_Pending..._

## Step 2 - Ingredient Approval
_Pending..._

## Step 3 - Presentation Planning
_Pending..._

## Step 4 - Cooking
_Pending..._

## Step 5 - Taste Testing (QA)
_Pending..._

## Step 6 - Safety Inspection (Security)
_Pending..._

## Step 7 - Recipe Notes
_Pending..._

---

## Decision Log
| Date | Phase | Decision | Rationale |
|------|-------|----------|-----------|
```

3. **CONFIRM** artifact file exists before proceeding

**CRITICAL:** Do NOT proceed to Phase 0 until artifact file is created and confirmed.

---

## Cooking Steps

### Phase 0 - Project Policy & Context (REQUIRED)

This phase runs BEFORE scope, UX, or implementation planning. No code, no design, no solutions are allowed in this phase. Project rules override user intent.

#### Step 0.1 - Discover Project Context Files

Search for and read the following files (do not fail if missing):

**Priority order:**
1. `CLAUDE.md` - project rules and constraints
2. `POLICY.md` - explicit policies
3. `ENGINEERING.md` - engineering standards
4. `README.md` - project overview
5. `docs/**/*.md` - architecture, ADRs, decisions
6. `.claude/agents/*.md` - project-specific chefs

**Chef Resolution Order:**
1. Project-specific chefs in `/.claude/agents/`
2. System-wide chefs in `~/.claude/agents/`

**System-Wide Chefs Available:**
- `engineer.md` - Head chef (implementation)
- `product.md` - Menu curator (scope decisions)
- `designer.md` - Presentation specialist (UX/flow)
- `security.md` - Health inspector (security audit)
- `qa.md` - Taste tester (quality assurance)
- `architect.md` - Kitchen designer (architecture)
- `docs.md` - Recipe writer (documentation)

#### Step 0.2 - Extract and Normalize Rules

From discovered files, extract and classify rules into:

**A) Hard rules (MUST / MUST NOT)**
- Non-negotiable constraints
- Security, architecture, legal, platform limitations
- Explicit "do not" statements

**B) Preferred patterns**
- Recommended libraries, architectures, conventions
- Style or process preferences
- Defaults the project expects

**C) Explicit non-goals / forbidden approaches**
- Deprecated patterns
- Known bad ideas
- Things intentionally avoided

**D) Implicit assumptions (derived)**
- Assumptions inferred due to missing or unclear documentation
- MUST be clearly marked as assumptions

#### Step 0.3 - Detect Conflicts

If user request conflicts with extracted rules:
- Do NOT resolve it yet
- Do NOT propose alternatives
- Record the conflict clearly

#### Step 0.4 - Risk Classification

Based on documentation completeness, classify alignment risk:
- **LOW** - clear policies found
- **MEDIUM** - partial policies
- **HIGH** - no meaningful policies found

#### Step 0.5 - Output Format (MANDATORY)

Produce this section in the cook artifact:

```markdown
## Phase 0 - Project Policy & Context

### Sources scanned
- 

### Hard rules (must not be violated)
- 

### Preferred patterns
- 

### Explicit non-goals / forbidden approaches
- 

### Assumptions due to missing documentation
- 

### Detected conflicts with request
- None OR 

### Policy alignment risk
- LOW | MEDIUM | HIGH
```

#### Step 0.6 - Blocking Rule

If ANY of these conditions are true:
- A hard rule directly blocks the requested feature
- Alignment risk is HIGH

Then:
1. Set status: `needs-more-cooking`
2. Document the blocking reason
3. STOP - do not proceed to Step 1

The issue must be acknowledged before continuing.

This Phase 0 output informs ALL subsequent cooking steps.

#### GATE: Write Phase 0 to Artifact

**STOP. Before proceeding to Step 1, you MUST:**

1. Update artifact file - replace `_Pending..._` under `## Phase 0` with actual output
2. Update `## Current Phase` to `Phase 0 - Complete`
3. Update `## Status` to `cooking`
4. Add entry to Decision Log

**DO NOT proceed until artifact is updated.**

---

### Step 1 - Read the Order
- Restate feature in concrete terms (what dish are we making?)
- Identify affected modules/components (which stations are involved?)
- Identify risks and dependencies (allergens, timing)
- No

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [PJuniszewski](https://github.com/PJuniszewski)
- **Source:** [PJuniszewski/cook](https://github.com/PJuniszewski/cook)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-pjuniszewski-cook-cook
- Seller: https://agentstack.voostack.com/s/pjuniszewski
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.