Skip to main content

inrelay Documentation

inrelay turns scattered product context into a grounded PRD or low-risk lightweight brief, targeted Technical Discovery, a shaped draft Delivery Plan, explicit Linear handoff, and a prepared Handoff Pack for engineers or AI agents.

Teams with the Handoff Pack First rollout enabled may create newly flagged initiatives that go directly from source context to Handoff Pack readiness, target confirmation, draft packs, approval PRs, and explicit publication. In that flagged mode, PRDs, technical requirements docs, and work breakdowns are optional exports, not required gates.

The web UI is the main workflow control surface. Slack remains available for source capture, status checks, notifications, deep links, and secondary answer input.

The initiative UI also shows operation feedback for work inrelay has accepted but not finished yet, including queued jobs, running work, retries, waiting on external systems, partial results, failures, and stale work that needs attention.

Who Uses inrelay

  • Product and engineering leads use inrelay to collect context, approve scope, close technical gaps, and prepare a trustworthy handoff.
  • Workspace admins configure Slack, GitHub, Linear, billing, teams, provider routing, and handoff settings.
  • Engineers use confirmed Handoff Pack scope, optional blueprint pull requests, handed-off Linear issues, and explicitly published GitHub pull requests during delivery.

Core Workflow

  1. Create or select an initiative. In the UI, choose work type, expected size, and optional initial context when profiled intake is enabled.
  2. Build the Shape Brief from Slack, email, uploaded files, transcripts, direct Markdown, or other supported source material.
  3. Review pre-flight signals when available, then draft a PRD. Strict low-risk bugs and patches can use a lightweight implementation brief when required context is present. Product-context gaps can appear as section-level gaps; operational blockers still stop drafting.
  4. Review and approve the PRD draft or lightweight brief, filling gap sections or missing brief fields before approval, or reject it with correction notes.
  5. Complete Technical Discovery & Refinement so retrieval scope, cited code-inferred answers, implementation assumptions, risks, and unresolved questions are explicit.
  6. Generate and shape the draft Delivery Plan, including sequencing, dependencies, QA, release, ownership, acceptance details, retained target-context answers, and task reshaping.
  7. Use Send to Linear when the task list is final; Linear issue creation does not happen during draft generation.
  8. Review Handoff Pack candidates, confirm or amend repository scope, resolve hard repo/docs blockers, carry forward actionable repo/docs questions only when asked, and satisfy blueprint or no-blueprint decisions when required.
  9. Let inrelay run automated Handoff Pack readiness and prepare packs when gates pass, then explicitly publish prepared packs to GitHub, Linear, download, or another supported destination when the team is ready.

GitHub and Linear are optional until the workflow reaches their stages. inrelay can still gather context, review PRDs, and prepare a handoff with only Slack and the web UI.

Current automation is deliberately bounded: repo-first Technical Discovery, cited code-inferred answer proposals, Delivery Plan target signatures, and repeated-question suppression apply broadly when evidence exists; low-risk auto-confirm, code-answer auto-apply, lightweight briefs, and new non-hard repo/docs auto-carry-forward are limited to strict bug or patch work sized xs or s with fresh single-repo evidence and no hard or high-risk blockers.

Start Here