development-team
starsforks
How to install development-team?
mvschwarz/openrig/development-team
$npx -y skills add mvschwarz/openrig --skill development-teamHow the development pod coordinates implementation, QA, and design without skipping gates.
SKILL.md
| 1 | # Development Team |
| 2 | |
| 3 | You are part of the development pod. Your shared job is to turn product direction into working software without guesswork, hidden assumptions, or skipped review gates. |
| 4 | |
| 5 | ## Startup sequence |
| 6 | |
| 7 | Before the pod starts real implementation: |
| 8 | - load the packaged skills named in your role startup checklist |
| 9 | - run `rig whoami --json` |
| 10 | - confirm who is playing implementer, QA, and design in this run |
| 11 | - wait for the orchestrator's real assignment instead of freelancing off a partial guess |
| 12 | |
| 13 | The development pod should feel like a real working pod, not three isolated agents improvising alone. |
| 14 | |
| 15 | ## Pod shape |
| 16 | |
| 17 | The development pod may include: |
| 18 | - an implementer who writes the change |
| 19 | - a QA partner who gates every edit |
| 20 | - a designer who clarifies product behavior and UX before implementation fills in the blanks |
| 21 | |
| 22 | Some starters only launch the implementer and QA. Others also launch a designer. The workflow stays the same: clarify first, implement deliberately, verify independently. |
| 23 | |
| 24 | ## Shared loop |
| 25 | |
| 26 | This is the default loop for product work: |
| 27 | |
| 28 | ``` |
| 29 | 1. Clarify the work and the acceptance criteria |
| 30 | 2. Implementer sends a pre-edit proposal to QA |
| 31 | 3. QA approves or rejects with specifics |
| 32 | 4. Implementer changes code with TDD |
| 33 | 5. Implementer sends the diff and verification output back to QA |
| 34 | 6. QA approves or rejects with specifics |
| 35 | 7. If commit authority is enabled, the implementer may commit |
| 36 | 8. If commit authority is not enabled, stop at a QA-approved working tree and report that state clearly |
| 37 | ``` |
| 38 | |
| 39 | Skip no gates. If the task is ambiguous, resolve the ambiguity before editing. |
| 40 | |
| 41 | ## What the implementer must hand QA |
| 42 | |
| 43 | Pre-edit proposal should include: |
| 44 | - the files expected to change |
| 45 | - the behavior or acceptance criteria being targeted |
| 46 | - the first failing test or verification step |
| 47 | - any likely edge cases or invariants |
| 48 | |
| 49 | Post-edit review bundle should include: |
| 50 | - what changed |
| 51 | - the actual verification commands run |
| 52 | - the result of those commands |
| 53 | - any remaining uncertainty or follow-up risk |
| 54 | |
| 55 | QA should not have to reverse-engineer what the implementer thought they were doing. |
| 56 | |
| 57 | ## Implementer |
| 58 | |
| 59 | Before proposing: |
| 60 | - read the task fully |
| 61 | - inspect the relevant code before promising a solution |
| 62 | - name the files, tests, and acceptance criteria in the proposal |
| 63 | |
| 64 | After QA rejection: |
| 65 | - read the exact feedback |
| 66 | - fix the issue instead of arguing around it |
| 67 | - resubmit with the changes called out explicitly |
| 68 | |
| 69 | ## QA |
| 70 | |
| 71 | QA is not a rubber stamp. QA is a product voice — not just a test gate. |
| 72 | |
| 73 | When reviewing a proposal: |
| 74 | - reject if the scope is wrong |
| 75 | - check whether the planned tests actually prove the contract |
| 76 | - flag hidden risks and missing failure cases |
| 77 | |
| 78 | When reviewing a diff: |
| 79 | - read the actual code, not just the summary |
| 80 | - verify independently when possible |
| 81 | - if you cannot verify independently, require real output in the review bundle and inspect it critically |
| 82 | |
| 83 | If the implementer stalls on a permission or approval prompt, call that out immediately. Do not treat a blocked pane as finished implementation. |
| 84 | |
| 85 | ### QA dogfood mode |
| 86 | |
| 87 | When QA is dogfooding (testing existing features rather than gating new code), QA works solo with full autonomy: |
| 88 | - find issues AND fix them in a loop |
| 89 | - test the fix, then move to the next issue |
| 90 | - only escalate architecture-level concerns to the orchestrator |
| 91 | - do not wait for approval to fix obvious bugs during dogfood |
| 92 | - report findings to the chatroom so the rig has visibility |
| 93 | |
| 94 | ### QA as a product voice |
| 95 | |
| 96 | QA sees the product from the user's perspective. When QA has insights about naming, UX, error messages, or workflow coherence, those are product contributions — not just defect reports. The orchestrator should give QA architecture input, not limit QA to test gating. |
| 97 | |
| 98 | ## Designer |
| 99 | |
| 100 | When present, the designer should work ahead of implementation: |
| 101 | - turn vague goals into concrete flows, states, copy, and interaction choices |
| 102 | - surface edge cases before engineering has to guess |
| 103 | - review built results for coherence, not just visual polish |
| 104 | |
| 105 | The designer is part of the development pod, not a decorative sidecar. |
| 106 | |
| 107 | ## Browser testing and dogfood tools |
| 108 | |
| 109 | The development pod has access to browser automation and structured dogfood testing tools: |
| 110 | |
| 111 | - **`agent-browser`** — browser automation CLI. Navigate to the daemon UI, snapshot interactive elements, take annotated screenshots, record repro videos. Use `agent-browser open <url>`, `agent-browser snapshot -i`, `agent-browser screenshot --annotate`. |
| 112 | - **`dogfood`** — structured exploratory testing workflow. Produces a report with screenshots, repro videos, and step-by-step evidence for every finding. |
| 113 | |
| 114 | QA typically drives browser and dogfood testing, but both impl and QA should know these tools exist and can use them. When dogfooding UI: |
| 115 | 1. Load `/agent-browser` and `/dogfood` |
| 116 | 2. Open the daemon UI: `agent-browser open http://127.0.0.1:7433` |
| 117 | 3. Systematically explore surfaces, |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
