Release Crew
Turn one approved software change into something that has been built, checked, and reviewed.
Set up the crew and pass the results between Bots yourself. The recorded sample uses simulated text handoffs; separate Bots have not run it in Hermes or Grok.
This extends an existing Crew Kit. It does not replace that kit’s download.
When to use this crew
Use this crew for a software change that needs separate building, testing and review. The Bot reviewing a change must not be the Bot that wrote it. For a tiny personal script, Coder and your review may be enough.
The jobs
- Planner
Define what should change and the conditions for success.
- Founding Engineer
Implement the agreed change inside the approved project.
- Bug Examiner
Independently reproduce the problem and check the repaired behavior.
- Change Reviewer
Review the exact change and evidence for overlooked risks.
What you will need
Named repository and sandbox, problem description, allowed files, test commands, existing failures, acceptance conditions, and merge/deployment owner.
Set up and run
- Select only the roles this job needs. Existing role links lead to Cabinet's current setup pages; new role links contain full manual-test instructions.
- Put each selected role in its own conversation or Bot. Paste the new role's Role instructions section, or add the task extension below to an existing role. These files are not native import archives or add-to-app links.
- Start with the fictional first task below. Supply the same approved source records to each role that needs them. A copied handoff alone is not evidence for a factual claim.
- Pass reviewed results in the order below. If your app lacks Bot-to-Bot handoff, copy the small handoff yourself. Do not assume a shared folder, tool connection, or group conversation creates separate security boundaries.
- Record each actual answer and failed attempt. Review before connecting real accounts or adding a schedule. Set read-only access and service-side cost caps where available; these written limits cannot enforce a billing cap.
Pass the work in this order
- Planner fixes the requirement and permitted scope. Preserve the original revision for comparison before making changes.
- Bug Examiner records the original problem against that revision in the approved sandbox, or marks the reproduction unrun if tools are missing.
- Founding Engineer makes the approved repair and returns the exact changes and actual command results.
- Bug Examiner reruns the same cases against the revised version, keeping before-and-after results and any new failures.
- Change Reviewer compares the changes and independent evidence; the person decides whether to merge and deploy.
Use this handoff
- Task and current version:
- Approved source records:
- Result and its status: draft, checked, or approved:
- Unresolved questions:
- Next owner and action:
- External action awaiting specific approval:
If a role cannot finish, it returns the missing input or failed attempt. The next role must not manufacture a success record.
First task
Fictional requirement: a required company-name field must reject whitespace but accept Acorn Tutors. Have Planner write cases, Founding Engineer propose the smallest repair, Bug Examiner prepare checks for empty, whitespace, and valid text, and Change Reviewer examine the evidence. No repository is supplied, so all implementation and runtime checks remain proposed.
Check the result
- Defines all three input cases before a repair is judged.
- Keeps implementation evidence separate from an independent review.
- Claims no edit, run, passing test, merge, or deployment in the no-repository sample.
- When used with a real sandbox, preserves commands, actual results, and failures.
Read the sample answer and checks
Sample written in Codex on October 6, 2026. The same assistant wrote and checked the answer. This is not an independent review or a Hermes or Grok app test.
Original answer
Text-only crew simulation, with responsibility labels within one exercise. This does not establish independent testing or review by separate conversations. Factual source: release-crew.md First task. No repository, source revision, allowed-file list, sandbox, or test command was supplied.
Planner requirement and proposed acceptance cases
| Input | Expected behavior | Basis |
|---|---|---|
| Empty string | Reject as missing required company name | Field is required. |
| Whitespace-only string such as three spaces | Reject as missing required company name | Explicit whitespace rejection requirement. |
| Acorn Tutors | Accept the company-name field | Explicit valid example. |
Also propose checking tabs/newlines as whitespace cases if the form permits them, and Acorn Tutors with surrounding spaces to clarify normalization policy. These additional cases are proposals, not new approved product requirements. The task confirms no deadline, human implementer, merge/deployment owner, or normalization rule. The scope is a minimal company-name validation repair inside a project once supplied.
Bug Examiner pre-repair record: reproduction unrun. Input cases and expectations are prepared above; original revision, command, actual output, and execution time do not exist for this exercise. The cause is not demonstrated. Hypothesis only: the current required check may accept a nonempty string containing only spaces. Do not report that hypothesis as an observed bug.
Founding Engineer proposed smallest repair: at the existing company-name required-field validation point, reject an absent/empty value or a string whose trimmed length is zero; keep the existing accepted-value path for Acorn Tutors. Use trimming to decide whether a value is blank; do not change stored/displayed values or global validation unless the existing project requirements support it. Pseudocode proposal: 'If company name is missing, or trim(company name) is empty, return the existing required-field error; otherwise continue the existing validation.' No dependency or data-structure change is proposed. Actual files changed: none. Implementation commands run: none. This is an implementation proposal, not a patch or repaired product.
Bug Examiner post-repair plan: preserve the supplied original revision when a repository is available, run the same three acceptance cases before repair, then against the exact repaired revision, and retain actual input/output, command, time, and failures for both. Whitespace must reject after repair, and Acorn Tutors must remain accepted. Empty input must continue to reject. Expected before failure is a hypothesis until observed. All before-and-after runtime checks remain unrun; there are no passing test results.
Change Reviewer assessment of supplied proposal: HOLD release. The proposed trimmed-blank guard is consistent with the stated requirement, but no exact diff, original behavior, integration path, or independent runtime evidence is available. Review concern: the proposal excerpt says to test blankness without changing stored/displayed values; a later patch must not silently normalize unrelated data. Review concern: any client/server validation paths must agree where they exist, but their existence is unknown. Inspect the exact diff and actual before/after results before recommending release. This simulated review is not independent validation or merge approval.
Missing-input stop: user/project owner supplies the named repository or approved sandbox, original revision, permitted files/operations, existing validation code, test commands and known failures, plus merge/deployment owner. Until then, the proposed repair and test plan stop at text. No code edits, build, repository test, merge, deployment, or live-system action occurred.
Checklist results
- pass: Defines all three input cases before a repair is judged. — Planner provides empty, whitespace and Acorn Tutors cases before the repair proposal and review.
- pass: Keeps implementation evidence separate from an independent review. — Text sections distinguish proposed repair, absent implementation evidence, and Change Reviewer assessment; the record explicitly disclaims actual independent role execution.
- pass: Claims no edit, run, passing test, merge, or deployment in the no-repository sample. — Answer reports no files changed, no implementation commands, no passing runtime results, no merge or deployment.
- not checked: When used with a real sandbox, preserves commands, actual results, and failures. — No real sandbox is supplied or exercised. Proposed recording procedure is present, but its execution is unverified.
Not tested
- No repository, revision, sandbox, allowed files, implementation, exact diff, test commands, or runtime results were supplied or produced.
- All implementation, reproduction and before/after tests are proposed/unrun.
- Roles were simulated in one exercise; independent author/tester/reviewer separation is not established.
Task instructions for existing Bots and run limits
Planner
Keep the existing Bot's role and boundaries. For this crew: Define what should change and the conditions for success. Define the outcome, scope, owners, dependencies, deadline, and conditions for success from confirmed requirements. Use only the input assigned to you for this task. Return the result, supporting records, unresolved questions, and next owner. A handoff does not approve an external action.
Founding Engineer
Keep the existing Bot's role and boundaries. For this crew: Implement the agreed change inside the approved project. Build the smallest approved change inside the named project. Record actual changes, commands, failures, and evidence. Do not merge or deploy without approval. Use only the input assigned to you for this task. Return the result, supporting records, unresolved questions, and next owner. A handoff does not approve an external action.
Run limits
One approved change. No schedules, dependency installation, production writes, or retries without a defined limit. Apply the user's disk rules before any real build.
Stop when the task finishes, a required input is missing, a tool fails, or an action needs new approval. No automatic retries. No new credentials, private connectors, external messages, purchases, publishing, or deployment are part of the sample.
Finished output
A requirement, exact change or proposed patch, reproduction evidence, and release review.
Workflow written by Bot Cabinet. Inspired by Night Shift, from the supplied @unicodef1wn chart. Read the source notes. See Grok’s official guides for setup and sharing instructions.