agentsys 5.3.7 → 5.4.1

package/agent-knowledge/github-org-project-management.md

@@ -1,319 +0,0 @@
-# Learning Guide: GitHub Organization Project Management for Multi-Repo Open Source Ecosystems
-
-**Generated**: 2026-02-21
-**Sources**: 15 resources analyzed
-**Depth**: deep
-
-## Prerequisites
-
-- Familiarity with GitHub Issues and Pull Requests
-- Basic understanding of GitHub Organizations
-- Awareness of multi-repo project structures
-- Optional: GraphQL API knowledge for automation
-
-## TL;DR
-
-- GitHub Projects v2 is the primary tool for cross-repo org-level project management, supporting up to 50,000 items and 50 custom fields across all repos in an org.
-- Issue Types (public preview, Jan 2025) and Sub-Issues enable structured work hierarchies at the org level without extra tooling.
-- Automation via built-in workflows, GitHub Actions (`actions/add-to-project@v1`), and the GraphQL API is essential for keeping cross-repo boards accurate at scale.
-- Successful open source orgs (Rust, Kubernetes, Astro, GitHub itself) combine a public roadmap project, RFC/enhancement-proposal repos, and working groups or SIGs to coordinate distributed contributors.
-- The GraphQL API with the `project` OAuth scope unlocks full programmatic control; `read:project` is sufficient for read-only integrations.
-
-## Core Concepts
-
-### GitHub Projects v2
-
-Projects v2 replaced the classic Projects board in 2022. It lives at the org level (not per-repo) and can aggregate items from any repository in the organization.
-
-Key capabilities:
-- **Views**: Table (spreadsheet-style), Board (kanban), Roadmap (Gantt-like timeline)
-- **Custom fields**: Up to 50 per project. Types: text, number, date, single-select, iteration
-- **Grouping, filtering, sorting**: Available across all views; filters use GitHub's advanced search syntax including AND/OR keywords and parentheses
-- **Capacity**: 50,000 items per project
-- **Cross-repo**: A single project can contain issues and PRs from any repo in the org
-
-### Issue Types
-
-Introduced in public preview January 2025. Org admins define up to 25 custom issue types (defaults: Task, Bug, Feature). Types are available across all repos and can be filtered in Projects and search.
-
-This replaces the common pattern of using label conventions (`type: bug`, `kind/feature`) with a first-class field.
-
-### Sub-Issues
-
-Also in public preview. Issues can have a parent-child relationship:
-- Break a large epic into sub-issues
-- Progress bar displayed on the parent issue
-- Sub-issues can live in different repos from the parent
-- Enables hierarchical tracking without external tools
-
-### Automation Tiers
-
-| Plan | Built-in Workflows |
-|------|--------------------|
-| Free | 1 active workflow |
-| Pro / Team | 5 active workflows |
-| Enterprise | 20 active workflows |
-
-Built-in workflow triggers:
-- Item closed → set status
-- PR merged → set status
-- Item added to repo → add to project (filter by label, status, or assignee)
-- Item archived by staleness (14 days, 3 weeks, or 1 month of inactivity)
-
-For more complex rules, use GitHub Actions or the GraphQL API.
-
-### GraphQL API
-
-All project mutations require the `project` OAuth scope. Read-only operations use `read:project`.
-
-Primary operations:
-- `addProjectV2ItemById` - add an issue/PR to a project
-- `updateProjectV2ItemFieldValue` - set a field value on an item
-- `createProjectV2` - create a new project
-
-Webhook events: `projects_v2_item` (created, edited, deleted, reordered, converted)
-
-## Code Examples
-
-### Auto-Add Issues from Any Repo via GitHub Actions
-
-```yaml
-# .github/workflows/add-to-project.yml
-# Place this in EACH repo that should auto-add items to the org project
-name: Add to Org Project
-
-on:
-  issues:
-    types: [opened]
-  pull_request:
-    types: [opened]
-
-jobs:
-  add-to-project:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/add-to-project@v1
-        with:
-          project-url: https://github.com/orgs/MY-ORG/projects/42
-          github-token: ${{ secrets.ADD_TO_PROJECT_PAT }}
-          # Optional: only add if issue has specific label
-          labeled: triage, bug, enhancement
-```
-
-The PAT must belong to an org member and have the `project` scope.
-
-### GraphQL: Add Issue to Project
-
-```graphql
-mutation AddIssueToProject($projectId: ID!, $contentId: ID!) {
-  addProjectV2ItemById(input: {
-    projectId: $projectId
-    contentId: $contentId
-  }) {
-    item {
-      id
-    }
-  }
-}
-```
-
-### GraphQL: Update a Field Value
-
-```graphql
-mutation SetStatus($projectId: ID!, $itemId: ID!, $fieldId: ID!, $optionId: String!) {
-  updateProjectV2ItemFieldValue(input: {
-    projectId: $projectId
-    itemId: $itemId
-    fieldId: $fieldId
-    value: {
-      singleSelectOptionId: $optionId
-    }
-  }) {
-    projectV2Item {
-      id
-    }
-  }
-}
-```
-
-### GraphQL: Find Project by Org and Number
-
-```graphql
-query FindProject($org: String!, $number: Int!) {
-  organization(login: $org) {
-    projectV2(number: $number) {
-      id
-      title
-      fields(first: 20) {
-        nodes {
-          ... on ProjectV2Field {
-            id
-            name
-          }
-          ... on ProjectV2SingleSelectField {
-            id
-            name
-            options {
-              id
-              name
-            }
-          }
-        }
-      }
-    }
-  }
-}
-```
-
-### Advanced Search: Filter Issues by Type and Status
-
-```
-org:MY-ORG is:open type:feature label:roadmap
-org:MY-ORG is:open type:bug (label:priority-high OR label:priority-critical)
-```
-
-## Org-Level Patterns from Real Projects
-
-### GitHub's Public Roadmap
-
-GitHub maintains a public project at `github.com/orgs/github/projects/4247`. Key practices:
-- Quarterly columns map to release milestones
-- The `shipped` label is applied when a feature lands, and the issue body is updated with a changelog link
-- Items stay visible after shipping in a "Shipped" column (archive only after some time)
-- This gives external contributors a real-time view of planned and recent work
-
-### Kubernetes SIG Model
-
-Kubernetes uses Special Interest Groups (SIGs) to coordinate work across 100+ repos:
-- Each SIG owns a subset of repos and has a dedicated project board
-- Kubernetes Enhancement Proposals (KEPs) live in a single `kubernetes/enhancements` repo as structured markdown files
-- KEPs link to issues/PRs in implementation repos
-- SIG leads triage new issues weekly and apply standardized labels (`sig/network`, `kind/feature`, etc.)
-
-### Rust-lang RFC Process
-
-- RFCs live in `rust-lang/rfcs` as PRs
-- Working groups coordinate cross-team implementation
-- A dedicated project tracks RFC lifecycle stages (proposed → accepted → stabilized → closed)
-- Cross-repo coordination uses GitHub Projects with a single-select "Phase" field
-
-### Astro (withastro)
-
-- 51 repos under one org
-- `withastro/roadmap` repo hosts RFC discussions and a public-facing roadmap project
-- Uses pnpm workspaces for the core monorepo; satellite repos (integrations, adapters) auto-add to the roadmap project via GitHub Actions
-- Labels are org-wide and enforced consistently
-
-## Common Pitfalls
-
-| Pitfall | Why It Happens | How to Avoid |
-|---------|---------------|--------------|
-| Project scope creep | One project tracks everything; becomes unusable | One project per initiative or quarter; archive completed projects |
-| Label inconsistency across repos | Each repo grows its own labels organically | Manage labels programmatically; use a shared label config script or action |
-| Missing automation tokens | PATs expire or lack correct scopes; cross-repo actions silently fail | Use fine-grained PATs with explicit `project` scope; rotate with secrets manager |
-| Stale items clogging board | Closed issues not archived; old PRs linger | Enable auto-archive: set staleness to 14 days or archive on close/merge |
-| No triage process | New issues pile up without status | Add "Needs Triage" as default status; automate: new issue → Needs Triage |
-| Cross-repo sub-issue confusion | Contributors open sub-issues in wrong repo | Document in CONTRIBUTING.md which repo to use for which issue type |
-| Workflow count limits on Free plan | Only 1 built-in workflow on Free | Use GitHub Actions instead of built-in workflows for more rules |
-| Views not shared with team | Each person builds their own view | Create named saved views in the project for common filters (My Items, This Sprint, Blocked) |
-
-## Best Practices
-
-1. **One source of truth per initiative** - Each major feature or release gets exactly one project. Avoid tracking the same item in multiple projects.
-
-2. **Standardize labels org-wide** - Use a label sync action (e.g., `EndBug/add-or-update-label`) to keep labels consistent across all repos. Document the label taxonomy in a `CONTRIBUTING.md` or `.github` repo.
-
-3. **Use Issue Types instead of type labels** - Now that Issue Types are available (Jan 2025 public preview), prefer them over label conventions for `bug`, `feature`, `task`. Labels are better for priority, status, and component.
-
-4. **Automate triage with GitHub Actions** - New issues opened in any repo auto-add to the org triage project with status "Needs Triage". Maintainers process the triage board, not individual repos.
-
-5. **Keep the roadmap project public** - A public roadmap project builds contributor trust and reduces duplicate "when will X be done?" issues. Model: GitHub's own public roadmap.
-
-6. **Use Iteration fields for sprints or releases** - Iterations are time-boxed periods (e.g., 2-week sprints). Assign items to iterations instead of milestones for better burndown tracking.
-
-7. **Multiple saved views per audience** - Create views for: "My open items" (assignee filter), "This sprint" (iteration filter), "Blocked" (status filter), "Triage queue" (status = Needs Triage).
-
-8. **Sub-issues for epics, not just labels** - Break large epics into sub-issues rather than relying on a checklist in the parent body. Progress tracking is automatic and cross-repo linking is supported.
-
-9. **Automate status transitions** - Configure built-in workflows: PR merged → item status set to Done. Issue closed as not-planned → item archived. This removes manual housekeeping.
-
-10. **Use the `.github` meta-repo** - A `.github` repo in the org stores default issue templates, PR templates, `CONTRIBUTING.md`, and Actions workflows that apply to all repos with no files.
-
-## Field Design for Multi-Repo Projects
-
-Recommended custom fields for an org-level project:
-
-| Field Name | Type | Values / Notes |
-|------------|------|----------------|
-| Status | Single Select | Triage, Backlog, In Progress, In Review, Done, Blocked |
-| Priority | Single Select | Critical, High, Medium, Low |
-| Sprint / Iteration | Iteration | 2-week cadence |
-| Effort | Single Select | XS, S, M, L, XL |
-| Component | Single Select | Per-repo or per-area (e.g., Core, Docs, CLI, API) |
-| Target Release | Single Select | v1.0, v1.1, Backlog |
-| Repo | Text | Auto-populated via automation (helps when filtering Table view) |
-
-## GitHub Actions Automation Recipes
-
-### Auto-Set Status to "In Progress" When PR Opened
-
-```yaml
-name: PR Opened - Set In Progress
-
-on:
-  pull_request:
-    types: [opened, reopened]
-
-jobs:
-  update-project:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Move linked issues to In Progress
-        uses: actions/github-script@v7
-        with:
-          github-token: ${{ secrets.PROJECT_PAT }}
-          script: |
-            // Use GraphQL to find project item for this PR and update status
-            // Implementation varies by project ID and field IDs
-```
-
-### Sync Org Labels Across All Repos
-
-```yaml
-# Run in the .github meta-repo
-name: Sync Labels
-
-on:
-  push:
-    paths: ['labels.yml']
-  schedule:
-    - cron: '0 2 * * 1'  # Weekly Monday 2am
-
-jobs:
-  sync:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: EndBug/label-sync@v2
-        with:
-          config-file: labels.yml
-          delete-other-labels: false
-          token: ${{ secrets.LABEL_SYNC_PAT }}
-          # Applies to all repos accessible to the PAT
-```
-
-## Further Reading
-
-| Resource | Type | Why Recommended |
-|----------|------|-----------------|
-| [GitHub Projects Docs](https://docs.github.com/en/issues/planning-and-tracking-with-projects) | Official Docs | Canonical reference for all Projects v2 features |
-| [GitHub's Public Roadmap](https://github.com/orgs/github/projects/4247) | Live Example | See how GitHub itself manages a public org project |
-| [actions/add-to-project](https://github.com/actions/add-to-project) | GitHub Action | Official action for cross-repo auto-add |
-| [Kubernetes SIG structure](https://github.com/kubernetes/community/blob/master/sig-list.md) | Reference | How Kubernetes scales to 100+ repos with SIGs |
-| [withastro/roadmap](https://github.com/withastro/roadmap) | Reference | Astro's RFC and roadmap coordination model |
-| [GitHub Issues API (GraphQL)](https://docs.github.com/en/graphql/reference/mutations#addprojectv2itembyid) | API Docs | GraphQL mutations for project automation |
-| [EndBug/label-sync](https://github.com/EndBug/label-sync) | GitHub Action | Sync labels across all org repos |
-
----
-
-*This guide was synthesized from research on GitHub Projects v2, Issue Types, Sub-Issues, GraphQL API, and real-world org patterns (Rust-lang, Kubernetes, Astro, GitHub). See `resources/github-org-project-management-sources.json` for full source list.*

package/agent-knowledge/github-org-structure-patterns.md

@@ -1,268 +0,0 @@
-# Learning Guide: GitHub Organization Structure Patterns for Developer Tool Ecosystems
-
-**Generated**: 2026-02-21
-**Sources**: 18 resources analyzed
-**Depth**: deep
-
-## Prerequisites
-
-- Familiarity with GitHub repositories and basic git workflows
-- Understanding of GitHub Actions concepts (workflows, triggers)
-- Basic knowledge of open source project conventions (CONTRIBUTING, CODE_OF_CONDUCT)
-
-## TL;DR
-
-- The `.github` org (public repo) is the control plane for org-wide defaults: community health files, reusable workflows, profile README, and starter workflows
-- Real-world orgs fall into two archetypes: **focused** (few high-quality repos, e.g. oven-sh/Bun) and **ecosystem** (many small packages, e.g. unjs, sindresorhus)
-- Reusable workflows (`workflow_call`) are the primary mechanism for DRY CI across many repos in an org
-- CODEOWNERS + working groups (teams) is the dominant governance pattern for monorepos
-- AI usage disclosure policies are becoming a new category of org-level community health file
-
-## Core Concepts
-
-### The `.github` Repository as Org Control Plane
-
-Every GitHub org has a special `.github` repository that acts as the configuration and defaults layer for the entire org.
-
-**Profile README** (`profile/README.md`):
-- Public-facing org description shown on the org's GitHub page
-- Supports full markdown: badges, images, links, embedded stats
-- A separate `.github-private` repo can hold a `profile/README.md` visible only to org members — useful for internal runbooks and links
-
-**Default Community Health Files**:
-The `.github` repo (which MUST be public to cascade org-wide) can define default files that apply to every repo in the org that does not override them:
-
-| File | Purpose |
-|------|---------|
-| `CODE_OF_CONDUCT.md` | Community behavior standards |
-| `CONTRIBUTING.md` | How to contribute |
-| `FUNDING.yml` | Sponsorship links |
-| `GOVERNANCE.md` | Decision-making processes |
-| `SECURITY.md` | Vulnerability reporting policy |
-| `SUPPORT.md` | Where to get help |
-| Issue templates | Default issue forms |
-| PR templates | Default PR descriptions |
-
-**Important caveat**: If any individual repo has ANY files in its own `.github/ISSUE_TEMPLATE/` directory, the org-level issue template defaults no longer apply to that repo. The override is all-or-nothing per file type.
-
-**What cannot be org defaults**: License files must be defined per-repo.
-
-### Org-Level Pinned Repositories
-
-Orgs can pin up to 6 repositories on their public profile page. A separate set of up to 6 pins can be configured for the member-only view. Use pins to surface:
-- The primary product repo
-- The standard library or docs repo
-- Developer tooling repos (actions, setup tools, homebrew taps)
-- Community/contribution entry points (roadmap, good-first-issues)
-
-### Reusable GitHub Actions Workflows
-
-Reusable workflows eliminate CI duplication across many repos in an org. They use the `workflow_call` trigger.
-
-**Reference syntax**:
-```yaml
-jobs:
-  call-shared-workflow:
-    uses: myorg/.github/.github/workflows/ci.yml@main
-    with:
-      node-version: "22"
-    secrets: inherit
-```
-
-**Key constraints and features**:
-- Maximum 10 nesting levels (reusable workflows calling other reusable workflows)
-- Permissions can only be maintained or reduced, never elevated
-- `secrets: inherit` passes the caller's secrets implicitly — preferred for org-internal workflows
-- Matrix strategies are supported in callers
-- Inputs and outputs are typed (string, boolean, number, choice)
-
-**Pattern**: Keep reusable workflows in the org `.github` repo under `.github/workflows/`, then reference `{owner}/.github/.github/workflows/{name}.yml@{ref}`.
-
-### Starter Workflows
-
-Starter workflows appear in the "Actions" tab of new repos as suggested templates. They live in the `.github` repo under `workflow-templates/`.
-
-Each starter workflow requires two files:
-- `workflow-templates/{name}.yml` — the workflow definition
-- `workflow-templates/{name}.properties.json` — metadata (name, description, iconName, categories)
-
-**Five categories**: CI, Deployments, Automation, Code-scanning, Pages
-
-Variable substitution is supported: `$default-branch` resolves to the repo's default branch, `$cron-daily` to a daily cron expression.
-
-### CODEOWNERS and Working Groups
-
-CODEOWNERS files define who must review changes to specific paths. The **last matching pattern wins** (bottom-to-top precedence).
-
-**Tauri's two-team pattern** (simple and effective):
-```
-# .github/CODEOWNERS
-* @tauri-apps/wg-tauri
-.github @tauri-apps/wg-devops
-```
-
-This gives the main working group ownership of all code, while the DevOps working group exclusively owns CI and tooling changes — preventing accidental breakage of infrastructure by feature contributors.
-
-**Common patterns**:
-- `docs/ @org/docs-team` — separate docs ownership
-- `*.rs @org/core-team` — language-specific ownership
-- `/packages/plugin-* @org/plugin-maintainers` — plugin subsystem
-
-### GitHub Pages for Orgs
-
-| Type | Repo Name | URL |
-|------|-----------|-----|
-| Org site | `<owner>.github.io` | `https://<owner>.github.io` |
-| Project site | any repo | `https://<owner>.github.io/<repo>` |
-
-One org site per account. Custom domains are supported on all tiers. Free plan limits Pages to public repos.
-
-## Real-World Org Archetypes
-
-### The Focused Minimal Org (oven-sh / Bun)
-
-- ~7 visible repos: primary product, community list, setup action, homebrew tap, essential forks
-- High signal-to-noise: every repo has clear purpose
-- Pinned repos do the navigation work
-- Setup tooling (`setup-bun`) is a first-class citizen in the org
-
-**When to use**: Single primary product with companion tooling. Avoid repo sprawl that dilutes contributor attention.
-
-### The Ecosystem Org (denoland / Deno)
-
-- 216+ repos: runtime, standard library, framework (Fresh), toolchains, bindings
-- Standard library (`deno_std`) is its own monorepo, separately versioned
-- Distinct registries: Deno now publishes std to JSR (JavaScript Registry) alongside npm
-- Verified domain lends authority to the org
-
-**When to use**: Platform-level products where many independent but related modules need separate release cycles.
-
-### The Framework Org (withastro / Astro)
-
-- ~51 repos: core framework, docs site, compiler (separate language), roadmap (RFC process), deployment action, Starlight docs builder
-- `roadmap` repo used for public RFCs and planning — community-facing project management
-- pnpm workspaces for monorepo dependency management
-- `astro-action` for GitHub Pages deployment
-
-**When to use**: Frameworks with distinct subsystems (compiler, runtime, CLI) that benefit from separate contribution histories but shared releases.
-
-### The Working Group Org (tauri-apps)
-
-- Working groups as GitHub Teams: `wg-tauri`, `wg-devops`
-- CODEOWNERS maps paths to working groups
-- Monorepo with clear subsystem ownership
-
-**When to use**: Mature projects with specialized contributor groups. Teams enforce review requirements automatically.
-
-### The Utility Library Ecosystem (unjs / sindresorhus)
-
-- Dozens to hundreds of small, focused packages
-- Each package is its own repo with its own release cycle
-- Org profile README serves as the package index
-- Contributing to any package follows org-wide defaults from `.github`
-
-**When to use**: Utility ecosystems where each package solves one problem and has independent users.
-
-## Contributing Guide Patterns
-
-### Setup Complexity Tiers
-
-**Lightweight** (JS/TS projects like Astro):
-- Requires: Node >=22.12, pnpm >=10.28
-- GitHub Codespaces support for zero-install onboarding
-- Single `pnpm install && pnpm build` setup
-
-**Heavy** (compiled projects like Bun):
-- Requires: LLVM 21.1.8 (specific version), Zig (auto-installed by build script)
-- 10-30 minute first setup expectation set explicitly
-- Debug build alias (`bun bd`) documented prominently
-
-### Priority Labels
-
-Astro uses a p1-p5 priority scale for issues. This is more expressive than simple priority/non-priority and helps maintainers triage community PRs.
-
-### Branch Targeting Conventions
-
-Biome targets changes to `main` or `next` depending on stability. This should be explicitly documented — contributors who target the wrong branch create merge conflicts.
-
-### AI Contribution Policies
-
-Emerging pattern (Biome, OXC): explicit AI usage disclosure in CONTRIBUTING.md:
-
-- **Biome approach**: AI disclosure as the first section — sets tone before anything else
-- **OXC approach**: AI accountability policy — contributor is responsible for all AI-generated code quality, must review and test it, cannot use AI generation as excuse for quality issues
-
-This is becoming a community health default to consider for new orgs in 2025+.
-
-### Just Commands (Biome pattern)
-
-Using `just` (Justfile) for project commands standardizes the contributor experience across platforms:
-```
-just build
-just test
-just lint
-```
-Avoids npm script confusion and works identically in all shells.
-
-### Changesets for Versioning
-
-Biome and others use Changesets for coordinated multi-package version management. Contributors add a changeset file alongside their PR describing the change type (major/minor/patch), and release automation assembles the changelog.
-
-## Common Pitfalls
-
-| Pitfall | Why It Happens | How to Avoid |
-|---------|---------------|--------------|
-| Org defaults silently overridden | Repo has any file in `.github/ISSUE_TEMPLATE/` | Audit all repos; prefer org defaults where possible |
-| `.github` repo is private | Created as private by default | Must be public for defaults to cascade |
-| CODEOWNERS pattern order wrong | Assuming first match wins | Remember: last matching pattern wins |
-| Reusable workflow permissions escalation | Caller tries to grant more than caller has | Permissions are only reducible, never elevated |
-| Workflow nesting beyond 10 levels | Over-decomposed reusable workflows | Flatten; use composite actions for deeply nested logic |
-| Pinned repos not updated post-launch | Set once and forgotten | Review pins at each major release |
-| Contributing guide assumes one platform | Windows contributors fail silently | Test setup steps on Windows or document platform limits |
-
-## Best Practices
-
-1. **Create `.github` repo first** — Before any other repo. It's the org's foundation. (Source: GitHub Docs)
-2. **Pin repos strategically** — Primary product + setup action + docs + roadmap covers most navigation needs. (Source: oven-sh, withastro patterns)
-3. **Use working groups as GitHub Teams** — Map CODEOWNERS to teams, not individuals. Individuals leave; teams persist. (Source: tauri-apps)
-4. **Set contributing guide setup time expectations explicitly** — "This takes 10-30 minutes" prevents contributor abandonment. (Source: Bun contributing guide)
-5. **Add AI contribution policy early** — Easier to establish norms before your first AI-assisted PR than after. (Source: Biome, OXC)
-6. **Use `secrets: inherit` for org-internal reusable workflows** — Avoids secret enumeration and future maintenance. (Source: GitHub Actions docs)
-7. **Separate the standard library / docs into its own repo** — Deno, Astro, and others all do this. Separate release cadence, separate contributors. (Source: denoland, withastro)
-8. **Use a `roadmap` repo for public RFCs** — Gives contributors a place to discuss direction without polluting the main issue tracker. (Source: withastro)
-9. **Verify your org's domain** — GitHub org domain verification adds authority and enables SAML SSO. (Source: denoland example)
-10. **Consider Changesets from day one** — Retrofitting automated versioning is painful; starting with it is cheap. (Source: Biome pattern)
-
-## Org Structure Decision Guide
-
-```
-Single product?
-├── Yes → Focused minimal org (oven-sh model)
-│         Repos: product + setup-action + homebrew-tap + awesome-list
-└── No → Multiple products?
-         ├── Related subsystems → Framework org (withastro model)
-         │   Repos: core + compiler + docs + action + roadmap
-         ├── Many small utilities → Ecosystem org (unjs model)
-         │   Each utility = own repo, org README = index
-         └── Large platform → Ecosystem org (denoland model)
-             Repos: runtime + std + frameworks + toolchains
-```
-
-## Further Reading
-
-| Resource | Type | Why Recommended |
-|----------|------|-----------------|
-| [GitHub: Default community health files](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file) | Official Docs | Primary reference for `.github` repo mechanics |
-| [GitHub: Reusing workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) | Official Docs | Complete `workflow_call` reference with constraints |
-| [GitHub: Starter workflows](https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization) | Official Docs | How to create org-level workflow templates |
-| [withastro org](https://github.com/withastro) | Example | Framework org archetype with roadmap pattern |
-| [tauri-apps CODEOWNERS](https://github.com/tauri-apps/tauri/blob/dev/.github/CODEOWNERS) | Example | Working group CODEOWNERS pattern |
-| [biomejs CONTRIBUTING.md](https://github.com/biomejs/biome/blob/main/CONTRIBUTING.md) | Example | AI disclosure + just commands pattern |
-| [oxc-project CONTRIBUTING.md](https://github.com/oxc-project/oxc/blob/main/CONTRIBUTING.md) | Example | AI accountability policy |
-| [denoland org](https://github.com/denoland) | Example | Large ecosystem org structure |
-| [unjs org](https://github.com/unjs) | Example | Utility ecosystem, many small packages |
-| [GitHub: About CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) | Official Docs | CODEOWNERS syntax and precedence rules |
-
----
-
-*This guide was synthesized from 18 sources. See `resources/github-org-structure-patterns-sources.json` for full source list.*