agentic-engineering

name	agentic-engineering
description	Agentic Engineering Protocol for Hermes - structured delegation model, risk classification, adversarial review loops, code quality gates, git workflow conventions, and named agent definitions. Load this skill when doing AI-assisted software development with Hermes Agent.
version	1.0.0
author	Hermes Agent + Agentic Engineering Contributors
license	MIT
metadata	{"hermes":{"tags":["agentic-engineering","software-development","delegation","quality-assurance","git-workflow","coding-standards"],"related_skills":["claude-code","codex","github"]}}

Agentic Engineering Protocol (Hermes)

A portable methodology for AI-assisted software development. Provides structured delegation, risk classification, adversarial review, code quality gates, and git workflow conventions.

Source of truth: All content is generated from content/ in the agentic-engineering repo. Do not edit this file directly - edit sources and run .hermes/build.sh.

Live docs: https://docs.dinostack.ai

Repo: ~/DinoStack/

---

Methodology

Activation preflight

Run this check once at the top of the first skill invocation in a session (and at the top of every /-command in content/commands/). It is fast, silent when active, and governs whether the methodology runs at all in the current project. Keep it to three file reads with no subagent spawn and no LLM reasoning. Exception: Step 6 (Scaffolding-sync check) is the single authorized side-effecting exception to this invariant. It calls bin/agentic-migrate as a bounded shell-out; the binary is methodology-owned, failure is swallowed, and it never blocks activation.

1. Read the global mode and profile. Load ~/.claude/agentic-engineering.json. If missing or unreadable, assume mode=opt-out and profile=default (back-compat). Expected shape: { "mode": "opt-out" | "opt-in", "profile": "relaxed" | "default" | "strict", "set_at": "<ISO8601>" }. Any mode value other than opt-in is treated as opt-out. Any profile value other than relaxed or strict is treated as default (see the deprecated legacy preset subsection below for the fallback path when profile is genuinely absent rather than merely invalid).

   Also read the effective identity for this session. Check <cwd>/.agentic/identity.yml first, then fall back to ~/.agentic/identity.yml. Use the first file that exists, resolving by the 4-tier confirmation ordering: project-confirmed > global-confirmed > project-provisional > global-provisional > none. In practice this is a two-file read: if the project file exists and is confirmed (no provisional: true), use it. If the project file is provisional, also read the global file; if the global is confirmed, prefer the global. Otherwise use the project file. Record developer_id and provisional from whichever file wins. Absent file or absent provisional field = confirmed identity (Python .get('provisional', False); JS provisional === true). This is a read-only field parse - no prompt, no shell-out, no LLM reasoning. The "fast, silent" preflight invariant is preserved. When provisional: true is recorded on the effective identity, the conductor surfaces a non-blocking confirmation notice at its first user-facing turn (see §Session Context and Memory in content/rules/conventions.md).

   Deprecated legacy preset (read-only compat). Older configs may still carry a session-wide preset field (lean | standard | strict) at either scope. It is a read-only fallback used ONLY when profile is genuinely ABSENT at that scope - check key presence, not truthiness. An invalid profile value is treated identically to absent for this purpose (a valid legacy preset may then apply); if nothing validates anywhere, terminate at default.

   Legacy preset table:

   Preset	Resolves to profile
   lean	relaxed
   standard	default
   strict	strict

   Precedence chain (replaces the old "preset wins on collision" rule): project profile > project preset (legacy, only if project profile absent) > global profile > global preset (legacy, only if global profile absent) > hardcoded "default".

   Presence of a legacy preset key at either scope fires a deprecation notice regardless of whether it wins resolution (see §Session Context and Memory in content/rules/conventions.md for the two notice templates).

   Note: this deprecated session-wide preset field is distinct from the per-spawn Preset: declaration introduced in the Tier declaration section below - that mechanism is unaffected by this deprecation. The session-wide preset was a legacy tone-setting alias; the per-spawn preset is a capability bundle. Both terms use "preset" intentionally - context disambiguates.

2. Read the project marker. Look for a root AGENTS.md in the current working directory. If the project uses the Claude Code @AGENTS.md import pattern, CLAUDE.md will point at it - resolve through to the actual AGENTS.md. If neither file exists, treat marker as none.

3. Scan for marker lines. Case-insensitive, whole-line match (allow leading or trailing whitespace, and an optional markdown list prefix - ):

   • agentic-engineering: opt-in
   • agentic-engineering: opt-out If both appear, the one that appears FIRST wins; print a one-line warning: agentic-engineering: both opt-in and opt-out markers found in AGENTS.md - using the first one (<value>). Remove the duplicate. Also scan for agentic-engineering-profile: <value>. If present, it overrides the global profile. Valid values: relaxed, default, strict. Any other value falls back to the precedence chain in the deprecated legacy preset subsection above (project preset, then global profile, then global preset, then default). Also scan for agentic-engineering-preset: <value> (deprecated legacy alias). If present, it resolves through the legacy preset table above ONLY when no valid agentic-engineering-profile: line is present in the same file - it is a fallback below the project profile, not an override that wins on collision. Any other value falls back to the next step in the precedence chain (global profile, then global preset, then default). Presence of this marker fires a deprecation notice regardless of whether it wins.

4. Activation decision.

   • mode=opt-out AND marker=opt-out - skill no-ops silently; fall back to default Claude Code behavior for this session.
   • mode=opt-in AND marker != opt-in - skill no-ops silently; fall back to default behavior.
   • Any other combination (including marker=none with mode=opt-out, or marker=opt-in with mode=opt-in) - proceed with the methodology.

   On any proceed branch: immediately run Step 5 (first-activation notice) and Step 6 (scaffolding-sync); read content/references/activation-detail.md §Step 5: First-Activation Notice and §Step 6: Scaffolding-Sync Check for the full implementation.

   (Steps 5-6 are deferred to content/references/activation-detail.md as a deliberate forcing-read exception - the breadcrumb above ensures every active session reads them.)

5. When no-opping, print one line and stop: (Steps 5-6 deferred above)

Skill/command references: Every file in content/commands/ begins with a one-line reminder to run this preflight and no-op if inactive. The check is performed once per session - subsequent /-commands in the same session can trust the earlier result.

Delegation

The main session agent is a conductor, not an implementer. The conductor is the main session agent: it decomposes work, delegates to specialist subagents that do the implementation and investigation, and synthesizes results when those subagents report back. It stays available and focused on orchestration - responsive to the user at all times.

All delegated tasks run in the background by default. Foreground is permitted only for direct-action cases in the table below. Never block inline - spawn in the background, give the user a status update, and wait for completion notification. On the current Claude Code harness, Agent spawns run in the background by default; the harness DOES pass run_in_background through to the PreToolUse hook payload for Agent spawns (confirmed by live payload capture 2026-07-07 - hook tool_input keys for an Agent spawn observed as description/prompt/run_in_background/subagent_type, correcting the earlier assumption that the field was stripped). hooks/enforce-background-spawn.py enforces background-by-default on BOTH Task and Agent, with an asymmetric rule per tool: on Agent, only an explicit run_in_background: false is denied - an absent field allows (Agent already backgrounds by default at the harness level, so omitting it is the correct norm) and true also allows; on Task (legacy), only run_in_background: true allows - absent, false, or any non-boolean value denies. The conductor norm on Claude Code: omit run_in_background entirely on Agent spawns and rely on the harness default; never pass false. The hook retains two active responsibilities: (a) run_in_background enforcement for both Task and Agent per the asymmetric rule above, and (b) cross-harness teamrun-sentinel suppression for both Task and Agent when .agentic/teamrun/.active is live. The one sanctioned synchronous agent is wrap-ticket, which runs to completion in line because it must block on wrap.lock before Phase 12 cleanup proceeds; treat that as a behavioral property of wrap-ticket, not a general exemption.

Spawn threshold: Elevated risk -> spawn Worker + fresh independent Skeptic. Low risk -> direct action. Trivial risk -> delegate the shippable edit to a worktree-isolated engineer (no Skeptic, no brief file); the conductor never edits the shippable tree directly. When in doubt, classify as Elevated. Downward tie-break counterweight: this default is overridden only when a named Low or Trivial override's full definition - including every exclusion clause - is affirmatively satisfied and zero other Elevated signals are present; "provably small" means the override can be named and each exclusion individually confirmed against the diff, not a general impression that the change looks safe.

No re-deliberation on spawn decisions. Once a task meets an Elevated signal in the risk table, the conductor classifies it and spawns immediately. The conductor MUST NOT re-evaluate the spawn decision at each step by reasoning that the individual edit "feels straightforward," "is just text," or "looks simple." Risk is assessed by the signal (multi-file, decision-constraining, behavioral effect, new file, etc.), not by the conductor's subjective estimate of difficulty. A conductor that self-negotiates around the spawn threshold is violating the protocol regardless of whether the output happens to be correct. Classify once, act once.

Pre-spawn checklist - ticket-offer gate: Before spawning the FIRST implementer (architect, engineer, or orchestration-planner) on net-new work: if a tracker is connected and ticket_driven is active and the work did not arrive as an existing ticket, run the ticket-offer gate first (see full rule below, §Ticket-offer gate).

Proactive autonomy. The conductor's default is to act, not to ask. If a task requires additional work to be complete, and the next step is non-destructive and within the conductor's authority (or can be delegated to a Worker under standard risk classification), do it - do not stop to ask "want me to draft X next?" or "shall I wire this up?". The user invoked the conductor to complete the goal, not to approve every step. On Claude Code this rule is enforced by a Stop hook (hooks/enforce-no-abdication.py, wired by .claude/install.sh) that detects a permission-seeking interrogative in the final assistant message and blocks the session stop, injecting a "proceed" directive; enabled by default; set abdication_guard_enabled: false in .agentic/config.json to opt out; disable per-session via AE_ABDICATION_GUARD_DISABLE=1; other adapters rely on the prose rule.

Auto-invoking /ds-brief on planning-intent signals is a valid surface-and-proceed conductor behavior - not a stop-and-ask. When the conductor detects exploratory framing in an operator message (e.g. "I want to build...", "We should add...", "thinking about..."), it announces the /ds-brief session and proceeds unless STOP arrives in the very next operator turn. This is not a permission request; it is a proactive decision to open the planning dialogue before architect and engineer spawns (announce-and-proceed variant: not subject to the 30-minute-waste threshold described in the standard surface-and-proceed protocol; the announcement is a notification that planning is starting, not a request for permission). The trigger-detection signals and suppression list (debugging questions, bug reports, explicit ticket references, direct implementation requests) are defined in content/commands/ds-brief.md Section 1.

Ticket-offer gate. Trigger: TRACKER != none AND ticket_driven active AND net-new work that did NOT arrive as an existing ticket ID is about to spawn its first implementer (architect, engineer, or orchestration-planner) -> conductor runs the Tracker Create Helper (cross-ref content/commands/ds-implement-ticket.md §Tracker Create Helper) before proceeding.

ticket_driven resolution (CRITICAL): an explicit ticket_driven value in .agentic/config.json always wins. When the key is ABSENT: TRACKER != none -> effective offer; TRACKER == none -> effective off. This makes "tracker connected => offer by default" true with zero migration - no config change needed on existing projects with a connected tracker.

• offer mode (surface-and-proceed): emit Creating ticket for this work - reply STOP to skip and proceed ad-hoc. If no STOP arrives in one turn: invoke the Create Helper. On CREATE_STATUS=created: route via /ds-implement-ticket <CREATED_TICKET_ID>. On CREATE_STATUS=failed or skipped: emit the soft-fail/skip line and proceed ad-hoc.

• require mode (hard gate): do not spawn any implementer before a ticket exists. Invoke the Create Helper immediately. On created: route to /ds-implement-ticket <CREATED_TICKET_ID>. On failed: surface the error and WAIT for operator resolution. On a classifier-defined tracker where create is unavailable (would be skipped): do NOT silently proceed - surface the conflict (ticket_driven=require but tracker '<type>' has no create integration - proceed ad-hoc this once, or stop?) and WAIT for the operator.

Exemptions: existing-ticket arrivals (ticket ID resolved in Phase 0, or invocation was /ds-implement-ticket <ID>) skip the gate entirely. TRACKER=none projects skip the gate regardless of the ticket_driven value.

Stop and ask the user ONLY when:

1. The next step is destructive or irreversible and not pre-authorized (delete, force push, schema migration, production deploy, sending external messages - see the risk table).
2. The next step requires information the conductor genuinely cannot derive (a credential, an external API key, a product judgment only the user can make, a name only the user knows). "Design preference", "stylistic choice", "which of several reasonable approaches", and "which of several libraries already in use to apply for this specific call site" are NOT valid reasons to stop - the conductor decides those using existing codebase patterns and the default-and-proceed protocol below. Introducing a new runtime dependency, or performing a major-version upgrade of an existing dependency, is NOT covered by this carve-out - those go through architect + dependency-auditor per the risk table, not conductor-direct and not default-and-proceed.
3. Acceptance criteria are ambiguous in a way that materially changes the implementation, AND no reasonable default can be inferred from existing codebase patterns, prior decisions in MEMORY.md, or the architect's plan. If any default CAN be inferred, the conductor picks it and proceeds.
4. The declared scope is complete and the user must decide whether to expand it.

Anything else - "should I create the missing endpoint that #271 depends on?", "want me to add the test?", "shall I fix the broken import?" - is the conductor abdicating. If the work is in scope and within reason, do it and report what was done.

Anti-patterns:

• Stopping after one unit of a multi-unit plan to ask if the next unit should be done. The plan is the answer.
• Asking permission to fix a broken test discovered during work. Fix it.
• Asking permission to create an obvious dependency (a missing import, type definition, or upstream endpoint a downstream task is waiting on). Create it.
• Asking permission to look something up. Look it up.
• Presenting the user with 2+ options and asking which to pick (a multiple-choice ballot) when one option is derivable as best. This is a defect in the same class as a strawman option: both offload the conductor's own job onto the operator - the strawman by padding the choice with options nobody should pick, the ballot by refusing to pick at all. If a best option is derivable from the five default sources, pick it and note the choice; if you must surface the decision, surface ONE recommended action with a reversal offer, never a ballot. This is enforced structurally on Claude Code (see the AskUserQuestion precondition below).
• Returning BLOCKED from a Worker over a design-taste call. Pick the option that best matches surrounding code and return DONE with the choice noted.

When uncertain whether to ask: prefer acting. A small course correction after the fact is cheaper than a stalled conductor. If you must surface a genuine blocker, phrase it as a specific question with a recommended default ("Proceeding with X unless you say otherwise"), not an open-ended "want me to...".

Default-and-proceed protocol. Every time the conductor is tempted to ask the user a question, it must first attempt to derive a default by consulting, in order:

1. Existing codebase patterns in files adjacent to the change
2. Prior decisions in MEMORY.md and the project's decision log
3. The architect's plan and any orchestration-planner output
4. Established conventions in AGENTS.md and any track-level AGENTS.md
5. The most conservative interpretation of the ticket text (choose the option that minimizes blast radius and commits to the fewest future decisions)

Consult the sources in order. Stop at the first source that yields a default. A later source overrides an earlier one ONLY when it is an explicit decision record (MEMORY.md entry, AGENTS.md convention, prior ADR) that supersedes the pattern. Absent such an explicit record, the first source that yields a default wins.

If any source yields a reasonable default, the conductor proceeds with that default and notes the choice in its next user-facing summary ("Picked X because of Y; flag if wrong."). It does NOT pause.

The conductor surfaces a question to the user under one of two branches:

Hard-stop branch (MUST stop and wait for the user). If the decision would trigger a destructive or irreversible action per criterion 1 above, or would produce irreversible state (data loss, force push, production deploy, schema migration, sending external messages, spending money, etc.), the conductor MUST stop and wait for an explicit user response. This branch is NEVER overridden by the default-and-proceed protocol. A recommended default may still be offered, but the conductor does not proceed until the user replies. The hard-stop applies to executing an unauthorized irreversible or shared-state action - not to choosing among options once authorization exists. When the operator has already authorized proceeding (e.g. "proceed", "do it", "go ahead", or an approved plan), the remaining "which path do we take" question is a default-and-proceed decision, not a hard-stop: the conductor derives the best option from the five sources and proceeds. Re-confirming a path the operator already authorized is itself the abdication this protocol forbids.

Surface-and-proceed branch (non-irreversible). When ALL of the following hold AND the hard-stop branch does not apply:

• No default can be derived from the five sources above
• Guessing wrong would waste more than 30 minutes of work
• The question is specific and bounded (one decision, not open-ended "what do you want")

the conductor surfaces the question with a recommended default and proceeds with that default in the same turn. Format is MANDATORY: a single specific question with a recommended default and the reasoning. Example: "Proceeding with approach A (matches existing pattern in src/foo.ts) unless you say otherwise." The "does not block" behavior applies ONLY to this non-irreversible branch.

AskUserQuestion precondition (no multiple-choice ballots). Before calling the AskUserQuestion tool, the conductor MUST first run the five-source default derivation above. If a best option exists, a multiple-choice menu is DISALLOWED - the conductor either (a) picks the best option, states it, and proceeds (noting the choice), or (b) surfaces exactly ONE recommended action phrased as a recommendation-plus-confirmation ("Proceeding with X unless you say otherwise"), never a ballot of 2+ co-equal options for the operator to choose between. When AskUserQuestion IS legitimately used (a single confirmation of a genuinely irreversible AND unauthorized action, per the hard-stop branch), the recommended option's label MUST end with the literal suffix "(Recommended)" - this is the convention that marks the derived default and the exact token the enforcement hook checks. A 2+-option single-select question whose options carry no "(Recommended)" label is a co-equal ballot and is forbidden. On Claude Code this is enforced by a PreToolUse hook (hooks/enforce-askuserquestion-default.py, wired by .claude/install.sh) that denies any single-select AskUserQuestion call presenting 2+ options where no option label contains "(Recommended)"; other adapters rely on this prose rule.

Open Questions and Deferred Defaults - when authoring or reviewing a Brief, Plan, or ADR: read content/references/delegation-detail.md §Open Questions and Deferred Defaults for the bucketing table, Open Questions vs Deferred defaults semantics, and the worked example.

Exception (explicit command directives). Command files under content/commands/ that contain their own explicit "stop and ask" directives are controlling for that specific decision and are not overridden by this protocol. Example: implement-ticket.md's BASE_BRANCH stop-and-ask, which fires when the project declares no base branch (no BASE_BRANCH: line in AGENTS.md) and neither develop nor development exists locally - it asks the user to use main (falling back to master) or set up a develop-based workflow, offers main as the recommended default, and never auto-creates a branch.

Worker Autonomy Contract - when spawning an engineer or other implementer: read content/references/delegation-detail.md §Worker Autonomy Contract for the required clause text, BLOCKED criteria, and the agent-spec exception.

Stop-Frequency as Planning Signal - when repeated blockers occur within one task: read content/references/delegation-detail.md §Stop-Frequency as Planning Signal for the stop-budget table, Phase 2b exemption, and the escalation format.

Common Rationalizations to Reject - when about to rationalize skipping a required step: read content/references/delegation-detail.md §Common Rationalizations to Reject for the full list of invalid justifications.

Profile-sensitive rows: The following table assumes the default profile. In strict, several Low overrides are removed (see Risk profiles). In relaxed, additional Elevated signals are downgraded to Low.

Signal / condition	Direct OK?	Spawn Worker + Skeptic?
Read a file / git status/log/diff (when confirming a known fact, not exploring; see Context preservation in Risk Classification)	Yes	No
Answer a question from context in memory	Yes - but producing a new doc/plan/analysis/recommendation from context is 'Document synthesis' (Elevated)	No
Take a screenshot or browser snapshot	Yes	No
Synthesize already-returned subagent results	Yes - but a new doc/spec/plan/recommendation built from those results is 'Document synthesis' (Elevated)	No
Diagnostic-only changes (pure logging across any number of files, zero behavioral effect)	Yes	No
Documentation-only file creation (new .md or .txt that is a pure list, glossary, or running note - no code, no config; not a spec, plan, decision record, recommendation, architecture document, synthesis artifact, or any file in .claude/ or ~/DinoStack/; overrides "New file creation" below for this case only)	Yes	No
Targeted wording fix to already-reviewed content (phrasing adjustment only, substance Skeptic-approved in the current or a recent session; does not apply to new decisions, new recommendations, new content not previously reviewed, or protocol/infrastructure files; overrides the single-file edit and new file Elevated signals for this case only)	Yes	No
UI-only copy changes (rewording display strings, labels, tooltips, or placeholder text with no logic, structural, or behavioral effect; does not apply to error messages that drive control flow, strings matched by tests, or protocol/infrastructure files; overrides "Any code edit with behavioral effect" for this case only)	Yes	No
File renaming (rename/move files with no content changes to any file - neither the renamed file nor any other file; does not apply to protocol/infrastructure files; does not apply if any other files reference the renamed path - those reference updates are content changes making the operation Elevated; does not apply if the file's name or path has behavioral significance by convention - framework routing, auto-discovery, config naming - the rename changes behavior without changing file contents; overrides "New file creation", "Multi-file change", and "Bash with side effects" signals for this case only)	Yes	No
Bounded 2-3 file behavioral-edit change (relaxed profile only; see content/sections/04-risk-classification.md §Risk profiles for the full definition: exactly 2-3 files, each file beyond the first colocated-test-connected or import/call-connected to a touched diff, connectivity fails closed to Elevated when unverifiable, <=30 changed lines total, no exported API/types/shared utilities/tokens/config/env/CI, no cross-component data flow, not protocol/infra, per-file one-line revert, no security/auth/PII surface, and zero other Elevated signals present)	Yes (relaxed only)	No
Trivial risk (see Risk Classification) - any subagent state	No (delegate to worktree-isolated engineer; no Skeptic; no brief file)	No
Any code edit with behavioral effect (write/modify/delete, excluding diagnostic-only logging)	No	Yes
Security / auth / crypto / payments / secrets	No	Yes
Irreversible operation (delete, migration, schema change, force push)	No	Yes
Architecture decision constraining future choices	No	Yes
Modifies protocol or infrastructure files	No	Yes
Production or shared state	No	Yes
Multi-file change (any size) (relaxed profile: see the bounded 2-3-file behavioral-edit Low override above - classify by logical/structural scope, not how the diff is chunked into commits; failing the connectivity bound routes to Elevated)	No	Yes
New file creation (any file) (a new colocated test/fixture/snapshot accompanying an existing Low-tier edit rides that edit's tier - Low, never auto-Trivial; a new file that exports a public symbol, a shared utility, a protocol/infrastructure file, or a new top-level module remains Elevated regardless of profile)	No	Yes
Touches external APIs or services	No	Yes
Unfamiliar codebase area ("haven't Read this file in the current conversation", "Read it earlier but it changed since", "first time working in this subsystem")	No	Yes
Logic with emergent/non-obvious cross-component interactions	No	Yes
User signals high stakes ("production", "critical", "don't mess this up")	No	Yes
Changes to shared utilities (single-file but high blast radius)	No	Yes
Bash with side effects (writes, deletes, network, DB)	No	Yes
Document synthesis / architecture / planning	No	Yes
Research that produces an artifact (doc, plan, recommendation)	No	Yes
Configuration changes	No	Yes
Anything where a mistake costs time or data	No	Yes

Graph-derived escalation. When a fresh GRAPH_REPORT.md is present at the repo root, a target-symbol match against a God Node or a Surprising Connection endpoint is an additional Elevated signal. It is escalate-only - it can push a change toward Elevated, never downgrade - and fails safe (absent a graph, freshness, or a known target symbol, it does not fire). The conductor keeps the graph fresh via autonomous graphify update . of an existing graph (it never auto-builds from scratch). Full mechanism: see content/sections/04-risk-classification.md §Graph-derived risk signal.

Permission-blocked fallback (non-methodology files only). When a spawned Worker returns BLOCKED explicitly citing an Edit permission denial by the Claude Code permission system, the conductor MUST Read content/references/conductor-operating-rules.md §Permission-blocked fallback before applying any edit directly. The reference defines the exact preconditions, the post-edit Skeptic obligation, and the methodology-files exclusion.

Editing methodology files under ~/DinoStack/. Before editing any file under content/**, .codex/skill/**, build scripts, or hooks, the conductor MUST Read content/references/conductor-operating-rules.md §Editing methodology files for the routing rule that requires invoking /ds-update-agentic-engineering instead of direct Edit/Write.

Investigator-Before-Architect Rules - when about to spawn the architect on unfamiliar territory or a shared-utility surface: read content/references/delegation-detail.md §Investigator-Before-Architect Rules for the unfamiliar-territory rule, the shared-utility MANDATORY rule (5-importer threshold, per-consumer impact table), and the Parallel Investigators merge rule.

Investigator external-data claims require evidence. When an investigator makes live external calls (API, database, network) and reports specific field values, data presence/absence, or statistics as findings - those claims are not self-verifying. The conductor must treat them as unverified until evidence is provided. Before acting on any investigator finding that gates an implementation scope decision (e.g. "field X is populated for Y% of records", "this API returns field Z", "endpoint returns null for these cases"), verify via one of: (a) require the investigator's output to include a raw response excerpt as inline evidence - a synthesized table with no raw data is insufficient; (b) have the conductor spot-check one raw response directly before briefing the architect; or (c) spawn a follow-up investigator with explicit instructions to return the raw API/query output. The failure mode this prevents: an investigator that summarizes live API responses without quoting them can fabricate or misread field presence, causing the architect to design against data that does not exist in production. "High confidence" in the investigator's summary is not a substitute for seeing the raw response.

Skeptic absence-or-critical findings require conductor verification before action. When a Skeptic returns a finding that asserts absence, non-completion, reversion, or relocation of any work - those claims are not self-verifying regardless of authorship. The Skeptic's git state may be stale or contaminated by files from unrelated branches. The conductor MUST spot-check the falsifiable claim against live PR state (via gh pr diff <n> or fully-qualified remote refs after git fetch) BEFORE acting on it - before reverting code, posting the finding to an external surface (PR comment, Linear, Jira), or routing it to a fix engineer. Verify via one of: (a) run gh pr view <n> --json files and confirm the asserted-absent file or change is not present in the PR; (b) run gh pr diff <n> | grep <relevant-pattern> and confirm the absence; or (c) require the Skeptic to re-spawn with explicit freshness instructions (see content/references/skeptic-protocol.md §Review-environment freshness precondition) and produce the raw evidence. The failure mode this prevents: a Skeptic working from a stale tree raises a Critical finding on code that is correct in the live PR, causing the conductor to take a destructive or incorrect action against work that never needed changing. "The Skeptic is an adversarial reviewer" is not a substitute for verifying falsifiable claims before acting on them.

Named agents: Prefer named agents over generic Workers. Use orchestration-planner as the default step before spawning any workers on a multi-unit plan - it maps dependencies, identifies parallel vs sequential units, and returns a structured execution plan the conductor follows directly. Do not analyze task structure or parallelization yourself; delegate that reasoning to the orchestration-planner. Skip the planner only when a preceding architect or orchestration-planner has already returned a single fully-specified atomic implementation unit - i.e., the structural reasoning was already done by an agent, not self-assessed by the conductor. Or the unit meets the simple/targeted-unit metric (content/sections/04-risk-classification.md §Simple/targeted unit (mechanical metric)) and carries neither the Unfamiliar-codebase-area nor the Architecture-decision-constraining-future-choices signal - skip both architect and planner, go straight to Worker+Skeptic. Safety net: Mid-task reclassification (content/sections/04-risk-classification.md §Mid-task reclassification) applies if either hard exclusion turns out to be present after work starts. For the full named-agent table - agent names, roles, write permissions, when to spawn each - see content/references/agent-team.md. Fall back to general-purpose only when none of these fit. Pure shell and git operations follow the risk table: low-risk shell/git (reads, status, log, diff, diagnostic-only commands) run conductor-direct via the Bash tool - there is no separate shell-only agent type. When a shell task carries Elevated risk signals (side effects on shared or production state, irreversible ops, multi-file effects), or otherwise warrants delegation (long-running, or context-isolation desired), route it to general-purpose (or the appropriate named agent) for Worker + Skeptic review. No subagent can spawn subagents - the main agent is the sole orchestrator. On Claude Code this is enforced by a PreToolUse hook (hooks/enforce-orchestrator-singularity.py, wired by .claude/install.sh) that denies any Agent spawn issued from a subagent context (detected via the agent_id field); set AE_SINGULARITY_GUARD_DISABLE=1 to disable. Other adapters rely on the prose rule. The Mandatory Tier-3 review escalation rule (Risk Classification) is mechanically backstopped on Claude Code by a PreToolUse hook (hooks/enforce-tier.py, wired by .claude/install.sh) that denies an explicit sub-Opus model param on a security-auditor spawn (always) or a skeptic spawn whose brief matches a Tier-3 escalation signal; escalate-only and fail-open, it never blocks the omit-the-param role-default path and does not catch the novel-architecture signal (not keyword-detectable - the conductor and frontmatter default remain the controls there). The hook also backstops the authoring-role escalation (architect / adr-generator / product-discovery on Plan+ADR-tier units, per risk-config-and-tiers.md): it denies an explicit sub-Opus model param on those spawns when the brief matches an authoring escalation signal, but the structural Plan+ADR trigger is conductor-computed and invisible to the hook, so the conductor's explicit model: opus remains the primary control. Set AE_TIER_GUARD_DISABLE=1 to disable. Other adapters rely on the prose rule. The Brief/Plan authoring gate is backed by an advisory PreToolUse(Write/Edit) hook (hooks/enforce-planning-artifact-spawn.py) that warns when a docs/planning/** artifact is written without a recent architect spawn on record; warn-only, never blocks; set AE_PLANNING_GUARD_DISABLE=1 to silence. For Trivial-classified tasks, the conductor delegates the shippable change to a worktree-isolated engineer with no Skeptic and no brief file - the conductor never edits the shippable tree directly; only the execution location moves off the primary checkout, and the lightweight Trivial posture (no Skeptic, no brief) is preserved (see the shippable/exempt classifier in content/rules/conventions.md §Git Workflow). When fan-out is active, the orchestration-planner output JSONL block includes unit_slug, merge_order, and skeptic_strategy fields. Per-unit Skeptic spawning is a valid conductor behavior for parallel fan-out of independent units (complementing the existing "independent elevated units get their own Skeptic" rule in Task Decomposition below). The skeptic_strategy field - "per-unit", "integration", or "multi-dimensional" - is the authoritative source; do not re-derive this from the plan prose. multi-dimensional fans out a correctness-Skeptic, security-auditor, and perf-analyst in a single message on the same diff; see subagent-protocol.md for full definition. wrap-ticket writer carve-out: See content/references/conductor-operating-rules.md §wrap-ticket writer carve-out.

Learnings Pipeline - when a learning-worthy event occurs in a session: read content/references/delegation-detail.md §Learnings Pipeline for the two-feeder mechanism (learning-extractor vs learnings-agent), their distinct triggers, and session-tracking semantics.

Architect plan output requires Skeptic review before the plan is acted on. When the architect returns a plan, spawn a Skeptic using the "Document synthesis, architecture, and planning" adversarial brief. Do not spawn engineers, run the orchestration-planner, or take any other downstream action until the Skeptic grants sign-off. This is not optional - a flawed plan propagates errors through every downstream Worker. When orchestration-planner output triggers Brief or Plan promotion (see METHODOLOGY.md §Planning Artifacts), an additional Skeptic pass reviews the Brief or Plan before any engineer spawns.

Open Questions are a hard gate. If the Skeptic-approved Architect plan's "Open questions" section is non-empty, the conductor must NOT spawn any downstream worker (engineer, orchestration-planner, or any other agent that acts on the plan) until every open question is resolved. Resolution paths: (a) ask the human directly, (b) spawn an Investigator for questions that can be answered by reading the codebase, or (c) escalate if the question requires a human architectural decision. "Open questions" as a non-empty section is itself a protocol-level blocker - it is not advisory. A Worker that runs against unresolved open questions is executing on a plan the Architect itself flagged as incomplete, which is exactly the mid-Worker drift failure mode this gate exists to prevent. The same hard gate applies to Brief and Plan Open Questions with identical semantics (see METHODOLOGY.md §Planning Artifacts). A plan whose "Open questions" section is empty but whose "Deferred defaults" section is non-empty does NOT trigger this gate - Deferred defaults are resolved at authoring time and do not block downstream spawns.

Worker Preamble and Execution Contract Template - when spawning an Elevated-risk engineer: read content/references/delegation-detail.md §Worker Preamble and Execution Contract Template for the full contract fields, verification mandate, and task_id field semantics.

Worktree isolation is MANDATORY. Every concurrent engineer, qa-engineer, and release-orchestrator spawn MUST set isolation: "worktree" on the Agent tool call. The main worktree is reserved for the conductor's branch and its untracked scaffolding (.agentic/, in-flight planning artifacts, loop-state files). A subagent that runs in the main worktree can stage and commit conductor-side untracked files into its own commit, polluting the PR with files the operator never intended to ship. This is a class of failure that does not surface as a test break - it surfaces as a reviewer asking "why is .agentic/loop-state.json in this PR?" days later, and as cross-engineer commit contamination when two parallel spawns share a working tree. Isolation is the primary mechanism that prevents both.

There is no in-place exception. The Trivial-path solo engineer spawn is also isolation: "worktree": the conductor never edits the shippable tree directly, so even a single-engineer Trivial change runs in an isolated worktree. The lightweight Trivial posture (no Skeptic, no brief) is preserved; only the execution location moves off the primary checkout.

Pre-spawn stash fallback: see content/references/worktree-lifecycle.md §Pre-spawn stash fallback.

Preamble: "You are a Worker agent. Implement this specific change and return your complete output. The main agent will arrange Skeptic review."

Cross-harness teams (opt-in) - harness-neutral conductor contract. When team.yml is present and enabled: true, the conductor - regardless of which CLI harness it is running on (Claude Code, Codex, Gemini, Cursor, Kimi, Pi, omp, OpenClaw, OpenCode, Copilot, Hermes) - follows the same four-step dispatch contract for any dispatchable role (engineer, debugger, qa-engineer, skeptic, security-auditor) whose team.yml entry resolves to a harness other than its own:

1. Discover - run bin/agentic-team discover to confirm the target harness binary is installed and its native sandbox flag (if any). Missing binary -> fall back to native delegation unchanged, no error, no prompt.
2. Dispatch - run bin/agentic-team dispatch --role <role> --brief <path> to spawn the worker in its own throwaway workdir (worktree or directory copy). The conductor never runs git inside the worker's workdir; the conductor remains sole git owner of the live repo.
3. Status poll - run bin/agentic-team status <run-id> until the run reaches a terminal state (done/failed/timeout). Poll, do not block synchronously past the configured dispatch.timeout_seconds watchdog.
4. Collect - run bin/agentic-team collect <run-id> to demux the harness-specific output shape and extract the final message text.

Once collect returns the final message, that text is treated identically to a native Worker return summary: it enters the existing Skeptic/QA gates unchanged - same adversarial review, same qa_criteria triggers, same re-route limits. No new gate, no bypass, no special case for cross-harness origin.

Routing enforcement differs by harness. Only Claude Code has a mechanical PreToolUse deny hook (hooks/enforce-background-spawn.py, wired by .claude/install.sh) that enforces background-by-default on legacy Task spawns and suppresses native Task/Agent spawns and oh-my-claudecode:* Skill calls while a cross-harness run's sentinel (.agentic/teamrun/.active) is live. A future enhancement will also proactively block a native spawn for a dispatchable role whose resolved team.yml harness is not claude, but that check is not yet merged. On every other harness (Codex, Gemini, Cursor, Kimi, Pi, omp, OpenClaw, OpenCode, Copilot, Hermes) this is a binding prose contract, not a mechanically enforced hook - the conductor on those harnesses must self-apply the discover -> dispatch -> status -> collect sequence and must not silently fall back to a native spawn just because no hook stops it. See content/references/cross-harness-teams.md for the full decision rule, config schema, self-containment guard, per-harness dispatch table, and the per-harness enforcement-status table.

Digest-Return Discipline - when a loop-running background spawn returns: read content/references/delegation-detail.md §Digest-Return Discipline for the required digest fields, the optional learnings_candidate[] field routing, and conductor consumption rules.

Planning Artifacts

The promotion gate that sits between orchestration-planner output and the first engineer spawn: 0-1 Elevated units -> no Brief; 2-5 -> Brief; 6+ or cross-track or multi-session -> Plan. See content/references/planning-artifacts.md for the trigger table, track definition, gate-semantics authoring sequences, Brief template, Plan-tier directory layout, promotion mechanics, and qa_default_skip definition.

What blocks engineer spawn:

• Missing required artifact at any tier.
• Brief or Plan Skeptic finds Critical or Major findings: same loop semantics as architect-plan Skeptic (re-route limits apply, max 3 fix passes).
• Brief or Plan Open Questions section non-empty: same hard gate as architect Open Questions (METHODOLOGY.md §Delegation).
• Verification gate field set to "cannot specify": blocks Skeptic sign-off until resolved.
• Cross-artifact alignment check has an unresolved UNCOVERED success criterion: blocks the Skeptic-on-Brief from running until resolved.

What does not block:

• Risk class = Elevated single-unit: no Brief required. The architect plan is the artifact.
• A non-empty "Deferred defaults" section does not trigger the Open Questions hard gate (METHODOLOGY.md §Delegation).

Risk Classification

Perform a brief risk assessment before starting any task. Any single Elevated signal triggers Worker + fresh independent Skeptic review. Low risk permits direct action with a brief inline self-check. When in doubt, classify as Elevated. Downward tie-break counterweight: this default is overridden only when a named Low or Trivial override's full definition - including every exclusion clause - is affirmatively satisfied and zero other Elevated signals are present; "provably small" means the override can be named and each exclusion individually confirmed against the diff, not a general impression that the change looks safe.

Letter equals spirit: Violating the letter of these rules is violating the spirit. "I followed the intent" after skipping a required step is not a defense. This is not in tension with the downward tie-break counterweight above: affirmatively satisfying a named override's full definition, exclusions included, is applying the letter of that override - not bending it.

Context preservation - apply risk to the task, not the tool call. A sequence of reads, greps, and bashes that collectively constitute investigation or diagnosis is an Elevated task - regardless of whether each individual step would pass as Low in isolation. A read is Low when you know what you are looking for and are confirming a specific fact. A read is part of an Elevated investigation when the goal is to understand something - tracing behavior, finding a root cause, mapping blast radius, or producing a diagnosis. If you find yourself making exploratory tool calls to understand an unfamiliar area, stop and reclassify the overall task as Elevated. Delegation serves two pillars: a conductor doing investigation is unavailable for parallel coordination, and it conflates two distinct reasoning tasks (terrain-mapping vs orchestration decisions). Separating them via named agents improves both - the investigator maps the terrain without orchestration interference, the conductor coordinates without being pulled into implementation detail. (Context hygiene is an additional benefit; its weight is deployment-dependent.) When in doubt, spawn the appropriate named agent: investigator for codebase exploration, debugger for root cause analysis, architect for design questions.

Level	Delegation	Review	Declaration
Trivial	Delegate the shippable edit to a worktree-isolated engineer (no Skeptic, no brief file); the conductor never edits the shippable tree directly	None (no Skeptic, no brief file)	Silent
Low	Direct action	Brief inline self-check	Silent
Elevated	Worker	Fresh independent Skeptic	Stated before starting
Elevated + Cleanup	Worker	Skeptic -> /simplify -> Skeptic (narrow)	Stated before starting

Risk profiles

The methodology supports three risk profiles that shift the boundary between Low and Elevated. The profile is resolved during the Activation preflight (Step 1 and Step 3) and defaults to default when unset.

• relaxed — minimal Skeptic overhead. Use for rapid iteration on well-understood UI or local bug fixes.
• default — slightly relaxed from legacy behavior. Single-file locally-scoped behavioral edits are Low rather than Elevated.
• strict — broad Skeptic coverage. Use when correctness is paramount and review bandwidth is acceptable.

Profile deltas

The existing signal lists below represent the default profile. These deltas apply:

relaxed (additional Low overrides):

• Single-file, locally-scoped code edits with behavioral effect are treated as Low instead of Elevated.
  • Definition: touches exactly one file; modifies local behavior (e.g., a bug fix in one function, a local handler update); does NOT change exported API surface, types, shared utilities, shared design tokens, theme files, config, env, or CI; does NOT affect data flow across components; reversible with a one-line revert; no security/auth/permissions/billing/PII surface.
• Multi-file pure-UI-only changes are treated as Low instead of Elevated.
  • Definition: changes across 2-3 files that are exclusively visual or copy (colors, padding, font-size, Tailwind classes, display strings, labels, tooltips, placeholders); no logic, structural, or behavioral effect; no shared design tokens; no strings matched by tests; no protocol or infrastructure files involved.
• Bounded 2-3 file behavioral-edit changes are treated as Low instead of Elevated.
  • Definition: touches exactly 2-3 files. Mechanical connectivity bound: every file beyond the first is either (a) the colocated test/snapshot of another touched file, or (b) directly connected via a single grep-checkable import/call edge - the file imports or invokes a symbol that another touched file's diff modifies. A touched non-test file with no such edge disqualifies the whole change to Elevated; connectivity fails closed to Elevated when it cannot be mechanically verified (e.g., an operator config flip with no renamed symbol to trace). Total changed lines (added + removed) across all files <= 30. No exported API surface, types, shared utilities, helpers, abstractions, shared design tokens, theme files, config, env, or CI. Does NOT affect data flow across components and does not match "Logic with emergent/non-obvious cross-component interactions" (see the Elevated signal table in content/sections/02-delegation.md) - ported from the single-file override's guardrail. Not protocol or infrastructure files; each file individually reversible with a one-line revert; no security/auth/permissions/billing/PII surface; not an unfamiliar codebase area. Explicit backstop gate: applies only when zero other Elevated signals from the full canonical Elevated signal list are present.

default (compared to legacy):

• Single-file, locally-scoped code edits with behavioral effect are treated as Low instead of Elevated (same definition as relaxed above). All other signals remain at their legacy levels.

strict (removed Low overrides):

• UI-only copy changes are treated as Elevated; the Low override is removed.
• File renaming is treated as Elevated; the Low override is removed.
• Targeted wording fixes to already-reviewed content are treated as Elevated; the Low override is removed.
• Diagnostic-only changes and documentation-only file creation remain direct-action eligible but require the conductor's inline self-check (they are treated as Low rather than unconditionally direct).

All signals not mentioned above keep their default level regardless of profile.

Elevated signals

See §Delegation signal table above for the full Elevated signals list.

Trivial signals

ALL must hold - any single disqualifier pushes to Elevated: touches exactly one file (or one file plus its colocated test/snapshot); no change to control flow, data flow, state shape, API surface, or types; no change to shared design tokens, theme files, config, env, or CI; no change to anything a downstream consumer imports (exported symbols, public CSS classes, route paths); reversible with a one-line revert; no security, auth, permissions, billing, or PII surface involved. Canonical Trivial examples: a hardcoded color, padding, font-size, or spacing value in one component; user-visible copy, button label, heading, or alt text; moving or reordering elements within a single template or component; a typo fix in code, comment, or doc; Tailwind class tweaks on one element. NOT Trivial even if it feels small: edits to tailwind.config.*, theme files, CSS variables, or any shared token file; any change touching 2+ files; copy changes on legal, pricing, compliance, or marketing-claim surfaces; DOM-order changes with a11y or tab-order impact; anything in auth, payments, or data-handling paths; renames, even local ones. A new colocated test/fixture/snapshot file paired with a Low-tier (not Trivial-tier) edit does not itself confer Trivial eligibility - it rides the Low tier of the edit it accompanies (see the new-file-creation qualifier in the Elevated signal table); the Trivial two-file allowance above applies only when the base edit itself is Trivial-eligible. When in doubt between Trivial and Elevated, choose Elevated.

Conductor rule for Trivial: The conductor delegates the shippable edit to a worktree-isolated engineer (no Skeptic, no brief file) regardless of subagent state; the conductor never edits the shippable tree directly (see the shippable/exempt classifier in content/rules/conventions.md §Git Workflow). A commit message is still required. If a Worker discovers mid-task that the change is not actually Trivial (e.g., the "one-file color tweak" lives in a shared token file), it must stop, report, and the conductor re-classifies as Elevated.

Post-debugger Low classification. Post-debugger-brief bug fixes that are single-file and exercised by an existing test may be classified Low if they meet all Trivial signals; otherwise standard Elevated applies.

Simple/targeted unit (mechanical metric)

A unit is simple/targeted when ALL hold: (a) the diff touches exactly 1 file, or 1 file plus its colocated test/snapshot file (2 files total); AND (b) total changed lines (added + removed) <= 40; AND (c) the unit matches none of the 5 Mandatory Tier-3 escalation signal categories (see content/references/risk-config-and-tiers.md §Mandatory Tier-3 review escalation). This is computed from the actual diff, not estimated. This metric is a shared, canonical definition referenced by name from other parts of the methodology (loop-cost round limits, Tier-2 Skeptic carve-outs, architect/orchestration-planner skip conditions) - it does not by itself loosen any risk gate; a unit can be simple/targeted and still Elevated.

Low signals

Clearly reversible reads (reads with no writes); exploration / research / draft work - only when the output is understanding, not a decision-driving artifact; diagnostic-only changes (pure logging additions - console.log, .catch() for error visibility, test interceptors) across any number of files, where every change has zero behavioral effect — in strict profile, treat as Low (self-check required) rather than unconditionally direct; documentation-only file creation (new .md or .txt files that are pure lists, glossaries, or running notes - no code, no config; not a spec, plan, decision record, recommendation, architecture document, synthesis artifact, or any file in .claude/ or ~/DinoStack/; overrides the "new file creation" Elevated signal for this case only) — in strict profile, treat as Low (self-check required) rather than unconditionally direct; targeted wording fixes to already-reviewed content (phrasing adjustments where the substance was already Skeptic-approved in the current or a recent session - e.g., syncing parallel descriptions, adding a clarifying phrase to an existing enumeration; does not apply to new decisions, new recommendations, or new content not previously reviewed; does not override the "modifies protocol or infrastructure files" Elevated signal; overrides the single-file edit and new file Elevated signals for this case only) — in strict profile, this override is removed; treat as Elevated; file renaming (renaming or moving files via git mv or equivalent, with no content changes to any file - neither the renamed file nor any other file; overrides the "new file creation", "multi-file changes", and "Bash with side effects" Elevated signals for this case only; does not override the "modifies protocol or infrastructure files" Elevated signal - renaming protocol or infrastructure files remains Elevated regardless; if any other files reference the renamed path - imports, cross-references, config entries - the operation is Elevated because those reference updates constitute content changes in other files; if the file's name or path has behavioral significance by convention - framework routing, auto-discovery, config naming - the operation is Elevated because the rename changes behavior without changing file contents) — in strict profile, this override is removed; treat as Elevated; UI-only copy changes (rewording display strings, labels, tooltips, or placeholder text where the change has no logic, structural, or behavioral effect - e.g., "The path is clear" to "The path seems clear"; does not apply to strings matched by tests, error messages that drive control flow, or protocol/infrastructure files; overrides the "any code edit with behavioral effect" Elevated signal for this case only) — in strict profile, this override is removed; treat as Elevated.

Mid-task reclassification

If a task initially classified as Low reveals Elevated signals during execution, stop, reclassify as Elevated, and apply adversarial review from that point.

Low risk self-check

After completing a Low-risk change, re-read it in full. Verify intent, edge cases, and side effects. If any concern arises, reclassify as Elevated.

The conductor reads .agentic/config.json to resolve sixteen project-level orchestration toggles before classifying and spawning (one, qa_default_skip, is reserved/inert - documented for schema completeness but does not currently alter behavior). Read content/references/risk-config-and-tiers.md §Config Toggle Catalog (behavioral) for the full toggle list.

When a fresh GRAPH_REPORT.md exists at repo root, the conductor checks freshness, runs graphify update . once/session if stale, and treats a God-Node/Surprising-Connection target match as an additional Elevated signal; read content/references/risk-config-and-tiers.md §Graph-derived risk signal for the freshness algorithm and mechanism.

Separately, the operator-owned product-intent layer docs/overview/vision.md + docs/overview/requirements.md sits above task-level Briefs. When present, the Architect treats them as authoritative product intent and the Investigator reads them for framing context; agents read but never write these files. Schema and authoring rules: content/references/planning-artifacts.md §Product-intent layer (operator-owned) and content/rules/conventions.md §Project Overview Layer.

Capture classification is the learnings analogue to risk classification: just as every Elevated task triggers a risk declaration, every mandatory trigger event triggers a Capture: MUST/SKIP declaration. See content/references/capture-classification.md for the guardrail-first precedence chain and the MUST/SHOULD/SKIP table.

Declaration format

Risk: Elevated - [specific signal]
Tier: 2 (role default)
Applying adversarial review.

Risk: Elevated + Cleanup - [specific signal]
Tier: 2 (role default)
Applying adversarial review with /simplify cleanup pass.

When a Brief or Plan governs the task (see METHODOLOGY.md §Planning Artifacts), include the artifact path under the Risk: and Tier: lines:

Risk: Elevated - multi-unit feature
Tier: 2
Brief: docs/planning/<slug>.md
Applying adversarial review.

Risk: Elevated - cross-track architectural change
Tier: 3
Plan: docs/planning/<slug>/
Applying adversarial review.

Declare tier at spawn time; Tier 2 is the default for implementation roles, Tier 3 is mandatory for security/auth/crypto/payments/novel-architecture/high-blast-radius units; mechanical enforcement via hooks/enforce-tier.py (escalate-only, fail-open); read content/references/risk-config-and-tiers.md §Tier Declaration Detail for the role-default table, model-param mapping, and the role-model/cross-harness routing layers.

Spawn presets (per-spawn capability bundles)

Spawn presets (per-spawn capability bundles): See content/references/spawn-presets.md for the full protocol - bundle format, library locations (~/.agentic/presets.yml global; .agentic/presets.yml project), resolution rules, and the canonical architect:grill variant. Declaration format: a Preset: <agent>:<variant> line immediately below Tier: at spawn time. Example library: content/references/spawn-presets-example.yml.

For default tiers by agent role see the Role-default tier table above; for upgrade cases see the Mandatory Tier-3 review escalation rule above.

QA Gate

QA fires for every Elevated unit unless qa_skip is one of the 5 valid enum values: pure-backend-library, config-only, type-only-refactor, dep-bump-no-runtime-change, docs-only. The rationale is logged in the Brief / architect plan. A project having no qa.md is NOT a reason to skip QA. The qa_default_skip key in .agentic/config.json is reserved and inert (canonical definition in content/references/planning-artifacts.md).

Concurrent QA + Skeptic for UI-visible changes. When a unit's qa_criteria indicates QA fires (qa_skip == null, scenarios non-empty), spawn qa-engineer IN PARALLEL with the Skeptic in a single message (both background). Sign-off requires both to pass. For non-UI or deferred-QA paths, the post-Skeptic QA flow applies. See content/references/qa-gate.md for the full step-by-step gate flows, per-ticket in-flow rules, conductor env preflight, INCONCLUSIVE classification, parallel-by-worktree fan-out, and the dev-server boot pattern.

Diff-read rule and review ordering

For Elevated correctness, security, auth, crypto, or payments units, the Skeptic MUST read the diff in full before sign-off. QA evidence is supplementary - it confirms runtime behavior but does not substitute for line-by-line diff review. On these units the review order is fixed: diff first, QA evidence second.

For behavior-visible Elevated units that are not in the exclusion set above (UI changes, behavioral feature additions), the Skeptic SHOULD read the diff AND the QA evidence. When both are present, the Skeptic may use QA evidence as the primary signal for UI correctness claims, but diff review remains required for logic, side effects, and security surface.

For Low or Trivial units, the Skeptic applies its inline self-check. QA is not spawned for Trivial units (direct action path); QA for Low units follows the standard flow above.

Reading 'diff is secondary' as 'diff is optional' on any Elevated unit is a protocol violation. The diff obligation is unconditional for Elevated units; only the ordering and primary-signal weight differ by risk class.

Re-route limits

Re-route limits. Within any loop (Skeptic re-route or QA re-route), the conductor applies a max of 3 fix passes before escalating to the human. This applies to loops inside /ds-implement-ticket Phase 6 and 6b, and to any ad-hoc Skeptic loop the conductor runs outside that command. The conductor tracks re-route count in-context. When the cap is reached with open findings, the conductor does not spawn another Engineer - it surfaces the stall with the open findings list and waits for human direction.

Convergence failure. A convergence failure occurs when a Skeptic raises the same finding unchanged after the Engineer claimed to have addressed it. Convergence failures bypass the remaining iteration budget and escalate immediately. They indicate either a misunderstanding between the Engineer and the finding, or a design-level conflict that requires human arbitration. Within the persistence loop, one re-raise after a claimed fix is sufficient (overrides the 2-re-route rule in skeptic-protocol.md Section 5 - see that section for the override note).

Capability Preflight

Before every Agent spawn, the conductor reads the target agent's capabilities: block (if present) and verifies that all declared tools are available in the current environment. Absent block = no-op for that agent.

For each declared entry, the conductor evaluates the required_when predicate against the current spawn context (qa_criteria scenarios, Brief fields, task fields) to determine whether a required entry applies to this specific spawn. Surviving required entries are checked via their check command; safe entries with auto_install: true are installed automatically on miss before re-checking.

Advisory vs blocking mode is controlled by .agentic/config.json capability_preflight_mode (default blocking). In advisory mode the conductor emits a warning naming the agent, tool, and install command, then proceeds with the spawn. In blocking mode the conductor refuses the spawn when any required dependency remains missing after auto-install. The default is blocking as of P2 - every agent under content/agents/ now has a populated manifest. Setting advisory switches to warn-and-proceed.

For the full YAML schema, required_when predicate grammar, auto_install safety constraints, 7-step preflight procedure, output message format, and cache schema, see content/references/capability-preflight.md.

Cross-session loop resume

Long-running /ds-implement-ticket loops survive via .agentic/loop-state.json written at every phase transition; read content/references/cross-session-loop-resume.md §Cross-session loop resume at session start when loop-state.json exists.

Task-state file

For multi-unit plans the conductor maintains .agentic/tasks.jsonl (sole writer); read content/references/task-state-file.md §Task-state file for schema and protocol (incl author_model).

Events log

.agentic/events.jsonl is an optional per-project structured event log. The conductor appends one line per orchestration boundary (worker spawn, worker return, Skeptic finding/sign-off, QA result, /ds-wrap completion, finding fix). The file is gitignored.

Writer scope: the conductor is the primary writer of .agentic/events.jsonl. The Stop hook (hooks/stop-context.js) appends a single session_total event at session exit; this is sanctioned because the conductor turn has ended by the time the hook fires, so there is no contention. Subagents do not write to it. Other .agentic/ files retain their own writers (qa.md by qa-engineer, tasks.jsonl by conductor, loop-state.json by conductor + Stop hook).

Schema (one JSON object per line):

• ts: ISO8601 UTC timestamp (required)
• phase: orchestration phase label (required)
• event: event type (required)
• agent: spawned agent name, nullable
• task_id: correlation id when scoped to tasks.jsonl, nullable
• data: free-form object for event-specific fields

For the full V1 telemetry event-type schemas (field-level data shapes for spawn_start, spawn_complete, meta_review_complete, session_total, tool_failure_workaround), per-developer session log, pending-buffer, session_uuid, append discipline, atomicity, retention, and consumer notes, see content/references/events-log.md. (conductor_direct is deprecated and no longer emitted; its schema is preserved there for historical reference.)

Emit calls are inline shell snippets in command/agent specs that reach the relevant boundary; the conductor adds them as needed without ceremony.

Task Decomposition

One agent, one task, one prompt. The conductor breaks work into atomic units before spawning Workers. A focused agent is a correct agent - Workers should not do epics alone. Unit size is bounded by reviewability - Skeptic effectiveness and human PR comprehension - not by what the writing model is capable of producing; a more capable model that can write a larger unit in one pass should not, because review quality binds first.

Decompose implementation, not review. Workers get narrow scope; Skeptics get the full picture where it matters. The orchestration-planner identifies unit boundaries and dependencies; the conductor applies the following rules to the planner's output:

• Independent elevated units (planner-identified): each gets its own Skeptic (small diff, high signal)
• Interdependent elevated units (planner-identified): separate focused Workers, but one Skeptic reviewing the combined diff - the integration Skeptic replaces per-unit Skeptics, not layers on top
• Low-risk units: direct action with self-check (no Skeptic) - e.g., reads, snapshots, memory answers, subagent result synthesis, diagnostic logging only

Before spawning workers: run the orchestration-planner. After an architect or investigator returns a plan (and after the Skeptic has signed off on the plan - see Named agents section), before spawning any workers, run the orchestration-planner. The planner identifies which units are independent (parallel) vs dependent (sequential), and returns the execution order the conductor follows. The conductor does not derive this order itself - that reasoning belongs to the planner. Exception: if the architect already returned a single fully-specified atomic unit, skip the planner - there is nothing to decompose. Or the unit meets the simple/targeted-unit metric (content/sections/04-risk-classification.md §Simple/targeted unit (mechanical metric)) and carries neither the Unfamiliar-codebase-area nor the Architecture-decision-constraining-future-choices signal - skip both architect and planner, go straight to Worker+Skeptic. Safety net: Mid-task reclassification (content/sections/04-risk-classification.md §Mid-task reclassification) applies if either hard exclusion turns out to be present after work starts. When orchestration-planner output triggers Plan-tier promotion (see METHODOLOGY.md §Planning Artifacts), the conductor authors risk register, rollback, and verification gate before spawning workers.

Worktree Lifecycle

Two classes of worktree, two cleanup triggers.

Isolation is mandatory for every shippable-edit spawn. Every engineer, qa-engineer, and release-orchestrator spawn MUST set isolation: "worktree" on the Agent tool call (see §Delegation > Worker preamble). The main worktree is reserved for the conductor's branch and its untracked scaffolding. There is no exception: the Trivial-path solo engineer spawn is also isolation: "worktree" - the conductor never edits the shippable tree directly, so even a single-engineer Trivial change runs in an isolated worktree. Everything below assumes isolation is in use for every shippable-edit spawn.

Isolation worktrees (worktree-agent-*) are created by the Agent tool when isolation: "worktree" is set. Once the branch has been pushed to origin, the isolation worktree is redundant - the remote ref now holds the commits. The conductor must remove it immediately. See content/references/worktree-lifecycle.md §Isolation worktree cleanup commands for the command block.

Feature worktrees (feature/*, fix/*, chore/*) are removed after the PR is merged. See content/references/worktree-lifecycle.md §Feature worktree cleanup commands for the command block.

Worktree prune and branch prune run ONCE at session start, not before every subagent spawn. Base-branch resolution's non-interactive checks (declaration / develop / development) may run then too, but its step-4 prompt is deferred - resolved lazily on first shippable need (see content/rules/conventions.md, "Base branch resolution"). Cache the resolved base branch in-context for the session. Re-run only if: (a) the user explicitly switches branches during the session, or (b) more than 30 minutes of idle time has elapsed since the last preflight. See content/references/worktree-lifecycle.md §Session-start prune script and §Branch prune for the command blocks. The branch prune removes stale local branches via safe signals: [gone]-upstream branches, branches merged into origin/main, and orphaned worktree-agent-* branches.

Subagents do not have hooks. Hooks fire only in the main session. Claude Code locks each isolation worktree while its agent is running, so git refuses the non-force removal and branch-deletion commands this methodology uses against it from any concurrent session for the duration (a double-force git worktree remove -f -f would override the lock, which is why no cleanup path here uses it). Per Claude Code's own worktree documentation and its v2.1.157 changelog, once the agent finishes the harness releases the lock and then auto-cleans the worktree via git worktree remove (not a raw directory delete) if it is unchanged, and a periodic orphan sweep also skips any still-locked worktree. Isolation worktrees with changes persist until the conductor explicitly removes them.

Protocol Details (read on trigger)

Activation detail (Steps 5-6) - when Step 4 of the activation preflight resolves to active: Read content/references/activation-detail.md §Step 5: First-Activation Notice and §Step 6: Scaffolding-Sync Check for the sentinel write contract, TTY/QUIET gate, and agentic-migrate flow.

Planning artifacts (Brief and Plan tiers) - when authoring a Brief or Plan after orchestration-planner returns 2+ Elevated-or-above units: See content/sections/03-planning-artifacts.md for the blocking/non-blocking rules. Full ordering, trigger table, gate-semantics authoring sequences, Brief template, Plan-tier directory, verification-gate template, promotion mechanics, product-intent layer, and the canonical qa_default_skip definition live in content/references/planning-artifacts.md.

Delegation detail - when consulting the full Worker autonomy contract, stop-frequency planning signal, or investigator-before-architect rules: Read content/references/delegation-detail.md §Worker Autonomy Contract, §Stop-Frequency as Planning Signal, §Investigator-Before-Architect Rules, §Learnings Pipeline, §Worker Preamble and Execution Contract Template, and §Digest-Return Discipline.

Risk config and tiers - when consulting config toggles, the graph-derived risk signal, or tier declaration detail: Read content/references/risk-config-and-tiers.md §Config Toggle Catalog (behavioral), §Graph-derived risk signal, and §Tier Declaration Detail.

Phase breadcrumb - at every natural orchestration boundary (after agent spawn, agent return, escalation, task completion): Emit [phase: label] inline in your status update to the user. Full vocabulary in ~/DinoStack/.claude/skills/agentic-engineering/references/subagent-protocol.md Rule 6.

Skeptic loop orchestration - when Elevated risk is declared: Run /ds-skeptic for the full orchestration template, or read ~/DinoStack/.claude/skills/agentic-engineering/references/skeptic-protocol.md (Sections 2-5) for loop steps, state management, re-route limits, and escalation. For findings accumulation rules across loop iterations (findings_log schema, re-raise detection, auto-close rule), see /ds-implement-ticket Phase 6.

Findings classification and sign-off - when reviewing Skeptic output: Read ~/DinoStack/.claude/skills/agentic-engineering/references/skeptic-protocol.md (Sections 6, 11) for Critical/Major/Minor definitions, required sign-off format, and validation rules.

Elevated + Cleanup path - when declaring Elevated + Cleanup: Read ~/DinoStack/.claude/skills/agentic-engineering/references/skeptic-protocol.md (Section 12) for the /simplify integration workflow and second Skeptic narrow-scope review.

Adversarial briefs - when writing the brief for a Skeptic: Run /ds-skeptic (includes brief selection table) or read ~/DinoStack/.claude/skills/agentic-engineering/references/skeptic-protocol.md (Section 8) for domain-specific templates.

Parallel spawning and worktrees - when decomposing work into multiple agents: Read ~/DinoStack/.claude/skills/agentic-engineering/references/subagent-protocol.md (Sections 2, 5, 7) for parallel-by-default, worktree isolation rules, and check-in behavior.