WORKFLOW_AUTO.md
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.
Core Principle
Fresh context per task. Structured prompts. Verify before reporting success.
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 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
## Phase 1: {Name} [✅ DONE | 🔄 IN PROGRESS | ⏳ TODO]
- Dependencies: none
- Tasks: ...
## Phase 2: {Name} [status]
- Dependencies: Phase 1
- Tasks: ...
# 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
MANDATORYLessons 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
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>
Wave Execution Protocol
Before spawning multiple sub-agents, map dependencies and group into waves for parallel execution.
-
1
List all tasks needed for the phase
-
2
Map dependencies — which tasks depend on others?
-
3
Group into waves: independent tasks in parallel, dependent tasks after
-
4
Respect the 5-agent limit — max 5 concurrent sub-agents per session
-
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)
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.
Map-Codebase Protocol
When starting work on an existing codebase, run 4 parallel analyses before touching anything.
Stack Mapper
Languages, frameworks, versions, dependencies
→ docs/codebase/STACK.md
Architecture Mapper
File structure, patterns (MVC/microservices/etc), data flow
→ docs/codebase/ARCHITECTURE.md
Convention Mapper
Naming patterns, code style, error handling patterns
→ docs/codebase/CONVENTIONS.md
Concern Mapper
Tech debt, security issues, performance bottlenecks, red flags
→ docs/codebase/CONCERNS.md
Post-Completion Protocol
MANDATORYExecute EVERY time, BEFORE reporting success. No exceptions.
Checklist (in order)
Notion — Document what was done
Document in the relevant Notion page. For new projects, create page under Clawdbot root.
Git — Commit + Push
Descriptive commit message. Push if code changed.
Memory — Update daily log
Update memory/YYYY-MM-DD.md with what happened.
What counts as "significant"
"If I wake up tomorrow with zero memory, would I know this happened?" — If NO, you forgot to document. Go back and do it.
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.mdwith raw events - → Long-term:
MEMORY.mdwith curated insights - → Per-project:
STATE.mdfor project-specific state
When context is getting heavy (>50%):
- Save important state to files
- Trigger "dale con la escoba" (context cleanup)
- Resume from saved state
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.
Knowledge Capture — Skill Updates
MANDATORYAny reusable knowledge discovered during a task must be persisted — not just in session memory.
Decision tree after every debug/integration task
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
Gotcha from a third-party API (Notion, Telegram, Firebase)?
chub annotate <id> "description" — if important enough, also edit or create a SKILL.md
Architecture decision or project preference?
memory/YYYY-MM-DD.md + MEMORY.md if long-term. NOT in skills (skills are cross-project reusable).
Project-specific context?
projects/{name}/STATE.md or PROJECT.md. NOT in global skills.
Knowledge Destination Map
| Finding Type | Destination |
|---|---|
| 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 preference | MEMORY.md |
| Session lesson | memory/YYYY-MM-DD.md |
| Current project state | projects/{name}/STATE.md |
| Reusable technical pattern | WORKFLOW_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
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_sendfor 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
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