Skip to main content

Implementation Blueprints

Blueprints are an optional gate between Delivery Plan review and prepared Handoff Packs.

Use blueprints when:

  • A task may touch multiple repositories.
  • Exact repository ownership is not obvious during discovery.
  • Engineers need to review implementation approach before an agent-ready pack is generated.
  • The team wants GitHub pull request review as the approval surface.

Blueprint Flow​

  1. inrelay groups Delivery Plan work into Handoff Pack candidates.
  2. A user confirms or amends repository scope for the candidate.
  3. inrelay runs repo/docs refinement against the confirmed scope.
  4. inrelay suppresses repeated resolved repo/docs questions when material evidence is unchanged. A user resolves hard repo/docs blockers or carries forward remaining actionable repo/docs questions only when inrelay cannot resolve them from the confirmed scope.
  5. inrelay creates or updates a draft blueprint pull request when blueprint review is required and gates pass.
  6. Engineers edit blueprint.md and relay.yaml in GitHub.
  7. inrelay validates required sections, Mermaid architecture diagram presence, metadata shape, and metadata references after inrelay-created or updated PRs and GitHub PR updates.
  8. GitHub review state is reflected back into inrelay.
  9. Merging the blueprint pull request approves the blueprint.
  10. inrelay can prepare repo-specific Handoff Packs for approved targets.

If no blueprint is needed, use No blueprint required in the Handoff Pack candidate UI and provide a reason. inrelay still needs confirmed or amended repository scope before packs can be prepared.

The normal UI does not ask users to press Validate blueprint, Sync blueprint, or Create/update PR. Use Refresh from GitHub only when Blueprint PR state looks stale, and use Regenerate Blueprint PR only when the Handoff Pack candidate exposes it as a recovery action.