N
Nix Workflow Framework

WORKFLOW_AUTO.md

Open Framework · Free to use

Nix Workflow Framework

A structured execution framework for AI agents — born from 25+ days of real-world orchestration. Covers project structure, sub-agent spawning, verification protocols, and knowledge capture.

10 Sections
Ready-to-use Templates
Battle-tested

Core Principle

Fresh context per task. Structured prompts. Verify before reporting success.

1

Project Structure Standard

Every project in projects/ SHOULD have a consistent directory layout with four key files.

projects/{name}/
├── PROJECT.md       # Vision, scope, stack, constraints
├── ROADMAP.md       # Phases with dependencies and status
├── STATE.md         # Current position, decisions, blockers
├── docs/            # Analysis, specs, diagrams
└── ...code...
PROJECT.md
# {Project Name}
## Vision: One-line description
## Stack: Languages, frameworks, hosting
## Constraints: Budget, hosting limits, timeline
## Scope v1: What's included
## Scope v2: What's deferred
## Links: Repo, production URL, Notion
ROADMAP.md
# Roadmap
## Phase 1: {Name} [✅ DONE | 🔄 IN PROGRESS | ⏳ TODO]
- Dependencies: none
- Tasks: ...
## Phase 2: {Name} [status]
- Dependencies: Phase 1
- Tasks: ...
STATE.md
# State — Last updated: {date}
## Current Phase: {N}
## Current Task: {description}
## Decisions Made: (list of key decisions with rationale)
## Blockers: (anything blocking progress)
## Next Action: (exactly what to do next)
!

Claude Code — Launch Protocol

MANDATORY

Lessons from 4 dead sub-agents on Mar 2, 2026.

Required Flags

claude --dangerously-skip-permissions "Your task"

The PTY Bypass Warning Problem

Even with --dangerously-skip-permissions, Claude Code shows an interactive prompt in PTY:

WARNING: Claude Code running in Bypass Permissions mode
❯ 1. No, exit        ← DEFAULT SELECTED
  2. Yes, I accept

Proven Solution

After launching with pty:true background:true:

# 1. Wait 5s
process poll timeout:5000

# 2. Send Down + Enter SEPARATELY (not together)
process send-keys sessionId:XXX keys:["Down"]
process poll timeout:1000   # wait for cursor move
process send-keys sessionId:XXX keys:["Enter"]

# 3. Verify it started working
process poll timeout:10000  # look for "Reading" or "thinking"

Post-Launch Monitoring

DO

  • ✓ First 10s: Verify bypass prompt passed
  • ✓ Every 5 min: Poll to verify still alive
  • ✓ If dies without event: Relaunch IMMEDIATELY

ANTI-PATTERNS

  • ✗ Launch and forget until user asks
  • ✗ Send Down+Enter together
  • ✗ Launch without --dangerously-skip-permissions
  • ✗ Assume bypass prompt won't appear
2

Sub-Agent Prompt Template (XML-Structured)

When spawning sub-agents, use this XML structure for clarity and consistency.

<task type="auto">
  <name>{Clear task name}</name>
  <context>{What the agent needs to know — project state, prior decisions}</context>
  <files>{Specific files to read/modify}</files>
  <action>
    {Step-by-step instructions. Be explicit about:}
    - What to create/modify
    - What patterns to follow
    - What to avoid
  </action>
  <verify>
    {How to confirm it works:}
    - Command to run
    - Expected output
    - Edge cases to test
  </verify>
  <done>
    {Definition of done — what success looks like}
  </done>
  <commit>{Commit message format}</commit>
</task>
<name> Clear identifier
<context> Minimal necessary context
<verify> Never skip verification
<done> Explicit success definition
3

Wave Execution Protocol

Before spawning multiple sub-agents, map dependencies and group into waves for parallel execution.

  1. 1
    List all tasks needed for the phase
  2. 2
    Map dependencies — which tasks depend on others?
  3. 3
    Group into waves: independent tasks in parallel, dependent tasks after
  4. 4
    Respect the 5-agent limit — max 5 concurrent sub-agents per session
  5. 5
    Track in STATE.md — update after each wave completes
# Example dependency graph:
Wave 1 (parallel):   Backend models, Seed data script
Wave 2 (parallel):   API routes (needs models), Frontend pages
Wave 3 (sequential): Integration tests (needs everything)
4

Auto-Verify Protocol

After EVERY task/sub-agent completion, run the appropriate verification checklist.

Backend Changes

  • → Hit the API endpoints (curl/fetch)
  • → Check response codes and data shape
  • → Verify no regressions on existing endpoints

Frontend Changes

  • → Build succeeds (npm run build)
  • → Browser screenshot shows expected UI
  • → No console errors

Data Migrations

  • → Row counts match expectations
  • → Referential integrity (0 orphans)
  • → Spot-check 3–5 random records

Deploy

  • → Production URL returns 200
  • → Test critical user flow end-to-end
  • → Check error logs

If verification fails:

Don't report success. Create a fix plan and either fix it (if small) or spawn a fix sub-agent with the error context.

5

Map-Codebase Protocol

When starting work on an existing codebase, run 4 parallel analyses before touching anything.

S

Stack Mapper

Languages, frameworks, versions, dependencies

→ docs/codebase/STACK.md
A

Architecture Mapper

File structure, patterns (MVC/microservices/etc), data flow

→ docs/codebase/ARCHITECTURE.md
C

Convention Mapper

Naming patterns, code style, error handling patterns

→ docs/codebase/CONVENTIONS.md
X

Concern Mapper

Tech debt, security issues, performance bottlenecks, red flags

→ docs/codebase/CONCERNS.md
6

Post-Completion Protocol

MANDATORY

Execute EVERY time, BEFORE reporting success. No exceptions.

Checklist (in order)

1

Notion — Document what was done

Document in the relevant Notion page. For new projects, create page under Clawdbot root.

2

Git — Commit + Push

Descriptive commit message. Push if code changed.

3

Memory — Update daily log

Update memory/YYYY-MM-DD.md with what happened.

What counts as "significant"

Any feature/fix/module completed Any deployment Any OpenClaw update New project/tool configured Any migration or data operation Any research/analysis delivered
"If I wake up tomorrow with zero memory, would I know this happened?" — If NO, you forgot to document. Go back and do it.
7

Context Management

Prevent Context Rot

  • → Sub-agents get ONLY the context they need (not entire conversation)
  • → Include: PROJECT.md + relevant STATE.md + specific files
  • ✗ Exclude: Unrelated conversation, old debug sessions, other projects

Memory Saves

  • → Daily: memory/YYYY-MM-DD.md with raw events
  • → Long-term: MEMORY.md with curated insights
  • → Per-project: STATE.md for project-specific state

When context is getting heavy (>50%):

  1. Save important state to files
  2. Trigger "dale con la escoba" (context cleanup)
  3. Resume from saved state
8

Decision Log

Every significant decision should be recorded with context to survive future memory loss.

What

The decision made

Why

The reasoning behind it

Alternatives

What was considered and rejected

Date

When it was decided

Store in STATE.md for project decisions, MEMORY.md for cross-project decisions.

9

Knowledge Capture — Skill Updates

MANDATORY

Any reusable knowledge discovered during a task must be persisted — not just in session memory.

Decision tree after every debug/integration task

1

Found a gotcha/workaround in a tool or system?

Update relevant skill → chub get nixclawd/<skill> — if no skill exists, create ~/clawd/skills/<name>/SKILL.md

2

Gotcha from a third-party API (Notion, Telegram, Firebase)?

chub annotate <id> "description" — if important enough, also edit or create a SKILL.md

3

Architecture decision or project preference?

memory/YYYY-MM-DD.md + MEMORY.md if long-term. NOT in skills (skills are cross-project reusable).

4

Project-specific context?

projects/{name}/STATE.md or PROJECT.md. NOT in global skills.

Knowledge Destination Map

Finding TypeDestination
Gotcha in a tool/system (OpenClaw, Telegram, launchd...)~/clawd/skills/ + ~/.claude/skills/
Gotcha in a third-party API (Notion, Firebase, Stripe...)chub annotate <id> + skill if recurring
Architectural decision / Manuel's preferenceMEMORY.md
Session lessonmemory/YYYY-MM-DD.md
Current project stateprojects/{name}/STATE.md
Reusable technical patternWORKFLOW_AUTO.md

How to Update an Existing Skill

# 1. View the current skill
chub get nixclawd/<name>

# 2. Edit SKILL.md — add finding in "Known Gotchas" section
edit ~/clawd/skills/<name>/SKILL.md

# 3. Bump revision in frontmatter (revision: N → N+1) and updated-on
# 4. Update date in registry.json
python3 -c "
import json
from datetime import date
r = json.load(open('/Users/macdenix/clawd/skills/registry.json'))
for s in r['skills']:
    if s['id'] == 'nixclawd/<name>':
        s['lastUpdated'] = str(date.today())
        break
json.dump(r, open('/Users/macdenix/clawd/skills/registry.json','w'), indent=2)
print('Registry updated')
"

# 5. Sync to ~/.claude/skills/ for future sessions
cp ~/clawd/skills/<name>/SKILL.md ~/.claude/skills/<name>/SKILL.md
10

Sub-Agent Communication Improvements

10.1 Async Webhooks (vs Polling)

Problem: Watchdog polls every 5 min — burns tokens and time. Solution: Callback pattern where sub-agent notifies orchestrator on completion.

  • → Sub-agents already auto-announce completion (push-based) — leverage this
  • → Reduce watchdog to "safety net" every 15–30 min, not the main mechanism
  • → Watchdog only detects agents that died silently
  • → For long tasks: use sessions_send for progress updates

10.2 Critic Pattern (Multi-Model Validation)

When a model generates critical output (categorization, parsing, data), a second cheaper model validates.

Generator

Sonnet / Llama 3.3

Does the heavy lifting

Critic

Scout / Groq

Validates format & coherence

Use when: Data pipelines, HTML parsing, output going directly to DB
Skip when: Simple code tasks where compiler/tests already validate

10.3 Few-Shot Prompting Standard

For any classification/categorization task with an LLM:

  • → Minimum 3–4 labeled examples in the prompt
  • → Examples must cover edge cases (ambiguous categories)
  • → Include a "not classifiable" example if applicable
  • → Measure accuracy before/after to justify the extra token cost

10.4 Structured Output (JSON Mode)

Whenever an LLM generates output that will be parsed programmatically:

// Use JSON mode in Groq
response_format: { type: "json_object" }

// Always define the expected schema in the prompt
// Validate with JSON schema before processing
// Fallback: regex extraction if JSON mode fails

Framework v1.1 — Mar 2, 2026

v1.0: Feb 18, 2026 — Inspired by GSD + 25 days of real-world orchestration

v1.1: Mar 2, 2026 — Added async webhooks, critic pattern, few-shot & structured output