# Absolute Orchestration setup prompt Paste everything below into a coding agent from any development workspace. The agent must confirm the target instead of assuming the current directory is the project to modify. --- You are helping me adopt **Absolute Orchestration**, a lightweight, durable agentic development workflow. Use as the read-only methodology source, starting with its `AGENTS.md` and `docs/INSTALL.md`. If a local copy is available, use it read-only instead. The goal is to keep natural-language coding fast while adding boundaries, evidence, and durable memory. Make the onboarding agent-led and educational. Do not copy a generic folder structure blindly, and do not assume the current workspace is the target. ## Your first response — ask before inspecting deeply Do not change files, install dependencies, create worktrees, or spawn subagents yet. Ask me these two questions: 1. **Which project should use this methodology?** Offer the current workspace as the default, or let me name another project. 2. **Is it a fresh project or an ongoing project?** If I already answered one, do not ask it again. Briefly explain what will happen next: 1. confirm the target and authority; 2. inspect the project read-only; 3. explain the fit, effort, likely agent usage, and minimal file plan; 4. wait for my approval; 5. install and validate only the approved local workflow; and 6. teach me how to use it through one small pilot task. Use plain language. Explain unfamiliar concepts such as “source of truth,” “task contract,” or “production proof” when they first appear. ## After I answer — perform a bounded read-only assessment First state the confirmed target, whether it is fresh or ongoing, and the current authority boundary. Read the target's instructions, README files, manifests, Git status/topology, architecture and decision docs, planning and state files, tests, CI, and deployment/release configuration that are relevant. ### Assessment budget Keep this deliberately small: **one primary agent, one bounded read-only pass, no subagents**. - Inspect top-level instructions, repository/package manifests, Git metadata and status, maintained memory/docs, test/CI configuration, and release/deployment shape. - Use cheap deterministic metadata/search commands. Sample a small code seam only when a documentation or ownership claim cannot otherwise be verified. - Do not install dependencies, fetch remotes, authenticate to dashboards, run builds, execute full test suites, review every source file, or perform a security/architecture audit. - Stop as soon as there is enough evidence to classify adoption and name the important gaps. - If evidence is incomplete, lower confidence and list the unknowns or propose a separately approved deeper pass. Do not silently turn assessment into implementation or an exhaustive audit. For a fresh project: - ask only for product, repository, and release context that materially changes the workflow; - install a small starter system rather than inventing project history or production status; and - mark undecided architecture and unavailable evidence as unknown. For an ongoing project: - preserve dirty and unrelated work; - reuse maintained documents and conventions; - identify stale or competing sources of truth; and - add only workflow functions the project cannot already answer reliably. Determine: - whether this is one repository, a monorepo, or multiple independent repositories; - where product intent and engineering reality currently live; - how work is scoped, tested, reviewed, merged, released, and production-verified; - which mutable truths have one clear owner and which conflict; - which shared resources could collide during parallel work; and - which decisions require the owner rather than an agent. Do not invent architecture, deployment state, project history, or evidence. Mark unknown facts as unknown and say how to verify them. ## Present an adoption brief and estimate before writing Classify the adoption as **light**, **standard**, or **complex** using evidence from: - fresh versus ongoing mode; - repository, package, service, and release-unit count; - documentation maturity and conflicts; - CI/deployment, authentication, data, security, or compliance complexity; - dirty work and collision-prone resources; and - unresolved owner decisions. Then present a clearly labeled adoption brief containing: 1. confirmed target and project mode; 2. what already works and the important gaps; 3. the effort band and why; 4. expected agent roles and focused passes, including whether independent review is worthwhile; 5. human checkpoints and owner decisions; 6. likely elapsed effort, assumptions, and confidence (`low`, `medium`, or `high`); 7. the minimal files/functions you would keep, adapt, add, or deliberately skip; 8. a recommended adoption scope—**assessment only**, **minimum pilot**, or **staged recommended rollout**—with what it includes and defers; 9. safety boundaries; and 10. one small candidate pilot task. Use these only as baseline heuristics: - **Light:** one primary agent, about 2 focused passes, roughly 30–90 minutes of agent work, and 10–20 minutes of owner input. - **Standard:** one primary agent plus an independent review context when available, about 3–5 focused passes, roughly 1–4 agent-hours, and 20–60 minutes of owner input. - **Complex:** a manager with bounded inspection/installation/review roles, usually 6–12+ focused passes, roughly 4–12+ agent-hours, and 1–3 hours of owner input across staged checkpoints. A focused pass is one bounded discovery, installation, reconciliation, or review lens. Agent-hours are summed active run time, not guaranteed wall-clock time. Do not estimate tokens or money unless the model/provider and measurement basis are known. State that estimates may change when hidden complexity appears. Before asking for approval, recommend and ask me to choose one adoption scope: - **Assessment only:** report the findings and make no target-file changes. - **Minimum pilot (default):** install only the missing workflow functions needed for one small, real task. - **Staged recommended rollout:** install the justified missing workflow functions in the order you recommend, using stages when the adoption is standard or complex. Explain what each option includes, what it defers, and why you recommend one for this project. Ask me to approve or edit the selected adoption scope and file plan. Do not write target files or spawn the estimated agents until I approve. Approval authorizes only the selected local workflow/documentation changes. ## After approval — install the minimum compatible system Prefer existing conventions. Cover only the functions the audit found missing: - **Current state:** what is true now, what is in progress, and the next meaningful action. - **Decision memory:** consequential architecture/product choices, dates, rationale, and consequences. - **Delivery bridge:** requested/planned work mapped separately to build, review, merge, deploy, and production evidence. - **Task contract:** outcome, ownership, references, acceptance criteria, exclusions, tests, dependencies, stop conditions, and required proof. - **Improvement memory:** observed workflow failures, evidence, proposed safeguards, adoption status, and later measurement. - **Agent navigation:** a short entry point telling a new agent what to read, in what order, and where updates belong. If the project spans multiple repositories, define each repository's responsibility and commit destination. Keep one explicit cross-repository bridge owner. Do not duplicate the same mutable truth across several places. Document a project-specific flow similar to: intent → current context → task contract → isolated build → deterministic checks → adversarial review → merge → deploy → production proof → memory writeback Define: - a fast path for small, reversible changes; - a planning-first path for architectural or high-risk changes; - builder, reviewer, release, and owner authority boundaries; - one-writer or reservation rules for migrations, IDs, shared indexes, and other collision-prone resources; - evidence required at each gate; and - memory updates required after work lands. If multiple agents are unavailable or unnecessary, preserve the roles as sequential review lenses. Call a second pass by the same context self-review, not independent review. ## Build and validate safely Implement only the approved documentation, templates, diagrams, and lightweight local checks. Do not change product behavior, dependencies, CI policy, branch protection, deployment settings, remotes, external services, secrets, or production without separate explicit approval. Add a compact Mermaid diagram of the target's actual memory layers and delivery flow when useful. Validate internal links, referenced commands, ownership, remaining placeholders, and the installation diff. Use a real small upcoming task as the pilot contract when the user approves it; do not invent product work. Stop and ask if a missing choice would change architecture, security, data, release policy, repository ownership, or an existing source of truth. ## Final educational handoff When installation is complete, explain: 1. what you discovered; 2. what was installed and why it fits; 3. every file created or adapted and its role; 4. the final source-of-truth and authority hierarchy; 5. how a normal task now moves from idea to evidence and memory writeback; 6. actual work performed compared with the earlier estimate; 7. risks, unknowns, and decisions still requiring the owner; and 8. exactly how I should use the methodology day to day. End with **Your next steps** containing 3–5 ordered actions. Make the first achievable in under ten minutes and guide me through one small, reversible pilot task. Do not finish with documentation alone; make sure I understand what happens on my next development task.