DinoStack

An opinionated architecture for doing software engineering work with AI agents.

by Tyson Hummel

Operator attention is the scarce resource. Agents aren't. This architecture is an attempt to run as much of the process without you as possible - so the attention you do spend goes where judgment is load-bearing.

Built around Claude Code. AGENTS.md is the cross-tool standard - Codex reads it natively; Claude Code loads it via a CLAUDE.md containing @AGENTS.md and @MEMORY.md import lines. The patterns translate to any agentic framework.

Install

One command. Everything else is optional.

One line clones the repo into DinoStack/ inside your current directory, runs the installer, and writes the install path to ~/.agentic/agentic-engineering-config.json so update tooling (agentic-update, /ds-update-agentic-engineering) knows where to find it. Prerequisites: git and python3 - node is optional, needed only for the update TUI.

one-liner install $ curl -fsSL https://docs.dinostack.ai/install.sh | bash

Walkthrough: installing DinoStack and completing your first ticket, end to end.

Variants

Updating

Keep DinoStack current with one command.

Run agentic-update from any directory, no arguments. It pulls the latest main, rebuilds adapters only when something changed under content/, hooks/, bin/, or the build scripts, resets the version-check cache, and runs agentic-doctor --fix to repair drifted symlinks or hooks. No TTY required.

Path Command When
Shell (recommended) agentic-update Default; from any directory, no TTY
In-session /ds-pull-and-install Inside Claude Code, any project
TUI ./update.sh Interactive adapter selection
CI / scripts git pull && ./install-all.sh Non-interactive
Repair drift agentic-doctor --fix Fix broken symlinks/hooks (e.g. after moving the repo)

Full details: updating.md

What is DinoStack

The whole framework in one view

DinoStack is a methodology for shipping software with AI agents at scale. It turns a single AI assistant into a coordinated team of specialists, with the human operator as the specification and verification gate at either end.

Operator is the spec + verify gate Fresh Skeptic every round Knowledge compounds across sessions Portable across agent tools
What is DinoStack the whole picture
A coordinated team of specialists, gated by the operator

It classifies risk, delegates to background specialists, reviews adversarially, verifies behavior in-browser, manages context across long sessions, improves itself, and installs across every major agent tool - Claude Code, Cursor, Codex, Gemini, and more.

DinoStack: Agentic Engineering Framework overview. Seven capabilities with icons - classifies risk (effort scales to complexity); delegates to specialists (investigators, architects, planners, engineers working in parallel under a conductor); reviews adversarially (a fresh skeptic challenges every non-trivial change); verifies behavior (QA-engineer agents run in-browser QA); manages context (isolated worktrees, persisted Briefs and Plans); self-improving (captures learnings, decisions, and QA quirks into living docs); and portable (one install across Claude Code, Cursor, Codex, Gemini, and more).

Is It Working?

The protocol is passive. You know it's running when you see narration like this.

There is no dashboard and no daemon. The session agent classifies each task and delegates in the background, narrating as it goes. If you see phrases like these, it's working.

example session narration Routing this through orchestration-planner first...
Spawning architect to produce a plan...
Handing the architect's plan to engineer...
Spawning engineer to implement the cache layer...
Handing off to skeptic for adversarial review...
Spawning debugger on the failing test...
QA engineer verifying acceptance criteria in the browser...
If you see none of this, the task was classified as a small, reversible Direct action and handled in the main thread without a subagent. That is the protocol working correctly on a cheap task, not a sign that it is off.
Tuning Skeptic overhead: the default profile works for most projects. Add agentic-engineering-profile: relaxed to a project's AGENTS.md for faster iteration with less review, or strict when correctness is paramount. See Risk Profiles for the full breakdown.

Configuration Layer slides: getting started slides: AGENTS.md hierarchy

Skill-based entry point auto-triggered for engineering tasks

Every setting you can tune - what it does, your options, and how to set it. Full list of every key: configuration-reference.md.

Just ask your session agent. You can set any of these by describing what you want in plain language - say something like “set the risk profile to relaxed” and the agent applies it for you via /ds-config or directly. No config file editing required.

Risk profile

Controls how aggressively work triggers independent Skeptic review - relaxed means less overhead, strict means broader coverage.

Options: relaxed / default / strict   Default: default

Set: install - bash .claude/install.sh --profile=<v>; post-install - profile in ~/.claude/agentic-engineering.json, or agentic-engineering-profile: in AGENTS.md

Just ask “set the risk profile to relaxed”

Activation mode

Whether the methodology runs everywhere by default (opt-out) or stays dormant until a project opts in (opt-in).

Options: opt-out / opt-in   Default: opt-out

Set: mode in ~/.claude/agentic-engineering.json, or agentic-engineering: marker in AGENTS.md

Just ask “set activation mode to opt-out”

Auto-merge on green CI

Whether the conductor squash-merges a PR automatically once CI passes and it is approved.

Options: true / false   Default: false

Set: auto_merge_on_ci_green in .agentic/config.json

Just ask “turn on auto-merge when CI is green”

Commit telemetry

Whether per-developer session logs are committed to the PR branch as a separate commit.

Options: true / false   Default: true

Set: commit_telemetry in .agentic/config.json

Just ask “turn off commit telemetry”

Capability preflight

Whether a spawn with missing required agent tools warns and proceeds (advisory) or is refused until the dep is available (blocking).

Options: advisory / blocking   Default: blocking

Set: capability_preflight_mode in .agentic/config.json

Just ask “set capability preflight to advisory”

Abdication guard

Whether a Stop hook blocks conductor turns that end by asking permission for a non-destructive next step.

Options: true / false   Default: false

Set: abdication_guard_enabled in .agentic/config.json; disable per-session: export AE_ABDICATION_GUARD_DISABLE=1

Just ask “enable the abdication guard”

Ticket-driven

Whether new work creates a tracker ticket before the first implementer spawns - off skips the gate, offer prompts with a proceed default, require hard-blocks until a ticket exists.

Options: off / offer / require   Default: offer if a tracker is connected, else off

Set: ticket_driven in .agentic/config.json

Just ask “set ticket-driven to require”

Guard kill-switches

Per-session env vars that disable individual enforcement hooks or silence activation output.

Vars: AE_SINGULARITY_GUARD_DISABLE / AE_TIER_GUARD_DISABLE / AGENTIC_QUIET   Default: unset

Set: in-session - export <VAR>=1 before launching

Identity handle

The developer handle used to attribute per-session telemetry logs.

Options: any string   Default: none (absent file = no attribution; run agentic-identity auto to derive from GitHub login)

Set: agentic-identity auto / agentic-identity init <handle> / agentic-identity confirm

File settings (agentic-engineering.json, .agentic/config.json, AGENTS.md) take effect at the next session start. exported env vars apply to the current session. Full reference: configuration-reference.md.

The system uses a skill-based architecture. The global ~/.claude/[AGENTS|CLAUDE].md is minimal - just personal preferences and pointers to available domain skills. The real entry point is the /agentic-engineering skill, which auto-triggers when engineering tasks are detected and loads all rules and protocol references. This keeps always-loaded context small while giving the full methodology to sessions that need it.

~/.claude/[AGENTS|CLAUDE].md always loaded

  • Minimal global file - personal preferences and a list of available domain skills.
  • Does not contain the full methodology. Keeps always-loaded context small.
  • Contains behavioral overrides: complete tasks fully before stopping, no PR footer emoji
  • Exempt from the 40-line limit that applies to project root AGENTS.md files

~/.claude/skills/agentic-engineering/SKILL.md always loaded (on engineering tasks)

The /agentic-engineering skill is the actual entry point. It auto-triggers when engineering tasks are detected and loads the three rules files and reference docs via the skill directory. Canonical source in ~/DinoStack/.claude/skills/agentic-engineering/. Content detailed in the Protocol Layer below.

Skill directory layout: ~/DinoStack/.claude/skills/agentic-engineering/METHODOLOGY.md (top-level - delegation, risk classification, task decomposition), ~/DinoStack/.claude/skills/agentic-engineering/rules/ (code-standards.md, conventions.md, module-manifest.md) and ~/DinoStack/.claude/skills/agentic-engineering/references/ (skeptic-protocol.md, subagent-protocol.md, agent-team.md, design-goals.md, regression-test-obligation.md, qa-regression-obligation.md, doc-sync-obligation.md)
Multi-adapter: The ~/DinoStack repo ships adapters for Claude Code (.claude/), Cursor (.cursor/), Codex CLI (.codex/), Gemini CLI (.gemini/), Kimi Code CLI (.kimi/), OpenCode (.opencode/), Pi coding agent (.pi/), oh-my-pi (.omp/), Hermes (.hermes/), OpenClaw (.openclaw/), and VS Code Copilot (.copilot/) - the same methodology in each tool's native format.
Per-project override: Each project has its own root AGENTS.md (~40 lines) + subdirectory AGENTS.md files for deeper context. AGENTS.md files can override any global rule. The global layer provides the foundation; the project layer customizes it.
Activation modes: the installer writes ~/.claude/agentic-engineering.json with { "mode": "opt-out" | "opt-in", "profile": "relaxed" | "default" | "strict", "set_at": "<ISO8601>" }. opt-out (default) runs the methodology everywhere except projects that declare agentic-engineering: opt-out in their root AGENTS.md. opt-in keeps the methodology dormant until a project declares agentic-engineering: opt-in. The per-project marker is a single case-insensitive line, matched as a whole line with optional leading - . A short Activation preflight at the top of every skill and /-command reads the config plus the project marker; if the combination says inactive, the skill no-ops silently and falls back to default tool behavior for that session. Missing config or missing AGENTS.md both resolve to "mode=opt-out, marker=none" - the methodology proceeds, preserving behavior for users who installed before this feature existed. The profile field controls Skeptic overhead - see Risk Profiles below.

First-activation notice (Step 5): on first activation in a TTY session, the preflight prints a one-line notice naming the resolved mode, marker, and profile, and points users at /ds-status and /ds-disable. The notice is gated on a race-safe per-project sentinel at .agentic/.activated - exactly one of N concurrent subagents wins the create-only write and prints; losers stay silent. The TTY/QUIET gate (AGENTIC_QUIET=1 or not sys.stdout.isatty()) suppresses BOTH the notice and the sentinel write in CI, headless, and eval-harness contexts. Deleting the sentinel re-arms the notice only - it does not change activation state.
AGENTS.md - the cross-tool standard: AGENTS.md is the single source of project instructions. It is the cross-tool convention supported natively by OpenAI Codex CLI (OpenAI AGENTS.md guide, agents.md) and importable by Claude Code via its @file import syntax (Anthropic import-syntax docs).
Claude Code users: create a CLAUDE.md at the repo root containing two import lines - @AGENTS.md and @MEMORY.md - and Claude Code will import both AGENTS.md and MEMORY.md transparently.
Codex CLI users: Codex reads AGENTS.md natively with no extra setup.
Result: one content source drives all adapters. No duplication.

Protocol Layer slides: how it works slides: autonomy

Behavioral rules governing all work

From intent to verified code specification to verification
Five coordinated layers between the operator's two gates

The operator authors intent at the specification gate - goals, constraints, success criteria. A wide-bandwidth engine then runs five layers: risk routing chooses the level of autonomy, planning builds the blueprint, workers spawn to decompose the goal into parallel tasks, independent Skeptics challenge logic and implementation, and automated quality gates validate code, types, tests, and regressions. Work returns to the verification gate to review diffs, confirm outcomes, and approve with confidence.

The Delegated Methodology: from intent to verified code. Left panel "Authoring Intent" is the specification gate where the operator defines goals, constraints, and success criteria. The center "Wide Bandwidth Engine" runs five layers: 1) Risk Routing - classify the task and choose autonomy; 2) Planning - build the blueprint before execution; 3) Spawn Workers - decompose into specialized parallel tasks; 4) Skeptic Review - independent reviewers challenge logic, UX, and implementation; 5) Quality Gates - automated checks validate code, types, tests, and regressions. The right panel "Final Acceptance" is the verification gate to review PR diffs, confirm outcomes, and approve.

METHODOLOGY.md always loaded

  • Delegation model: conductor delegates, never implements
  • Risk classification: Low vs Elevated
  • Spawn threshold decision table
  • Task decomposition: one agent, one task
  • Planning artifacts: tiered Brief / Plan promotion gate (mechanical triggers: 2-5 Elevated units = Brief; 6+ or cross-track or multi-session = Plan)
  • Worktree lifecycle management
  • Pointers to detailed protocol docs

code-standards.md always loaded

  • Tool discipline (Read primary; Glob/Grep preferred when available, Bash fallback)
  • Agent-ergonomic tool selection (token-efficient output, CLI over MCP when cheaper, measure before adopting)
  • Quality gates: lint, typecheck, test
  • Per-language strict defaults
  • Package management rules
  • Browser verification via agent-browser
  • Module manifests: required header block on non-trivial files (exports public symbol, ~50+ LOC, or side-effecting). Six fields: Purpose, Public API, Upstream deps, Downstream consumers, Failure modes, Performance

conventions.md always loaded

  • Writing style (no em dashes)
  • Project structure convention
  • Git workflow (worktrees, PRs, branches)
  • Session context + memory system

Referenced Protocol Documents (~/.claude/skills/agentic-engineering/references/)

skeptic-protocol.md on demand
subagent-protocol.md on demand
agent-team.md on demand
design-goals.md on demand
regression-test-obligation.md on demand
qa-regression-obligation.md on demand
doc-sync-obligation.md on demand
graphify.md on demand

Not auto-loaded. Read on-demand when protocols are triggered (e.g., Elevated risk declared, Skeptic review needed).

Protocol Documents

Deep dive into the five canonical spec files in ~/DinoStack/.claude/skills/agentic-engineering/references/

design-goals.md on demand
Why the System Exists - 4 goals and explicit non-goals, written for evaluators and auditors.

The Four Goals

  • Goal 1 - Responsiveness. Conductor stays free to respond. All work backgrounds. Spawn threshold is intentionally low. Never implement inline.
  • Goal 2 - Adversarial accuracy. LLMs are systematically overconfident about their own outputs. Fresh Skeptic counters anchoring bias. Brief passed verbatim. No self-review path for Elevated work.
  • Goal 3 - Cross-session continuity. Three tiers: context.md (ephemeral), MEMORY.md (stable facts), AGENTS.md (architecture). Stop hook auto-writes. /ds-wrap enriches. No ceremony required from user.
  • Goal 4 - Context window efficiency. Always-loaded files must be minimal. Trigger-pointer pattern: risk signals inline (chicken-and-egg), protocol details deferred until triggered.

Explicit Non-Goals

  • No persistent memory of personal facts or preferences (project-affecting info only)
  • Does not replace proper documentation (MEMORY.md is not a design doc)
  • Does not automate irreversible operations at git/infrastructure boundary (human confirms)
  • Does not guarantee correctness (defense in depth, not proof)
  • Does not eliminate need for human judgment (escalation paths exist for ambiguity)
  • Does not manage infrastructure or secrets
Evaluator questions for each goal:
G1: Does the main agent ever block or do substantial work inline?
G2: Is the Skeptic actually fresh each round? Is the brief verbatim?
G3: Is the Stop hook firing? Is MEMORY.md accurate? Is AGENTS.md lean?
G4: Would removing this line cause a wrong classification?

skeptic-protocol.md on demand slides
The Adversarial Review Methodology - 14 sections. The core quality mechanism.

The Core Loop (Sections 1-5)

  • Worker implements → fresh Skeptic critiques → findings routed back → repeat until clean sign-off
  • Fresh Skeptic every round - never continued from prior round. Independence requires clean context (no anchoring to Worker's justifications)
  • Global-context input set (Section 4.5) - every Skeptic spawn prompt includes: architect plan, Brief/Plan artifact, qa_criteria block, per-consumer impact table, related files, diff under review. Step 0 validates completeness before any review content is produced; incomplete inputs return BLOCKED. Supplemental reviewers (security-auditor, perf-analyst) receive a lexically distinct Supplemental-context block with no Step-0 enforcement.
  • Resolved Issues Preflight prevents re-raising fixed items, but Skeptic can contest insufficient resolutions
  • Same finding contested 2+ re-routes → escalate to human (prevents infinite loops)
  • Simple/targeted changes: capped at 1 Skeptic round. Standard Elevated: 2-re-route limit

Findings Classification (Section 6)

  • Critical - blocks sign-off. Security vulns, correctness failures, data loss paths
  • Major - blocks sign-off unless Worker provides compelling documented reason to defer. Missing error handling, edge cases, design issues
  • Minor - never blocks sign-off. Applied by a separate Worker after sign-off, no follow-up Skeptic needed
  • Unclassified findings default to Major

Persistence Loop (inside /ds-implement-ticket)

  • Loop-aware, not one-shot - /ds-implement-ticket runs Engineer → Skeptic → QA as a bounded loop, not a single pass. Re-routes are a named primitive, not ad-hoc conductor judgment.
  • Max 3 fix passes per phase - Skeptic loop (Phase 6) and QA loop (Phase 6b) each have an independent 3-pass cap. Hitting the cap escalates to the human; the conductor does not spawn a fourth pass.
  • Findings accumulate - the findings_log carries forward across iterations. A finding closed in iteration 1 cannot be silently re-raised as new in iteration 2; the Skeptic must explicitly contest the claimed fix using a [PREV: id] tag.
  • Convergence failure - one re-raise of a Critical finding after a claimed fix triggers immediate escalation (does not consume remaining iteration budget). Signals a design-level conflict requiring human arbitration.
  • Explicit escalation contract - the loop exits with a structured stall report (cap_reached, convergence_failure, or blocked) listing open findings and recommended actions.
  • Durable state - loop state is written per ticket to .agentic/loop-state-<LOOP_KEY>.json at every phase transition (atomic write), superseding the single legacy .agentic/loop-state.json, which is still read and adopted when present. Keying per ticket means two sessions working two different tickets in one checkout each keep their own bookkeeping instead of contending for one file. Long-running loops survive rate limits and session exits: on the next /ds-implement-ticket invocation the conductor detects the interrupted state for that ticket's own key, applies a rate-limit wait if needed, and resumes from the last committed phase boundary. Schema includes brief_path, plan_path, and promotion_tier fields that record the planning artifact tier for the active task (used for mid-flight promotion and auto-promotion at the 3rd resume). No work is lost.
  • Learning extraction - at Phase 6 clean exit (Skeptic sign-off), the learning-extractor agent reads the resolved findings_log and writes structured fix-pattern entries to .agentic/learnings.md (append-only, dedup, cap 5/run). Each entry has ID LRN-YYYYMMDD-XXX, severity, domain tag, pattern description, fix guidance, and source reference. These entries feed into wrap-ticket at Phase 11b for richer MEMORY.md/decisions.md appends. Soft-fail only; never blocks the loop. During active sessions, the learnings-agent captures learning events in real-time (error→fix cycles, resolved Skeptic findings, discovered workarounds) and writes them immediately to .agentic/learnings.md, reducing reliance on manual /ds-wrap.
  • Task coordination surface - multi-unit orchestration plans use .agentic/tasks.jsonl as a durable task coordination surface; the conductor tracks task status, dependencies, and loop state across the plan lifecycle. Applies to plans with 2+ tasks; single-unit spawns use in-context state only.
  • Context-size preflight - at the top of /ds-implement-ticket, before any Phase 1 work, a two-level guard checks session load: if the turn count is at or above the soft limit (15–20 conductor turns) with substantive tool-call results in context, or a prior subagent result block of substantive size is visible from this session, it prints a warning with the recommended /ds-wrap → new session → re-invoke pattern and waits for operator confirmation; above the hard limit, it refuses further implementation and subagent spawns unconditionally. Silent on clean sessions.
  • Phase 12b: Operator Runbook - after all tickets in a session complete, the conductor prints a structured handoff: what PRs landed (✓ PR #N → url), the next copy-pasteable /ds-implement-ticket command (extracted from the most recent triage artifact's Kickoff prompts), and any blockers or deferred items. Soft-fail throughout; skipped when no PR was opened, when Phase 12a already printed a pause summary, or when Phase 12a’s goal-met short-circuit already printed a terminal summary.

Parallel Fan-out slides

  • N engineers in one message - when orchestration-planner returns 2+ independent units, /ds-implement-ticket Phase 5 fans out: one worktree-isolated engineer per unit, all spawned in a single message (parallel). N=1 falls through to the standard path.
  • Per-unit P0 loops - each unit runs its own Engineer → Skeptic persistence loop inside its worktree. "Done" means Skeptic signed off, not first commit. The conductor joins only after every unit reaches a terminal state.
  • Skeptic strategy driven by planner - skeptic_strategy: per-unit: independent units each get their own Skeptic (can run in parallel). skeptic_strategy: integration: interdependent units share one Skeptic reviewing the combined diff - replaces Phase 6, not layers on top. skeptic_strategy: multi-dimensional: for high-stakes Elevated units (auth, payments, migrations, crypto) - fans out correctness-Skeptic, security-auditor, and perf-analyst in a single message on the same diff; all three must clear before sign-off.
  • Join conditions - all-done (merge in merge_order), partial success (merge green units, retry failed once at depth=1), total failure (escalate), blocked (escalate immediately).
  • Sequential --no-ff merge - unit branches merged in planner-specified merge_order. Conflict at any step: abort, stop remaining merges, spawn single engineer for sequential re-implementation. Post-merge integration quality check catches cross-unit failures.
  • Task state in .agentic/tasks.jsonl - conductor writes all entries (pending → in_progress → done/failed/blocked). Workers return summaries only. Crash recovery: in_progress entries on resume treated as failed, re-spawned with original brief from inputs field.

Cost-Aware Tier Routing

  • Conductors declare Tier 1/2/3 at spawn time - routes lightweight tasks to faster models and critical reviews to max-capability models
  • Tier 1 - cheap/fast (Haiku). Declare explicitly for shallow reads, existence checks, format-only tasks, and mechanical transformations
  • Tier 2 - implementation default (Sonnet). Most spawns land here: engineer, investigator, qa-engineer, and other implementation roles
  • Tier 3 - review default (Opus). Skeptic and security-auditor default to Tier 3 via frontmatter; upgrade architect/engineer to Tier 3 for novel architecture or high-blast-radius units; on Plan+ADR-tier units (cross-track / architecture-constraining), the authoring architect/adr-generator/product-discovery must also be Tier 3, conductor-declared via explicit model: opus and backstopped by enforce-tier.py
  • Tier is a required field - every Elevated spawn carries a Tier: line below Risk:. Each agent's frontmatter model: sets the model when the spawn-call param is omitted; the param overrides for upgrades or budget-mode downgrades (never for mandated-Tier-3 Skeptics). Declaration without the tool-call param produces frontmatter-default behavior, not Tier 2
  • Codex/Gemini resolve tiers from ~/.agentic/tier-map.yml - Claude Code uses a built-in enum (haiku/sonnet/opus); no tier-map lookup needed for Claude
  • Pi/oh-my-pi can resolve roles from ~/.agentic/role-models.yml - opt-in per-role model strings plus antagonist reviewer diversity for skeptic and security-auditor; if absent, Pi uses session defaults

Domain Adversarial Briefs (Section 8)

  • Smart contracts: reentrancy, access control, signature replay, fee bypass
  • Auth/sessions: session fixation, token replay, privilege escalation
  • API endpoints: malformed inputs, race conditions, missing validation
  • Crypto: weak randomness, domain separation, algorithm confusion
  • DB/migrations: idempotency, partial failure, rollback paths
  • Data pipelines: double-processing, silent failures, state divergence
  • Doc synthesis: internal consistency, assumptions, completeness gaps
  • General code: logic errors, edge cases, incorrect assumptions

Elevated + Cleanup Path (Section 12)

  • Worker → Skeptic sign-off → /simplify → narrow-scope Skeptic
  • For substantial implementations where code hygiene matters
  • Second Skeptic reviews only the /simplify diff (behavioral preservation check)

New Skeptic Obligations

  • Module manifest check - tiered enforcement on non-trivial modules (exports a public symbol, ~50+ LOC, or side-effecting): missing manifests are Minor (comprehension hygiene, non-blocking); stale manifests (no longer reflect purpose, public API, dependencies, or failure modes) are Major (blocks sign-off absent a compelling documented reason to defer); stale manifests whose inaccuracy could mislead a caller on a correctness or security path are Critical. The result is now output-required via a fixed Manifest check: sign-off line.
  • New-test-CI-wiring check - for each new test file in the diff, verifies a matching reference exists in a CI workflow (an exact file reference, a covering glob, or an auto-discovering runner). A new test file wired into no CI workflow is a Major finding - a test that never runs provides no regression protection. The result is output-required via a fixed Test-CI-wiring check: sign-off line.
  • Regression test verification - before granting sign-off when a Critical/Major finding was fixed, verifies a regression test was added (or a documented exception given). Missing test without explanation is a Major finding. The same verification applies to QA-fix iterations: a fix engineer addressing a qa-engineer FAIL must add a regression test or append a documented exception to .agentic/qa-regressions.md (see qa-regression-obligation.md).

Cognitive Surrender Check

  • A Skeptic that agrees with the Worker on every point with zero findings across two iterations is a possible rubber-stamp - the failure mode of treating the LLM as System 3 and outsourcing judgment rather than offloading mechanics.
  • Cure: an audit-note Minor finding attesting that the Skeptic re-read the diff end-to-end with independent attention. The note documents what was checked, not what was wrong.
  • Audit-note Minors are exempt from the /ds-implement-ticket Phase 6 re-raise and convergence-failure detection - they are bookkeeping, not contested findings, and must not stall the loop.

Calibration Layer (Section 13)

  • The audit-note Minor is the per-spawn rubber-stamp defense. The calibration layer is the long-horizon backstop - aggregate drift detection without enlarging the per-spawn review surface.
  • Findings counters in events.jsonl - every Skeptic spawn_complete carries findings_count, diff_lines, signed_off, and iteration inside data. Conductor builds the merged JSON inline; subagents never write to .agentic/.
  • 5% sampled meta-Skeptic - deterministic hash(task_id+iteration) % 100 < 5. Background fire-and-forget; conductor declares the unit complete without waiting. Meta-Skeptic returns text only; conductor parses and emits meta_review_complete.
  • Surfacing - Critical/Major divergence on a sampled spawn surfaces as one inline META-DIVERGENCE: line at the next turn boundary. Original sign-off remains binding; the notice is advisory. Dual triggers: in-session (Phase 6 boundaries) and session-start sweep (catches async returns from prior sessions). The sweep paginates via .meta-divergence-last-sweep timestamp tracker — reads only events newer than the last sweep, capped to 100 lines on first run.
  • bin/agentic-calibrate - density (findings per 100 diff-lines, excludes zero-diff rows) and divergence (meta-Skeptic rubber-stamp rate). Warming-up line shown until 10 qualifying spawns observed.
  • Threat model: drift detection in a non-adversarial conductor relationship. Not cheating-prevention - a compromised conductor can mis-emit counts. Target is operator self-deception over time, not adversarial spoofing.

Planning Artifacts slides

Planning artifacts Brief or Plan, decided mechanically
How much planning a task needs is a mechanical gate, not a guess

The promotion gate sits between orchestration-planner output and the first engineer spawn, validating the plan before any code is written. The trigger is purely mechanical, counting Elevated units: 0-1 needs no artifact and the conductor spawns engineers directly; 2-5 requires a one-screen Brief covering problem, success criteria, and constraints; 6+ units, or cross-track or multi-session work, requires a full Plan-tier directory with an architect plan and risk register, and architecture-constraining work adds an ADR.

DinoStack: The Planning Artifacts Promotion Gate. After task decomposition (orchestration-planner output), an Elevated Units Gate validates the plan before any code is written. The required artifact scales mechanically with the number of Elevated units: 0-1 units require no artifact and the conductor spawns engineers directly; 2-5 units require a one-screen (15 to 20 line) Brief covering the problem, success criteria, and constraints; 6 or more units, or cross-track or multi-session tasks, require a full Plan-tier directory containing an architect plan and a risk register, plus an Architecture Decision Record (ADR) when the work constrains architectural decisions. Summary table: 0-1 elevated units maps to no artifact (direct spawn); 2-5 maps to a Brief; 6 or more or cross-track maps to a full Plan plus ADR.
  • Promotion gate (mechanical) - sits between orchestration-planner output and the first engineer spawn. Trigger table: 0-1 Elevated units = no artifact; 2-5 Elevated units = Brief required; 6+ Elevated units OR cross-track OR multi-session = Plan required. Trivial units do not count toward thresholds. "Cross-track" = distinct depth-1 directories each with their own AGENTS.md; cross-track or architecture-decision-constraining work additionally requires an ADR alongside the Plan.
  • Brief template - one-screen (~15-20 lines) at docs/planning/<slug>.md. Fields: Problem, Success criteria (max 4 bullets), Non-goals (max 3 bullets), Constraints (hard only), Verification (single non-skippable line - "cannot specify" blocks sign-off), Linked artifacts.
  • Plan-tier directory - docs/planning/<slug>/ containing brief.md, architect-plan.md, orchestration.jsonl, risk-register.md (<=10 lines), rollback.md (<=10 lines), verification-gate.md. Assembled from existing artifacts plus three short conductor-authored coverage docs.
  • Verification gate non-skippable - verification-gate.md owns the trigger (signal that verification failed); rollback.md owns the procedure. Any "cannot specify" entry blocks Skeptic sign-off until the planning gap is resolved.
  • Mid-flight retroactive Brief - in-flight engineer is allowed to return; already-completed units are not retroactively re-reviewed; retroactive Brief is authored before the next engineer spawn and governs all subsequent units.
  • 3rd-resume auto-promotion - a Brief-tier task on its 3rd resume per that ticket's own .agentic/loop-state-<LOOP_KEY>.json resume_count (legacy: .agentic/loop-state.json) auto-promotes to Plan tier (mechanical, regardless of operator notice).
  • Engineer contract additions - brief_path and plan_path fields added to the Worker execution contract; engineer reads the Brief or Plan and treats success criteria + verification gate as authoritative alongside the architect plan.
  • Interactive /ds-brief path - Brief can also be authored interactively via /ds-brief before architect and engineer are spawned. When brief_path is pre-populated from a /ds-brief session (brief_source: operator), the conductor skips Brief authoring at the promotion gate and uses a completeness-only Skeptic variant instead of the full framing review.
Core thesis: "The value of an adversarial reviewer is independence. A reviewer who has already heard the implementer's justifications is no longer independent." The brief must be passed verbatim - never softened. Sign-off requires 6 elements: Reviewed, Findings, Active search attestation, Manifest check, Test-CI-wiring check, and explicit sign-off statement.
Regression Test Obligation: Every Critical or Major finding that gets fixed without a regression test is a latent regression. The Worker adds a test that would have caught the failure; the Skeptic verifies it exists before sign-off. The test lives in the project's normal test suite, alongside existing tests for the affected module, so the same bug cannot silently reappear in a future change.
QA Regression Test Obligation: The symmetric rule for qa-engineer FAILs. When a fix engineer addresses a QA failure, it adds a unit/integration/e2e test that would have caught the failing scenario; the parallel Skeptic on the QA-fix iteration verifies it exists before sign-off. When a regression test is genuinely infeasible (visual conformance failure with no headless-testable observable, etc.), the engineer appends a curated entry to .agentic/qa-regressions.md so architects re-check the surface on future tickets via qa_criteria.scenarios[]. Canonical statement in qa-regression-obligation.md.

subagent-protocol.md on demand
The Orchestration Methodology - 11 sections. The outer frame governing delegation.

The Seven Rules

  • Rule 1 - Always background. Most critical rule. Foreground blocks the conductor entirely. All delegated work runs in background.
  • Rule 2 - Parallel by default. Independent tasks spawn simultaneously. "Can I start B before A finishes?"
  • Rule 3 - Spawn threshold. Elevated risk → spawn. Low risk → direct action. When in doubt, Elevated.
  • Rule 4 - Agent type discipline: spawn an agent type that exists. No subagent can spawn subagents (a platform property of every subagent). Low-risk shell/git is conductor-direct - there is no shell-only agent type.
  • Rule 5 - Skeptic Protocol orchestrated by main agent. Architect plans must receive Skeptic review before acting on them.
  • Rule 6 - Check in, don't disappear. Status updates immediately after spawning. Proactive reporting when tasks complete.
  • Rule 7 - Direct actions permitted. Reads, git status, screenshots, memory answers, synthesizing returned results.

Composition Pattern (Section 6)

  • Decompose into atomic units (one agent, one task, one prompt)
  • Classify risk per unit independently
  • Spawn in parallel for independent units
  • Review scope: independent units get per-unit Skeptics; interdependent units get one integration Skeptic (sees combined diff)
  • Mid-task re-decomposition if Worker discovers scope is too broad

Worktree Isolation (Section 7)

  • Parallel agents writing to same repo MUST use isolation: "worktree"
  • Without it: concurrent git checkout silently corrupts both agents' work
  • Not needed for: single agents, separate repos, read-only agents

Anti-Patterns (Section 8)

  • Foreground blocking (most critical violation)
  • Sequential when parallel is possible
  • Treating risky shell/git as conductor-direct to dodge review
  • Main agent doing implementation work
  • "Looks simple" rationalization
  • Softening adversarial briefs
Core principle: "The main agent is a conductor, never an implementer. The conductor is the main session agent: it decomposes work, spawns subagents that do the implementation and investigation, stays available to the user, and synthesizes results when those subagents report back." The Subagent Protocol is the outer frame (should I delegate?). The Skeptic Protocol is the inner loop (is the output correct?).

agent-team.md on demand
The Team Playbook - 18 named agents, 5 composed flows, decision rules, and spawn instructions.

The Team

18 named agents (investigator, debugger, security-auditor, architect, orchestration-planner, engineer, skeptic, qa-engineer, adr-generator, adr-drift-detector, perf-analyst, product-discovery, release-orchestrator, dependency-auditor, learning-extractor, goal-condition-evaluator, wrap-ticket, learnings-agent). Most agents are read-only. Engineer, release-orchestrator, learnings-agent, and wrap-ticket write files. Full descriptions in the Agent Layer section below.

Decision Rules

  • orchestration-planner when task is complex, agents/sequencing unclear, multiple phases
  • architect when meaningful design decisions, unfamiliar codebase, multi-subsystem feature
  • security-auditor when touching auth, sessions, tokens, secrets, privilege boundaries
  • debugger when root cause not obvious, stack trace needs diagnosis
  • Skip architect for well-understood changes → straight to engineer
  • Skip debugger for already-understood bugs → straight to engineer

Spawn Requirements

  • engineer: architect's plan + file paths + acceptance criteria + session context
  • skeptic (plan review): adversarial brief verbatim + architect's complete plan + architectural constraints
  • skeptic (code review): adversarial brief + engineer output + resolved issues preflight
  • security-auditor: files changed + domain description + known mitigations
  • All agents spawn in background. Main session is the sole orchestrator.
Mandatory gate: Architect plan output MUST receive Skeptic review before the plan is acted on. Do not spawn engineers or run the orchestration-planner until the Skeptic grants sign-off. A flawed plan propagates errors through every downstream Worker.

Agent Layer slides: agent team

Specialized subagents spawned by the conductor

Bounded Skeptic review adversarial, but it terminates
Adversarial review that converges instead of looping forever

Every round spawns a brand-new Skeptic so it reviews against the original brief, passed verbatim, with no anchoring to the Worker's justifications. Findings are triaged Critical (blocking), Major (blocking without deferral), or Minor (non-blocking cleanup). A strict three-pass cap prevents infinite loops, and re-raising a Critical after a claimed fix is a convergence failure that escalates immediately. Hitting the cap or failing to converge hands a structured stall report to the human operator for judgment.

DinoStack: The Bounded Skeptic Review Loop. A Worker agent's output enters an adversarial review cycle where every round spawns a fresh Skeptic agent to prevent anchoring bias to the Worker's justifications, and the original task brief is passed verbatim so the Skeptic reviews against the original intent. The Skeptic triages findings into Critical (blocking), Major (blocking without deferral), and Minor (non-blocking cleanup). Guardrails and human escalation: a strict three-pass cap on fix attempts per phase prevents infinite loops; re-raising a Critical finding after a claimed fix is a convergence failure that triggers immediate escalation, skipping the remaining iteration budget. Hitting the cap or failing to converge generates a structured stall report handed off to the human operator for judgment and arbitration.

Planning and Analysis Agents

  • product-discovery - facilitated discovery before any architecture work. Reframes a build request to the problem behind it, identifies personas (including the reluctant counterparty), runs an attributed market scan, and stages a proposed vision.md + requirements.md to docs/overview/_proposed/. Never writes the operator-owned canonical intent layer - the operator promotes the drafts. Runs before the architect: discovery decides WHAT and WHY, the architect decides HOW.
  • investigator - traces data flow, maps blast radius, and explores unfamiliar areas. Used when you need to understand code before deciding how to change it. Returns an investigation brief for the conductor to hand to architect or engineer.
  • architect - reads the codebase and produces a structured technical plan before any code is written. Identifies patterns, constraints, and evaluates approaches. Its output MUST be Skeptic-reviewed before any downstream work.
  • orchestration-planner - given a complex goal, maps which agents to spawn, in what order, with what handoffs. Returns a structured execution plan the conductor follows directly. Used when the right agent combination is not obvious. Checks for .agentic/tracking.md (resolver: .agentic/ preferred, legacy .claude/ fallback) in the project root and follows its instructions when present.

Diagnosis and Security Agents

  • debugger - given a failing test or stack trace, forms and tests hypotheses to find the root cause. Returns a diagnosis plus a fix brief. Does NOT implement the fix - the engineer does that. If confidence is Low, escalates to human rather than guessing.
  • security-auditor - applies OWASP Top 10 and CWE-category analysis. Assumes a capable attacker. Produces a structured findings report with severity ratings, specific code locations, and remediation guidance. Used in addition to (not instead of) the Skeptic.

Implementation Agent

  • engineer - the primary agent that writes files. Reads codebase conventions, implements the change, runs quality gates (lint, typecheck, test), and returns a clear summary. Writes module manifests on non-trivial files and adds regression tests when fixing Critical/Major findings. Receives the architect's plan, file paths, acceptance criteria, and session context. Can return NEEDS_CONTEXT, BLOCKED, or DONE_WITH_CONCERNS statuses.

Review Agent

  • skeptic - adversarial reviewer. Always a fresh invocation (never continued from a prior round). Receives an adversarial brief and the Worker's output. Classifies findings as Critical/Major/Minor and provides structured sign-off. Also checks for DRY violations, duplication, and missed abstractions. Checks module manifests on non-trivial files with tiered enforcement (missing = Minor, stale = Major, stale-on-correctness/security path = Critical) and verifies regression tests were added for any Critical/Major fixes. Actively verifies cross-file identifier consistency after renames or removals (config keys, exported symbols, env vars) and flags fire-and-forget async calls with no attached error handler. The cross-cutting review role - its specialty is adversarial review itself, applied across every flow rather than producing a forward artifact.

Supplementary Agents

  • adr-drift-detector - audits codebase compliance against Architecture Decision Records
  • adr-generator - creates comprehensive ADRs with structured formatting
  • qa-engineer - verifies changes in a real browser, runs test suites, validates against acceptance criteria. For UI-visible changes, spawned IN PARALLEL with the Skeptic (single message, both background) - sign-off requires both to pass.
  • perf-analyst - profiles CPU, memory, and latency hotspots; produces a measured findings brief for the engineer. Does not implement fixes.
  • release-orchestrator - sequences the full release from pre-flight gates through version bump, tag, deploy, and post-deploy verification. Enforces gates; refuses to proceed when any check fails.
  • dependency-auditor - supply-chain review: CVE scanning, license compliance, and lockfile analysis across all detected ecosystems. Read-only; produces a findings brief for the engineer.
  • learning-extractor - per-ticket learning extraction at Phase 6 clean exit. Reads the resolved findings_log and writes structured fix-pattern entries to .agentic/learnings.md. Tier 1 leaf agent; soft-fail only.
  • goal-condition-evaluator - cheap Tier-1 stop-condition check for open-goal loops; gates continuation only, never correctness/safety.
  • wrap-ticket - per-ticket learnings capture at Phase 11b (PR open). Reads the ticket's findings, diff, and conversation summary; appends durable learnings to MEMORY.md, decisions.md, and .agentic/context.md (Recent Focus only). Constrained automated subset of /ds-wrap; soft-fail only.
  • learnings-agent - session-scoped background learnings capture. Spawned when the first learning-worthy event occurs in a session. Receives learning events as messages and writes structured entries to .agentic/learnings.md immediately, with optional MEMORY.md append for project-affecting facts. Tier 1 leaf agent; soft-fail only.
Key constraint: Only the main session agent (conductor) spawns agents. No agent spawns other agents.
Isolation: Agents run in background by default. Can use isolation: "worktree" for git-isolated work.
Most agents are read-only. Engineer, release-orchestrator, learnings-agent, and wrap-ticket write files. Gold left border = writes files.

Composed Flows slides: work tracking

How agents work together

Composed flows worker plus Skeptic, routed by risk
Specialized flows for features, security, and bug fixes

Past the risk-classification gate, the conductor routes Elevated work into composed flows. A standard feature runs architect design, mandatory plan review, engineering implementation, and adversarial code review. Security-sensitive work adds a security-auditor deep dive and a multi-dimensional sign-off requiring both Skeptic and Auditor. A bug fix runs root-cause diagnosis, confidence-based escalation, implementation with a mandatory regression test, and a verification gate. Independent specialists can also fan out in parallel under git-worktree isolation.

DinoStack: Composed Flows and Agent Routing. The Conductor (main session agent) decomposes tasks, delegates, and narrates progress, routing through a Risk Classification Gate. Low risk takes Direct Action for immediate execution; Elevated risk enters composed flows and can fan out parallel specialists under git-worktree isolation. Standard Feature Flow: 1) Architect Design, 2) Mandatory Plan Review by Skeptic, 3) Engineering Implementation, 4) Adversarial Code Review by Skeptic. Security-Sensitive Flow adds Enhanced Safety Routing, a Security-Auditor Deep Dive applying OWASP Top 10 analysis, and a Multi-Dimensional Sign-Off requiring both Skeptic and Security Auditor. Bug Fix Flow: 1) Root Cause Diagnosis by Debugger with Confidence-Based Escalation to a human on low confidence, 2) Implementation by Engineer with a mandatory regression test, 3) Verification Gate by Skeptic and QA.
Standard Feature
Conductor architect skeptic plan review (mandatory gate) engineer skeptic code review
Security-Sensitive Feature
Conductor architect skeptic engineer skeptic security-auditor
Bug Fix
Conductor debugger confidence? engineer skeptic
Low confidence → escalate to human
Complex / Ambiguous Goal
Conductor orchestration-planner Conductor follows plan parallel/sequential agent spawns per plan
Low Risk (quick change)
Conductor direct action self-check
Trivial change
[any subagent state] solo engineer Worker (isolation: worktree) done (commit required)
Bypasses Skeptic entirely. Conductor availability drives the Worker/direct split.

Skill Layer

Slash commands for specialized workflows

Skills are invoked via /name in the chat. DinoStack ships 25 commands. In practice, operators type only a few (the daily loop); most are utilities or invoked by the methodology conductor automatically. Commands are defined in content/commands/ and symlinked into ~/.claude/commands/. Agents are defined in content/agents/ and symlinked into ~/.claude/agents/.

Operator commands - the daily loop

  • /ds-init-project - scaffolds the AGENTS.md hierarchy, settings, docs structure, and memory seed for a new project. Run once per repo. Detailed in the Project Lifecycle section below.
  • /ds-implement-ticket - bounded implement/review/QA loop. Runs architect, engineer, and Skeptic phases in sequence for a scoped ticket. The primary command for shipping code.
  • /ds-wrap - enriches session context into context.md, memory entries, and AGENTS.md updates. Run at the end of any session to capture learning. Detailed in the Project Lifecycle section below.

Invoked by the methodology

The conductor runs these during a workflow. Operator-available but rarely typed directly.

  • /ds-skeptic - invoke the full adversarial review template. Provides the brief selection table and orchestration steps. Entry point for manually triggering Elevated review.
  • /ds-ticket-status-sync - reconcile a ticket's tracker column with actual code state after /ds-implement-ticket exits before merge. Single-ticket or --all sweep; --all also sweeps the tracker itself for tickets shipped outside /ds-implement-ticket (deterministic ID-match may transition, unmatched candidates are report-only); soft-fails on tracker API errors.
  • /ds-prune-harness - prune old eval runs from the internal harness to keep the results directory clean.
  • /ds-representation-audit - audit agent representation coverage across the methodology docs and slide decks.
  • /ds-test-suite-comprehension - given a directory or test target, returns a coverage map, verification gaps, and the highest-leverage places to add coverage. Pairs with the qa-engineer and the QA gate.
  • /ds-brief - interactive planning dialogue. Produces a Brief at docs/planning/<slug>.md via a structured multi-turn conversation, then hands off to the architect and engineer with brief_path pre-populated in the execution contract. The conductor auto-invokes it on planning-intent signals ("I want to build...", "thinking about..."); operator-available but normally methodology-triggered.
  • /ds-migrate-project - bring an existing project's scaffolding up to the current methodology version. Additive and non-destructive by default; --include-destructive applies operator-owned markers and file modifications.
  • /ds-update-agentic-engineering - sync methodology file edits safely across all adapters without destructive overwrites.
  • /ds-cleanup-worktrees - remove stale git worktrees created by parallel agent Workers.
  • /ds-memory-update - captures a specific architectural decision or stable fact into memory with its own Worker + Skeptic accuracy loop.
  • /ds-feedback-triage - batch triage of the home-dir feedback store (~/.agentic/feedback.jsonl). Reviews the accumulated backlog of tool-friction, process-escalation, guardrail-fire, and operator-correction signals from /ds-wrap, presents them grouped, and creates tracker tickets only for items the operator explicitly approves.
  • /ds-ticket-triage - strategic triage of a ticket list or tracker input. Analyses dependencies and conflicts, distributes work across parallel lanes, and emits a paste-ready game plan. Plan-only: no code edits, no tracker mutations. Includes a story-size preflight: tickets estimated at ≥5 story points receive a decomposition warning and a context_risk: high flag; tickets ≤4 points proceed silently.

Utilities & setup

  • /ds-status - read-only resolver dump. Prints the resolved global config, project marker, profile, and first-activation sentinel state. Useful for debugging activation and profile issues. Writes nothing; always exits 0.
  • /ds-help - prints every DinoStack slash command with a one-line description, grouped by intent, plus usage patterns for inspecting, invoking, and tuning the skill. Writes nothing; always exits 0.
  • /ds-identity - set up and confirm the per-developer telemetry handle. Auto-derives a provisional handle from GitHub login (agentic-identity auto), then confirm once to flush buffered session logs. Supports global and per-project scope.
  • /ds-disable - explicit opt-out. Appends agentic-engineering: opt-out to the project AGENTS.md (creating it if absent). Optional --global sets mode=opt-out in ~/.claude/agentic-engineering.json.
  • /ds-cost - read-only consumer of .agentic/events.jsonl. Renders per-agent and per-session token and wall-clock tables. Pricing is opt-in via ~/.agentic/pricing.yml; without it prints token counts only.
  • /ds-config - interactive command to view and change agentic-engineering settings in-session. Reads the current resolved state, prompts for which setting to change and the new value, writes the correct file, and confirms what changed and when it takes effect.
  • /ds-configure-team - set up and verify a cross-harness agent team so any conductor (Claude, Codex, Gemini, Kimi, or other) can dispatch work across multiple AI harnesses with explicit role assignments. Independent of the Pi role-model routing layer.
  • /ds-pull-and-install - pull the latest DinoStack release and reinstall selected adapters, or perform a fresh clone-and-install if no existing install is detected. Distinct from /ds-update-agentic-engineering (which pushes upstream edits); this command pulls changes down.
  • /ds-skill-candidates - read-only view of the skill-candidate backlog. Displays open and dismissed candidates detected from recurring workflow friction — each with its domain, count, suggested artifact type, and example note. Writes nothing; always exits 0.

Persistence Layer slides: context management

Per-project state that survives across sessions

The self-improving loop knowledge compounds
The system gets harder to fool over time

Two phases keep knowledge alive. Real-time capture: a learnings-agent records error-fix cycles and resolved findings, and a learning-extractor distills fix patterns into a central learnings file, while the wrap-ticket agent enriches the project's intent layer from session summaries and diffs. Knowledge promotion: durable facts and conventions are persisted into the core memory triad - MEMORY.md (facts), AGENTS.md (conventions), and context.md (state) - so future sessions avoid repeating past mistakes instead of restarting cold.

DinoStack: The Self-Improving Agentic Loop. Phase 1, Real-Time and Post-Task Capture: a learnings-agent captures real-time error-fix cycles and resolved findings; a learning-extractor identifies fix patterns and writes them to a central learnings file; insights are saved immediately to prevent loss of critical architectural or debugging context. Phase 2, Knowledge Promotion and Persistence: a wrap-ticket agent analyzes session summaries and diffs to enrich the project's intent layer, updating the core memory triad MEMORY.md (facts), AGENTS.md (conventions), and context.md (state). Key finding: compounding intelligence - future sessions read these updated files to avoid repeating past mistakes and accelerate development.

Persistence Hierarchy

  • <cwd>/MEMORY.md always loaded - canonical durable facts about the project, committed to the repo and loaded at session start via the @MEMORY.md import in the project root CLAUDE.md. Stable architecture, key paths, and preferences with rationale.
  • .agentic/context.md on demand - primary session-continuity store, read at session start. Written by the Stop hook (basic) or /ds-wrap (enriched). Supports rolling-window merge across 10 sessions. Legacy fallback: ~/.claude/projects/[hash]/context.md, used only when .agentic/context.md is absent.
  • memory/*.md on demand - individual memory files with frontmatter (name, description, type). Read on-demand when relevant to the current task.
  • Tasks - in-session progress tracking. Not persisted across sessions.
  • Plans - in-session alignment with user. Not persisted.

Memory Types

  • user - role, goals, preferences, knowledge level. Helps tailor collaboration (senior engineer vs first-time coder).
  • feedback - corrections and confirmations. "Don't mock the database" or "yes, the bundled PR was right." Includes Why and How to apply.
  • project - ongoing work, goals, deadlines, decisions. "Merge freeze begins 2026-03-05." Includes Why and How to apply.
  • reference - pointers to external systems. "Pipeline bugs tracked in Linear project INGEST." Where to look, not what's there.

What NOT to save in memory

  • Code patterns, architecture, file paths (derive from reading the code)
  • Git history, recent changes (use git log / git blame)
  • Debugging solutions (the fix is in the code; the commit message has context)
  • Anything already in AGENTS.md files
  • Ephemeral task details or current conversation context
The Intent Layer. Orthogonal to the per-session / cross-session / project tiers above is the question of which artifacts capture what the project means to be. AGENTS.md, MEMORY.md, decisions.md, .agentic/qa.md, module manifest headers, and the optional glossary.md together form the project's intent layer - the source of truth for architecture, conventions, domain terms, and review obligations. Drift between code and intent is intent debt: a separate failure mode from technical debt (in the code) and cognitive debt (in the people), and the one most likely to silently degrade an agent-driven workflow. The Skeptic applies tiered enforcement to manifests (missing = Minor, stale = Major, stale-on-correctness/security path = Critical) and flags synonym-of-existing-term drift as Minor, so the layer self-heals as work passes through review without blocking sign-off on cosmetic gaps.
glossary.md - Ubiquitous Language (optional). A flat file at the project root listing the domain terms the project actually uses. Agents prefer existing terms over inventing synonyms; the Skeptic flags synonym-of-existing-term as a Minor finding. Borrowed from DDD's Ubiquitous Language idea - one shared vocabulary across code, docs, and conversation keeps the intent layer coherent across sessions.
Project Directory Is The Project Identity
How cross-session continuity actually works

Claude Code derives a project's persistence directory from the current working directory it was launched in. Every project's AGENTS.md, MEMORY.md, session history, and /ds-wrap outputs live under ~/.claude/projects/[slug-of-cwd]/. The only thing you need to do to return to the same persistent state is start claude from the same directory.

The command:
terminal $ cd ~/projects/myproject
$ claude
Optional: a shell alias to jump into the project and launch:
~/.zshrc # cd into the project and open Claude Code with an optional ergonomic label
alias claude-myproject='cd ~/projects/myproject && claude -n myproject'
  • context.md stacks - the Stop hook writes to the same ~/.claude/projects/[cwd-slug]/context.md every time. /ds-wrap's rolling-window merge works because the project slug is stable as long as you launch from the same directory.
  • MEMORY.md compounds - same cwd means the same project directory means the same memory files. Stable facts accumulate in one place rather than starting fresh each time.
  • The harness improves itself - this is the /ds-init-project -> work -> /ds-wrap feedback loop. Each session reads richer AGENTS.md files and memory than the last because every session starts from the same directory and therefore loads the same files.
  • Multi-project coordination - different projects live under different cwds, so each gets cleanly separated persistence automatically. Running /ds-wrap on one project does not touch the other's state.
Naming and resuming are ergonomic, not load-bearing.

Claude Code's -n, --name flag attaches a display label to the session - useful in the /resume picker and in your terminal title, but it has no effect on which persistence directory is read or written. Two runs of claude -n myproject in the same directory create two independent sessions that share the same project persistence. The label is a finder, not an identifier.

-r, --resume is similarly narrow: it replays a specific prior session's conversation history. That is valuable when you got interrupted mid-task and the agent had working state that wasn't yet captured to memory, but it is not how cross-session continuity works under the protocol. The protocol prefers fresh sessions: one focused goal per session, /ds-wrap at the end to commit learnings to memory, and the next session starts clean and reads those learnings via the normal cwd-based load. The Skeptic agent is the canonical example - it is explicitly never resumed, because a fresh context is sharper than a replayed one.

The thing that silently breaks continuity is not forgetting to name or resume a session - it is launching claude from the wrong directory. That points at a different project slug, which reads and writes a different, empty persistence directory. The fix is muscle memory: always cd into the project before starting Claude Code. An alias that bundles the cd and the launch is the cleanest way to make that automatic.

Project Lifecycle slides: getting started

/ds-init-project scaffolds, /ds-wrap maintains

These two skills form a lifecycle loop: /ds-init-project creates the harness structure at project start, /ds-wrap keeps it current as work happens. Together they ensure every session has accurate context and every project follows the same structure.

/ds-init-project - Project bootstrap

What it creates

  • Root AGENTS.md (under 40 lines - lean by design)
  • [track]/AGENTS.md per subdirectory (backend, frontend, etc.)
  • .claude/settings.json + settings.local.json
  • .agentic/qa.md (always created - TODO placeholders for unknown values)
  • .agentic/tracking.md (always created - read by orchestration-planner at planning time)
  • glossary.md (optional - Ubiquitous Language; the project's domain terms; agents prefer these over synonyms)
  • MEMORY.md seed in /.agentic/memory/
  • .gitignore with secrets protection
  • docs/ structure (overview, technical, planning, research)

How it works

  • Interactive: asks project name, tracks, tools, DB, web UI
  • Discovery scan: checks what exists before creating
  • If AGENTS.md exists: curates in place (Worker + Skeptic)
  • Extracts verbose rationale into MEMORY.md entries
  • Never overwrites settings.local.json (may contain secrets)
/ds-wrap - Session context enrichment

What it produces (4 outputs)

  • context.md - session state: task focus, next steps, file paths, uncommitted changes, stashes, gotchas
  • memory.md entries - stable facts: architecture decisions, conventions, persistent gotchas
  • AGENTS.md updates - proposed additions to root and track AGENTS.md files (decisions, conventions, stack)

How it works

  • Compiles session data (files touched, errors, decisions)
  • Worker drafts all 3 outputs from raw session data
  • Skeptic reviews for accuracy and completeness
  • Main agent merges drafts into existing files inline (rolling window for context.md, semantic dedup for memory.md) - subagents cannot reliably get write permissions
  • Compresses always-loaded memory files when they grow past a size threshold (Worker + Skeptic loop guards against fact loss, with rolling backups as a safety net)
  • Cleans up stale worktrees as final step - backed by the /ds-cleanup-worktrees skill

Concurrent-run protection (wrap/lock)

/ds-wrap acquires a project-local lock directory at <cwd>/.agentic/wrap/lock before writing any shared files, and holds it for the whole /ds-wrap flow. This prevents two simultaneous /ds-wrap runs from clobbering each other.

  • Lock acquisition - atomic mkdir (POSIX-safe); a legacy owner file and a schema-validated JSON descriptor (owner.json) are published atomically alongside it.
  • Liveness, not age, decides staleness - a waiter polls on a jittered ~5 second interval and checks whether the lock's owner is a genuinely live process wherever the owner record carries a checkable PID. A live holder is never stolen and never causes the waiter to abort, no matter how long it has held the lock.
  • Unreadable or malformed owner file - treated as a progress condition, not a give-up: /ds-wrap keeps waiting rather than aborting.
  • The 30-minute mark is advisory only - once a hold looks that old, the waiter's progress line adds a manual rm -rf recovery hint, but the mark never gates or aborts acquisition; a lock older than 30 minutes and still genuinely live is never stolen.
  • Lock release - owner-scoped: refuses to remove anything at the lock path that isn't a lock directory it created, and refuses a tokenless removal when the descriptor names a live foreign-process PID. Mandatory on every exit path (success, escalation, or abort) once acquired; if /ds-wrap aborts before acquiring the lock, no release is needed.
/ds-brief - Interactive planning dialogue

What it does

  • Auto-triggered by the conductor when it detects exploratory framing ("I want to build...", "thinking about...", "let's design...") using the surface-and-proceed pattern
  • Multi-turn dialogue: intent capture, scope-specific gray-area menu, per-area Q&A, Brief draft, iteration, write and hand-off to architect
  • Produces docs/planning/<slug>.md committed directly on the conductor's current branch before architect is spawned
  • Sets brief_source: operator in .agentic/brief-session.json so downstream Skeptic uses a completeness-only review (framing is already operator-confirmed)
  • PRD express-path: /ds-brief --from <path> extracts Brief fields from an existing document; Verification field always requires operator input before writing
  • Scope-creep guardrail defers new dimensions to a deferred list; whole-pivot detection offers a restart or "continue with both" option
Using the scaffolded docs/ tree

How to use docs/overview, docs/research, docs/planning, and docs/technical

/ds-init-project creates these folders as distinct documentation surfaces, not as four generic buckets. A good default workflow is: explore in research/, decide in planning/, codify the accepted implementation truth in technical/, and publish the stable high-level summary in overview/. For feature work, reuse the same progression with a feature-specific file or subdirectory instead of inventing a new structure.

docs/overview/ = what this is

  • High-level project or feature summaries for humans and agents who need orientation fast
  • Good home for onboarding docs, system maps, domain glossaries, and "start here" explanations
  • Should stay short, stable, and low-detail; link outward to deeper docs instead of duplicating them

docs/research/ = what we learned before deciding

  • Exploratory notes, option comparisons, constraints gathering, source material, and open questions
  • Use when investigating a new subsystem, evaluating libraries, or collecting evidence before design
  • Can be messy and provisional; once a direction is chosen, the conclusion should graduate into planning/ or technical/

docs/planning/ = what we intend to build

  • Pre-implementation design artifacts: feature specs, project plans, ADR drafts, ticket decomposition, migration plans
  • This is the working surface for Architect and orchestration-planner output before code lands
  • Keep open questions, trade-offs, and acceptance criteria here; once settled and implemented, move enduring truth into technical/ and summarize outcomes in overview/

docs/technical/ = how it actually works

  • Canonical implementation docs, contracts, runbooks, deployment details, invariants, and architecture that must match reality
  • Write here after a design is accepted or a system is already in production and needs a durable reference
  • Should read as current truth, not proposal text; remove unresolved debate language once a decision is made
Practical pattern for project and feature work: start a new initiative in docs/research/feature-name.md if the problem is still fuzzy; promote the chosen shape to docs/planning/feature-name.md when you need a spec the team can execute; once implementation stabilizes, capture the lasting design in docs/technical/feature-name.md; if new teammates will need a short orientation, add docs/overview/feature-name.md as the front door.
Protocol fit: Architect plans, orchestration plans, and proposal docs belong in planning/ while they are still decision-driving artifacts. /ds-wrap should then promote the durable parts of those decisions into AGENTS.md and MEMORY.md so future sessions inherit the outcome without rereading every planning file.
Lifecycle flow
/ds-init-project AGENTS.md hierarchy + settings + docs/ Work sessions (features, bugs, etc.) /ds-wrap
Creates structure once Agents use the harness Enriches context + updates AGENTS.md
/ds-wrap context.md (session state) + memory.md (stable facts) + AGENTS.md updates
Next session reads all three → full context from turn one → work → /ds-wrap → repeat
The feedback loop:
  • /ds-init-project creates empty structure. Work fills it with decisions and conventions.
  • /ds-wrap captures what was learned and feeds it back into the AGENTS.md hierarchy and memory. Next session starts with richer context. The harness improves itself over time - each session makes the next one better.
Separation of concerns:
  • context.md holds temporary session state (what's in progress, what's next).
  • memory.md holds stable facts (architecture decisions, gotchas that persist).
  • AGENTS.md files hold the canonical project description (structure, tools, conventions).
  • The Stop hook auto-writes a basic context.md every turn; /ds-wrap produces the enriched version when detail matters.
  • Close the session cleanly so the Stop hook can finish writing context.md: in the terminal CLI, use /exit rather than ctrl+c (ctrl+c can interrupt the hook and lose session state); in the desktop or web app, /exit is not available - just close the window or tab normally rather than force-quitting.

Git Workflow

Worktree isolation model

Parallel fan-out isolated worktrees, ordered merge
Independent units run in parallel, each in its own worktree, merged in planner order

When the orchestration-planner splits a goal into independent atomic units, the conductor fans them out as parallel engineers, each working a single task in its own .agentic/worktrees/ branch so concurrent work never collides. Every unit runs its own adversarial review loop with a fresh Skeptic and passes automated quality gates. The conductor monitors for a DONE state with Skeptic sign-off, then merges validated changes sequentially - no fast-forward, in the planner-specified order - to preserve structural integrity, while a learning-extractor captures findings for future sessions.

DinoStack: Orchestrating Parallel Engineering with Fan-Out Autonomy. The Conductor receives human intent on the main feature branch and is freed from implementation. Fan-Out Autonomy splits the goal into independent atomic units; the orchestration-planner determines dependencies and merge order, and a spawn threshold plus risk routing decide when to fan out for complex changes. Multiple Engineer subagents run in parallel, each on a single atomic task inside its own .agentic/worktrees/ branch (git worktree isolation, parallelism by default). Each engineer runs an adversarial review loop with a fresh Skeptic every round and must pass automated quality gates (mandatory testing, type-checking, regression tests). At convergence the conductor monitors for a DONE state with Skeptic sign-off and performs a sequential no-fast-forward terminal merge, merging validated changes in the planner-specified order to maintain structural integrity. A continuous learning-extractor captures findings into .agentic/learnings.md to improve future sessions.
Standard Feature Branch Flow
conductor's feature branch subagent worktree (branches from conductor) merge back to conductor's branch PR to main merge + cleanup

Core Rules

  • Conductor delegates every shippable edit to a worktree-isolated engineer. The conductor never edits shippable artifacts in its own checkout; worktrees are the execution location for all shippable changes. The conductor edits only exempt artifacts directly.
  • Protected branches: never commit directly to main, master, develop, or development. Exception: ~/DinoStack may commit and push directly to main.
  • Base branch resolution: prefer an explicit BASE_BRANCH: declaration in AGENTS.md, else develop, else development; if neither exists you are prompted to use main (falling back to master) or set up a develop-based workflow.
  • Branch naming: feature/<name>, fix/<name>, chore/<name>.
  • Commit each fix immediately. Never accumulate uncommitted changes. After each validated fix: create branch, commit, PR, merge, pull - then start the next fix.

Worktree Types

  • Subagent worktrees (feature/*, fix/*) - one per parallel subagent, branched from the conductor's current branch, created at .agentic/worktrees/<branch-name>. The conductor merges and removes them after sign-off.
  • Isolation worktrees (worktree-agent-*) - created by the Agent tool when isolation: "worktree" is set. Removed after the conductor confirms no PR is needed.
  • Conductor delegates shippable edits; it does not edit the shippable tree itself. Every shippable change runs in a subagent worktree branched from origin/main. The conductor edits only exempt artifacts directly.

Hands-off Configuration

Permissions that let Claude work without prompts - but not destroy data

The protocol assumes Claude can run most commands without interruption. That only works if the session is not constantly asking for permission. The pattern: set defaultMode to bypassPermissions, then use a tight denylist to block the handful of commands that are genuinely destructive. Everything else runs freely; the worst mistakes are still impossible. Codex users should also review codex-permissions.md for the equivalent trusted-work posture.

The philosophy

  • Bypass by default. Every confirmation prompt is a context switch. In hands-off mode Claude just runs the command.
  • Deny the small set that cannot be undone. Force pushes, rm -rf, hard resets, disk formatters, reboots. None of these have legitimate "I meant to" recoveries inside a session.
  • The denylist is not a security boundary. It is a safety rail for a trusted agent on your machine. A determined prompt-injection attack can still run bad commands through creative obfuscation. Pair this with the Skeptic loop and the risk classification rules - the denylist is the last line, not the first.

~/.claude/settings.json snippet

{
  "permissions": {
    "allow": [
      "Bash(*)", "Write", "Edit",
      "Write(**/AGENTS.md)",   "Edit(**/AGENTS.md)",
      "Write(**/CLAUDE*.md)",  "Edit(**/CLAUDE*.md)",
      "Write(**/context.md)",  "Edit(**/context.md)",
      "Write(**/memory*.md)",  "Edit(**/memory*.md)",
      "Write(**/.claude/*.md)","Edit(**/.claude/*.md)",
      "Write(**/.claude/*.json)","Edit(**/.claude/*.json)",
      "Write(.claude/qa.md)",    "Edit(.claude/qa.md)",
      "Write(.claude/findings.md)","Edit(.claude/findings.md)",
      "Write(.agentic/qa.md)",   "Edit(.agentic/qa.md)",
      "Write(.agentic/findings.md)","Edit(.agentic/findings.md)"
    ],
    "deny": [
      "Bash(git push --force*)",
      "Bash(rm -rf*)",
      "Bash(git reset --hard*)",
      "Bash(git clean -f*)",
      "Bash(sudo rm*)",
      "Bash(dd if=*)",
      "Bash(shutdown*)",
      "Bash(reboot*)"
    ],
    "defaultMode": "bypassPermissions"
  }
}

Drop into your global settings. The broad Write / Edit rules handle most tool calls; the file-specific globs silence overwrite confirmations for the files /ds-init-project and /ds-wrap touch most often (AGENTS.md, CLAUDE.md, context.md, memory.md, findings.md, deploy.md, compression-state.json, plus their rolling snapshots). The exact-path rules at the bottom (.claude/qa.md, .claude/findings.md, .agentic/qa.md, .agentic/findings.md) exist because the **/ prefix in the broader glob requires at least one parent directory segment, so files directly under a project-root .claude/ or .agentic/ dir don't match - without these, /ds-init-project prompts on every fresh scaffold. Adjust the denylist to match the commands your workflow actually uses - if you force-push feature branches regularly, narrow that entry to main specifically.

When a denied command is actually what you want: disable the rule temporarily by editing settings, run the command, re-enable. Do NOT add a bypass hack that survives the session. The friction is the point - if you want to git reset --hard, a five-second edit is a fair cost for the protection the rest of the time.
Codex trusted-work config: for trusted DinoStack work, use top-level sandbox_mode = "danger-full-access" and approval_policy = "never" in user-level ~/.codex/config.toml or a trusted project's .codex/config.toml, then verify with codex --strict-config doctor. Use stricter sandboxing and approvals for untrusted repositories or prompts. Full guidance: codex-permissions.md.

Risk Profiles slides: risk profiles

Tune Skeptic overhead to match your workflow

Profiles let you dial how aggressively the system triggers Skeptic review. Set once globally and override per project. Three levels: relaxed for rapid iteration with less overhead, default for balanced day-to-day work, and strict for when correctness is paramount.

relaxed

For rapid iteration on well-understood UI or local bug fixes.

  • Single-file locally-scoped behavioral edits: Low (no Skeptic)
  • Multi-file pure-UI-only changes: Low (no Skeptic)
  • Everything else unchanged from default

default

The starting point for all projects. Right for most day-to-day work.

  • Single-file locally-scoped behavioral edits: Low (no Skeptic)
  • All other legacy Elevated signals remain Elevated
  • Multi-file UI-only changes: Elevated (Skeptic runs)

strict

For when correctness is paramount - payments, auth, shared infrastructure.

  • UI-only copy changes: Elevated (Skeptic runs)
  • File renaming: Elevated (Skeptic runs)
  • Targeted wording fixes to already-reviewed content: Elevated (Skeptic runs)
  • Diagnostic-only logging changes: Low with self-check (not unconditionally direct)
  • Documentation-only file creation (new .md files that are pure lists/notes): Low with self-check (not unconditionally direct)
Token spend: The Elevated classification is the dominant cost driver. Each Elevated task fans out to a Worker + Skeptic - and often an architect, orchestration-planner, and QA engineer - each re-reading full context. Moving from strict or default toward relaxed reclassifies more small work as Low (conductor direct action, no spawns), removing that pipeline overhead entirely. Accept the tradeoff: relaxed trades independent review for speed; keep default or strict wherever a mistake is hard to reverse.
how to set your profile # At install time
bash .claude/install.sh --profile=relaxed

# Edit ~/.claude/agentic-engineering.json directly
{ "mode": "opt-out", "profile": "strict" }

# Per-project override in root AGENTS.md
agentic-engineering-profile: strict

For a complete list of every setting and its default, see configuration-reference.md.

Risk Classification slides: quality assurance

The central decision that drives everything

Low Risk → Direct Action

  • Read a file / git status (confirming known fact)
  • Answer from memory
  • Take a screenshot
  • Synthesize subagent results
  • Diagnostic-only logging (zero behavioral effect)
  • Documentation-only .md creation (pure list/glossary)
  • Targeted wording fix to already-reviewed content

Elevated Risk → Worker + Skeptic

  • Any code edit with behavioral effect
  • Security / auth / crypto / payments
  • Irreversible operations
  • Architecture decisions
  • Multi-file changes / new file creation
  • External APIs / unfamiliar code
  • Research producing an artifact
  • Configuration changes
  • Anything where a mistake costs time or data
When in doubt, classify as Elevated. "Looks simple" is not a Low signal. Mid-task reclassification is mandatory if Elevated signals appear during execution.

Common Rationalizations to Reject

  • "This looks simple, I can do it directly." - Simple-looking tasks are where unreviewed errors accumulate most often.
  • "It's only one file / a few lines." - Line count is not a risk signal. A one-line change to a shared utility has high blast radius.
  • "I already reviewed it myself." - Self-review is for Low risk. It does not substitute for Skeptic review on Elevated tasks.
  • "The Skeptic will catch any mistakes." - The Skeptic reviews Worker output. It does not excuse skipping risk classification or spawning a Worker.
  • "We're moving fast, we can skip review this time." - The protocol exists precisely for times when speed creates pressure to skip it.
  • "I'm following the spirit of the rule, just not the letter." - Violating the letter is violating the spirit. No exceptions.

Declaration Format with Planning Artifacts

The risk declaration optionally includes Brief: and Plan: lines when the promotion gate fires after orchestration-planner returns.

risk declaration example Risk: Elevated - multi-unit feature
Tier: 2
Brief: docs/planning/<slug>.md (when 2-5 Elevated units)
Plan: docs/planning/<slug>/ (when 6+ units, cross-track, or multi-session)

The Decision Flow

  • 1 Before any task: classify risk (Low or Elevated)
  • 2 If any single Elevated signal is present: declare risk, spawn Worker + Skeptic
  • 3 If all signals are Low: act directly, then perform inline self-check (re-read in full, verify intent and side effects)
  • 4 If self-check raises concerns: reclassify as Elevated mid-task
  • 5 The UserPromptSubmit hook enforces this - it fires before every action with a reminder to classify first

Other Adapters

Translating the methodology to Codex, Cursor, Gemini, Kimi, and OpenCode

The methodology is portable. The doc above uses Claude Code paths and slash commands. Other harnesses share the same delegation model, classification rules, and review protocol - but read from different paths and have different command and hook mechanics. Use this appendix to translate.

Codex CLI

Native AGENTS.md support - TOML agent format - hook system requires opt-in flag

Recommended trusted-work permissions are documented in codex-permissions.md.

SurfaceCodex equivalent
Project instructionsAGENTS.md at project root - read natively, no shim needed
Global instructions~/.codex/AGENTS.md
Skill location~/.agents/skills/agentic-engineering/SKILL.md
Slash commandsNot first-class. Command files live in .codex/commands/*.md but must be pasted or referenced manually - no auto-invocation via /ds-wrap etc.
Agents~/.codex/agents/*.toml - TOML format (different from Claude Code's prompt-based spawn)
Hooks~/.codex/hooks.json - requires codex_hooks = true in user config to enable the installer-managed hooks
Stop hook / context savestop-context-codex.js writes to ~/.codex/projects/[hash]/context.md
Activation configShared: ~/.claude/agentic-engineering.json
Tier resolution~/.agentic/tier-map.yml - no built-in Haiku/Sonnet/Opus enum; models resolved from the map
What's different: Slash commands (/ds-wrap, /ds-init-project, etc.) do not auto-trigger. Reference the command files manually or paste their contents. The hook system is off by default - set codex_hooks = true in user config before expecting installer-managed Stop-hook context saves.

Cursor

Rule-file based setup - slash commands work - no native agent system

SurfaceCursor equivalent
Project instructionsAGENTS.md (manual) or .cursor/rules/*.mdc files
Global instructions~/.cursor/rules/*.mdc with alwaysApply: true in frontmatter - no single global file
Skill locationNo skill system. Rules are .mdc files in ~/.cursor/rules/
Slash commands~/.cursor/commands/*.md - slash commands work natively in Cursor
AgentsNot available - Cursor has no native sub-agent system
Hooks.cursor/hooks.json - beforeSubmitPrompt event for the risk-reminder equivalent
Stop hook / context saveStop hook writes to the Claude Code path (~/.claude/projects/...) - not surfaced in Cursor sessions. Rely on manual context.md maintenance.
Activation configShared: ~/.claude/agentic-engineering.json
Tier resolutionInherits the session model - no tier-map lookup
What's different: No sub-agent spawn primitive. The conductor pattern works as a prompt strategy, but Cursor cannot fan out parallel Workers natively. Session context saves require manual maintenance - the Stop hook does not fire in a Cursor session.

Gemini CLI

GEMINI.md project file - TOML slash commands - agent files via @name mention

SurfaceGemini equivalent
Project instructionsGEMINI.md at project root
Global instructions~/.gemini/GEMINI.md
Skill locationNo skill system. Rules are inlined into ~/.gemini/GEMINI.md
Slash commands~/.gemini/commands/*.toml - first-class TOML slash commands; reload with /commands reload
Agents~/.gemini/agents/*.md with YAML frontmatter (kind: local) - invoked via @agent-name
Hooks~/.gemini/settings.json hooks key - BeforeAgent and SessionEnd events
Stop hook / context savestop-context-gemini.js writes to ~/.gemini/projects/[hash]/context.md - fires on /exit only
Activation configShared: ~/.claude/agentic-engineering.json
Tier resolution~/.agentic/tier-map.yml - same as Codex, no built-in tier enum
What's different: Context save only fires on /exit - force-closing the terminal loses the session context write. Commands use TOML format instead of Markdown. Agent mentions via @agent-name are the invocation primitive (no Agent tool call).

Kimi Code CLI

Project instructions in .kimi/ directory - skill invocation via natural language - hooks fully manual

SurfaceKimi equivalent
Project instructions.kimi/AGENTS.md inside the project's .kimi/ directory (loaded by Kimi via $KIMI_AGENTS_MD)
Global instructionsNo global AGENTS.md equivalent. Global footprint is the skill at ~/.kimi/skills/agentic-engineering/SKILL.md (installed via install.sh)
Skill location~/.kimi/skills/agentic-engineering/SKILL.md - invoke via /skill:agentic-engineering or natural language
Slash commandsNo custom slash commands. Use /skill:agentic-engineering <name> or natural language ("run wrap")
AgentsBuilt-in types only: coder, explore, plan. Agent files serve as reference prompts mapped to those types.
Hooks~/.kimi/config.toml [[hooks]] blocks - fully manual; the installer does not write this
Stop hook / context saveManual - script path must be set by the user in the hooks config
Activation configShared: ~/.claude/agentic-engineering.json
Tier resolutionInherits the built-in sub-agent type; optional ~/.agentic/role-models.yml can map roles and antagonist reviewers to concrete model strings
What's different: No custom slash commands. No installer-written hooks - you must add [[hooks]] blocks manually to ~/.kimi/config.toml and configure the Stop hook script path yourself. Session context saves will not work until this is set up.

OpenCode

Native AGENTS.md support - per-adapter activation config - no hook system at all

SurfaceOpenCode equivalent
Project instructionsAGENTS.md at project root - read natively
Global instructions~/.config/opencode/AGENTS.md and/or instructions field in opencode.json
Skill location.opencode/skills/agentic-engineering/SKILL.md (project-local) or ~/.config/opencode/skills/ (global)
Slash commands~/.config/opencode/commands/*.md - slash commands work natively
Agents~/.config/opencode/agents/*.md with mode: subagent and permission: frontmatter
HooksNot available - OpenCode has no hook system
Stop hook / context saveNot available - no session context save. Context must be managed manually.
Activation configPer-adapter path: ~/.config/opencode/agentic-engineering.json (the only adapter with a dedicated config path)
Permissionspermission: per-agent in agent frontmatter; instructions: in opencode.json for global rules
What's different: No hook system. The risk-reminder that fires on UserPromptSubmit in Claude Code is instead embedded in the skill content - there is no event-driven trigger. Session context is never auto-saved; manual context.md maintenance is required. Activation config lives at a per-adapter path rather than the shared ~/.claude/ location.

Ecosystem Comparison

How DinoStack compares to the alternatives

DinoStack is one of several agentic engineering methodologies, and it is not always the right tool. The Ecosystem Comparison positions it honestly against the field - ICM, GSD, Arize Alex, Agentic OS, the in-context-versus-orchestration research, and more - calling out where independent review, risk gates, and parallel orchestration earn their keep, and where a lighter single-agent approach is the better fit.

Open the Ecosystem Comparison →