Workflow Stages
inrelay shows a five-stage handoff-first workflow in the initiative UI. The underlying system still keeps detailed internal states for compatibility, audit history, and integrations, but day-to-day work should follow these visible stages.
| Stage | What It Means | What To Do |
|---|---|---|
| Shape Brief | The initiative needs enough source context to support a useful PRD and downstream handoff. inrelay may also run pre-flight checks for duplicate, conflicting, or related work. | Add Slack messages, files, email context, or direct Markdown. Review quality, readiness gaps, pre-flight signals, conflicts, and source evidence. |
| PRD Review | inrelay has drafted or can draft a structured PRD with section quality states: sourced, inferred, gap, or not applicable. Strict low-risk bugs and patches may use a lightweight implementation brief with required source metadata. | Review evidence, assumptions, conflicts, and coverage. Fill gap sections or missing brief fields before approval. Approve the PRD or brief, or reject it with correction notes. |
| Technical Discovery & Refinement | inrelay starts with discovery repo retrieval scope when repo context exists, then checks implementation assumptions, risks, cited code-inferred answers, and unresolved technical context. | Confirm or amend discovery repo search scope when asked, accept or edit cited code proposals, then answer focused questions in the UI or Slack. This scope controls retrieval, not final implementation authority. |
| Delivery Plan | inrelay turns the approved PRD or lightweight brief and discovery context into editable draft delivery work before Linear handoff. Material target signatures can retain unchanged target-context answers. | Shape draft tasks, review retained assumptions, sequencing, dependencies, QA, release, ownership, acceptance, and Handoff Pack candidates. Use Send to Linear only when the task list is final. |
| Handoff Pack | inrelay prepares the final engineer or agent handoff after Delivery Plan and handoff gates pass. It can suppress repeated resolved repo/docs questions when material evidence is unchanged. | Confirm or amend pack repository scope, resolve hard repo/docs blockers, carry forward actionable repo/docs questions only when asked, let inrelay run automated readiness, review and merge blueprint PRs in GitHub when required, then explicitly publish prepared packs. |
Operation Feedback
Operation feedback stays inside these five stages; inrelay does not add a separate Operations stage. When a submitted action starts queued, running, retrying, waiting-external, partial, failed, stale, nested, batch, or synchronous long-running work, the initiative page shows immediate pending feedback and then durable operation status in the affected stage or substep.
Operation status explains progress and failures. It does not replace PRD, discovery, task, blueprint, or Handoff Pack gate checks.
Handoff Guardrails
- A Handoff Pack is required before inrelay considers an initiative ready for engineering or agent execution.
- inrelay may automatically run repo/docs refinement, Blueprint PR creation or update, approved-scope revision PR creation, and Blueprint validation after existing gates pass.
- inrelay may prepare Handoff Packs automatically when preparation gates pass, depending on team settings.
- inrelay does not publish externally by surprise. GitHub PRs, Linear updates, downloads, and future destinations require an explicit publish action.
- Delivery Plan generation creates inrelay draft tasks first. Linear issue creation waits for explicit Send to Linear.
- Discovery repo scope is retrieval scope only. Handoff Pack repository scope and blueprint mappings remain authoritative for implementation.
- Repository scope is inferred by inrelay, but it must be confirmed or amended before it controls blueprint or handoff output.
- Repo/docs carry-forward is evidence-based. Repeated already-resolved questions can be suppressed for all initiatives when material evidence is unchanged; only strict low-risk work may auto-carry-forward new non-hard questions; hard blockers remain visible.
- Code-inferred discovery answers require citations. They stay proposals outside the low-risk lane, and low-risk auto-apply is limited to fresh, high-confidence, code-answerable evidence.
- Advanced recovery controls are quiet: use Refresh from GitHub for stale Blueprint PR state and Regenerate Blueprint PR only when the UI offers it.
- inrelay may propose documentation or ADR updates as handoff context. It does not automatically write repo docs.
When To Connect Integrations
Slack is the first integration to install when teams want source capture, notifications, and compatibility commands in Slack.
GitHub and Linear can be added later:
- Connect GitHub read-only before Technical Discovery or Handoff Pack refinement needs codebase context.
- Connect Linear before reviewed Delivery Plan work needs to be sent into issues.
- Upgrade GitHub write permissions only when blueprint pull requests or explicit Handoff Pack publishing to draft pull requests are enabled.
Flagged Handoff Pack First Initiatives
Some teams may enable the separate Handoff Pack First rollout for newly flagged initiatives. Those initiatives use:
Add Context -> Resolve Gaps -> Confirm Targets -> Review Handoff Packs -> Approval PR -> Publish
In that mode, the Handoff Pack workspace uses source-linked evidence, requirements, answers, and confirmed targets as the source of truth. Draft Handoff Packs do not require PRD generation, PRD approval, Delivery Plan generation, Delivery Plan acceptance, generated tasks, or Work Packages.
Existing and unflagged initiatives still use the five-stage workflow above. See Handoff Pack First for the flagged workflow, approval PR, publishing, optional artefact, and rollback behavior.