Skip to content

Cross-Repository Feature Workflow

Cross-repository features are planned once in this repository, then decomposed into implementation tasks for the repositories that own the affected systems. GitHub issues and the Anuva Video Creator GitHub Project carry the durable handoff and execution state.

sequenceDiagram
    participant Product as anuva-main-video-creator
    participant Project as GitHub Issues + Project
    participant Web as anuvax-cms
    participant Python as anuva-python-server
    participant Unity as anuva-unity-video-creator
    participant Review as Product Review
    participant Docs as anuva-dev-docs

    Product->>Product: Define feature intent and acceptance criteria
    Product->>Product: Create RepositoryImpact.md and tasks.yml
    Product->>Project: Create repository issues and project items
    Project->>Web: Route Web issue
    Project->>Python: Route Python issue
    Project->>Unity: Route Unity issue
    Web-->>Project: Report PR, verification, and docs status
    Python-->>Project: Report PR, verification, and docs status
    Unity-->>Project: Report PR, verification, and docs status
    Project-->>Product: Sync progress and risks
    Product->>Review: Run product integration review
    Review->>Product: Update product docs, releases, and changes
    Product->>Docs: Trigger or record publishing refresh

When To Use This Workflow

Use this workflow when a feature:

  • affects more than one repository
  • changes shared contracts or capability ownership
  • requires coordinated sequencing
  • has unclear repository ownership
  • creates a new repository or service boundary
  • needs integration-level acceptance criteria
  • changes handbook registries, templates, skills, or standards

Handoff Rules

  • Keep the product feature plan in this repository.
  • Put repository-specific implementation details in GitHub issues and owning repository docs.
  • Do not edit implementation code from this repository.
  • Name cross-repository dependencies explicitly.
  • Include expected verification and documentation updates per repository.
  • Use tasks.yml when automation will create or update GitHub issues.
  • Keep GitHubTasks.md, Progress.md, project fields, and PR completion reports aligned.

RepositoryImpact.md Structure

RepositoryImpact.md should identify:

  • affected capabilities
  • affected repositories
  • repository-specific scope
  • sequencing dependencies
  • docs impact
  • verification expectations
  • open questions
  • product acceptance criteria

tasks.yml Structure

tasks.yml should provide a machine-readable task list for issue creation:

feature_id: 2026-07-05-example-feature
product_repository: anuva-main-video-creator
project: Anuva Video Creator
change_folder: docs/changes/2026-07-05-example-feature
tasks:
  - repository: anuvax-cms
    title: Implement Web portion of the feature
    priority: high
    docs_impact: local
    acceptance_criteria:
      - Web behavior is implemented
      - Web-local docs are updated
      - Web verification is run or skipped with a reason

GitHubTasks.md Structure

GitHubTasks.md should track:

  • feature id
  • product change folder
  • affected repositories
  • GitHub issue links
  • GitHub Project item status
  • linked PRs
  • verification status
  • docs impact
  • product review status

Completion Rules

A cross-repository feature is complete only when:

  • The product feature plan acceptance criteria are satisfied.
  • Each repository reports implementation, docs, and verification status through issues, project fields, and PR completion reports.
  • GitHub Project fields match the actual implementation state.
  • Product docs are updated to match delivered behavior.
  • Release notes, change history, and publishing refresh notes are updated.
  • Remaining risks and follow-ups are recorded.