Recommended architecture for shared organizational standards across private AIDD plugins

[waewoo]

Recommended architecture for shared organizational standards across private AIDD plugins

Hi,

I'm exploring how to structure a private AIDD marketplace for an organization with multiple teams, technologies, and shared engineering standards.

The idea is to provide independent, domain-specific plugins, for example:

• DevOps — Airflow, Terraform, Ansible, CI/CD practices.
• Quality — code quality, testing, reviews, maintainability.
• Security — secrets management, secure configuration, compliance.
• Operations — troubleshooting, observability, runbooks.

Before implementing this, I'd like to understand the architecture AIDD recommends for organizing, sharing, and distributing standards across these plugins.

The challenge

Some engineering standards belong to multiple domains.

For example:

• Airflow DAG retry, timeout, and error-handling conventions (Airflow + Quality).
• Terraform security and maintainability requirements (Terraform + Security + Quality).
• Prohibiting hardcoded secrets across all technologies (cross-cutting Security).

This raises two related questions:

1. Ownership: Where should a standard live when it belongs to both a technology and a cross-cutting concern?
2. Reuse and distribution: How can multiple independent plugins apply the same standard without duplicating its maintained source or introducing tight coupling?

For example, if an Airflow quality rule is owned by the DevOps plugin, how should a Quality plugin use it?

Copying the rule into both plugins risks drift. Directly referencing another plugin's internal files conflicts with AIDD's cross-plugin orthogonality and skill portability principles.

What I found in the current AIDD implementation

I reviewed the architecture documentation and the relevant implementation on next.

AIDD already provides several mechanisms:

• Skill references: Supporting documentation can live in skills/<skill>/references/, with links kept within the skill directory for portability.
• Plugin rules: Canonical plugin rules live under plugins/<plugin>/rules/.
• Project rules: aidd-context maintains canonical project rules in aidd_docs/rules/ and supports publication to host-specific instruction surfaces.
• Cross-plugin isolation: Capabilities are discovered by responsibility rather than through hardcoded references to another plugin's internal files.

There are also relevant host-specific limitations:

• Kilo Code and OpenCode use flat distribution rather than native marketplace layouts.
• On next, both flat build contracts still declare plugin rules and commands as unsupported.
• feat(cli): emit rules in Kilo flat builds #1069 introduces Kilo flat rule distribution, including publication into .kilo/rules/ and registration in kilo.json[c].instructions. It is a related improvement, but does not address sharing one canonical standards source across multiple plugins.
• The existing project-rule publication mechanism provides a possible consumption boundary, but does not automatically distribute an organization-wide standards catalog across projects.

I couldn't identify a documented mechanism that resolves shared organizational standards from a private marketplace into multiple independent plugins.

Possible architectures

I see three potential approaches:

1. Plugin-owned standards

Each plugin owns the standards relevant to its responsibility. Other plugins discover and invoke its capabilities when needed, without reading internal files.

This maintains plugin isolation, but raises questions about how independent quality or security checks access all applicable standards.

2. Centralized standards with build-time packaging

A separate, versioned standards source is maintained centrally. Relevant standards are packaged into self-contained skills or published as host-native rules during distribution.

This preserves a single maintained source and standalone plugin execution, but requires a build or publication mechanism.

3. Shared project-level rules

Organization-wide standards are selected and published into each consuming project's rule surfaces.

Independent plugins then discover applicable project rules without depending on each other.

This seems aligned with AIDD's existing separation between project rules and plugin capabilities, but would still require a strategy for distribution, versioning, updates, overrides, and drift detection.

For illustration, a private marketplace could conceptually look like:

coe-marketplace/
├── standards/
│   ├── airflow/
│   │   ├── quality.md
│   │   └── security.md
│   ├── terraform/
│   │   └── quality.md
│   └── global/
│       └── security.md
└── plugins/
    ├── devops/
    ├── quality/
    └── security/

This is only a conceptual source layout, not an assumption that AIDD currently supports root-level shared standards or automatic packaging.

Related work

Several existing issues seem relevant:

• spike(framework): validate a portable project-policy boundary #585 — Portable project-policy boundary.
• refactor(framework): the tool declarations live in two copies, because an install carries only some directories #702 — Shared resource duplication caused by skill isolation and installation boundaries.
• spike(framework): define the portability boundary for agent artifacts #929 — Artifact portability and reuse across AI hosts.
• ci(framework): mechanically enforce cross-plugin orthogonality on PRs #250 — Cross-plugin orthogonality.
• feat(aidd-context): audit an existing rule corpus for conflicts, duplication and drift #792 — Rule corpus consistency, overlap, and duplication.
• feat(cli): emit rules in Kilo flat builds #1069 — Kilo flat rule distribution (PR).

These address individual aspects of the problem, but I couldn't identify a complete recommended pattern for organization-wide standards shared by multiple private plugins.

Questions

1. Ownership: Should technology-specific quality and security standards belong to the technology plugin, or to the cross-cutting Quality/Security plugins?

2. Preferred architecture: Is publishing centrally maintained standards into project-level rules the intended way for independent plugins to consume shared policies? Or is another pattern recommended?

3. Distribution and portability: Should shared standards be packaged into consuming skills, published into host-native rule surfaces, or handled through another supported mechanism, especially for flat-only hosts such as Kilo Code and OpenCode?

4. Existing support vs. extension: Is there already an AIDD-supported approach I may have missed, or would this require a separate packaging/publication capability?

I'm primarily looking for architectural guidance before implementing custom infrastructure, rather than proposing a new framework feature at this stage.

Thanks!