Quick Start - Why IDD exists

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.

bootstrap
curl -fsSL https://raw.githubusercontent.com/dan1hc/idd/main/install.sh | bash
Interface Copilot Chat
Contract .github/copilot-instructions.md
North star Feature specs

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.

Artifacts touched
Why this 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.

01 - Repo memory

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.

02 - Bounded surfaces

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.

03 - Model leverage

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.

Layer 1

Contract in repo

The operating rules live in .github/copilot-instructions.md, not in a shell wrapper.

Layer 2

Intent becomes durable

Each repo builds durable context in architecture.md, conventions.md, inventory.md, and especially maintained feature specs.

Layer 3

Models get stronger

New model generations read the same artifacts with better judgment, synthesis, and recall.

Layer 4

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
.github/copilot-instructions.md

The canonical operating contract Copilot reads first.

.github/idd/architecture.md

System shape, runtime topology, integrations, and open questions.

.github/idd/conventions.md

Code boundaries, style, library patterns, and component placement.

.github/idd/inventory.md

Repository evidence, modules, entrypoints, routes, and jobs.

.github/idd/features/*.md

The primary planning and execution layer, with glossary anchors that reconnect future maintenance to the right code.