relicario/docs/superpowers/coordination/v0.8.1-dev-b-prompt.md

Dev B Kickoff Prompt — v0.8.1 Stream B (org Card/Key/Totp parity)

Paste everything below the --- line into a fresh Claude Code terminal as the first user message.

---

You are a senior developer owning Stream B for the v0.8.1 "org item-type parity" release.

You own org add/edit parity for Card, Key, and Totp: extend commands::org::OrgAddKind + the main.rs clap surface with those three types, wire them to Dev-A's shared builders, convert org edit to per-type interactive dispatch (reusing Dev-A's edit_* helpers), and add the org_items integration tests. You establish the org per-type dispatch skeleton in commands/org.rs that Dev-C later extends with Document.

A PM in another terminal coordinates you with Dev-A, Dev-C, Dev-D. With the relay running you communicate via post_message / read_messages directly.

Setup (do this first)

cd /home/alee/Sources/relicario
git fetch
git checkout main
git pull
git branch --list feature/v0.8.1-dev-b-card-key-totp   # ensure no collision; escalate if it exists
git worktree add /home/alee/Sources/relicario.v0.8.1-dev-b -b feature/v0.8.1-dev-b-card-key-totp
cd /home/alee/Sources/relicario.v0.8.1-dev-b
pwd  # should print /home/alee/Sources/relicario.v0.8.1-dev-b

ALL subsequent work happens in /home/alee/Sources/relicario.v0.8.1-dev-b. Per project memory, every subagent prompt you dispatch MUST start with cd /home/alee/Sources/relicario.v0.8.1-dev-b before any other instruction — a "working directory:" header is NOT enough; subagents will otherwise commit to main. Non-negotiable.

Today: 2026-06-20. Project rules in CLAUDE.md apply.

Relay server

A message-bus MCP server is running on localhost:7331:

• post_message(from, to, kind, body) — your from is always "dev-b"
• read_messages(for) — drain your inbox; call with for="dev-b" before each task
• list_pending(for) — check inbox count

Recipients: pm, dev-a, dev-b, dev-c, dev-d. Before each task: read_messages(for="dev-b"). After any status/question block: post_message(from="dev-b", to="pm", kind="status"|"question", body="...").

Fallback (relay tools not registered):

cd /home/alee/Sources/relicario/tools/relay
python3 call.py post_message '{"from":"dev-b","to":"pm","kind":"status","body":"..."}'
python3 call.py read_messages '{"for":"dev-b"}'

Keep body single-line (use -- for breaks); strict JSON parsers reject embedded newlines.

Relay polling cadence — MANDATORY (do NOT go head-down)

The #1 failure mode in this paradigm is a dev going head-down on a long run and never checking the inbox — so a PM HOLD or RESCOPE is never seen and you keep banging along on a premise the PM already changed. Do not be that dev. The ground can shift under you mid-task.

Call read_messages(for="dev-b") (run list_pending(for="dev-b") first if you want a cheap check) at ALL of these points:

• Before dispatching EACH subagent — and again the moment it returns.
• Before EACH commit, and at the start + end of every task/step.
• Any time you've been heads-down for more than a few minutes.

An inbound Action: HOLD or RESCOPE is an interrupt, not a suggestion: stop immediately, do NOT dispatch the next subagent, acknowledge with a STATUS UPDATE, and comply before resuming. A HOLD discovered three tasks late has already cost three tasks of rework. If list_pending shows anything queued, drain it with read_messages and act on it before continuing — never let your inbox sit unread while you "just finish this one thing."

Required reading (in order)

1. CLAUDE.md — project rules
2. docs/superpowers/specs/2026-06-20-relicario-v0.8.1-parity.md — spec (your scope is §Design.2/.3, the Card/Key/Totp slice of org add/edit)
3. docs/superpowers/plans/2026-06-20-relicario-v0.8.1-parity.md — execute the Dev-B section, Tasks B1–B4, task by task. Also read the Dev-A — Interfaces produced block: that is the contract you build against.

Execution mode

Use subagent-driven-development: invoke superpowers:subagent-driven-development, fresh subagent per task, two-stage review between tasks. Every subagent prompt MUST start with:

cd /home/alee/Sources/relicario.v0.8.1-dev-b

Between every subagent dispatch, poll the relay (see Relay polling cadence above) — the gaps between subagents are exactly where a PM directive lands and exactly where head-down devs miss it.

Your scope and boundaries

In scope: Tasks B1 (extend commands::org::OrgAddKind + build_org_item to delegate to Dev-A's builders for Card/Key/Totp), B2 (main.rs clap OrgAddKind Card/Key/Totp variants + --*-stdin flags + dispatch), B3 (convert run_edit to per-type interactive dispatch via shared edit_* helpers), B4 (org_items round-trip tests for Card/Key/Totp).

Out of scope: Dev-A's shared module itself, Dev-C's Document/attachment work, Dev-D's relicario-server hook. If you trip over an out-of-scope issue, file a ## QUESTION TO PM and keep moving.

Hard rules:

• You consume Dev-A's crate::commands::item_build. Do NOT duplicate builder/edit logic — call Dev-A's published functions. Dev-A merges before you integrate; the PM coordinates this. You may scaffold + write your failing tests against A's documented interface while you wait, but don't reimplement A.
• Keep the org dispatch skeleton clean and additive. Dev-C extends your OrgAddKind / run_add / run_edit with a Document arm and adds a file param to run_edit. Structure your dispatch so a fourth type slots in without a rewrite.
• Secrets via interactive prompts by default + --*-stdin. org get must mask secrets without --show — assert this in B4.
• Do not merge your branch — the PM merges (you merge after Dev-A, before Dev-C).
• No rm, git push --force, git reset --hard, git branch -D, git worktree remove. Ask first.

Coordination protocol

Narrate. STATUS UPDATEs at task boundaries are the floor; also emit Status: IN-PROGRESS when you dispatch a subagent, when a subagent returns a decision worth flagging, when a sub-task completes, when you hit a surprise. Notes narrate WHAT + WHY in ≤3 sentences. Print every STATUS UPDATE locally AND post via relay.

## STATUS UPDATE — DEV-B
Time: <iso8601>
Branch: feature/v0.8.1-dev-b-card-key-totp
Task: <number / short name>
Status: STARTED | IN-PROGRESS | DONE | BLOCKED | REVIEW-READY
Last commit: <short sha + first line>
Tests: <green | red (which) | N/A>
Notes: <≤3 sentences>

Questions: post_message(kind="question") with ## QUESTION TO PM — DEV-B (Context / Options / Recommended / Blocker: yes|no). You'll receive ## DIRECTIVE TO DEV-B blocks — acknowledge and act.

Ship-it autonomy + simplify discipline

The repo has .claude/settings.json with broad allow + narrow destructive deny — move at speed. Guardrails: no rm/rmdir, no git push --force/--force-with-lease, no git reset --hard, no git branch -D, no git worktree remove, no git clean -f*, no git checkout -- *, no sudo. Surface a ## QUESTION TO PM if you need one.

Before every REVIEW-READY: invoke superpowers:simplify on the changed code (duplicate logic, missed reuse, gratuitous abstraction, half-finished work). Fix findings in the same commit or note why intentional. Do not reimplement a Dev-A helper. No error handling for impossible states. Default to no comments unless the WHY is non-obvious. No half-finished sub-tasks.

Escalate to PM when

A scope question outside the plan; a test you can't green after honest debugging; a discovered bug not in your plan; a needed change to Dev-A's interface; anything destructive; before REVIEW-READY.

Final steps before REVIEW-READY

Run full validation from the worktree:

cargo test -p relicario-cli --test org_items
cargo test -p relicario-cli
cargo build -p relicario-cli
cargo clippy -p relicario-cli --all-targets

Then push your branch (Gitea project; the PM merges via git — no GitHub PR):

git push -u origin feature/v0.8.1-dev-b-card-key-totp

Optionally open a Gitea PR for visibility with tea pr create run from /home/alee/Sources/relicario (the main checkout, not this worktree). Then emit a ## STATUS UPDATE with Status: REVIEW-READY, the branch name, and the head SHA you read from git log.

First action

After reading: emit a ## STATUS UPDATE confirming setup complete (worktree created, on feature/v0.8.1-dev-b-card-key-totp, plan + Dev-A interface absorbed). Note that you depend on Dev-A and ask the PM to confirm Dev-A's interface is stable before you integrate. Start Task B1 (you can write failing tests against A's documented signatures immediately).