Skip to main content

Handoff Packs And Publishing

inrelay stores the prepared handoff artefact as an implementation pack record, but the user-facing workflow treats it as a Handoff Pack. Handoff Packs are generated from:

  • The approved product document.
  • A lightweight implementation brief when strict low-risk bug or patch work used the shorter review path.
  • PRD section quality metadata, including source refs, assumptions, gaps, and resolutions.
  • Latest pre-flight signals and acknowledgement state.
  • Completed or manually closed discovery.
  • Discovery repo search-scope decisions and snapshots.
  • Accepted Delivery Plan context when required.
  • Retained Delivery Plan target-context answers when material target signatures are unchanged.
  • Task-generation deltas and Linear issue anchors where available.
  • Confirmed or amended Handoff Pack repository scope.
  • Repo/docs refinement findings.
  • Relevant codebase index summaries and selected full files when GitHub access allows it.
  • Blueprint mappings when blueprints are enabled.

inrelay indexes an inventory of eligible source paths and concise summaries; it does not store full repository source contents. Full files are fetched on demand only for selected handoff or refinement flows when GitHub access allows it.

For newly flagged Handoff Pack First initiatives, packs are stored in dedicated Handoff Pack First records instead of task-bound implementation pack records. That mode generates draft Handoff Packs directly from source-linked context snapshots and confirmed targets without requiring PRD generation, PRD approval, Delivery Plan generation, Delivery Plan acceptance, generated tasks, or Work Packages. See Handoff Pack First for that workflow.

Each pack is generated as a planning-pack-shaped directory under .inrelay:

  • .inrelay/AGENTS.md: shared instructions for agents working from inrelay handoff packs.
  • .inrelay/handoff-pack-<INITIATIVE ID>/README.md: pack map and execution order.
  • Numbered Markdown files for requirements context, scope, implementation plan, workstreams, task backlog, risks and decisions, execution checklist, rollout and verification, contracts and schemas, and original source context.

Preparation​

inrelay may run automated Handoff Pack readiness after successful explicit Linear handoff when the existing gates allow it. Readiness automation can check repo/docs context, suppress repeated already-resolved questions when material evidence has not changed, auto-carry-forward new non-hard repo/docs questions only for strict low-risk work, create or update draft Blueprint PRs, and validate Blueprint PR content. It stops for user decisions, GitHub review and merge, missing integrations, stale evidence, ambiguous scope, or hard blockers.

inrelay may prepare Handoff Packs automatically when all preparation gates pass, depending on team settings. Preparation happens inside inrelay and does not create external pull requests by itself.

With blueprints enabled, packs wait until the relevant blueprint is approved or explicitly marked not required. Without blueprints, packs still require confirmed or amended repository scope and any required repo/docs decision.

Publishing​

Publishing is explicit. A user chooses where prepared packs should go:

  • Structured file-list download.
  • GitHub draft pull request.
  • Linear sync where configured.

When GitHub publishing is selected and GitHub write permissions are available, inrelay creates a branch named like:

relay/ENG-123-implement-the-checkout-retry-message-hierarchy

It writes .inrelay/AGENTS.md plus .inrelay/handoff-pack-<INITIATIVE ID>/... and opens a draft pull request. When the pull request becomes ready for review, inrelay can post a review comment. When the pull request is merged, inrelay marks the task done from the GitHub webhook.