Flow-Next — Prompts
Verbatim Excerpt 1: flow-next-plan SKILL.md (Plan Role + No-Implementation Rule)
---
name: flow-next-plan
description: Create structured build plans from feature requests or Flow IDs...
user-invocable: false
---
## The Golden Rule: No Implementation Code
**Plans are specs, not implementations.** Do NOT write the code that will be implemented.
### Code IS allowed:
- **Signatures/interfaces** (what, not how): `function validate(input: string): Result`
- **Patterns from this repo** (with file:line ref): "Follow pattern at `src/auth.ts:42`"
- **Recent/surprising APIs** (from docs-scout): "React 19 changed X — use `useOptimistic` instead"
- **Non-obvious gotchas** (from practice-scout): "Must call `cleanup()` or memory leaks"
### Code is FORBIDDEN:
- Complete function implementations
- Full class/module bodies
- "Here's what you'll write" blocks
- Copy-paste ready snippets (>10 lines)
**Why:** Implementation happens in `/flow-next:work` with fresh context. Writing it here wastes tokens in planning, review, AND implementation — then causes drift when the implementer does it differently anyway.
Prompting technique: Explicit "code IS allowed / FORBIDDEN" table with forbidden items listed as concrete examples. The "Why" rationale section makes the rule self-enforcing: the model understands the token-efficiency reason, not just the rule.
Verbatim Excerpt 2: worker agent (Re-Anchor Phase)
---
name: worker
description: Task implementation worker. Spawned by flow-next-work to implement a single task...
model: inherit
disallowedTools: Task
color: "#3B82F6"
---
## Phase 1: Re-anchor (CRITICAL - DO NOT SKIP)
Use the FLOWCTL path and IDs from your prompt:
```bash
# 1. Read task and parent specs (substitute actual values)
<FLOWCTL> show <TASK_ID> --json
<FLOWCTL> cat <TASK_ID>
<FLOWCTL> show <SPEC_ID> --json
<FLOWCTL> cat <SPEC_ID>
# 2. Check git state
git status
git log -5 --oneline
# 3. Check memory system
<FLOWCTL> config get memory.enabled --json
If memory.enabled is true, query relevant memory via the CLI (not by reading files directly)...
**Prompting technique:** "Re-anchor" pattern forces every worker to re-read full spec context before implementing. The `disallowedTools: Task` declaration prevents worker subagents from spawning further sub-subagents (depth control). CLI-mediated state access (`<FLOWCTL> show`) enforces the metadata/narrative separation at the prompt level.
---
## Verbatim Excerpt 3: `hooks.json` (Ralph Guards)
```json
{
"description": "Ralph workflow guards - only active when FLOW_RALPH=1 and ralph-init has been run",
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|Execute",
"hooks": [{
"type": "command",
"command": "[ ! -f scripts/ralph/hooks/ralph-guard.py ] || scripts/ralph/hooks/ralph-guard.py",
"timeout": 5
}]
}
],
"Stop": [
{
"hooks": [{
"type": "command",
"command": "[ ! -f scripts/ralph/hooks/ralph-guard.py ] || scripts/ralph/hooks/ralph-guard.py",
"timeout": 5
}]
}
]
}
}
Design pattern: Guard-via-file-existence — the hook only activates if ralph-guard.py exists (i.e., after ralph-init has run). Non-intrusive for users who don't use Ralph. The guard reads FLOW_RALPH=1 env var at runtime.