2 Research Community Patterns
jbr870 edited this page 2026-04-30 10:12:29 +00:00
Status Last updated Parent Read before this
complete 2026-04-30 none none

Community Patterns

External patterns devwork-skills draws on or has explicitly considered.

Current state

Ralph Wiggum loop. A community-originated bash pattern for autonomous iteration: keep an agent running until a stop condition is genuinely met, rather than letting it declare done at the first plausible stopping point. Now distributed as a Claude Code plugin. devwork-skills uses it inside /develop (one Ralph-enabled Test Writer + Implementer pair per work unit) and as a prerequisite for Agent Teams to be reliable. See Role - Coding Harness Agents.

obra/superpowers. A repository of battle-tested Claude Code skills with patterns for context management, subagent dispatch, and workflow design. Influence on devwork-skills is at the pattern level (skill folder structure, progressive disclosure, subagent isolation) rather than direct code reuse.

Anthropic's official claude-code plugins. The code-review and pr-review-toolkit plugins overlap with the QA pipeline. code-review is GitHub-specific (it posts to PRs); pr-review-toolkit is platform-agnostic and bundles six specialist review agents (comment-analyzer, silent-failure-hunter, type-design-analyzer, etc.). devwork-skills' /code-validate covers similar ground with Bug Hunter, Static Security Reviewer, and Spec Checker — the Spec Checker (validating against PREQ acceptance criteria) is a differentiator because the official plugins don't have an acceptance-criteria source to check against.

Claude Code /loop. A native cron-style scheduling primitive shipped by Anthropic in March 2026. Session-scoped, max 50 concurrent tasks, 3-day expiry. Could be useful as a building block for monitoring tasks inside a running Claude Code instance — different from Ralph (which iterates on a single task) and not a replacement for the orchestrator.

Claude Code auto mode. A research preview feature (March 2026) using a classifier to review each tool call and block destructive ones while allowing safe ones to proceed automatically. Sits between conservative defaults and --dangerously-skip-permissions. Worth experimenting with for /develop if the devcontainer-per-feature isolation makes the residual risk acceptable; would substitute for --permission-mode=dontAsk with a tighter classifier.

Rationale

Documenting these explicitly serves two purposes. It records what was considered and (where we diverged) why — so a future reader doesn't have to re-derive the analysis. It also surfaces what to watch: if Anthropic's official plugins gain a Spec Checker equivalent, or if auto mode matures past research preview, devwork-skills' QA pipeline could simplify in response.

The general posture is to adopt community patterns when they fit and decline them when they don't, with the rationale on the page rather than in someone's head.

Open questions

None.