Product Main Repository Template

Use this template when creating a Product Management repository such as anuva-main-video-creator or a future anuva-main-realtime.

Product-main repositories coordinate product work. They should not contain product implementation code.

# <Product Main Repository Name>

## Repository Purpose

This repository owns Product Management and cross-repository coordination for `<Product Name>`.

It owns:

- Product vision.
- Product roadmap.
- Product architecture.
- Product capability map.
- Product repository registry.
- Cross-repository feature planning.
- GitHub issue and GitHub Project task coordination.
- Product ADRs.
- Product playbooks.
- Product release coordination.
- Product prompts and templates.
- Product MkDocs source docs, published through `anuva-dev-docs` when configured.

It does not own implementation code. Implementation work belongs in the product implementation repositories listed in the product repository registry.

## Recommended Top-Level Files

```text
README.md
AGENTS.md
mkdocs.yml
docs/
```

## Recommended Docs Structure

```text
docs/
  index.md
  bootstrap/
    <Product>_Product.md
  product/
    ProductVision.md
    ProductArchitecture.md
    ProductRoadmap.md
    ProductGlossary.md
  repositories/
    ProductRepositoryRegistry.md
  capabilities/
    ProductCapabilityMap.md
  development/
    ProductChangeWorkflow.md
    CrossRepositoryFeatureWorkflow.md
    DocsParityRules.md
    GitHubProjectWorkflow.md
  skills/
    ProductSkillsOverview.md
  playbooks/
    index.md
  prompts/
    index.md
    GenerateImplementationBootstrapContext.md
    PlanCrossRepositoryFeature.md
    CreateGitHubProjectTasks.md
    CreateRepositoryTask.md
    ImplementGitHubProjectIssue.md
    ReviewFeatureCompletion.md
  templates/
    ProductFeature_Template.md
    RepositoryImpact_Template.md
    ProductADR_Template.md
  adr/
    index.md
  releases/
    index.md
  changes/
    index.md
```

## AGENTS.md Requirements

`AGENTS.md` should state:

- This repository owns `<Product Name>` product coordination, not implementation.
- Engineering-wide process comes from `anuva-engineering-handbook`.
- Product-level work belongs here.
- Repository-specific implementation belongs in the owning implementation repository.
- Codex should create repository-specific GitHub issues and GitHub Project items for implementation work after product docs are reviewed.
- GitHub issues are durable implementation handoff packets; Codex chat is not the source of truth.
- Product docs, product repository registry, and product capability map should stay in sync.
- Product progress docs, GitHub issues, PR completion reports, and GitHub Project fields should stay in sync.
- Product-specific implementation details should be summarized only as needed for planning.
- Bootstrap Context documents for implementation repositories may be generated here and manually copied to `docs/bootstrap/BootstrapContext.md` in the target implementation repository.

## Product Architecture Page

The product architecture page should include a lightweight component diagram.

```mermaid
flowchart TD
  product["<Product Name>"] --> main["<product-main-repository>"]
  main --> repoA["<implementation-repository-a>"]
  main --> repoB["<implementation-repository-b>"]
  main --> repoC["<implementation-repository-c>"]
```

Keep this page at product level. Link to implementation repositories for code-level details.

## Product Capability Map

| Capability | Owner Repository | Level | Status | Notes |
| --- | --- | --- | --- | --- |
| `<Capability>` | `<Repository>` | Product or implementation | Planned | `<Notes>` |

## Product Repository Registry

| Repository | Role | Owned Capabilities | Local Docs | Verification |
| --- | --- | --- | --- | --- |
| `<repo>` | `<role>` | `<capabilities>` | `<docs path>` | `<commands>` |

## Cross-Repository Feature Template

Use product-level feature plans to coordinate work before opening implementation tasks. For work that spans implementation repositories, create GitHub issues and add them to the product GitHub Project.

```mermaid
flowchart TD
  feature["Product feature"] --> impact["Repository impact analysis"]
  impact --> tasks["tasks.yml and HandoffPrompts.md"]
  tasks --> issueA["GitHub issue for repository A"]
  tasks --> issueB["GitHub issue for repository B"]
  issueA --> project["Product GitHub Project"]
  issueB --> project
  project --> review["Product integration review"]
  review --> release["Product release checklist"]
```

Feature change folders should normally include:

```text
docs/changes/<YYYY-MM-DD-feature-name>/
  BrainDump.md
  FeatureBrief.md
  RepositoryImpact.md
  HandoffPrompts.md
  GitHubTasks.md
  Progress.md
  ReviewChecklist.md
  tasks.yml
```

## Implementation Repository Bootstrap Context

Product-main repositories may generate Bootstrap Context documents for implementation repositories.

The generated document should be copied into the implementation repository at:

```text
docs/bootstrap/BootstrapContext.md
```

It should describe the implementation repository's product role, ownership boundaries, expected capabilities, expected `docs/core` and `docs/state` pages, integration points, verification expectations, and open questions.

The implementation repository bootstrap process should not create `AGENTS.md` until `docs/bootstrap/BootstrapContext.md`, `docs/process/ChangeWorkflow.md`, `docs/core`, and `docs/state` exist.

## GitHub Project Fields

Product-main repositories should define the project fields needed for coordination.

| Field | Purpose |
| --- | --- |
| `Status` | Current task state, such as Backlog, Ready, In Progress, In Review, Done, or Blocked. |
| `Repository` | Owning repository for the implementation task. |
| `Feature ID` | Shared feature identifier across product-main docs, issues, and PRs. |
| `Product Change Folder` | Path to the product-main feature docs. |
| `Docs Impact` | Whether local, product, handbook, or publisher docs need updates. |
| `Verification` | Whether verification is pending, passed, skipped, or failed. |

## Verification

Product-main repositories should run docs checks such as:

```bash
git diff --check
mkdocs build --strict
```

Implementation tests should run in the owning implementation repositories, not in the product-main repository.

When product-main docs, GitHub task status, or implementation docs change, `anuva-dev-docs` should be refreshed or the required publishing refresh should be recorded.