What you are trying to do
You have hired specialists before — a senior engineer, a QA lead, a product manager, a designer. Each of them owns a specific kind of decision. The same is true inside Ship. Each state in the process is owned by a named specialist with one job and clear rules about when to stop and ask you.
This page tells you who those specialists are, what they own from your point of view, and when you should expect to hear from them.
The specialists you will meet
The Planning bundle turns a one-line request into a real plan. It reads the ticket you wrote, decides whether it is a feature, a bug, a refactor or an improvement, and produces a spec with acceptance criteria, an architecture note, and a test plan. If the ticket is too thin to plan against — no problem statement, no goal — it stops and asks. You will never get a fabricated spec back; you will get a question.
The Developer owns the code change. Once a plan exists, the developer specialist picks up the ticket, writes the change on a branch named after it, runs the test and build gates, and opens a pull request. It does not get to decide what to build — that decision belongs to Planning. It also never merges on its own; the merge is yours.
The Validation bundle is your QA. It walks the test plan the architect wrote, scenario by scenario, against the running build. If something is wrong, it stops and writes you a defect list — it will not try to "just fix it." If everything passes, it adds automated tests on top of the same pull request so the same bug cannot come back next month.
The Reviewer is the final pair of eyes on a pull request before it reaches you. It walks the diff and posts comments on correctness, maintainability, tests, and risk. It cannot push code. It cannot click approve. Approval is a human signal, and Ship keeps it that way on purpose.
The DevOps specialist is a separate role for infrastructure, deploy and observability work. It carries extra latches: it must spell out a rollback step in every pull request, it must never commit a secret, and it can never auto-merge anything that touches production. If you file an infrastructure ticket, this specialist picks it up rather than the regular developer.
The Designer review runs only on pull requests that touch the user interface. It checks for token violations, components reinvented from scratch, and copy that breaks your tone guidelines. Like the reviewer, it comments — it never approves.
The Clarification specialist is the polite specialist who handles the awkward case. When a ticket arrives without enough detail, it posts one short follow-up comment asking for the missing piece, then waits. It will not retry, nag, or fabricate context. If you answer in a comment, the ticket re-enters the regular flow.
Bundles versus single roles
Some of these specialists are bundles. A bundle means one agent run does the work that used to be a chain of three or four separate runs. The Planning bundle handles intake, business analysis, architecture and test architecture in a single pass. The Validation bundle handles exploratory QA and automated test writing as one job.
From your point of view, the difference is speed and coherence. A bundle reads the ticket once and walks the phases internally instead of cold-starting four times. You see one comment per state, not four.
What this changes about your week
When you open a ticket and look at its history, every comment ends with a tag — [Ship SDLC:role-developer], [Ship SDLC:role-validation], [Ship SDLC:role-reviewer] — so you always know who left it. A defect list is from Validation. A line-by-line code critique is from the Reviewer. A request for clarification is from the planner.
You stop having to translate. You stop wondering whether "the bot" did something. There is no "the bot." There is a small team of named specialists, each with one job, each leaving fingerprints you can grep for next month.