Execution

Execution uses one coordinator and role-specific agent skills. The coordinator interviews the user, drives the phase pipeline, and uses commits and task validation as evidence. There is no command system or separate workflow state layer in the knowledge base.

Operating Flow

1. Gather the user's intent and enough information to define the change. Reuse existing knowledge and ask focused questions about material gaps.
2. Assign the change tier. Start the change on a dedicated branch. Complete Requirement, Specification, and Plan sequentially. Edit the artifact's knowledge in place and self-check each phase. Commit each phase for a medium or large change; commit the three phases together for a small change.
3. For a medium or large change, present the implementation plan and wait for explicit user approval. For a small change, the user's request is the approval.
4. Implement approved tasks, validate them, and validate the integrated change. Respect upstream version gates.
5. Prepare the proposed version record and identity record update. Push branches and open PRs when remotes exist.
6. Stop for the team to review and merge. A version becomes established only when all required knowledge and implementation changes land on main or master.

A new plan or material change requires renewed plan approval before affected implementation continues. Ordinary fixes within the approved scope do not require another review.

Required Skills

All ADD roles must apply kiss and asd-ste-100. Each role skill core has a self-check with five KISS and STE items; a role reads the full skills when that checklist does not settle a case. In the adopted bundle, their instructions are at required-skills/kiss/SKILL.md and required-skills/asd-ste-100/SKILL.md.

Use KISS when defining requirements, choosing designs, planning work, and implementing changes. Use ASD-STE100 principles when writing or rewriting artifact documents and task evidence. Preserve necessary contracts, constraints, and detail. This applies writing principles; it does not certify ASD-STE100 compliance.

Apply both during existing phase and task self-checks. They do not add a workflow phase or a separate review. Consumer AI setup must make both skills available to all roles. If either is missing, restore it from the ADD bundle before continuing affected work.

Role Skills

Skill	Responsibility
ADD coordinator	Interview, phase coordination, plan approval, dependency gates, integration, and PR handoff.
ADD Product Owner	Author and self-check requirements.
ADD Technical Lead	Produce specifications, ADRs, and the plan sequentially, with self-checks in one frontier-model session.
ADD implementer	Implement assigned tasks, run DoD checks, and record validation evidence.

Each role skill has a core of at most 400 words: the role's duty, its steps by tier and a self-check checklist. A Read-when table follows the core. Each row names a condition and the guidance to load when the condition is true: a section of the skill's reference.md, a guideline or a pattern. Content that only some changes need, such as the legacy layout, publication without a remote, flows, representations, claims, units and patterns, is behind a row.

Skills can run within one session. Separate agents are used automatically for independent implementation tasks when useful; roles do not require separate sessions or redundant reviews.

Before a role acts, read its skill core, unless its complete current instructions are already loaded in the same session. A summary or a path alone does not meet this condition. Reload the affected instructions after context loss, after their sources change, or after a switch to another adopted bundle.

Knowledge Layout

Each artifact keeps one working set of its requirements, specifications, and decisions directly under the artifact directory. A change branch edits this knowledge in place. Start a change by adding changes/<change>/README.md with its reason and scope; copy nothing into the change or into a version. The change keeps its plan, tasks, and evidence in changes/<change>/tasks/.

Structural facts are in YAML front matter only: the identity record in the artifact README (current_version, depends_on), version records, plan task lists, task declarations, unit briefs, references, and flow documents. Prose and headings carry no structural facts. The protected branch holds established knowledge. The difference between the change branch and the protected branch is the proposed knowledge. Git history holds each version snapshot.

Existing artifacts in the legacy snapshot-copy layout remain readable. The artifact model describes both layouts and the migration to the in-place layout.

Built-In Patterns

Use the pattern library to select relevant guidance. PO work can use strategic DDD and BDD for discovery. TL work uses strategic DDD and contract-driven Specification, with tactical design where needed. Implementers use the selected tactical, contract, and behavior checks. Patterns produce knowledge and evidence in existing artifact files; they do not create additional workflow phases or state.

Repository Layouts

• Separate repositories: One knowledge repository and separate implementation repositories. Create one PR per changed repository and cross-link the PRs for the coordinated artifact change.
• One Git repository: Knowledge and multiple applications or services share a repository. Use one coordinated PR.

Inspect the actual repositories, branches, remotes, and local instructions before working. Do not infer paths or repository ownership from names alone.

Parallel Implementation

Create or reuse agents for independent approved tasks. Each parallel implementation agent uses a separate Git worktree on a dedicated branch in its target repository. The coordinator integrates their commits onto the change branch and runs combined validation.

Give agents the governing contracts, task scope, dependencies, and DoD. Keep knowledge updates under the coordinator's control to avoid agents concurrently editing the same task or artifact files. Integrate code commits, then record returned evidence in the relevant tasks.

Evidence and Resuming Work

The knowledge base contains domain and technical knowledge, plans, task checklists, and validation evidence. Git contains commit history. Do not add phase status tables, copied commit hashes, approval registries, or a workflow database.

Derive progress from artifacts, implementation, validation results, Git history, and available user authorization. A commit records work; it does not prove that a phase or task passed its checks. If plan approval cannot be established from available context, ask before implementing.

Publication and Establishment

Never commit directly to protected branches, including main and master. On the change branch, add the version record versions/<version>/README.md with source_change, and set current_version and any changed depends_on in the identity record. The version record contains no knowledge directories and no tasks. These updates describe the proposed post-merge state and must not make consumers treat an unmerged version as established.

When a remote exists, push the change branch and open a PR. For multiple repositories, describe the required companion PRs and their merge dependencies. Stop after handing off to the team; do not merge, enable automatic merging, or deploy.

If no remote exists, ask the user how to finish. They can choose a remote and PR workflow or explicitly authorize a local merge for solo work. The latter replaces the PR handoff only for the repositories the user authorizes. Merge the validated dedicated branch through Git's merge operation; do not create implementation commits directly on main or master. If branch protection prevents local integration, report that blocker. Do not assume either choice.

If required repositories merge at different times, the coordinated version remains unestablished until all required changes have landed. Report PR preparation separately from establishment. Verify all required merges before releasing dependent Implementation when work resumes.