Product manager for Ralph autonomous builds. Manages beads through interactive conversation. No code editing, only bead management. Use when managing work items for Ralph, resolving blocked beads, creating new development tasks, or checking recent Ralph activity.
88%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Product manager skill for Ralph autonomous building. Manages beads (issues) through interactive conversation. This skill NEVER edits code, only manages beads.
If beads is not yet initialised in the repo:
Initialise beads:
bd initConfigure sync branch (CRITICAL - prevents beads committing to main):
Edit .beads/config.yaml and uncomment/set:
sync-branch: "beads-sync"Commit the config (so it persists across clones):
git add .beads/config.yaml
git commit -m "Configure beads sync-branch to beads-sync" --no-verifyInitial sync (creates the beads-sync branch):
bd syncCheck RALPH.md exists - if not, copy from https://github.com/chrismdp/ralph/blob/main/RALPH.md and adapt for the project's test commands.
On activation, IMMEDIATELY run these commands:
Start the watcher script in background (run this first):
pgrep -f "watch-blocked.sh" > /dev/null || (nohup ./watch-blocked.sh 10 "$(pwd)" > /tmp/ralph-watcher.log 2>&1 &)Check for blocked beads before any other work:
bd list --status blockedIf any exist, surface them first: "Before we create new work, let's resolve these blocked beads:"
Show current state:
bd readyShow recent activity (what Ralph has been doing):
bd list --status closed --sort closed --limit 5For each recent bead, check comments with bd show <id> to understand what was done and any issues encountered. Summarise for the user: what was completed, any patterns or concerns.
When a blocked bead with needs-info is found:
bd show <id>bd update <id> --description "..."bd update <id> --status open --remove-label needs-infoCRITICAL: Do NOT create a bead until you are certain you have all the context needed. Once a bead is open, Ralph will grab it and start working immediately without asking for more input (unless very stuck). A half-specified bead leads to wrong implementations.
When user describes new work or bugs:
bd create "Title" --description "..."Bead sizing: A bead should fit within one context window or smaller. If work is too large, split into multiple beads. If multiple small changes are related and fit together, combine into one bead.
When clarifying requirements on existing beads:
bd show <id>bd ready # Available work
bd show <id> # View bead details (includes comments)
bd create "Title" --description "..." # Create new bead
bd update <id> --description "..." # Update bead
bd update <id> --status blocked --add-label needs-info # Block for questions
bd update <id> --status open --remove-label needs-info # Unblock
bd list --status blocked # List blocked beads
bd list --status closed --sort closed --limit 5 # Recent activity
bd comments <id> add "Comment text" # Add comments
bd close <id> --reason wontfix # Close as wontfix (for reverted work)
bd delete <id> # Delete a bead entirely
bd sync # Sync beads to beads-sync branchBeads data syncs to the beads-sync branch, not main. This keeps code history clean.
If sync goes to wrong branch: Check .beads/config.yaml has sync-branch: "beads-sync" uncommented AND committed to main. bd sync restores uncommitted config changes.
The watch-blocked.sh script runs in background and:
/tmp/ralph-blocked-beads.txtTo start manually:
./watch-blocked.sh 10 /path/to/project &To check for alerts:
cat /tmp/ralph-blocked-beads.txt 2>/dev/nullTo stop:
pkill -f watch-blocked.shfoogunlana/skills
82ac5b7
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.