| name | sybra-plan |
| description | Interactive operator planning for a Sybra task when a human explicitly asks to plan or replan in chat. Do not use for workflow-dispatched plan/review/test/implementation agents or prompts that already contain stage instructions. |
| allowed-tools | Bash, Read, Glob |
| user-invocable | true |
| disable-model-invocation | true |
Sybra Task Planning
Produce a detailed implementation plan for a task. Do NOT implement, write code, create files, or make changes.
Only run when a human/operator explicitly invokes this skill in chat. Never use it inside workflow-dispatched plan/review/test/implementation agents; those prompts already carry their own stage contract.
You run inside an interactive tmux session. After producing a plan you STAY at the prompt and wait for feedback from the user — you never exit.
CLI Reference
The ONLY valid flags for sybra-cli update are: --title, --status, --body, --plan, --plan-file, --mode, --tags, --project. Do NOT use any other flag.
Process
1. Read the task
sybra-cli --json get <id>
2. Analyze scope
- Read the task body, understand what's being asked
- If URLs are referenced, fetch context with
gh for GitHub or curl for public pages when available.
- Explore the codebase: find relevant files, understand existing patterns
- Identify dependencies and potential risks
- Triviality check — if the task is a typo / single-line / mechanical rename / single-file edit with no design choices, skip persona-driven planning and jump straight to Step 5 with the plan written directly.
3. Auto-select 2-3 personas
Default: 2 personas. Bump to 3 when:
- Two-surface task (eng + UX), or
- Refactor / cross-cutting / "complex" framing, or
- Best-fit shortcut group has 3 distinct lenses.
Always include one bias-correction persona (antirez, tef, hebert, meadows, chin, norman, nielsen, watson) unless the task is a narrow specialist audit. Avoid duplicate lenses — if two personas push for the same thing, keep the sharper domain fit.
Selection shortcuts:
- code-style / refactor: antirez + tef + muratori
- reliability / failure / ops: hebert + meadows + tef
- perf hot path: muratori + tef + antirez
- types / parsing / data validation: king + tef + antirez
- testing strategy: test-architect + hughes + chin
- domain modeling / bounded contexts: evans + king + meadows
- backend feature (default): antirez + hebert + tef
- UI feature: norman + krug + nielsen
- accessibility / WCAG: watson + norman + nielsen
- two-surface (eng + UX): antirez + tef + norman
Persona roster:
| Persona | Lens | Pushes for | Refuses |
|---|
| antirez | simplicity, design sacrifice | smallest plan that works, sharp scope cuts | over-abstraction, bloat |
| tef | deletability, anti-DRY, protocol over topology | code easy to throw away | premature shared abstractions |
| muratori | semantic compression, perf-from-day-one | data layout, hot path | Clean Code-style fragmentation |
| hebert | operability, supervision, controlled-burn | named failure modes, supervision boundaries | hidden coupling |
| meadows | systems, leverage points, feedback loops | feedback loops surfaced, stocks/flows | local optimization |
| chin | tacit knowledge, NDM | situational fit, empirical recipes | rigid frameworks |
| king | parse don't validate, totality | illegal states unrepresentable | runtime checks for type problems |
| evans | DDD, ubiquitous language, bounded contexts | clear context boundaries | cross-context bleed |
| test-architect | FCIS, tests as design pressure | functional core boundaries | tests that lock implementation |
| hughes | property-based testing, generators | properties + shrinking | example-only suites |
| norman | affordances, mental models | discoverability, error modes | hidden state |
| krug | trunk test, "don't make me think" | label clarity, scan-ability | clever interactions |
| nielsen | 10 heuristics, severity rating | consistency, error prevention | unscored issues |
| watson | a11y, screen reader, WCAG | semantic markup, focus order | visual-only signaling |
Announce the selection in one short line before spawning:
Auto-selected <p1> + <p2> [+ <p3>] because <one-line evidence>.
4. Spawn N×2 planners in parallel (Claude + Codex per persona)
For each selected persona, fire two Bash calls in parallel — one claude -p and one codex exec. All planners (personas × providers) launch in one tool-use block with run_in_background: true. Total: 4 calls (2 personas) or 6 calls (3 personas).
Output sink:
PLAN_DIR=$(mktemp -d -t sybra-plan-XXXX)
echo "$PLAN_DIR"
Persona brief template (substitute per persona before writing to file):
You are <persona-name> (<short identity>).
Your lens: <one-line philosophy from roster above>.
You push for: <2-3 specifics from roster>.
You refuse: <1-2 specifics from roster>.
Background:
- Task: <verbatim body from sybra-cli get>
- Files explored: <paths from Step 2>
- Relevant patterns / utilities: <list with paths>
Write a detailed implementation plan strictly through your lens.
- List critical files to modify (paths).
- Step-by-step implementation order.
- Name what you would cut and what you would refuse.
- No hedging. Disagree with the safe path if your lens says so.
Output a self-contained plan. End with marker line: ---END-PLAN---.
Write each persona brief to $PLAN_DIR/<persona>-prompt.txt, then for each persona issue two Bash tool calls (both with run_in_background: true):
Claude wrapper:
claude -p --output-format text < "$PLAN_DIR/<persona>-prompt.txt" \
> "$PLAN_DIR/<persona>-claude.md" 2>&1
Codex wrapper:
codex exec --sandbox read-only --skip-git-repo-check - \
< "$PLAN_DIR/<persona>-prompt.txt" \
> "$PLAN_DIR/<persona>-codex.md" 2>&1
read-only sandbox forbids file writes — Codex outputs only to stdout. If a planner fails (auth issue, timeout, empty output), skip it during synthesis rather than aborting; note the gap in Tradeoffs.
Wait for all backgrounded calls to complete (tool-call notifications fire on completion). Do not synthesize until every spawn has settled.
5. Synthesize one final plan
Read all $PLAN_DIR/*.md outputs. For each, extract content up to the ---END-PLAN--- marker (strip CLI chatter / tool-use lines that may precede the plan body).
Write the final plan with sections:
## Approach
Recommended path. Spine drawn from cross-provider, cross-persona convergence.
## Files to Change
- `path/to/file.go` — what changes and why
- `path/to/other.go` — what changes and why
## Steps
1. First step — details
2. Second step — details
3. ...
## Tradeoffs
Persona axis:
- <p1> wanted X, <p2> wanted Y. Chose X because <one-line reason>.
Provider axis (only when notable):
- On <persona>, claude proposed X while codex proposed Y. Chose X because <reason>.
## Risks
- Risk 1 and mitigation
- Risk 2 and mitigation
Convergence priority:
- Same persona, different providers agreeing = strong signal (use as spine).
- Different personas, same provider agreeing = weaker signal.
- Disagreements surface in Tradeoffs with a one-line rationale for the chosen side.
6. Publish the plan + hand off for review
sybra-cli --json update <id> --plan "<full plan markdown>"
sybra-cli --json update <id> --status plan-review
Then STOP and wait at the chat prompt. Do NOT exit. Do NOT implement.
7. Respond to feedback
The user may send feedback in the same chat session. When feedback arrives:
- Read it carefully
- Revise the plan in-place (do NOT re-spawn personas unless feedback substantially shifts scope)
sybra-cli --json update <id> --plan "<revised plan>"sybra-cli --json update <id> --status plan-review- Wait again
Guidelines
- Be specific: name files, functions, types
- Keep it actionable — each step should be implementable
- Note existing patterns to follow
- Flag anything ambiguous that needs human input
- Do NOT write code, create files, or make any changes
- Do NOT exit after publishing the plan — keep the session alive for review rounds
Input: Task `task-abc` body: "Add rate limiting to /api/login endpoint, 5 req/min per IP".
Step 3 announce: Auto-selected antirez + hebert because backend feature with reliability concerns.
Step 4: 4 parallel Bash calls (antirez+claude, antirez+codex, hebert+claude, hebert+codex), run_in_background: true, outputs to a temp dir.
Step 5 synthesized plan:
## Approach
Token bucket middleware keyed by client IP, reusing existing `internal/middleware`.
## Files to Change
- `internal/middleware/ratelimit.go` — new, token bucket implementation
- `internal/middleware/ratelimit_test.go` — new, table-driven tests
- `cmd/api/main.go` — wire middleware into `/api/login` route
## Steps
1. Add `golang.org/x/time/rate` to go.mod
2. Implement `NewIPLimiter(rps, burst)` returning `func(http.Handler) http.Handler`
3. Write tests: allow / deny / reset scenarios
4. Wire into login route in main.go
## Tradeoffs
Persona axis:
- antirez wanted in-memory map (smallest), hebert wanted LRU eviction. Chose LRU because unbounded map is a documented failure mode under sustained scan traffic.
## Risks
- Behind proxy: read `X-Forwarded-For`, trust only proxy CIDR range
- Memory growth: LRU cap 10k entries
Then publish + wait.
Input: User feedback "also add metrics for blocked requests".
Action: Revise Steps to add prometheus counter, re-publish plan, set status plan-review, wait. Do NOT re-spawn personas — feedback is additive, not scope-shifting.
