Workflow

The right design is a staged, read-first Dynamic Workflow: Fable 5.1 owns scope, architecture, orchestration, and the final verdict; Haiku inventories and normalizes evidence; Sonnet handles ordinary code tracing; Opus performs the difficult and security-sensitive investigations. Every material finding is independently verified before reaching the report.

Dynamic Workflows are a strong fit because the orchestration is encoded as JavaScript, intermediate results live outside the lead model’s context, and the runtime can enforce fan-out and verification rather than merely hoping the lead agent remembers every step. The runtime supports up to 16 concurrent agents and 1,000 total agents, though your first run should be much smaller. Anthropic’s workflow documentation

1. Proposed audit contract

Objective

Evaluate the API implementation rooted at one designated source directory and answer:

What API surface exists?
Does behavior match the intended contracts?
Are authentication, authorization, validation, and data boundaries correct?
Do error handling, observability, concurrency, transactions, and dependency calls behave safely?
Are tests adequate and meaningful?
What defects, risks, and coverage gaps exist?
Is the code fit to release under the agreed acceptance criteria?

Scope rule

Use three scope categories:

Primary scope
Every relevant file beneath the designated source directory must be examined.
Supporting scope
Agents may follow imports, calls, schemas, middleware, configuration, migrations, tests, and generated clients outside that directory when needed to understand primary-scope behavior.
Excluded scope
Supporting libraries are evidence, not new audit targets. Findings outside the source directory are reported only when they directly affect an in-scope API path.

This prevents an audit of src/api/ from silently becoming an audit of the entire monorepo.

Initial safety mode

The first run should be read-only:

No source edits.
No dependency upgrades.
No network calls to production systems.
No destructive database commands.
Tests may run only against an approved local or isolated test environment.
Any secrets found are redacted.
Generated reports go to a designated audit-output directory.
Fixes become a separate workflow after findings are accepted.

2. Model-routing policy

Work type	Preferred model	Why
Scope clarification and audit design	Fable 5.1	High-level framing and long-horizon orchestration
Architecture map and cross-cutting synthesis	Fable 5.1	Integrates evidence across the system
File discovery, endpoint extraction, import indexing	Haiku 4.5	Mechanical, parallelizable processing
Test-result and static-analysis normalization	Haiku 4.5	Structured data transformation
Routine handler/service tracing	Sonnet 5	Better balance of judgment, speed, and cost
Complex state, concurrency, auth, transaction, or business-rule analysis	Opus 5	Deep code reasoning
Security review and adversarial verification	Opus 5	Avoids relying on Fable for safeguard-sensitive security analysis
Independent finding verification	Opus for high severity; Sonnet for lower severity	Spend strong reasoning where errors matter most
Deduplication and severity normalization	Sonnet 5	Moderate judgment over structured results
Release verdict and executive report	Fable 5.1	System-wide judgment with explicit uncertainty

A useful routing rule is:

Haiku extracts facts.
Sonnet connects ordinary facts.
Opus resolves ambiguity and attacks claims.
Fable decides what the body of evidence means.

Current Anthropic guidance allows a workflow stage to request a different model; otherwise the session model is inherited. Organizational model allowlists can substitute models, and the workflow viewer reports substitutions. Model-selection behavior

Because Fable’s cybersecurity safeguards may route some security requests to an Opus model, explicitly assigning security investigations to Opus makes the workflow more predictable. Fable overview

3. Workflow phases

Phase 0 — Preflight and clarification

Fable produces an AuditPlan before substantive work begins.

Required inputs:

Repository root.
Primary source directory.
Languages and frameworks.
API style: REST, GraphQL, RPC, event-driven, or mixed.
Intended API specification location.
Test commands.
Static-analysis commands.
Safe environment assumptions.
Critical business invariants.
Explicit exclusions.
Severity rubric.
Token or cost budget.

Preflight validations:

Confirm the primary directory exists.
Detect repository instructions such as CLAUDE.md.
Detect dirty working-tree changes.
Identify build and package systems.
Determine which commands are safe.
Verify requested models are available.
Estimate endpoint count, file count, and likely agent count.
Stop and ask if the test environment or allowable commands are ambiguous.

Dynamic Workflows cannot accept ordinary user input midway through one run. Therefore, clarification must occur before launch, or the job should be split into multiple workflows with approval between them. Workflow limits

Phase 1 — Deterministic inventory

Haiku agents enumerate and normalize:

Route definitions and endpoint registrations.
HTTP methods and paths.
Controllers and handlers.
Request and response models.
Authentication and authorization middleware.
Input validation.
Services and repositories called.
External API clients.
Database entities and transactions.
Feature flags and configuration.
Tests associated with each endpoint.
OpenAPI, GraphQL, protobuf, or other formal contracts.

Output: one structured EndpointRecord per endpoint.

{
  "endpoint_id": "METHOD /normalized/path",
  "entrypoint": "path:line",
  "auth_chain": [],
  "request_schema": [],
  "response_schema": [],
  "call_chain": [],
  "external_dependencies": [],
  "data_stores": [],
  "tests": [],
  "unknowns": []
}

A completeness agent compares discovered files against processed files. No later phase starts until every relevant primary-scope file is either mapped or explicitly classified as irrelevant.

Phase 2 — Architecture and risk partitioning

Fable builds:

API architecture map.
Trust boundaries.
Shared middleware chain.
Data-flow map.
Dependency map.
Endpoint clusters.
Risk-ranked work packages.

Risk factors should include:

Public or unauthenticated exposure.
Privileged actions.
Personal, financial, or regulated data.
Multi-tenant behavior.
Complex validation.
Transactional writes.
Async processing.
External side effects.
Dynamic query construction.
File handling.
Webhooks.
Idempotency requirements.
Low test coverage.
High fan-in shared components.

Routine endpoint clusters go to Sonnet. High-risk clusters go to Opus.

Phase 3 — Automated evidence collection

Agents run only approved commands, such as:

Build or compilation.
Type checking.
Unit tests.
Integration tests.
Contract tests.
Linting.
Dependency checks.
Existing security scanners.
Coverage collection.
API-schema validation.

Haiku agents normalize outputs into structured evidence rather than asking expensive models to parse raw logs repeatedly.

Every command result records:

{
  "command": "...",
  "exit_code": 0,
  "environment": "...",
  "started_at": "...",
  "duration": "...",
  "summary": "...",
  "artifacts": [],
  "limitations": []
}

A failed command is evidence, not automatically a product defect. The workflow must distinguish:

Product failure.
Test failure.
Environment failure.
Tooling failure.
Inconclusive result.

Phase 4 — Parallel semantic audit

Assign independent work packages across these lenses:

API contract correctness.
Authentication.
Authorization and tenant isolation.
Input validation and canonicalization.
Output correctness and data leakage.
Error mapping and status codes.
Transactions and partial failure.
Concurrency and race conditions.
Idempotency and retry behavior.
External dependency resilience.
Resource exhaustion and pagination.
Injection and unsafe parsing.
Secrets and sensitive logging.
Observability and audit trails.
Backward compatibility.
Test quality and missing cases.
Dead or unreachable API paths.
Framework-specific hazards.

Agents must trace complete paths, not judge route files in isolation:

request
  → router
  → middleware
  → handler
  → service
  → repository/client
  → state change
  → response/error mapping

Each candidate finding must conform to:

{
  "finding_id": "candidate-local-id",
  "title": "...",
  "category": "...",
  "severity_proposed": "critical|high|medium|low|info",
  "confidence": 0.0,
  "endpoint_ids": [],
  "primary_location": "path:line",
  "supporting_locations": [],
  "preconditions": [],
  "execution_path": [],
  "expected_behavior": "...",
  "actual_behavior": "...",
  "impact": "...",
  "evidence": [],
  "test_evidence": [],
  "counterevidence": [],
  "recommended_fix": "...",
  "verification_plan": "..."
}

No finding should be accepted solely because a pattern “looks dangerous.”

Phase 5 — Adversarial verification

Every candidate finding gets a separate verifier that did not originate it.

Verification questions:

Is the cited code reachable?
Does upstream middleware already prevent the behavior?
Is the apparent defect intentional or documented?
Can the claimed input reach the vulnerable operation?
Do framework defaults invalidate the claim?
Is the severity realistic?
Is there a minimal safe reproduction?
Is contrary evidence present elsewhere?
Does the finding actually affect the primary source scope?

Disposition:

Confirmed.
Downgraded.
Rejected.
Duplicate.
Needs human/environment verification.

Routing:

Critical/high → Opus verifier.
Medium → Sonnet, escalating to Opus on disagreement.
Low/info → Sonnet.
Conflicting judgments → Opus adjudicator.
Systemic or release-blocking implications → Fable adjudication.

For high-severity findings, use two independent verifiers plus an adjudicator.

Phase 6 — Coverage and saturation check

The workflow must prove that it did not merely find a few interesting issues.

Calculate:

Primary files discovered versus processed.
Endpoints discovered versus reviewed.
High-risk endpoints versus Opus-reviewed.
Candidate findings versus verified findings.
Tests attempted versus completed.
Commands that failed for environmental reasons.
Untested paths and unresolved unknowns.
Supporting dependencies followed.
Findings by category and severity.

Run another search round focused on missed categories. Stop when:

All inventory items have a disposition.
All critical/high candidates have completed verification.
Two successive discovery rounds produce no materially new issue category; or
The budget is reached and remaining work is explicitly reported.

Phase 7 — Fable synthesis and verdict

Fable receives normalized evidence, not every raw agent transcript.

Required report:

Executive verdict.
Scope and exclusions.
Architecture and trust-boundary summary.
Coverage table.
Confirmed findings ordered by severity.
Rejected high-risk candidates, with reasons.
Test and tooling results.
Systemic themes.
Recommended remediation order.
Residual uncertainty.
Release recommendation.
Machine-readable findings appendix.

Permitted verdicts:

PASS
PASS_WITH_RESIDUAL_RISK
CONDITIONAL_PASS
FAIL
INCONCLUSIVE

The verdict must cite an explicit policy. A suggested default:

FAIL: any confirmed critical issue, or a high issue violating a release-blocking invariant.
CONDITIONAL_PASS: confirmed high issues with documented short-term controls.
PASS_WITH_RESIDUAL_RISK: only medium/lower issues, with acceptable coverage.
PASS: no release-blocking findings and all mandatory checks completed.
INCONCLUSIVE: insufficient coverage, broken environment, or unresolved critical evidence.

4. Execution procedure

Interactive Claude Code

Update Claude Code.
Open the repository root.
Confirm your plan supports Dynamic Workflows.
On Pro, enable Dynamic Workflows through /config.
Set the workflow-size guideline to small for the pilot.
Select Fable 5.1 as the session/orchestrator model.
Use manual or accept-edits permission mode for the pilot.
Submit the master prompt below.
Inspect the proposed phase plan and raw script.
Approve once.
Watch progress with /workflows.
Inspect model substitutions, token totals, failures, and verifier disagreements.
Save the successful workflow into .claude/workflows/.
Rerun it using its saved slash command.

Anthropic recommends beginning with a narrow slice because workflows can consume substantially more tokens than an ordinary session. The current size guidelines target fewer than 5, 15, or 50 agents for small, medium, and large runs respectively. Running and sizing workflows

For current versions:

/config workflowSizeGuideline=small
/model

Then submit the master prompt. If you want Claude to decide automatically when workflows are appropriate:

/effort ultracode

For a controlled audit, I prefer explicitly requesting one workflow instead of enabling ultracode for every substantive task.

Pilot progression

Run three levels:

Pilot: one endpoint cluster, fewer than five agents.
Calibration: roughly 10–20 representative endpoints, including one high-risk path.
Full audit: the complete primary directory, sized from the calibration results.

Do not scale up until you have checked false-positive rate, runtime, model routing, and cost from the calibration run.

Programmatic execution

For CI or repeatable automation, use the Claude Agent SDK. Dynamic Workflows require Claude Code 2.1.154 or newer; the documented Python SDK baseline is claude-agent-sdk >= 0.2.90. Allow the Workflow tool explicitly and stream progress/result messages. Agent SDK cookbook

Important operational differences:

Non-interactive runs do not show the workflow confirmation dialog.
Permission rules must allow Workflow or the saved workflow by name.
The literal ultracode trigger is not dependable for ordinary claude -p input; explicitly say “use a workflow.”
Use a saved workflow once the design is validated.
Never use bypass-permissions merely to simplify CI.
Provide only the minimum read and command permissions required.

5. Master prompt

Use a dynamic workflow to conduct a read-only, end-to-end correctness and risk audit of our API implementation.

Repository root: {{REPOSITORY_ROOT}} Primary source directory: {{PRIMARY_SOURCE_DIRECTORY}}

Every relevant file inside the primary source directory must be inventoried and reviewed. You may follow imports, middleware, schemas, services, repositories, tests, configuration, migrations, generated clients, and external-library usage outside that directory when necessary to understand in-scope behavior. Do not broaden the audit into a general review of those supporting libraries. Report an outside-scope defect only when it directly affects an in-scope API execution path.

Explicit exclusions: {{EXCLUSIONS}}

This is an analysis-only run. Do not edit source files, update dependencies, commit changes, open pull requests, or contact production systems.

Run only these approved commands: {{APPROVED_COMMANDS}}

Use only this test environment: {{TEST_ENVIRONMENT}}

Redact secrets, tokens, credentials, personal data, and proprietary payloads from all reports. If a required operation is not clearly authorized, record it as blocked rather than attempting it.

Languages and frameworks: {{STACK}}

API contract sources: {{API_SPEC_LOCATIONS}}

Critical business and security invariants: {{INVARIANTS}}

Repository-specific instructions: {{REPOSITORY_RULES}}

<model_routing> Use Claude Fable 5.1 for audit planning, architecture synthesis, orchestration, cross-cutting adjudication, and the final release verdict.

Use Claude Haiku 4.5 for mechanical file inventory, endpoint extraction, import indexing, log parsing, test-output normalization, and other high-volume structured processing.

Use Claude Sonnet 5 for routine endpoint tracing, ordinary correctness review, finding deduplication, and verification of medium- or lower-severity findings.

Use Claude Opus 5 for complex control flow, authorization, tenant isolation, concurrency, transactionality, subtle business invariants, security analysis, and independent verification of all critical or high-severity findings.

If a requested model is unavailable or substituted, record the requested model, actual model, affected stage, and impact on confidence. Do not silently perform every stage with the session model. </model_routing>

Before running the substantive audit, produce a preflight summary containing:

Resolved scope.
Detected build and test system.
Proposed phases.
Estimated endpoint, file, and agent counts.
Commands that will run.
Expected model allocation by phase.
Missing information or unsafe assumptions.
Estimated workflow size and token budget.

If essential information is missing, stop before launching the main workflow and ask me for it.

After preflight approval, execute these phases:

Inventory every in-scope file and API endpoint.
Build endpoint, middleware, dependency, data-flow, and trust-boundary maps.
Partition endpoints into risk-ranked work packages.
Run approved build, type, lint, test, contract, coverage, and security checks.
Audit all work packages in parallel across contract correctness, authentication, authorization, tenant isolation, validation, error handling, data leakage, concurrency, transactions, idempotency, external dependencies, resource controls, observability, compatibility, and test quality.
Require each candidate finding to include an exact execution path and source evidence.
Give every candidate finding to an independent verifier.
Give critical and high findings to two Opus verifiers and adjudicate disagreement independently.
Reject findings contradicted by middleware, framework behavior, configuration, or unreachable control flow.
Run coverage and saturation checks.
Have Fable synthesize the verified evidence and issue the final verdict.

The workflow must use deterministic discovery and accounting. Every relevant primary-scope file and endpoint must have a final status: reviewed, irrelevant with reason, blocked with reason, or unverified with reason.

<finding_standard> Do not report speculative pattern matches as confirmed defects.

Each finding must include:

Stable finding ID.
Title and category.
Proposed and final severity.
Confidence.
Affected endpoints.
Primary and supporting source locations.
Preconditions.
Complete execution path.
Expected behavior.
Actual behavior.
Concrete impact.
Evidence and counterevidence.
Relevant test or reproduction evidence.
Independent-verification result.
Minimal remediation direction.
A test that would prove the remediation.

Use these dispositions: confirmed, downgraded, rejected, duplicate, or needs-human-verification. </finding_standard>

Do not declare completion until:

Every in-scope endpoint has a disposition.
Every critical/high candidate has completed independent verification.
All approved checks have run or have a recorded blocker.
Coverage gaps and environmental limitations are explicit.
Two successive discovery passes produce no materially new issue category, unless the budget is exhausted.

Return:

Executive verdict: PASS, PASS_WITH_RESIDUAL_RISK, CONDITIONAL_PASS, FAIL, or INCONCLUSIVE.
Scope and exclusions.
Architecture and trust boundaries.
Coverage and completion metrics.
Confirmed findings ranked by severity.
Rejected critical/high candidates and rejection reasons.
Build, test, coverage, and analysis results.
Systemic themes.
Prioritized remediation plan.
Residual risks and unknowns.
Release recommendation and its explicit decision rule.
A machine-readable JSON findings appendix.

Save the workflow after a successful pilot so it can be rerun as a project command.

Workflow size guideline: {{SMALL_MEDIUM_OR_LARGE}} Maximum desired agents: {{AGENT_GUIDELINE}} Token or cost budget: {{BUDGET}} Wall-clock limit: {{TIME_LIMIT}}

6. Details I need from you

Please reply with:

The repository root and exact primary source directory.
Language, framework, and API style.
The safe build, test, lint, type-check, and coverage commands.
Whether local tests may use containers, databases, or outbound network access.
Where the intended API contract lives.
Your critical business/security invariants.
Whether the first job should be analysis-only or may also create tests.
Your preferred pilot budget: agent count, token/cost limit, or wall-clock limit.

With those answers, the placeholders can be replaced and the pilot scope and release rubric made specific to your codebase.

pmp/workflow.md

Select an option

No results found