Make repo context compound instead of evaporate.
IDD gives Copilot Chat a durable contract and a bounded artifact set inside the repository. Instead of re-explaining the system in every session, you keep architecture, conventions, inventory, learned rules, and feature memory in the repo itself. The north star is to keep feature specs current so they can guide both code execution and later maintenance. This is for software intent what IaC was for infrastructure: a durable layer that compounds as the models get better.
curl -fsSL https://raw.githubusercontent.com/dan1hc/idd/main/install.sh | bash
How IDD works
Switch between brownfield and greenfield and click through the flow. The feature spec is the hinge between repository understanding and source-code work, so the page updates the active prompt, artifacts touched, and why each step matters.
Why IDD is durable
IDD is not trying to freeze intelligence into a wrapper. It keeps stable repository memory close to the code, so improved models can keep extracting more value from the same substrate. That makes it closer to a new engineering layer than a conventional productivity feature.
Context survives the session.
Architecture, conventions, inventory, learned rules, and features live in the repo. The next chat session starts with structure instead of amnesia.
Feature specs steer execution.
The active feature spec becomes the execution contract for the work. Copilot implements from it and later maintenance returns to it.
Capability scales with each model generation.
Better models can infer more from the same contract, write tighter feature specs, and deliver stronger implementation, review, and maintenance without changing the product shape.
Contract in repo
The operating rules live in .github/copilot-instructions.md, not in a shell wrapper.
Intent becomes durable
Each repo builds durable context in architecture.md, conventions.md, inventory.md, and especially maintained feature specs.
Models get stronger
New model generations read the same artifacts with better judgment, synthesis, and recall.
A new paradigm emerges
The repo becomes easier to understand, decompose, implement, and review over time. That is why this is closer to IaC for application intent than to ordinary prompt engineering.
Installed footprint
The footprint stays intentionally small. One contract file tells Copilot how to operate, and the rest is repository memory.
.github/
├── copilot-instructions.md
└── idd/
├── architecture.md
├── conventions.md
├── inventory.md
├── learned.md
└── features/
├── _template.md
└── *.md
The canonical operating contract Copilot reads first.
System shape, runtime topology, integrations, and open questions.
Code boundaries, style, library patterns, and component placement.
Repository evidence, modules, entrypoints, routes, and jobs.
The primary planning and execution layer, with glossary anchors that reconnect future maintenance to the right code.