AgenticWorkflow — Common Directive for AI Agents

This file defines the rules that all AI agents working on this project must follow, regardless of model or tool. Whether you use Claude Code, Cursor, Copilot, Codex, or any other tool, the rules in this document apply.

1. Project Definition

An agent-based workflow automation project. Its purpose is to systematically design complex tasks as workflows and actually implement those workflows so that they run.

Final Goal — A 2-Stage Process

Creating workflow.md is only half the journey. The final goal is that the content described in it actually runs.

Reason for Existence — DNA Inheritance

AgenticWorkflow is a parent organism that gives birth to child agentic workflow systems. Whatever domain the child belongs to, it structurally embeds the entire parent genome.

Inheritance is not optional — it is structural. The child does not "reference" the parent's DNA, it embeds it. Details: soul.md §0.

12→9 Mapping: Of the 12 components in soul.md §0, the 9 above are structurally embedded in the child as inherited_dna. The remaining 3 — Design Principles P1-P4 (included in the Absolute Criteria), Sisyphus/Error→Resolution (behavioral pattern, not a structure), and RLM theory (theoretical foundation, not a structure) — are implicitly reflected in the child as internal mechanisms of the parent organism, but are not separated as distinct inherited_dna items. soul.md itself is a meta-document (the definition of inheritance), so it is not an inheritance target.

Basic Workflow Structure

Every workflow consists of three stages:

1. Research — Information gathering and analysis
2. Planning — Plan formulation, structuring, human review/approval
3. Implementation — Actual execution and deliverable generation

Each stage specifies:

• The task performed (Task)
• The responsible agent
• Data pre-processing / post-processing
• Deliverable (Output)
• Human intervention point (if applicable)

2. Absolute Criteria

These are the top-level rules applied to every design, implementation, and modification decision in this project. They sit above all principles, guidelines, and conventions below. Whatever principle it is, if it conflicts with an Absolute Criterion, the Absolute Criterion wins.

Absolute Criterion 1: Quality of the Final Deliverable

Speed, token cost, workload, and length limits are completely ignored. The only criterion for every decision is the quality of the final deliverable. Rather than making things fast by reducing steps, we choose the direction that raises quality even if that means adding steps.

Applied examples:

• If quality rises with more workflow stages → add stages
• If using more agents raises quality → add agents
• If repeated verification stages improve the deliverable → allow repetition

Absolute Criterion 2: Single-File SOT + Hierarchical Memory Structure

Under the design of a single-file SOT (Single Source of Truth) + hierarchical memory structure, no data inconsistency occurs even when dozens of agents operate simultaneously.

Design rules:

• State concentration: All shared state of a workflow is concentrated in a single file (e.g., state.json, state.yaml). Do not scatter state across multiple files.
• Single write point: Only the Orchestrator (or one designated agent) has write permission to the SOT file. Other agents access it read-only and produce their results as separate output files.
• Conflict prevention: Do not design structures in which multiple agents modify the same file simultaneously.

Bad:  Agent A → directly modifies state.json
      Agent B → directly modifies state.json  → data conflict

Good: Agent A → produces output-a.md → reports to Orchestrator
      Agent B → produces output-b.md → reports to Orchestrator
      Orchestrator → merges into state.json  → single write point

Absolute Criterion 3: Code Change Protocol (CCP)

Before writing, modifying, adding, or deleting code, you must internally perform the 3 steps below. Skipping this protocol is a violation of the Absolute Criteria.

If Absolute Criterion 1 (Quality) defines "what we optimize for," and Absolute Criterion 2 (SOT) defines "how we structure data," then Absolute Criterion 3 defines "how we behave when changing code." High-quality code emerges from a rigorous process that analyzes dependencies, coupling, and ripple effects of changes in advance.

Coding Anchor Points (CAP-1~4)

If CCP defines "what to perform" (procedure), then CAP defines "what attitude to perform with" (mindset). Every step of CCP is performed while internalizing the 4 anchor points below.

• CAP-1: Think Before Coding — Do not assume. Do not modify code before reading it; surface trade-offs when they exist; ask when unclear.
• CAP-2: Simplicity First — Write only the minimum code needed to satisfy the current requirement. Do not create speculative features, premature abstractions, or unnecessary helpers.
• CAP-3: Goal-Based Execution — Define success criteria before implementation, and verify after (e.g., tests, manual checks).
• CAP-4: Surgical Changes — Perform only the requested change. Do not "improve" unrelated code, and do not add comments, types, or documentation to code you did not touch.

CAP is a subordinate set of attitude norms under CCP, so when it conflicts with Absolute Criterion 1 (Quality), quality wins. Example: when CAP-2 (Simplicity) undermines quality — complexity required for quality is allowed.

Step 1 — Understand Intent:

• Have you accurately understood the implementation the user requested? You should be able to explain it clearly in 1-2 sentences.
• Have you accurately understood the purpose of the change (bug fix, refactoring, performance, feature addition, etc.) and the constraints (compatibility preservation, tech stack, etc.)?

Step 2 — Ripple Effect Analysis:

Investigate the impact that writing new code or modifying existing code has on the entire codebase:

• Direct dependencies: Functions / classes / modules / files where the target is defined
• Call relationships: Other code that calls this code, or that this code calls
• Structural relationships: Inheritance / implementation (inheritance, interface), composition, association / reference
• Data model / schema: Types / fields / validation logic that must change together
• Test code: Unit tests, integration tests, snapshot tests, etc.
• Configuration / environment / build: config, DI settings, routing, dependency injection, etc.
• Documentation / comments / API specs: comments, README, API documents, type definitions, etc.

Investigate at an expert level: "Since we're changing here, how far can this change ripple?" If there are highly coupled areas (tight coupling, change coupling, possibility of shotgun surgery), you must flag them in advance and discuss with the user.

Step 3 — Change Plan:

• Before updating the actual related code, propose a step-by-step change plan:
  • Step 1: Which file / class / function to modify first
  • Step 2: What changes to propagate to downstream dependencies / callers
  • Step 3: How to align tests / docs / configuration
• If you see a refactoring opportunity toward a better structure from the perspective of reducing coupling / increasing cohesion, propose it along with the plan (execute only after user approval).

Proportionality Rule — Always perform the protocol, but scale analysis depth to the scope of the change:

Applied examples:

Bad:  "User requests function modification → only modifies that function → 6 callers hit runtime errors"
Good: "User requests function modification → checks 6 call sites → reports impact scope → proposes step-by-step change plan → executes after approval"

Communication Rules:

• Avoid unnecessarily verbose theoretical explanations; focus on actual code and concrete steps.
• Add brief reasons for important design choices.
• Even when parts are ambiguous, do not avoid the work — state "reasonable assumptions" explicitly and propose the best design.

Priority Among Absolute Criteria

Absolute Criterion 1 (Quality) is the highest. Absolute Criterion 2 (SOT) and Absolute Criterion 3 (CCP) are co-equal means to guarantee quality.

Absolute Criterion 1 (Quality) — Highest. The reason every criterion exists.
  ├── Absolute Criterion 2 (SOT) — Means of guaranteeing data integrity
  └── Absolute Criterion 3 (CCP) — Means of guaranteeing code-change quality

Absolute Criteria 2 (SOT) and 3 (CCP) operate on different dimensions, so direct conflict between them is unlikely. Whichever criterion it is, when it conflicts with Absolute Criterion 1 (Quality), quality wins. Both SOT and CCP are means of guaranteeing quality, not ends that constrain quality.

Conflict scenarios and resolutions:

• The SOT single write point causes an information bottleneck and agents work with stale data → allow direct reference between agents' outputs (adjust the SOT structure)
• State complexity of the SOT grows due to added stages for quality improvement → accept it (Absolute Criterion 1 > 2)
• SOT is unnecessary for fully independent parallel work (no shared state between agents) → allow lightweight SOT (document the rationale)
• Full CCP analysis is excessive overhead for trivial changes → apply the Proportionality Rule (Step 1 only for minor changes)

3. Design Principles

These are subordinate principles under the Absolute Criteria.

P1. Data Refinement for Accuracy

Passing large data directly to AI drops accuracy through noise.

• Specify pre-processing at each stage: remove noise before handing off to the agent
• Specify post-processing at each stage: refine the deliverable before passing to the next stage
• Relationships computable in code are pre-processed → the AI focuses on judgment and analysis

Bad:  "Pass the entire collected HTML of the web page to the agent"
Good: "Extract only the body text via a Python script → pass only the essential text to the agent"

P2. Expertise-Based Delegation Structure

Maximize quality by delegating each task to the specialized agent that can best perform it. The Orchestrator coordinates overall quality, while specialized agents focus deeply on their respective domains.

Orchestrator (quality coordination + flow management)
  ├→ Agent A: Specialized research (optimized for the domain)
  ├→ Agent B: In-depth analysis (focused only on analysis)
  └→ Agent C: Verification and quality gate

Orchestrator Role Definition

Orchestrator = main Claude session. It is not a separate agent file; the main session executing the workflow plays the Orchestrator role. In (team) stages, the Orchestrator also serves as the Team Lead.

Sub-agent Invocation Protocol

Standard protocol for the Orchestrator to invoke a Sub-agent (@translator, @reviewer, @fact-checker):

1. How to invoke: specify the agent name via the subagent_type parameter of the Task tool

Task(subagent_type="translator", prompt="...", ...)

2. Context that must be included in the prompt:

• Workflow step number (step N)
• Input deliverable file paths (absolute paths)
• Verification criteria for that step (if any)
• SOT outputs.step-N path (where to save the deliverable)
• Reference file paths (glossary.yaml, previous step deliverables, etc.)

3. Receiving results: when the Sub-agent exits, the Task tool returns the result.

• The Orchestrator checks that the deliverable file was created on disk
• Runs the P1 validation scripts (validate_review.py, validate_translation.py, etc.)
• Records the path in SOT outputs.step-N (performed by the Orchestrator)

4. (team) stage Task Lifecycle:

Team Lead (= Orchestrator)
  1. TeamCreate → records SOT active_team
  2. TaskCreate (subject, description, owner=@teammate)
  3. Task(subagent_type, team_name, ...) → creates Teammate
  4. Teammate: performs work → L1 self-verification → L1.5 pACS self-scoring
  5. Teammate: SendMessage (report + pACS score) → TaskUpdate (completed)
  6. Team Lead: receives report → L2 comprehensive verification → updates SOT
  7. TeamDelete → SOT active_team → moves to completed_teams

Dense Checkpoint Pattern (DCP): Insert intermediate checkpoints (CP-1/2/3) into Tasks with turn count > 10. Details: references/claude-code-patterns.md §DCP

P3. Resource Accuracy

For stages that require images, files, or external resources, specify exact paths. Placeholders may not be omitted.

P4. Question Design Rules

When asking the user questions:

• At most 4 questions
• Each question offers roughly 3 options
• If there is no ambiguity, proceed without questions

4. Project Structure

AgenticWorkflow/
├── CLAUDE.md          ← Claude Code-specific directive
├── AGENTS.md          ← This file (model-agnostic common directive)
├── README.md          ← Project introduction
├── AGENTICWORKFLOW-USER-MANUAL.md              ← User manual
├── AGENTICWORKFLOW-ARCHITECTURE-AND-PHILOSOPHY.md  ← Design philosophy and architecture overview
├── DECISION-LOG.md          ← Project design decision log (ADR)
├── COPYRIGHT.md          ← Copyright
├── .claude/
│   ├── settings.json          ← Hook settings (Setup + SessionEnd)
│   ├── agents/                ← Sub-agent definitions
│   │   ├── translator.md     (English→Korean translation specialist — glossary-based terminology consistency)
│   │   ├── reviewer.md       (Adversarial Review — critical analysis of code/deliverables, read-only)
│   │   └── fact-checker.md   (Adversarial Review — external fact verification, web access)
│   ├── commands/              ← Slash Commands
│   │   ├── install.md         (Setup Init validation result analysis — /install)
│   │   └── maintenance.md     (Setup Maintenance health check — /maintenance)
│   ├── hooks/scripts/         ← Context Preservation System + Setup Hooks + Safety Hooks
│   │   ├── context_guard.py   (Hook unified dispatcher — single entry point for 4 events)
│   │   ├── _context_lib.py    (shared library — parsing, generation, SOT capture, Smart Throttling, Autopilot state reading/validation, ULW detection/compliance verification, centralization of truncation constants, sot_paths() path unification, multi-stage transition detection, decision-quality tag ordering, Error Taxonomy 12 patterns + Resolution matching, Success Patterns (extracting successful Edit/Write→Bash sequences), IMMORTAL-aware compression + audit trail, E5 Guard centralization (is_rich_snapshot + update_latest_with_guard), Knowledge Archive integration (archive_and_index_session — partial failure isolation), path tag extraction (extract_path_tags), KI schema validation (_validate_session_facts — ensuring RLM-required keys), SOT schema validation (validate_sot_schema — structural integrity of workflow state.yaml verified across 8 items: S1-S6 basic + S7 pacs 5 fields (dimensions, current_step_score, weak_dimension, history, pre_mortem_flag) + S8 active_team 5 fields (name, status (partial|all_completed), tasks_completed, tasks_pending, completed_summaries)), Adversarial Review P1 validation (validate_review_output R1-R5, parse_review_verdict, calculate_pacs_delta, validate_review_sequence), Translation P1 validation (validate_translation_output T1-T7, check_glossary_freshness T8, verify_pacs_arithmetic T9 generic, validate_verification_log V1a-V1c), Predictive Debugging P1 (aggregate_risk_scores + validate_risk_scores RS1-RS6 + _RISK_WEIGHTS 13 weights + _RECENCY_DECAY_DAYS decay), pACS P1 validation (validate_pacs_output PA1-PA6 — structural integrity of pACS log: file existence, minimum size, dimension scores, Pre-mortem, min() arithmetic, Color Zone), L0 Anti-Skip Guard (validate_step_output L0a-L0c — deliverable file existence + minimum size + non-empty), Team Summaries KI archive (_extract_team_summaries — SOT active_team.completed_summaries → preserved in KI), Abductive Diagnosis Layer (diagnose_failure_context pre-evidence collection + validate_diagnosis_log AD1-AD10 post-validation + _extract_diagnosis_patterns KA archiving + Fast-Path FP1-FP3 + hypothesis priority H1/H2/H3), module-level regex compilation (9+8+8+4+5 patterns — once per process))
│   │   ├── save_context.py    (save engine)
│   │   ├── restore_context.py (restore — RLM pointer + completion/Git state + Predictive Debugging risk score cache generation)
│   │   ├── update_work_log.py (work log accumulation — tracking 9 tools)
│   │   ├── generate_context_summary.py (incremental snapshot + Knowledge Archive + E5 Guard + Autopilot Decision Log safety net + ULW Compliance safety net)
│   │   ├── setup_init.py      (Setup Init — infrastructure health verification + SOT write pattern validation (P1 hallucination containment), --init trigger)
│   │   ├── setup_maintenance.py (Setup Maintenance — periodic health check, --maintenance trigger)
│   │   ├── block_destructive_commands.py (PreToolUse Safety Hook — blocks dangerous commands (P1 hallucination containment), blocks with exit code 2 + Claude self-correction)
│   │   ├── block_test_file_edit.py  (PreToolUse TDD Guard — blocks test file modification (.tdd-guard toggle), blocks with exit code 2 + directs to implementation code modification)
│   │   ├── predictive_debug_guard.py (PreToolUse Predictive Debug — warns about risky files based on error history, exit code 0 warning only)
│   │   ├── output_secret_filter.py  (PostToolUse secret detection — 3-tier extraction (tool_response→file read→transcript), 25+ regex patterns, 2-pass scanning (raw + base64/URL), fcntl-locked audit log, exit code 0 warning only)
│   │   ├── security_sensitive_file_guard.py (PostToolUse security-sensitive file warning — .env/PEM/credentials/cloud/K8s/terraform, etc. 12 patterns, session dedup, exit code 0 warning only)
│   │   ├── diagnose_context.py  (Abductive Diagnosis pre-evidence collection — generates an evidence bundle on quality gate FAIL, manually invoked by the Orchestrator)
│   │   ├── query_workflow.py    (workflow observability — 4 modes: dashboard/weakest/retry/blocked, P1 SOT schema validation + context-aware pACS extraction)
│   │   ├── validate_pacs.py    (pACS P1 validation + L0 Anti-Skip Guard — PA1-PA7, standalone script, JSON output)
│   │   ├── validate_review.py (Adversarial Review P1 validation — R1-R5, standalone script, JSON output)
│   │   ├── validate_translation.py (Translation P1 validation — T1-T9 + glossary validation, JSON output)
│   │   ├── validate_verification.py (Verification Log P1 validation — V1a-V1c structural integrity, JSON output)
│   │   ├── validate_diagnosis.py (Abductive Diagnosis P1 post-validation — AD1-AD10, JSON output)
│   │   ├── validate_traceability.py (Cross-Step Traceability P1 validation — CT1-CT5, JSON output)
│   │   ├── validate_domain_knowledge.py (Domain Knowledge P1 validation — DK1-DK7, JSON output)
│   │   ├── validate_workflow.py (DNA inheritance P1 validation — W1-W8, JSON output)
│   │   ├── validate_retry_budget.py (Retry Budget P1 validation — RB1-RB3 retry budget decision (ULW-aware), JSON output)
│   │   ├── _test_secret_filter.py   (output_secret_filter tests — 44 cases)
│   │   ├── _test_sensitive_file_guard.py (security_sensitive_file_guard tests — 44 cases)
│   │   └── _test_block_destructive.py (block_destructive_commands tests — 43 cases)
│   ├── context-snapshots/     ← runtime snapshots (gitignored)
│   └── skills/
│       ├── workflow-generator/   ← workflow design and generation
│       │   ├── SKILL.md          (skill definition + Absolute Criteria)
│       │   └── references/       (implementation patterns, templates, document analysis guide)
│       └── doctoral-writing/     ← doctoral-level academic writing
│           ├── SKILL.md          (skill definition + Absolute Criteria)
│           └── references/       (checklists, common errors, revision examples, discipline-specific guides)
├── prompt/              ← prompt materials
│   ├── crystalize-prompt.md      (prompt compression techniques)
│   ├── distill-partner.md        (essence extraction and optimization)
│   └── crawling-skill-sample.md  (crawling skill sample)
└── coding-resource/     ← reference materials

Context Preservation System

An automatic save/restore system that prevents the loss of work context when the context window is exhausted, the session is reset, or the context is compacted.

Core principles:

• RLM pattern applied: work history is persisted as an external memory object (MD file), and restored in a new session via pointers
• P1 principle followed: transcript parsing and statistics are performed deterministically by Python code. The AI focuses only on semantic interpretation
• Absolute Criterion 2 followed: the SOT file (state.yaml) is accessed read-only. Snapshots are stored in a separate directory (context-snapshots/)
• Knowledge Archive: Cross-session knowledge accumulation — session facts are deterministically extracted and accumulated in knowledge-index.jsonl. Recorded by both the Stop hook and SessionEnd/PreCompact, guaranteeing 100% indexing of the session. Each entry includes completion_summary (tool success/failure), git_summary (change status), session_duration_entries (session length), phase (session phase), phase_flow (multi-stage transition flow), primary_language (primary file extension), error_patterns (Error Taxonomy 12-pattern classification + resolution matching), tool_sequence (RLE-compressed tool sequence), final_status (success/incomplete/error/unknown), tags (path-based search tags — CamelCase/snake_case split + extension mapping). AI searches programmatically with Grep (RLM pattern)
• Resume Protocol: Snapshot includes deterministic restoration instructions — list of modified/referenced files, session metadata, completion state (tool success/failure), Git change state. Dynamic RLM query hints: Based on tags extracted from the modified file paths (extract_path_tags()) and error information, session-specific tailored Grep query examples are auto-generated. Guarantees a floor level for restoration quality
• Autopilot runtime reinforcement: When Autopilot is active, the snapshot includes an Autopilot state section (IMMORTAL priority), and on session restoration execution rules are injected into context. The Stop hook detects and compensates for missing Decision Logs
• ULW mode detection / preservation: detect_ulw_mode() detects the ulw keyword in the transcript using word-boundary regex. When active, the snapshot includes a ULW state section (IMMORTAL priority), and SessionStart injects the 3 reinforcement rules (Intensifiers) into context. check_ulw_compliance() deterministically verifies compliance. Tagged as ulw_active: true in the Knowledge Archive
• Decision-quality tag ordering: The "key design decisions" section of the snapshot is ordered [explicit] > [decision] > [rationale] > [intent], so that high-signal decisions are placed first in the 15 slots. Comparison / trade-off / selection patterns are also extracted
• IMMORTAL-aware compression: When the snapshot exceeds size, IMMORTAL sections are preserved with priority and non-IMMORTAL content is truncated first. In extreme cases, the beginning of IMMORTAL text is still preserved. Compression audit trail: The number of characters removed in each compression Phase is recorded at the end of the snapshot as an HTML comment (<!-- compression-audit: ... -->) (per-Phase deltas for Phases 1~7 + final size)
• Error Taxonomy: Tool errors are classified into 12 patterns (file_not_found, permission, syntax, timeout, dependency, edit_mismatch, type_error, value_error, connection, memory, git_error, command_not_found). Negative-lookahead and qualifier matching are applied to prevent false positives. Recorded in the error_patterns field of the Knowledge Archive. Error→Resolution matching: Successful tool invocations within 5 entries after an error are detected via file-aware matching and recorded in the resolution field (tool name + file name). Cross-session exploration of resolution patterns is possible via Grep "resolution" knowledge-index.jsonl
• System command filtering: In the snapshot's "current work" section, system commands such as /clear, /help are filtered out so that only actual work intent is captured
• Crash-safe writes: The atomic write pattern (temp → rename) is applied to all file writes (snapshots, archives, log cleanup). Prevents partial writes on process crash
• P1 Hallucination Prevention: Tasks that must be 100% accurate repeatedly are enforced by Python code. (1) KI schema validation: _validate_session_facts() guarantees the presence of RLM-required keys (session_id, tags, final_status, etc. — 10 items) right before writing to knowledge-index — fills with safe defaults if missing. (2) Partial failure isolation: In archive_and_index_session(), failure to write the archive file does not block knowledge-index update — protects the core RLM asset. (3) SOT write pattern validation: _check_sot_write_safety() in setup_init.py detects the coexistence of SOT file names + write patterns in Hook scripts, based on AST function boundaries. (4) SOT schema validation: validate_sot_schema() validates the structural integrity of the workflow state.yaml across 8 items (S1-S6 basic + S7 pacs 5 fields + S8 active_team 5 fields). (5) Adversarial Review P1 validation: validate_review_output() R1-R5, parse_review_verdict(), calculate_pacs_delta(), validate_review_sequence() deterministically guarantee review quality

Data flow:

Work in progress ─→ [PostToolUse] update_work_log.py ─→ accumulates work_log.jsonl (tracking 9 tools)
                 ├→ [PostToolUse] output_secret_filter.py ─→ secret detection on Bash|Read output (3-tier extraction, 25+ patterns, standalone)
                 └→ [PostToolUse] security_sensitive_file_guard.py ─→ Edit|Write sensitive file warning (standalone)
                                                         │ (when token > 75%)
                                                         ↓
Response complete ─→ [Stop] generate_context_summary.py ─→ saves latest.md (30s throttling)
                                                         │        + accumulates knowledge-index.jsonl
                                                         │        + archives to sessions/
                                                         │        + E5 Empty Snapshot Guard
                                                         ↓
Session end/compact ─→ [SessionEnd/PreCompact] save_context.py ─→ saves latest.md
                                                         │        + accumulates knowledge-index.jsonl
                                                         │        + archives to sessions/
                                                         ↓
New session start ──→ [SessionStart] restore_context.py ───────→ emits pointer + summary + completion state + Git state
                                                         AI restores the full content via Read tool

5. Implementation Element Mapping

When designing a workflow, combine the implementation elements below. Tools may use different names, but the concepts are the same.

The sole criterion for agent selection is "which structure best raises the quality of the final deliverable." Do not choose an agent group just because parallelism is fast. Do not choose a specialized agent just because it uses fewer tokens.

Specialized Agent vs Agent Group — Quality Judgment Matrix

Decide the structure along 5 quality factors. "Because it's faster" or "because it's cheaper" is not a criterion:

Judgment rules:

1. If specialized-agent advantage wins on 3 or more of the 5 factors → Specialized agent
2. If agent-group advantage wins on 3 or more factors → Agent group
3. Tie (2:2 + 1 undecidable) → Context depth acts as tiebreaker (context retention is generally safer)
4. When in doubt → Specialized agent (safe default — guarantees context retention)

Model Level Selection — Quality-Based Judgment

Judgment procedure:

1. How directly does this task affect the quality of the final deliverable?
2. Is the quality difference between model levels meaningful?
   • If meaningful → higher-tier model
   • If not meaningful → lower-tier model is permitted
3. When in doubt → higher-tier model (quality-guarantee principle — Absolute Criterion 1)

5.1 Autopilot Mode

A mode that enables uninterrupted workflow execution by automatically approving human-in-the-loop points.

Core principles:

• Autopilot only performs automatic approval of human intervention points
• Every workflow stage is fully executed — stage skipping is forbidden
• Every deliverable is produced at full quality — abbreviation is forbidden
• Automated verification (Hook exit code 2) still blocks under Autopilot

Target distinction:

Anti-Pattern:

1. Autopilot ≠ stage skipping: every stage is fully executed in sequence
2. Autopilot ≠ abbreviated output: every agent produces deliverables of the same quality and length as it would under human review

Anti-Skip Guard (runtime verification):

The deterministic verification performed by the Orchestrator on each stage completion:

1. Is the deliverable file recorded as a path in SOT outputs?
2. Does that file exist on disk?
3. Is the file size ≥ 100 bytes (ensuring meaningful content)?

In Claude Code's Hook system, the validate_step_output() function of _context_lib.py performs this verification deterministically. In other tools, implement equivalent file validation logic.

SOT record:

workflow:
  name: "my-workflow"
  current_step: 3
  status: "running"
  outputs:
    step-1: "research/raw-contents.md"
    step-2: "analysis/insights-list.md"
  autopilot:
    enabled: true
    activated_at: "ISO-8601"
    auto_approved_steps: [3, 6]

• autopilot.enabled: Boolean — whether Autopilot is active
• autopilot.auto_approved_steps: list of step numbers that were auto-approved
• outputs: per-step deliverable paths — the targets verified by Anti-Skip Guard
• Auto-approval decisions are recorded in a separate log file (autopilot-logs/step-N-decision.md) (transparency guarantee)
• Decision Log standard template: see Claude Code's references/autopilot-decision-template.md

Runtime reinforcement (Claude Code implementation):

The Hook layer accesses SOT read-only (Absolute Criterion 2).

Autopilot Execution Checklist (tool-common):

Mandatory actions that must be performed per stage when executing a workflow under Autopilot in any tool:

Claude Code details: docs/protocols/autopilot-execution.md defines additional Claude Code-specific checklists for (team) stages, translation, Hook integration, etc.

Activation: Default is inactive (interactive). Activated by specifying Autopilot: enabled in the workflow Overview or by user instruction at execution time. Can be toggled during execution.

5.1.1 ULW Mode (Claude Code)

ULW (Ultrawork) is a thoroughness-intensity overlay orthogonal to Autopilot. It is activated by including ulw in the prompt.

• Autopilot = automation axis (HOW) — skip (human) approvals
• ULW = thoroughness axis (HOW THOROUGHLY) — nothing omitted, perfect completion through error resolution

2x2 matrix:

3 reinforcement rules (Intensifiers):

1. I-1. Sisyphus Persistence — Up to 3 retries, each with a different approach. 100% completion, or report impossibility.
2. I-2. Mandatory Task Decomposition — TaskCreate → TaskUpdate → TaskList mandatory
3. I-3. Bounded Retry Escalation — No more than 3 retries on the same target (quality gates have a separate budget); when exceeded, escalate to the user

Deterministic reinforcement: A Python Hook deterministically verifies compliance with the 3 reinforcement rules (Compliance Guard). On violation, a warning is recorded in the IMMORTAL section of the snapshot.

Combination rule: ULW reinforces Autopilot — the Autopilot quality-gate retry limit is raised 10→15. Safety Hook blocks are always respected.

Details: docs/protocols/ulw-mode.md

5.2 English-First Execution and Translation Protocol

When executing a workflow, every agent works in English and produces deliverables in English. Because AI performs best in English, English-first execution is a direct realization of Absolute Criterion 1 (Quality).

Language Boundaries

Design documents (workflow.md) remain in Korean. Since it is a blueprint that the user reads and reviews, it uses the user's language. Language transitions occur at the design → execution boundary.

Determining Translation Targets

Not every stage requires translation:

When designing a workflow, specify Translation: @translator or Translation: none per stage to decide whether translation applies.

Translation Execution Protocol

Rationale for sub-agent selection: Because terminology consistency and context accumulation are key to translation quality, a specialized Sub-agent has a quality advantage over an agent group (factors "context depth" + "deliverable consistency" in the §5 quality matrix).

Execution order:

Step N English deliverable complete
  → record in SOT outputs.step-N + Anti-Skip Guard verification
  → invoke @translator sub-agent (only for stages with Translation: @translator)
    ① Read translations/glossary.yaml (terminology — RLM external persistent state)
    ② Read the full English source
    ③ Fully translate using established terms (no abbreviation — Absolute Criterion 1)
    ④ Self-review: compare against the source, check terminology consistency
    ⑤ Update glossary.yaml (add new terms)
    ⑥ Generate *.ko.md file
  → record in SOT outputs.step-N-ko
  → confirm the translation file exists and is non-empty
  → P1 validation: python3 .claude/hooks/scripts/validate_translation.py --step N --project-dir . --check-pacs --check-sequence
  → proceed to Step N+1

Terminology Glossary

translations/glossary.yaml is the translation agent's persistent external memory (RLM pattern). Together with memory: project (ADR-051), it forms a 2-layer memory: glossary.yaml = explicit terminology mapping, persistent memory = implicit style/tone pattern accumulation.

# translations/glossary.yaml
terms:
  "Single Source of Truth": "Single Source of Truth (SOT)"
  "Anti-Skip Guard": "Anti-Skip Guard"  # kept in English
  "workflow step": "Workflow Step"

Architectural consistency:

• The glossary is not an SOT — it is a local work file of the translation agent
• Not managed by the Orchestrator — managed by the translation agent itself
• No concurrent-write risk — translation runs sequentially (once after each stage)
• Hierarchical memory: glossary.yaml (explicit terminology) + memory: project (implicit experience accumulation) as 2 layers (ADR-051)

SOT Recording Rules

outputs:
  step-1: "research/raw-contents.md"          # English source
  step-1-ko: "research/raw-contents.ko.md"    # Korean translation
  step-2: "data/processed.json"               # translation unnecessary → no -ko
  step-3: "analysis/report.md"
  step-3-ko: "analysis/report.ko.md"

• The step-N-ko key follows the suffix convention: it is automatically skipped by Anti-Skip Guard's .isdigit() guard
• Anti-Skip Guard validates only step-N (the English source) → translation verification is performed by the Orchestrator checklist
• Stages without translation do not generate -ko keys

Translation in (team) Stages

The translation targets in agent-group stages are only the official deliverables recorded in SOT outputs.step-N:

1. Team Lead merges all Teammate deliverables
2. Records in SOT outputs.step-N + Anti-Skip Guard verification
3. Team Lead invokes @translator (on the merged official deliverable)
4. Records in SOT outputs.step-N-ko

Individual Teammate deliverables are intermediate artifacts (not recorded in SOT), and therefore are not translated.

Independent Translation Verification (optional — for final deliverables)

By default, the translator's self-review is sufficient. For stages where quality is especially critical, such as final deliverables, an independent verification sub-agent can be added:

@translator → output.ko.md
  → @translation-verifier (separate sub-agent)
    ① Read English source and Korean translation simultaneously
    ② Verify accuracy, completeness, terminology consistency, naturalness
    ③ Pass/Fail verdict + feedback
  → On Fail: request re-translation from @translator with feedback

This pattern is applied optionally in workflow design.

5.3 Verification Protocol (Work Verification)

A protocol that verifies whether each stage deliverable of the workflow has 100% achieved the functional goal.

Core principle:

"Declare the definition of done first, verify after execution, and re-execute on failure."

Anti-Skip Guard (file existence + ≥ 100 bytes) guarantees physical existence, and the Verification Protocol guarantees content completeness. The two layers operate independently, and both must pass before proceeding to the next stage.

Quality-guarantee layer structure:

  Anti-Skip Guard (Hook — deterministic)
    "Does the file exist and have meaningful size?"
      ↓ PASS
  Verification Gate (Agent — semantic)
    "Has the functional goal been 100% achieved?"
      ↓ PASS
  Update SOT + proceed to next stage

Declaring Verification Criteria

Define a Verification field in each stage of the workflow. Place it before the Task so that the agent starts work after first recognizing "what constitutes completion."

### N. [Step Name]
- **Verification**:
  - [ ] [specific, measurable criterion]
  - [ ] [specific, measurable criterion]
- **Task**: [task description]

Verification Criterion Types (5)

Criterion-writing rule: Each criterion must be mechanically pass/fail judgeable by a third party. Subjective judgments ("good quality," "sufficient depth") must not be used as criteria. Subjective quality judgments are handled by the existing (human) checkpoints.

Domain Knowledge Structure (DKS)

A pattern for verifying the validity of domain-specialized reasoning. In the Research stage, build domain-knowledge.yaml, and in the Implementation stage, use it as verification criteria. Optional — not required for every domain. Validation script: validate_domain_knowledge.py (DK1-DK7).

DKS necessity criteria:

Execution Protocol

1. Read verification criteria — agent first recognizes the definition of "100% complete"
2. Execute stage — produce the full-quality deliverable (Absolute Criterion 1)
3. Anti-Skip Guard — file existence + ≥ 100 bytes (deterministic)
4. Verification Gate — self-verify deliverable against each criterion (semantic)
   ├─ All criteria PASS → create verification-logs/step-N-verify.md → update SOT → proceed
   └─ Even one FAIL:
       ├─ Identify the failure cause + re-execute only the failing part (not full rework)
       ├─ Re-verify (up to 10 retries)
       └─ If still FAIL after 10 → escalate to user
5. Update SOT — record outputs, `current_step` +1

Scope of Self-Verification: The verification in this protocol is a completeness check — "Was what had to be executed executed?" Subjective quality judgment is handled by the existing (human) checkpoints, and the Verification Protocol does not replace them.

Verification Log Format

Recorded in verification-logs/step-N-verify.md:

# Verification Report — Step {N}: {Step Name}

## Criteria Check
| # | Criterion | Status | Evidence |
|---|-----------|--------|----------|
| 1 | [criterion text] | PASS | [specific evidence from the deliverable] |
| 2 | [criterion text] | FAIL→PASS | [first-round failure reason] → [evidence after re-execution] |

## Result: PASS (retry: 1)
## Verified Output: research/insights.md (2,847 bytes)

3-Layer Verification for (team) Stages

Agent-group stages perform a 3-layer verification:

Teammate: Execute Task → self-verify (L1) → pACS self-score (L1.5)
            → On PASS + GREEN/YELLOW: report to Team Lead (include pACS score)
            → On FAIL or RED: self-correct, then re-verify/re-score

Team Lead: Receive Teammate deliverables + pACS scores
            → Comprehensive verification against stage criteria (L2)
            → Stage pACS = min(each Teammate pACS) — apply min-score principle
            → On PASS: update SOT (outputs + pacs)
            → On FAIL: SendMessage with concrete feedback + re-execution directive

SOT compatibility: Teammate still produces only deliverable files and does not write to SOT. Self-verification and pACS self-scoring are completed inside the Teammate's session and conveyed to the Team Lead via the report message (Absolute Criterion 2). Only the Team Lead records in pacs-logs/ and updates the SOT.

Backward Compatibility

When creating new workflows, include the Verification field as mandatory. Existing workflows can add it incrementally.

SOT Impact

None. The Verification Protocol is an agent-execution protocol (prompt layer) and does not change the SOT structure. Advancement of current_step already implicitly means that verification has completed, and the verification details are recorded in verification-logs/ files.

5.4 pACS — predicted Agent Confidence Score (Self-Confidence Rating)

A protocol where an agent structurally self-rates the confidence of its own deliverable during workflow execution. Inspired by AlphaFold's pLDDT (predicted Local Distance Difference Test).

Core principle:

"Before assigning a score, speak about the weaknesses first." (Pre-mortem Protocol)

While the Verification Protocol (§5.3) verifies "completeness" — was what had to be executed executed? — pACS quantifies "confidence" — how much can we believe the result? The two protocols guarantee quality on different dimensions and operate independently.

3 Evaluation Dimensions (Orthogonal Dimensions)

Reason for limiting to 3 dimensions: Agent self-rating is a subjective estimate without calibration data. The more dimensions, the larger the precision illusion and the greater the interference between dimensions. 3 orthogonal dimensions is the practical upper bound.

Min-Score Principle

pACS = min(F, C, L)

Weighted averaging is not used. If any one dimension is low, the overall confidence is low. The weakest link determines overall quality.

Pre-mortem Protocol (Mandatory — perform before scoring)

A mechanism that structurally prevents score inflation. The agent must answer the 3 questions below before scoring:

1. "Where is the most uncertain part of this deliverable?" — areas where sources are unverified, recency is unclear, or reliance on estimation exists
2. "What is most likely to have been omitted?" — partial requirement unmet, edge cases unconsidered, data gaps
3. "Where is the weakest link in this argument?" — evidence→conclusion leaps, insufficient premise verification, unexplored alternatives

If the Pre-mortem responses reveal serious issues, you cannot assign a high score to the corresponding dimension.

Action Triggers

Quality-Guarantee Layer Structure (4 Layers)

L0  Anti-Skip Guard (Hook — deterministic)
      "Does the file exist and have meaningful size?"
        ↓ PASS
L1  Verification Gate (Agent — semantic)
      "Has the functional goal been 100% achieved?"
        ↓ PASS
L1.5  pACS Self-Rating (Agent — confidence)
        Pre-mortem → score F, C, L → min(F,C,L) = pACS
        ↓ GREEN/YELLOW: proceed (YELLOW flagged)
        ↓ RED: rework or escalation
L2    Adversarial Review (Enhanced — stages with a Review: field)
        @reviewer / @fact-checker independently reviews the deliverable adversarially (§5.5)

Relationship between L1 and L1.5: The Verification Gate is "checklist item PASS/FAIL" — a binary judgment. pACS is "overall confidence 0-100" — a continuous self-rating. Even when every Verification item is PASS, pACS can still be low (e.g., every item was addressed but source quality is low).

SOT Record

workflow:
  # ... existing fields ...
  pacs:
    current_step_score: 72          # pACS of current stage
    dimensions: {F: 72, C: 85, L: 78}
    weak_dimension: "F"             # min-score dimension
    pre_mortem_flag: "Step 3: 2 data sources unverified"
    history:                        # per-stage history
      step-1: {score: 85, weak: "C"}
      step-2: {score: 72, weak: "F"}

• The pacs field is append-only to the existing SOT schema — independent of existing workflow, autopilot, outputs, active_team fields
• SOT without pacs still functions normally (backward compatible)
• Because the Hook's capture_sot() includes the entire SOT in the snapshot, the pacs field is also automatically preserved across session boundaries

Translation pACS (for Translation Deliverables)

Additional 3 dimensions for the @translator sub-agent's translation deliverables:

Translation pACS = min(Ft, Ct, Nt). Action triggers are identical (GREEN/YELLOW/RED).

L2 Adversarial Review (Enhanced — stages with a Review: field)

An enhanced quality-verification layer that replaces the previous L2 Calibration. @reviewer (critical analysis of code/deliverables, read-only) and @fact-checker (external fact verification, web access) independently review the deliverable. Review results are deterministically guaranteed in quality via P1 validation (validate_review.py).

Applied to stages where the workflow design specifies Review: @reviewer or Review: @reviewer + @fact-checker. Default is self-rating (L1.5) only.

Details: see §5.5 Adversarial Review.

pACS Log Format

Recorded in pacs-logs/step-N-pacs.md:

# pACS Report — Step {N}: {Step Name}

## Pre-mortem
1. **Most uncertain**: [the uncertain part]
2. **Likely omission**: [possible omission]
3. **Weakest link**: [the weakest argumentative link]

## Scores
| Dimension | Score | Rationale |
|-----------|-------|-----------|
| F (Factual Grounding) | {0-100} | [specific evidence] |
| C (Completeness) | {0-100} | [specific evidence] |
| L (Logical Coherence) | {0-100} | [specific evidence] |

## Result: pACS = {min(F,C,L)} → {GREEN|YELLOW|RED}
## Weak Dimension: {F|C|L} — {description of weakness}

pACS Under Autopilot

• pACS GREEN → automatic progression
• pACS YELLOW → automatic progression + record weak dimension in Decision Log
• pACS RED → automatic rework (up to 10 times). If still RED after → escalate to user
• Add pacs_score, weak_dimension fields to the Autopilot Decision Log

Backward Compatibility

Design decision: pACS in isolation without Verification is forbidden. Performing confidence rating (L1.5) without completeness verification (L1) can lead to the contradictory state of "everything omitted, but confidence high."

5.5 Adversarial Review (Enhanced L2 — Adversarial Review)

An enhanced quality-verification layer that replaces the previous L2 Calibration. Deliverables are independently reviewed using the Generator-Critic pattern.

Quality Layer Architecture

L0   Anti-Skip Guard (Hook — deterministic)
L1   Verification Gate (Agent self-check)
L1.5 pACS Self-Rating (Agent confidence)
L2   Adversarial Review (Enhanced L2) ← this section
       ├── Content critical analysis (LLM — @reviewer / @fact-checker)
       ├── Independent pACS scoring (LLM → Python validates)
       └── P1 deterministic validation (Python — validate_review.py)

Agent Definitions

• Rationale for tool separation (P2): @reviewer reviews internal logic of code/docs, so it only needs read access. @fact-checker needs web access because external fact verification is required. Principle of least privilege.
• Rationale for Sub-agent selection: Single reviewer = Sub-agent (synchronous feedback loop). Since review results must be reflected immediately, this is more efficient than an Agent Team asynchronous pattern.

Execution Protocol

1. Generator produces the deliverable → passes L0/L1/L1.5
2. Orchestrator invokes the agent specified in the Review: field as a Sub-agent
3. The reviewer agent produces the review report (returned via stdout)
4. Orchestrator saves the report to review-logs/step-N-review.md
5. P1 validation: python3 .claude/hooks/scripts/validate_review.py --step N --project-dir .
6. Proceed based on verdict:

PASS → Translation (if any) → SOT update → next stage
FAIL → Rework (up to 10 times) → Re-review
       ↓ after 10
       Escalate to user

Review Field Syntax

Specify the Review: attribute per stage in the workflow:

### Step 3: Analysis Report (agent)
- Agent: @analyst
- Review: @reviewer          ← code/deliverable review
- Translation: @translator
- Verification:
  - [ ] ...

Rubber-stamp Prevention (4-Layer Defense)

P1 Hallucination Containment

5 tasks that must be 100% accurate in the review system are enforced by Python code:

Standalone script: python3 .claude/hooks/scripts/validate_review.py --step N --project-dir . Output: JSON {"valid": true, "verdict": "PASS", "critical_count": 0, ...}

Translation P1 Hallucination Containment

9 tasks that must be 100% accurate for translation deliverables are enforced by Python code:

Standalone script: python3 .claude/hooks/scripts/validate_translation.py --step N --project-dir . --check-pacs --check-sequence Output: JSON {"valid": true, "checks": {"T1": true, ...}, "pacs_valid": true}

Verification Log P1 Hallucination Containment

Structural integrity of the verification log is enforced by Python code across 3 items:

Standalone script: python3 .claude/hooks/scripts/validate_verification.py --step N --project-dir . Output: JSON {"valid": true, "checks": {"V1a": true, "V1b": true, "V1c": true}}

Issue Severity Classification

Review Report Format

Recorded in review-logs/step-N-review.md:

# Adversarial Review — Step {N}: {Step Name}
Reviewer: @{reviewer|fact-checker}

## Pre-mortem (MANDATORY — before analysis)
1. **Most likely critical flaw**: [...]
2. **Most likely factual error**: [...]
3. **Most likely logical weakness**: [...]

## Issues Found
| # | Severity | Location | Problem | Suggested Fix |
|---|----------|----------|---------|---------------|
| 1 | Critical | file:line | [...] | [...] |

## Independent pACS (Reviewer's Assessment)
| Dimension | Score | Rationale |
|-----------|-------|-----------|
| F | {0-100} | [...] |
| C | {0-100} | [...] |
| L | {0-100} | [...] |

Reviewer pACS = min(F,C,L) = {score}
Generator pACS = {score}
Delta = |Reviewer - Generator| = {N}

## Verdict: {PASS|FAIL}

Adversarial Review Under Autopilot

• Review PASS → automatic progression (including Translation)
• Review FAIL → automatic rework (up to 10 times, escalate to user on exceeding)
• pACS Delta ≥ 15 → record in Decision Log + recommend recalibration
• Review Decision Log: include review result in autopilot-logs/step-N-decision.md

Execution Order Constraint

Task → L0 → L1 → L1.5 → Review(L2) → PASS → Translation → SOT update

• Translation is executed only after Review PASS (enforced by P1 validate_review_sequence())
• Translation execution is forbidden while Review is FAIL
• Stages with Review unspecified (none) can proceed directly to Translation after L1.5

Backward Compatibility

Design decision: Adversarial Review is positioned as the Enhanced version of the existing L2 Calibration. The "cross-verification" of L2 Calibration is strengthened to "adversarial review," while the existing L0/L1/L1.5 layers are not changed at all. Stages without the Review: field behave identically to before.

5.6 Abductive Diagnosis Protocol

When a quality gate (Verification Gate, pACS, Adversarial Review) fails, instead of retrying immediately, pass through a 3-step diagnosis to raise retry quality. The existing 4-layer QA (L0→L1→L1.5→L2) is not changed; this is an additional layer inserted between FAIL and retry.

3-Step Process

Hypothesis System (H1/H2/H3/H4)

Fast-Path (FP1-FP3)

Deterministic shortcut paths that skip LLM diagnosis:

P1 Post-Validation (AD1-AD10)

Backward Compatibility

Design decision: Abductive Diagnosis is an additional layer that does not change the existing 4-layer QA. Diagnosis results are recorded only in diagnosis-logs/ and SOT is not modified. They are archived to the Knowledge Archive as diagnosis_patterns, enabling cross-session learning.

5.7 TOON Protocol (Token-Oriented Object Notation & Density Enforcement)

All agents, workflows, subagents, and tools in this system MUST enforce the TOON (Token-Oriented Object Notation v4.1) style for all structured data exchange, dialogue turns, task payloads, deliverables, and tabular summaries.

Reference Specification: TOON Specification v4.1 (toon-format/spec)

1. Core Motivation & 30-60% Token Savings

Standard JSON and verbose markdown tables consume excessive tokens due to repeated field keys, curly braces, quotes, and whitespace padding. TOON achieves 30% to 60% token reduction while preserving the full JSON data model, lossless round-trip decoding, and clean human readability.

2. Structural Formatting Rules

1. Uniform Object Arrays (Tabular Form §9.3): When transmitting lists of objects sharing the same fields, declare the field list once in the header, followed by delimiter-separated rows:

   users[2]{id,name,role}:
     1,Ada,admin
     2,Bob,user

2. Primitive Arrays (Inline Form §9.1): Emit primitive sequences on a single header line:

   tags[3]: research,benchmark,evaluation

3. Uniform Mappings (Keyed Tabular Form §9.5): Objects whose values share a uniform shape declare keys per row:

   services[2:]{port,status}:
     web: 8080,healthy
     db: 5432,healthy

4. Hierarchical & Nested Objects (§8): Use 2-space indentation instead of braces; strings are quoted only when required (§7).

3. Agent Communication & Deliverable Contracts

• Verification Logs & Quality Gate Reports:

  verdict: PASS
  pacs_score: 92
  dimensions[3]{dimension,score,evidence}:
    faithfulness,95,"Aligned 100% with spec v4.1"
    completeness,90,"All edge cases and delimiters handled"
    logic,92,"Deterministic round-trip parity"

• Inter-Agent Task Payloads: All subagents, teammates, and orchestrators exchange structured outputs via TOON.
• Native Runtime Adapters:
  • Python: core/engine_py/toon_adapter.py (encode_toon, decode_toon, format_conversation_turns)
  • TypeScript/Bun: src/engine_ts/toon-adapter.ts (powered by @toon-format/toon)

5.8 Supportive Tools Ecosystem & Sequential Operational Lifecycle Director

The workflow runtime automatically provisions supportive tools upon installation and directs their operation sequentially across every phase. The user never needs to manually decide when or how to invoke each supportive integration.

1. The 4 Foundation Supportive Tools

2. The Sequential Operational Lifecycle

┌─────────────────────────────────────────────────────────────────────────────┐
│                  AGENTIC WORKFLOW OPERATIONAL LIFECYCLE                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ CONTINUOUS PROTOCOL LAYER (Always Active):                                  │
│  • TOON Protocol (v4.1): Dense structured data, logs, & inter-agent state   │
│  • Caveman Mode: Ultra-terse, zero-slop agent dialogues & telemetry logs    │
├─────────────────────────────────────────────────────────────────────────────┤
│ PHASE 1: RESEARCH & DISCOVERY                                               │
│  • Skills Mesh Auto-Discovery: Resolve matching skills, tools & playbooks   │
│  • Fable Discover & Context Packets: Ground requirements in ground truth    │
│  • Output in TOON format to conserve context window for later phases        │
├─────────────────────────────────────────────────────────────────────────────┤
│ PHASE 2: ARCHITECTURE & PLANNING                                            │
│  • Ponytail Ladder (Rung 1-3): YAGNI check, stdlib-first, question whether  │
│    speculative scaffolding needs to exist. Strips over-engineering early!   │
│  • Fable Plan: Formulates verifiable plan with explicit success criteria    │
├─────────────────────────────────────────────────────────────────────────────┤
│ PHASE 3: PRODUCTION IMPLEMENTATION                                          │
│  • Ponytail Implementation (Rung 4-7): Shortest working diff, fewest files, │
│    boring over clever, root-cause fix over symptom patches                  │
│  • Fable Circuit Breaker: Tracks failure streaks, halts if streak >= 2      │
├─────────────────────────────────────────────────────────────────────────────┤
│ PHASE 4: VERIFICATION & CLEAN CODE GUARD                                    │
│  • L0 Anti-Skip + L1 Verification + L1.5 pACS + L2 Review                   │
│  • Ponytail Audit: Audits code for over-engineering debt & bloat            │
│  • Fable Multi-Pass Verification (Unit, Integration, Security/Taste)        │
├─────────────────────────────────────────────────────────────────────────────┤
│ PHASE 5: HANDOFF & CONTINUATION STATE                                       │
│  • Fable Handoff: Compacts state into .fable/state.json & PROGRESS.md        │
│  • TOON Serialization of run summary and audit ledger                       │
└─────────────────────────────────────────────────────────────────────────────┘

3. Automatic Provisioning & Dynamic Extensibility

• Automated Provisioning: Running ./install.sh or agentic-workflow init automatically verifies and provisions all supportive tools across ~/.claude, ~/.gemini, ~/.codex, and ~/.agents.
• Extensible Registry (integrations.json): Sibling tools can be added dynamically at any time without modifying core code:

  agentic-workflow integrations add <github-repo-url>

• Lifecycle Director Inspection:

  agentic-workflow integrations status
  agentic-workflow integrations phase <planning|implementation|verification|handoff>

6. Skill System

workflow-generator

A skill that designs and generates the workflow definition file (workflow.md).

• Triggers: "Make a workflow," "design an automation pipeline," "define a task flow"
• Entry point: .claude/skills/workflow-generator/SKILL.md
• Two cases: (1) idea only → interactive Q&A, (2) description document available → document analysis first

doctoral-writing

A skill for writing with doctoral-level academic rigor and clarity.

• Triggers: "Write in thesis style," "academic writing," "polish paper sentences"
• Entry point: .claude/skills/doctoral-writing/SKILL.md
• Core principles: Clarity, conciseness, academic rigor, logical flow

7. Skill Development Rules

When creating a new skill or modifying an existing skill:

1. All Absolute Criteria must be included — contextualized per domain (for non-code-change domains, Absolute Criterion 3 may be N/A)
2. Role separation between files — skill definition (WHY), reference material (WHAT/HOW/VERIFY)
3. Explicitly specify conflict scenarios among the Absolute Criteria — concrete field judgments, not abstract rules
4. Mandatory reflection after modification — do not merely insert wording; check for conflicts with existing content

8. Language and Style

• Framework documents / user conversation: Korean
• Workflow execution: English (maximize AI performance — Absolute Criterion 1 basis). Details: §5.2
• Final deliverables: English source + Korean translation pair
• Technical terminology: Keep in English (SOT, Agent, Orchestrator, Hooks, etc.)
• Visualization: Prefer Mermaid diagrams
• Narrative depth: Prefer comprehensive, data-driven narration over brief summaries
• Code comments: Korean (framework code) / English (workflow execution code)

9. Universal System-Prompt System (Hub-and-Spoke)

This project is designed so that the same methodology is applied automatically regardless of which AI CLI tool is used.

Architecture

                AGENTS.md (Hub — methodology SOT)
               /    |    |    \    \     \
          CLAUDE  GEMINI .cursor  .github/
          .md     .md    /rules   copilot-
                         (Spoke)  instructions.md

• Hub (AGENTS.md): Sole definition point for Absolute Criteria, design principles, and workflow structure
• Spoke (tool-specific files): Reference the Hub while providing implementation mappings tailored to each tool's own functionality

Tool File Mapping

Spoke File Principles

1. Inline Absolute Criteria + reference details: Each Spoke includes the core definitions of the Absolute Criteria (1-2 sentences) inline, and delegates the details to AGENTS.md §2.
2. Tool implementation mapping: Specifies the correspondence between the tool's own functionality (Hook, Agent, Plugin, etc.) and AgenticWorkflow concepts.
3. Context Preservation alternatives: For tools that cannot use Claude Code's Context Preservation System, guide to the alternatives available in that tool.

Conflict Resolution

AGENTS.md's Absolute Criteria take precedence over every Spoke. When tool-dependent implementation conflicts with a principle, the principle wins.

Synchronization Upon Changes to the Absolute Criteria

When the Absolute Criteria in AGENTS.md change, every Spoke file's inline duplicates must also be synchronized:

• CLAUDE.md, GEMINI.md — modify directly
• .cursor/rules/ — modify the inline portion
• .github/copilot-instructions.md — modify the inline portion