You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While exploring several topics around Rules, context engineering, architecture and orchestration, I realized that individual issues make it difficult to see the overall capability landscape of AIDD.
Rather than proposing another feature, I tried to map:
what AIDD already provides;
what is partially covered;
what is already tracked by an issue, PR or discussion;
what appears to be uncovered;
and, most importantly, what may be intentionally outside AIDD's scope.
Important
This is not a proposal that AIDD should implement every missing capability.
Some apparent gaps may be intentional boundaries. Identifying and documenting those boundaries is one of the main purposes of this discussion.
Note
Snapshot: this map reflects the main branch as reviewed on 2026-09-12.
AIDD is evolving quickly, so some statuses or tracked work may naturally change after this discussion is posted.
The complete matrix below is intended as a reference. I don't expect every row to be discussed individually.
🎯 Questions for roadmap discussion
Rather than reviewing the whole matrix line by line, I think four higher-level questions could help clarify AIDD's direction.
1. Rules & context governance
Does AIDD intend to own the complete lifecycle of agent context, not only creating Rules, Memory and other context artifacts, but also keeping the resulting context system coherent over time?
Several existing issues appear to form a possible lifecycle:
If yes, do these issues represent complementary parts of that lifecycle, or should some of them be consolidated differently?
2. Context efficiency
AIDD already encourages concise context and token-conscious authoring.
#792 and #793 also address unnecessary, duplicated or misplaced persistent context.
But there seems to be another possible level:
Should AIDD reason about the context actually consumed by a task?
For example:
what context was loaded;
why it was loaded;
whether it was relevant;
whether some of it was redundant;
whether information should have been loaded on demand instead;
whether context effectiveness can be measured alongside token consumption.
This is different from simply minimizing context size:
Context efficiency ≠ smallest possible context
Context effectiveness =
useful project-specific information
───────────────────────────────────
context consumed by the task
Is this an AIDD concern, a host/harness concern, or intentionally out of scope?
3. Living architecture
AIDD already provides several architecture-related capabilities:
bootstrap / initial architecture;
planning;
architecture assertions;
architecture audits;
architecture refactoring;
Mermaid diagrams;
human/agent-readable architecture knowledge through Project Memory.
What seems different is maintaining a persistent machine-readable architecture model:
Repository
⇅
Architecture model
⇅
Documentation / agent context
Possible capabilities would include:
deriving/updating the model from the repository;
detecting architecture model ↔ code drift;
using the model during planning/review;
potentially reasoning across repositories.
This is intentionally not a proposal for LikeC4, Archify or any particular tool.
The question comes first:
Does maintaining a living architecture model belong to AIDD at all?
If not, should AIDD instead define how external architecture sources are consumed?
Should AIDD workflows remain internal skills/orchestrators, expose a portable representation, or simply provide adapters when external orchestrators need them?
Existing architecture audit is code-oriented, not model↔code synchronization
—
⬜ / ❓
Cross-repository architecture model
—
—
⬜ / ❓
The last rows should not automatically be interpreted as feature requests.
A possible boundary could be that AIDD consumes architecture models maintained by external tooling rather than owning an architecture-modeling system itself.
AIDD telemetry covers more than cost reporting: its hooks provide a run/session journal that can connect work performed by AI tools to project/task context and measurement.
Cost/token data is not equivalent to relevance/effectiveness
—
⬜ / ❓
Evaluate AIDD workflow effectiveness
Individual outputs can be asserted/audited; no framework-level evaluation identified
—
⬜ / ❓
There is an important distinction between several kinds of observability:
Execution telemetry
│
└── What happened?
Which task/session?
Which model/tool/step?
How much did it cost?
Rule observability (#796)
│
└── Which Rule materially influenced
which Decision
and which Artifact?
Context effectiveness
│
└── Was the context loaded for this task
actually useful?
Framework effectiveness
│
└── Is using the AIDD workflow improving
quality / iterations / rework / cost?
These appear complementary rather than duplicate capabilities.
🔌 Tool / host support
Capability
Current support
Tracking
Status
Claude Code
Native marketplace/plugin model
—
✅
Codex
Existing AIDD tool/build support
—
✅
Cursor
Existing AIDD tool/build support
—
✅
GitHub Copilot
Existing AIDD tool/build support
—
✅
OpenCode
Existing support with host-specific lifecycle limitations
Host support is therefore another area where many apparent gaps are already known and tracked.
🧭 Potential capability boundaries
After separating capabilities that already exist from those already tracked, the remaining questions seem less like a list of missing features and more like ownership boundaries.
For each one, the useful question may be:
OWN — AIDD considers the capability part of the framework;
INTEGRATE — another system owns the capability, while AIDD interoperates with it;
EXCLUDE — the capability is intentionally outside AIDD's scope.
Capability
Existing coverage
Tracking
Status
Ownership question
Persistent machine-readable architecture model
Architecture Memory + Mermaid cover different concerns
—
❓
OWN / INTEGRATE / EXCLUDE
Architecture model ↔ code drift
Code architecture audit exists, but not model synchronization
Outputs can be tested/audited and execution measured
—
❓
OWN / EXCLUDE
Note
None of these rows means “AIDD should implement this.”
A useful outcome may be explicitly deciding that some capabilities should remain external or outside the framework.
🧭 From discussion to durable decisions
One concern with capability discussions like this is that their conclusions can eventually become difficult to rediscover.
For example, the community might decide that:
AIDD owns Rule and context governance;
AIDD does not own architecture modeling but integrates with architecture sources;
external workflow engines own graphical execution while AIDD owns SDLC semantics;
another capability should explicitly remain outside AIDD.
Those are not merely implementation choices.
They are durable framework boundary decisions.
AIDD already has a mechanism for capturing durable learnings and decisions through aidd-context:10-learn.
The current decision destination used by 10-learn is:
aidd_docs/memory/internal/decisions/<slug>.md
Decision records can preserve elements such as:
context;
decision;
alternatives;
consequences;
superseded / superseding decisions.
So if this discussion results in clear boundaries, would it make sense to capture them through the existing decision mechanism rather than leaving them only in a GitHub discussion?
A useful boundary model could be:
Capability
│
┌──────────┼──────────┐
▼ ▼ ▼
OWN INTEGRATE EXCLUDE
│ │ │
AIDD provides │ intentionally
the capability │ out of scope
│
external system
owns capability;
AIDD may interact
through adapters
For example:
Living architecture
│
└── INTEGRATE
│
└── AIDD may consume/update an external
architecture model but does not own
the architecture modeling system.
or:
Rules governance
│
└── OWN
│
└── AIDD owns creation, consistency,
application and verification of Rules.
The exact decisions obviously belong to the maintainers/community.
The suggestion is only that once a boundary has been decided, it becomes durable project knowledge rather than remaining buried in an issue or discussion.
This could then provide a simple decision path for future proposals:
New capability proposal
│
▼
Existing boundary decision?
/ \
yes no
│ │
▼ ▼
follow discuss
OWN / boundary
INTEGRATE /
EXCLUDE
❓ What I would like to validate
The goal is not to create more issues from every uncovered row.
I'd first like to understand whether this capability map broadly reflects AIDD today and where the framework's intended boundaries are.
In particular:
Are some capabilities marked partial/TBD actually already covered somewhere I missed?
Is Rules & Context Governance a concern AIDD intends to own end-to-end?
Should task-level context effectiveness be an AIDD capability or remain a host/harness responsibility?
Should AIDD maintain a living architecture model, or consume external architecture sources instead?
Where should AIDD orchestration stop relative to external workflow engines?
Are knowledge freshness concerns beyond AIDD's own tool references something the framework should own?
Does evaluating the effectiveness of AIDD workflows themselves belong to AIDD, or should AIDD stop at output validation and execution telemetry?
Which remaining capability boundaries should explicitly be classified as OWN, INTEGRATE, or EXCLUDE?
When those boundaries are decided, should they be captured through 10-learn as durable decisions so they remain discoverable?
If the high-level ownership of those areas can be clarified, the detailed matrix can then be updated accordingly without having to discuss every row individually.
💡 Possible outcome
The useful outcome of this discussion might therefore be less:
Gap
↓
New issue
↓
Implementation
and more:
Capability map
│
▼
Clarify ownership
│
┌────┼─────────┐
▼ ▼ ▼
OWN INTEGRATE EXCLUDE
│ │ │
└──────┼─────────┘
▼
Durable boundary decision
│
▼
Issues only where implementation
is actually required
As AIDD grows, documenting what the framework intentionally does not own may become almost as useful as documenting what it does.
A lightweight capability map combined with durable boundary decisions could make it easier to:
understand AIDD's scope;
avoid duplicate issues;
identify existing skills before proposing new ones;
connect related issues and discussions;
reason about roadmap priorities;
distinguish framework responsibilities from integration responsibilities;
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
While exploring several topics around Rules, context engineering, architecture and orchestration, I realized that individual issues make it difficult to see the overall capability landscape of AIDD.
Rather than proposing another feature, I tried to map:
Important
This is not a proposal that AIDD should implement every missing capability.
Some apparent gaps may be intentional boundaries. Identifying and documenting those boundaries is one of the main purposes of this discussion.
Note
Snapshot: this map reflects the
mainbranch as reviewed on 2026-09-12.AIDD is evolving quickly, so some statuses or tracked work may naturally change after this discussion is posted.
The complete matrix below is intended as a reference. I don't expect every row to be discussed individually.
🎯 Questions for roadmap discussion
Rather than reviewing the whole matrix line by line, I think four higher-level questions could help clarify AIDD's direction.
1. Rules & context governance
Does AIDD intend to own the complete lifecycle of agent context, not only creating Rules, Memory and other context artifacts, but also keeping the resulting context system coherent over time?
Several existing issues appear to form a possible lifecycle:
The high-level question is:
If yes, do these issues represent complementary parts of that lifecycle, or should some of them be consolidated differently?
2. Context efficiency
AIDD already encourages concise context and token-conscious authoring.
#792 and #793 also address unnecessary, duplicated or misplaced persistent context.
But there seems to be another possible level:
For example:
This is different from simply minimizing context size:
Is this an AIDD concern, a host/harness concern, or intentionally out of scope?
3. Living architecture
AIDD already provides several architecture-related capabilities:
What seems different is maintaining a persistent machine-readable architecture model:
Possible capabilities would include:
This is intentionally not a proposal for LikeC4, Archify or any particular tool.
The question comes first:
If not, should AIDD instead define how external architecture sources are consumed?
4. Workflow / orchestration boundary
AIDD already provides orchestration through:
aidd-orchestrator:00-async-devaidd-orchestrator:01-sdlcaidd-orchestrator:02-backlogSo orchestration itself is clearly not missing.
The boundary I'm unsure about is one level above:
There is already a related discussion:
The question is:
Should AIDD workflows remain internal skills/orchestrators, expose a portable representation, or simply provide adapters when external orchestrators need them?
🗺️ Capability map
Legend
main🧠 Context engineering
aidd-context:00-onboardaidd-context:01-bootstrapaidd-context:02-project-memoryaidd-context:03-context-generateaidd-context:04-skill-generateaidd-context:05-rule-generateaidd-context:06-agent-generateaidd-context:07-command-generateaidd-context:08-hook-generateaidd-context:09-mermaidaidd-context:10-learn10-learnassessment / routing10-learn→memory/internal/decisions/10-learndecision reconciliationaidd-context:11-exploreaidd-context:12-cookThis suggests that context governance may have at least three related dimensions:
📏 Rules lifecycle
aidd-context:05-rule-generate05-rule-generateaidd-dev:05-reviewPossible Rules lifecycle
Seen this way, these issues appear to address different stages of the same lifecycle rather than duplicate each other.
🛠️ Development lifecycle
aidd-dev:01-planaidd-dev:02-implementaidd-dev:03-assertaidd-dev:03-assertaidd-dev:04-auditaidd-dev:04-auditaidd-dev:04-auditaidd-dev:04-auditaidd-dev:04-auditaidd-dev:04-auditaidd-dev:04-auditaidd-dev:05-reviewaidd-dev:05-reviewaidd-dev:06-testaidd-dev:06-testaidd-dev:07-refactoraidd-dev:07-refactoraidd-dev:07-refactoraidd-dev:07-refactoraidd-dev:08-debugaidd-dev:09-for-sureaidd-dev:10-todoaidd-dev:11-browser-qaThis appears to be one of AIDD's strongest and most complete capability areas.
📦 Product management
aidd-pm:01-ticket-infoaidd-pm:02-user-storiesaidd-pm:03-prdaidd-pm:04-specaidd-pm:05-spikeaidd-pm:06-product-briefaidd-pm:07-epicaidd-pm:08-three-amigosaidd-pm:09-defectaidd-pm:10-task🧩 Refinement / meta-cognition
aidd-refine:01-brainstormaidd-refine:02-challengeaidd-refine:03-shadow-areasaidd-refine:04-fact-check🌿 Version control
aidd-vcs:00-repo-initaidd-vcs:01-commitaidd-vcs:02-pull-requestaidd-vcs:03-release-tagaidd-vcs:04-issue-create🏗️ Architecture
aidd-context:01-bootstrapaidd-dev:01-planaidd-dev:03-assertaidd-dev:04-auditaidd-dev:07-refactorarchitecture.mdaidd-context:09-mermaidThe last rows should not automatically be interpreted as feature requests.
A possible boundary could be that AIDD consumes architecture models maintained by external tooling rather than owning an architecture-modeling system itself.
🔄 Orchestration
aidd-orchestrator:00-async-devaidd-orchestrator:01-sdlcaidd-orchestrator:02-backlogThe question is therefore not whether AIDD has orchestration. It does.
The question is where the orchestration boundary should be.
🎨 UI / UX
AIDD's current UI plugin is still alpha/smoke-test level, while a broader implementation is being developed in:
feat(aidd-ui): govern UI systems and experience contractsaidd-ui:01-hellomain📊 Telemetry & observability
AIDD telemetry covers more than cost reporting: its hooks provide a run/session journal that can connect work performed by AI tools to project/task context and measurement.
aidd-telemetry:00-initaidd-telemetry:01-costaidd-telemetry:02-checkThere is an important distinction between several kinds of observability:
These appear complementary rather than duplicate capabilities.
🔌 Tool / host support
Host support is therefore another area where many apparent gaps are already known and tracked.
🧭 Potential capability boundaries
After separating capabilities that already exist from those already tracked, the remaining questions seem less like a list of missing features and more like ownership boundaries.
For each one, the useful question may be:
Note
None of these rows means “AIDD should implement this.”
A useful outcome may be explicitly deciding that some capabilities should remain external or outside the framework.
🧭 From discussion to durable decisions
One concern with capability discussions like this is that their conclusions can eventually become difficult to rediscover.
For example, the community might decide that:
Those are not merely implementation choices.
They are durable framework boundary decisions.
AIDD already has a mechanism for capturing durable learnings and decisions through
aidd-context:10-learn.The current decision destination used by
10-learnis:Decision records can preserve elements such as:
So if this discussion results in clear boundaries, would it make sense to capture them through the existing decision mechanism rather than leaving them only in a GitHub discussion?
A useful boundary model could be:
For example:
or:
The exact decisions obviously belong to the maintainers/community.
The suggestion is only that once a boundary has been decided, it becomes durable project knowledge rather than remaining buried in an issue or discussion.
This could then provide a simple decision path for future proposals:
❓ What I would like to validate
The goal is not to create more issues from every uncovered row.
I'd first like to understand whether this capability map broadly reflects AIDD today and where the framework's intended boundaries are.
In particular:
OWN,INTEGRATE, orEXCLUDE?10-learnas durable decisions so they remain discoverable?If the high-level ownership of those areas can be clarified, the detailed matrix can then be updated accordingly without having to discuss every row individually.
💡 Possible outcome
The useful outcome of this discussion might therefore be less:
and more:
As AIDD grows, documenting what the framework intentionally does not own may become almost as useful as documenting what it does.
A lightweight capability map combined with durable boundary decisions could make it easier to:
I'm particularly interested in corrections to the map:
All reactions