issue-driven-delivery

To coordinate delivery via GitHub issues, you treat issues as task contracts by tagging them with target archetypes and issue-type labels like feature or bug. This enforces ownership, explicit acceptance criteria, and visible question threads for traceability across orchestrator, spec, builder, and QA teams.

Tracking ownership and readiness in GitHub requires enforcing explicit acceptance criteria and key assumptions within the issue description. Tagging each issue with the target archetype and a high-level issue-type label maintains clear, auditable work scoping throughout the delivery lifecycle.

You maintain a transparent clarification trail during issue-driven delivery by using GitHub issue comments to surface questions. This creates a durable, visible record of decisions and scope changes across orchestrator, spec, builder, and QA workflows.

Yes, GitHub issues work as contracts for building and QA workflows by enforcing tagging policies and explicit acceptance criteria. Applying issue-driven delivery across these stages ensures readiness is verified against the documented assumptions and criteria before acceptance.

Documenting assumptions in GitHub issue descriptions keeps work scoping clear and auditable. It establishes a visible contract for delivery teams, ensuring that orchestrator, builder, and QA members share the same understanding of readiness and acceptance criteria.

No, issue-driven delivery requires no specific dependencies or components. It relies entirely on standard GitHub issues and comments to enforce tagging policies, acceptance criteria, and visible question threads for coordinating delivery work.