FactorBeam

Standalone article · part of a sequenced guide

What you'll unlock: A production workflow is a documented five-stage pipeline with validation, idempotency, and human-in-the-loop at the right gate — build a portfolio of these instead of reinventing prompts from memory.

View full guideNew here? Start Chapter 1
Tool guideChapter 9 of 10

Production-Grade Workflows

~110 min read

The end-to-end workflow patterns that make Claude a genuine productivity infrastructure — not just a tool you open, but a system you run

Chapter context

Teams adopt Claude individually — great demos, no compounding. Workflows without documentation don't survive handoffs or audits.Chapter 9 gives operators and leads a workflow operating system so Claude becomes team infrastructure, not personal magic.

Is this chapter for you?

Is the same task run weekly by multiple people?

Yes — document as production workflow (Concept 1); pick domain playbook (2–4).

Does output leave the organization (email, client doc, PR comment)?

Yes — mandatory HITL gate and output validation (1.5, 1.6).

Do workflows touch live data or production systems?

Yes — idempotency (1.4), read-only MCP default, human apply for deploys (4.7, 4.8).

Is the team rebuilding prompts from Slack memory?

Yes — start workflow portfolio registry (1.8) with three pilot workflows.

Chapters 4–8 taught prompting, Projects, MCP, and Claude Code. Chapter 9 turns those pieces into repeatable systems — the layer that makes Claude productivity infrastructure for teams.Whether you write content, analyze decisions, or ship code, the same five-stage anatomy applies. This chapter gives you the design principles and four workflow libraries to copy.

Chapter insight

A production workflow is a documented five-stage pipeline with validation, idempotency, and human-in-the-loop at the right gate — build a portfolio of these instead of reinventing prompts from memory.

Reference diagrams

Five-stage workflow anatomy

Every production workflow: trigger → input prep → Claude → output handling → downstream action.

TriggerEvent / scheduleStart
Input prepClean + chunkETL
ClaudeProject + toolsModel
ValidateSchema + HITLGuard
DownstreamSend / storeAct

Workflow portfolio layers

Design principles → domain libraries (content, analysis, technical) → shared Projects and MCP.

Principles1.1–1.8Design
Content2.1–2.8Comms
Analysis3.1–3.8Decide
Technical4.1–4.8Build

Implementation paths

Principles → three workflow libraries → portfolio mindset.

Production WorkflowsDesign principlesConcept 1 — 1.1–1.8Five stagesAnatomyHITL + idempotencyReliabilityContent & commsConcept 2 — 2.1–2.8Brief-to-draftPipelineEmail + meetingsMCPAnalysis & decisionsConcept 3 — 3.1–3.8Strategy + comp intelFrameRisk + financeQuantTechnicalConcept 4 — 4.1–4.8PR review + debugDaily engIncident + IaCOps

Concept 1

Workflow Design Principles

The design thinking behind effective Claude workflows — what makes a workflow robust, repeatable, and scalable

1.1

What a production workflow is

The difference between a one-off prompt and a repeatable system that delivers consistent output

Key takeaway

A production workflow is a documented, repeatable pipeline — trigger → prepared inputs → configured Claude step(s) → validated output → downstream action — not a clever prompt you remember.

Why this matters

One-off prompts don't scale across people, weeks, or handoffs; workflows do.

A one-off prompt: 'write me a QBR summary.' A production workflow: weekly trigger pulls metrics CSV, Project instructions define tone and sections, output lands in Notion template, human approves before Slack post.

Production bar — that's the difference from demo magic.

Workflow — do this next

  1. 01Name the workflow and owner.
  2. 02Define trigger (schedule, event, manual).
  3. 03Document inputs, Claude config, output schema.
  4. 04Run twice; compare outputs for drift.

1.2

The workflow anatomy

Trigger, input preparation, Claude configuration, output handling, and downstream action — the five stages every workflow shares

Key takeaway

Every robust workflow has five stages: trigger, input prep, Claude config (model, tools, instructions), output handling (parse, validate, store), downstream action (send, ticket, deploy).

Why this matters

Teams that skip stages get fragile pipelines — usually at input prep or output validation.

Trigger: cron, webhook, form submit, 'new PR opened'. Input prep: gather files, strip PII, chunk to context budget, attach schema. Claude config: Project, system prompt, MCP tools, temperature. Output: JSON schema, markdown sections, artifact. Downstream: email draft queue, Jira comment, git commit.

Workflow — do this next

  1. 01Draw five boxes for your workflow.
  2. 02Fill each box with concrete tool + owner.
  3. 03Identify the weakest stage (usually validation).

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Five-stage workflow canvas

TRIGGER: [event / schedule]
INPUT PREP: [sources, cleaning, chunking]
CLAUDE CONFIG: [model, Project, tools, prompt template]
OUTPUT HANDLING: [format, validation, storage]
DOWNSTREAM: [who/what acts on result]

1.3

Workflow failure modes

The points where workflows break — input variation, context limits, output format drift, and downstream dependency failures

Key takeaway

Workflows break at: messy inputs, context overflow, format drift (JSON → prose), hallucinated facts, and downstream APIs rejecting malformed payloads.

Why this matters

Knowing failure points lets you add guards before production, not after an incident.

Input variation: empty fields, new file types, renamed columns. Context limits: dumping 200-page PDF. Format drift: asked for JSON, got markdown fences. Downstream: Slack message too long, invalid GitHub review format.

Mitigate: input validators, summarization pre-step, structured output + parser retry, dry-run downstream in staging.

Workflow — do this next

  1. 01List last three workflow failures.
  2. 02Map each to a stage (1.2).
  3. 03Add one guard per failure class.

1.4

Idempotency in Claude workflows

Designing workflows that produce the same result when run twice — the reliability principle

Key takeaway

Idempotent workflows: deterministic inputs, versioned prompts, temperature 0 for extraction, dedupe keys on downstream writes — re-run safe without duplicate emails or double tickets.

Why this matters

Retries are inevitable (API timeouts, human 'run again'); non-idempotent workflows corrupt state.

Use content hashes or record IDs in downstream actions. Store 'last processed' cursor. For generative steps, separate extraction (idempotent) from creative (versioned, human-approved).

Workflow — do this next

  1. 01Ask: what happens if this runs twice today?
  2. 02Add idempotency key to writes.
  3. 03Pin prompt version in workflow doc.

1.5

Human-in-the-loop design

Where to put the human review step — the decision that determines how autonomous a workflow can safely be

Key takeaway

Place human review where error cost exceeds automation savings — external sends, financial figures, legal language, production deploys. Automate everything before and after that gate.

Why this matters

Wrong HITL placement either blocks velocity (review everything) or creates liability (review nothing).

High autonomy: internal research summaries, draft outlines, code suggestions on branch. Medium: client emails, competitive reports. Low: contract redlines, pricing changes, incident remediation without approval.

Review queue pattern beats paste-and-pray in chat.

Workflow — do this next

  1. 01Classify workflow output: internal / external / regulated.
  2. 02Set review gate per class.
  3. 03Measure time saved vs review burden.

1.6

Error handling and fallback design

What the workflow does when Claude produces unexpected output — the resilience layer

Key takeaway

Define fallbacks: schema validation failure → retry with repair prompt; empty extraction → escalate to human; tool timeout → partial result + alert; refusal → log and route to manual queue.

Why this matters

Silent failures are worse than loud ones — workflows need explicit unhappy paths.

Pattern: validate output against JSON schema or checklist → on fail, one structured retry ('fix JSON only') → on second fail, notify owner with raw output attached. Never auto-send unvalidated external content.

Workflow — do this next

  1. 01Define success criteria machine-checkable.
  2. 02Write retry prompt for format repair.
  3. 03Wire alert channel for hard failures.

Real example

JSON drift — two-strike fallback

Workflow expected { risks: [] }. Claude returned prose. Parser failed → retry with 'output JSON only'. Second failure → PagerDuty-lite Slack ping to workflow owner with session link.

1.7

Workflow documentation

How to document a Claude workflow so someone else can run it, audit it, or improve it

Key takeaway

Workflow doc includes: purpose, owner, trigger, inputs with examples, Claude config snapshot, output schema, downstream steps, failure runbook, last tested date, prompt version.

Why this matters

Undocumented workflows die when the builder leaves — or get 'improved' into breakage.

Store in repo WORKFLOWS/ or Notion database. Link Project ID, MCP servers used, model tier (Ch 2). Include redacted input/output samples for auditors.

Workflow — do this next

  1. 01Copy workflow doc template (Ch 9 artifact).
  2. 02Fill after first successful production run.
  3. 03Review quarterly or when prompt changes.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Workflow documentation template

# Workflow: [name]
Owner: | Last tested: | Prompt v:

## Purpose
## Trigger
## Inputs (with example)
## Claude configuration
Project / model / tools / temperature

## Steps (numbered)
## Output schema
## Downstream actions
## Failure runbook
## Idempotency notes
## Change log

1.8

The workflow portfolio mindset

Building a library of tested workflows rather than recreating good prompts from memory every time

Key takeaway

Treat workflows like a product portfolio — catalog by function, maturity (experimental → production), owner, and ROI; retire duplicates; promote winners with shared templates.

Why this matters

Memory-based prompting doesn't compound; a portfolio does.

Start registry: Content, Analysis, Technical tabs. Tag: MCP-required, HITL-level, model tier. New hire runs 'weekly competitive brief' from doc, not Slack archaeology.

Connect to Ch 6 Projects — one Project per production workflow family with pinned instructions and knowledge files.

Workflow — do this next

  1. 01Inventory existing Claude habits → name as workflows.
  2. 02Mark maturity: draft / pilot / production.
  3. 03Kill two redundant workflows this quarter.

Concept 2

Content & Communication Workflows

The end-to-end workflows for writing, editing, and communication — with detailed examples and the exact prompts that make them work

2.1

The content brief-to-draft workflow

Brief → research → outline → draft → edit → format — the complete pipeline with example prompts at each stage

Key takeaway

Six-stage pipeline: brief validation → targeted research → outline approval → section draft → edit pass → format for channel — never skip outline on long-form.

Why this matters

Skipping stages produces polished prose on the wrong thesis.

Stage prompts: (1) 'Validate brief: audience, goal, constraints, missing info.' (2) 'Research: 5 sources, cite URLs, flag gaps.' (3) 'Outline: H2s with one-line thesis each — stop for approval.' (4) 'Draft section 2 only.' (5) 'Edit for clarity, cut 15%, flag claims needing citation.' (6) 'Export as markdown + meta description.'

Workflow — do this next

  1. 01Load brief into Project with brand voice file.
  2. 02Run stages as separate messages (context hygiene).
  3. 03Human approves outline before draft.

Real example

Stage 3 — outline prompt

Given the approved brief below, produce an outline only. For each H2: thesis sentence, 3 bullet supports, estimated word count. Do not draft prose. Brief: [...]

2.2

The email management workflow

Inbox → priority triage → draft responses → send queue — connected to Gmail via MCP

Key takeaway

MCP Gmail workflow: fetch unread → classify (urgent/reply-later/FYI) → draft replies in your voice → queue for human send — never auto-send external mail in v1.

Why this matters

Email is high-stakes; triage + draft saves hours while HITL prevents embarrassment.

MCP Gmail Prompt: 'Triage last 20 unread: table with sender, topic, priority 1-3, suggested action. Draft replies only for priority 1-2; match tone samples in Project.'

Workflow — do this next

  1. 01Connect Gmail MCP read + draft scopes.
  2. 02Add 3 sent-email tone samples to Project.
  3. 03Morning: triage → review drafts → send.

2.3

The meeting intelligence workflow

Recording → transcript → summary → action items → calendar updates → Slack notification

Key takeaway

Pipeline: transcript upload → structured summary (decisions, risks, open questions) → action items with owner/due → optional MCP to Slack/calendar — validate names and dates.

Why this matters

Meeting notes fail when action items lack owners; structure fixes that.

Prompt after transcript: 'Output: (A) 5-bullet executive summary, (B) decisions table, (C) action items: owner | task | due | dependency, (D) follow-up meeting agenda if needed.' Human fixes wrong attendee attribution before Slack post via MCP.

Workflow — do this next

  1. 01Standardize recording → transcript tool.
  2. 02Run summary prompt in Project with attendee list.
  3. 03Human verify action items; MCP post to #team.

2.4

The report writing workflow

Data input → analysis → narrative → visualisation → formatted document — end to end with examples

Key takeaway

Feed data (CSV, metrics export) → Claude analyzes trends and anomalies → narrative sections → chart specs or code → assemble in artifact/Google Doc template.

Why this matters

Reports need numbers-grounded narrative — separate analysis from prose to reduce hallucination.

Step 1: 'List metrics, deltas, anomalies only — table format, cite row numbers.' Step 2: 'Write executive summary from table only — no new numbers.' Step 3: 'Suggest 3 chart types with axis labels.' Use code execution for charts when enabled.

Workflow — do this next

  1. 01Upload sanitized data to Project.
  2. 02Run analysis pass; human spot-check figures.
  3. 03Narrative + charts → final template.

2.5

The content repurposing workflow

One long-form piece → LinkedIn posts, newsletter, slides, and Twitter thread — the multi-format pipeline

Key takeaway

Single source article → extract core thesis + 5 proof points → parallel format passes (LinkedIn hook style, newsletter intro, slide titles, thread numbering) — shared fact sheet prevents drift.

Why this matters

Repurposing without a shared fact sheet invents new claims per channel.

Create FACT_SHEET.md: thesis, quotes, stats with sources, CTA. Then: 'LinkedIn: 3 posts, hook-first, 1200 chars max, from FACT_SHEET only.' Repeat per channel with format rules in Project instructions.

Workflow — do this next

  1. 01Generate fact sheet from long-form.
  2. 02Human approve facts once.
  3. 03Run per-channel format prompts.

2.6

The research synthesis workflow

Multiple sources → extraction → comparison → synthesis → cited output — with document upload and web search

Key takeaway

Upload PDFs + enable web search → per-source extraction template → comparison matrix → synthesis with inline citations → bibliography — require 'insufficient evidence' flag when thin.

Why this matters

Research workflows fail when synthesis invents bridges between sources.

Extraction prompt: 'For each source: claim | evidence quote | page/URL | confidence.' Comparison: 'Matrix of claims vs sources.' Synthesis: 'Answer question X; every sentence tagged [S1] or [WEB].'

Workflow — do this next

  1. 01Chunk large PDFs if needed (Ch 5).
  2. 02Run extraction per source batch.
  3. 03Human spot-check citations before publish.

2.7

The proposal workflow

Brief → competitive context → structure → draft → review → formatted output — with client Project configuration

Key takeaway

Client-specific Project: tone, case studies, pricing rules → intake brief → competitive landscape table → section outline → draft → legal/commercial review → branded PDF/markdown export.

Why this matters

Proposals mix creativity and compliance — Project encodes what must not change.

Never let Claude invent pricing or legal terms — reference approved snippets from Project knowledge. Prompt: 'Draft Section 3 Approach only; use case study B; flag assumptions.'

Workflow — do this next

  1. 01Create Project per client or vertical.
  2. 02Load approved case studies + boilerplate.
  3. 03Partner review before client send.

2.8

The editorial calendar workflow

Strategy → topic generation → brief creation → scheduling — with Notion integration

Key takeaway

Quarterly themes → Claude generates topic backlog scored by ICP fit → brief template per topic → MCP writes rows to Notion calendar with status, owner, publish date.

Why this matters

Calendars die without brief quality; automation should create briefs, not just titles.

Prompt: 'Given ICP doc and Q3 theme, propose 12 topics: title | angle | funnel stage | effort 1-5.' Approved topics → 'Fill brief template for topic 4.' Notion MCP creates database entries.

Workflow — do this next

  1. 01Define theme + ICP in Project.
  2. 02Generate and rank topic batch.
  3. 03MCP push approved briefs to Notion.

Concept 3

Analysis & Decision Workflows

The workflows that make Claude a genuine analytical partner — structured approaches to complex thinking tasks

3.1

The strategic analysis workflow

Problem framing → framework selection → analysis → options → recommendation — with structured prompting at each stage

Key takeaway

Five-step strategy workflow: frame problem (success metrics, constraints) → pick framework (SWOT, Porter, jobs-to-be-done) → analyze with evidence → generate 3 options → recommendation with risks — one stage per message.

Why this matters

Monolithic 'analyze our strategy' prompts produce generic McKinsey cosplay.

Stage 1: 'Restate problem; list unknowns; define decision deadline.' Stage 2: 'Pick framework; justify fit.' Stage 3: 'Apply framework using only attached data.' Stage 4: 'Three options with trade-offs.' Stage 5: 'Recommend one; dissenting view; next 30 days.'

Workflow — do this next

  1. 01Attach market data and internal metrics.
  2. 02Human picks framework at stage 2.
  3. 03Challenge recommendation in follow-up pass.

3.2

The competitive intelligence workflow

Inputs → extraction → comparison matrix → gap analysis → strategic implications

Key takeaway

Collect competitor pages, reviews, pricing, changelogs → structured extraction per competitor → feature/pricing matrix → gap analysis → 'so what' for product and GTM.

Why this matters

Comp intel without a matrix becomes a narrative without comparability.

Extraction fields: positioning, ICP, pricing model, key features, weaknesses, recent moves. Matrix columns: competitors; rows: dimensions. Final: 'Implications for our roadmap — prioritized list.'

Workflow — do this next

  1. 01Refresh sources monthly.
  2. 02Web search + uploads in Project.
  3. 03Product lead validates matrix cells.

3.3

The data interpretation workflow

Raw data → cleaning → analysis → insight extraction → narrative — with code execution enabled

Key takeaway

Upload CSV → Claude cleans (with code) → runs analysis → outputs insight table (metric, delta, significance, hypothesis) → executive narrative strictly from table.

Why this matters

Separating computation from narrative keeps numbers honest.

Code execution Prompt: 'Show code for each transform. Insights must reference computed values only.'

Workflow — do this next

  1. 01Provide data dictionary.
  2. 02Review code before trusting insights.
  3. 03Export charts + narrative artifact.

3.4

The document review workflow

Document upload → extraction → flagging → summary → action items — with examples from contracts, reports, and policies

Key takeaway

Review template by doc type: contracts (obligations, dates, liability), reports (claims vs evidence), policies (ambiguity, conflicts) → flagged clauses → summary → owner action items.

Why this matters

Generic 'summarize this' misses risk-bearing clauses.

Contract prompt: 'Table: clause | plain English | risk level | question for counsel.' Policy: 'List conflicting statements with section refs.' Human counsel reviews high-risk flags only.

Workflow — do this next

  1. 01Select review rubric for doc type.
  2. 02Chunk long docs (Ch 5).
  3. 03Route flags to specialist reviewer.

3.5

The decision framework workflow

Decision context → criteria definition → option evaluation → recommendation → rationale — the structured decision support pattern

Key takeaway

Define decision, stakeholders, criteria with weights → score options with evidence → sensitivity on weights → recommendation + what would change the decision.

Why this matters

Weighted criteria make disagreement explicit and auditable.

Prompt: 'Build decision matrix: criteria (weight %), options (score 1-5 with evidence column). Show weighted totals. List kill criteria — conditions that veto an option.'

Workflow — do this next

  1. 01Facilitator sets criteria with group.
  2. 02Claude scores; humans adjust scores.
  3. 03Document dissent in decision log.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Decision matrix prompt

Decision: [question]
Options: A, B, C
Criteria (weights must sum 100%): ...
For each cell: score 1-5 + one-line evidence
Output: weighted table, winner, sensitivity if top weights ±10%, kill criteria check

3.6

The scenario planning workflow

Strategic question → scenario generation → implication mapping → response planning — with structured output

Key takeaway

Strategic question → 3-4 scenarios (name, trigger, timeline, key dynamics) → implication map per scenario (revenue, ops, talent) → playbook actions per scenario → early warning signals.

Why this matters

Scenarios without implication maps are creative writing, not planning.

Output schema: Scenario | Probability band | Triggers | Implications by function | Prepared responses | Leading indicators.

Workflow — do this next

  1. 01Anchor on one strategic uncertainty.
  2. 02Leadership stress-tests scenarios.
  3. 03Store in planning Project for quarterly refresh.

3.7

The financial modelling workflow

Assumptions → model structure → calculation → sensitivity analysis → narrative — with code execution and artifact output

Key takeaway

Document assumptions table → Claude builds spreadsheet-style model in code → base/bear/bull → sensitivity tornado → narrative for CFO with assumption caveats.

Why this matters

Models fail when assumptions are buried; force explicit assumption block first.

Step 1: assumptions only — human approves. Step 2: build model, show formulas. Step 3: sensitivity on top 3 drivers. Step 4: 'Investor narrative — no new numbers.' Export artifact CSV.

Workflow — do this next

  1. 01Lock assumptions before calculation.
  2. 02CFO validates formula logic.
  3. 03Version model with date stamp.

3.8

The risk assessment workflow

Domain → risk identification → likelihood/impact scoring → mitigation options → register output

Key takeaway

Domain context → risk register draft (ID, description, category, L×I score, owner, mitigation, residual risk) → facilitation session edits → export to GRC tool or spreadsheet.

Why this matters

Risk workshops need a pre-read register; Claude accelerates draft, humans own scores.

Prompt: 'Identify risks for [launch/system/vendor]. Use 5×5 L/I. Mitigations must be actionable with owner role, not generic monitor.' Output markdown table for workshop.

Workflow — do this next

  1. 01Provide architecture or launch plan doc.
  2. 02Generate draft register.
  3. 03Workshop scores; update register.

Concept 4

Technical & Development Workflows

The workflows that connect Claude to code, data, and technical systems — production patterns for builders and technical teams

4.1

The code review workflow

PR description → code diff → review criteria → structured feedback → GitHub comment — end to end

Key takeaway

PR context + diff (via MCP GitHub or paste) → review rubric (security, tests, API breaks, style) → structured comment: severity-tagged findings → human editor posts or approves.

Why this matters

Unstructured reviews miss severity; templates make CI/agent review useful.

Prompt: 'Review PR #N. Output: Summary | Blockers | Suggestions | Questions. Tag each [BLOCKER|MAJOR|NIT]. Cite file:line.' GitHub MCP posts draft comment; human sends.

Combine with Ch 8 — Claude Code can fix blockers on a branch after human approves findings.

Workflow — do this next

  1. 01Define team review rubric in Project.
  2. 02Connect GitHub MCP read + comment draft.
  3. 03Human posts; never auto-approve merge.

4.2

The API integration workflow

API documentation → requirements → code generation → testing → documentation — with Claude Code

Key takeaway

OpenAPI/spec + requirements → Claude Code scaffolds client, error handling, retries → unit + integration tests → README with examples — TASK.md bounds scope.

Why this matters

API integrations are spec-driven — ideal for agent implementation with test gates.

TASK.md: endpoints needed, auth method, idempotency, rate limits, must-not-touch modules. Agent generates; human reviews auth secret handling and error taxonomy.

Workflow — do this next

  1. 01Attach OpenAPI to Project or repo.
  2. 02Claude Code on feature branch.
  3. 03Integration test against sandbox.

4.3

The data pipeline workflow

Source specification → transformation logic → code generation → testing → deployment

Key takeaway

Spec: sources, schema, SLAs, PII rules → transformation steps in plain language → Claude Code generates pipeline + data tests → dry-run → deploy with human approval.

Why this matters

Data bugs are silent — tests on row counts, null rates, and key uniqueness are mandatory.

Include sample rows (sanitized). Require: great expectations or dbt tests, rollback plan. Review joins and timezone handling explicitly.

Workflow — do this next

  1. 01Write pipeline spec in TASK.md.
  2. 02Generate + run tests locally.
  3. 03Deploy to staging; compare checksums.

4.4

The debugging workflow

Error message → codebase context → diagnosis → fix → test → documentation

Key takeaway

Repro package: stack trace, logs, env, recent commits → Claude Code traces call path → root cause hypothesis → fix + regression test → one-line changelog entry.

Why this matters

This is Ch 8 bug workflow operationalized as a team SOP with documentation step.

Add post-fix: 'Update RUNBOOK.md with symptom → cause → fix for on-call.' Prevents same incident twice.

Workflow — do this next

  1. 01Paste error into TASK with repro.
  2. 02Require root cause in PR description.
  3. 03Merge only with regression test.

4.5

The architecture decision workflow

Requirements → option generation → trade-off analysis → recommendation → ADR document

Key takeaway

Requirements doc → 3 architecture options → trade-off table (cost, latency, ops, risk) → recommendation → ADR markdown in docs/adr/ — human architecture review before build.

Why this matters

ADRs capture why; agents accelerate option generation and first draft.

Prompt in Project with constraints: 'Options must include boring default. Table: option | pros | cons | when to choose.' Output ADR template: Context, Decision, Consequences.

Workflow — do this next

  1. 01Gather NFRs and constraints.
  2. 02Generate options + ADR draft.
  3. 03Tech lead signs ADR; then TASK for build.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

ADR output template

# ADR-NNN: [title]
## Status: Proposed
## Context
## Decision
## Options considered
## Consequences
## Follow-ups

4.6

The SQL workflow

Business question → schema context → query generation → result interpretation → insight narrative

Key takeaway

Business question + schema DDL/sample → Claude writes SQL with comments → human runs in read-only warehouse → results back → insight narrative with caveats on sample bias.

Why this matters

SQL workflow separates write (reviewable) from execute (controlled) from interpret.

MCP database read-only where available. Prompt: 'Explain query plan assumptions. Flag full table scans. If ambiguous schema, ask before guessing joins.'

Workflow — do this next

  1. 01Load schema doc in Project.
  2. 02Review SQL before production run.
  3. 03Narrative cites result columns only.

4.7

The infrastructure-as-code workflow

Requirements → template generation → validation → deployment → documentation

Key takeaway

Infra requirements → Terraform/Pulumi module draft → validate/plan in CI → human apply → README with diagram and rollback — never auto-apply from chat.

Why this matters

Infra mistakes are expensive; plan-only automation with human apply is the floor.

Claude Code generates modules; CI runs terraform plan; human reviews diff for security groups, public exposure, IAM scope. Document inputs/outputs.

Workflow — do this next

  1. 01Spec resources and environments.
  2. 02Generate IaC on branch.
  3. 03Plan in CI; apply manually.

4.8

The incident response workflow

Alert → context gathering → diagnosis → remediation steps → post-mortem draft — with PagerDuty and GitHub integration

Key takeaway

Alert via PagerDuty MCP → gather logs, recent deploys, dashboards (links in Project) → timeline + hypothesis → remediation checklist → post-mortem draft (5-whys, action items) — human commands all production changes.

Why this matters

Incidents need speed with guardrails — automate context, not remediation clicks.

Workflow: on-call pastes alert → Claude pulls GitHub recent merges + runbook → suggests checks ranked by likelihood → drafts comms template → after resolution, post-mortem skeleton. MCP: PagerDuty acknowledge notes, GitHub blame.

Workflow — do this next

  1. 01Maintain RUNBOOK.md + service map in Project.
  2. 02Use read-only MCP during triage.
  3. 03Human executes remediation; Claude drafts PM.

Real example

Incident context prompt

Alert: elevated 5xx on checkout API. Gather: deploys last 2h, error log patterns, dependency status. Output: timeline table, top 3 hypotheses with checks, draft status page text — no shell commands executed.

Concept 5

Cross-Surface Workflows

End-to-end workflows combining Skills, vision, Chrome, Cowork, computer use, and connectors

5.1

Skill-powered document workflow

Brief → research skill → pptx/docx skill → human QA → MCP publish to Drive/SharePoint

Key takeaway

Chain: Project brief → research skill with citations → document skill for deck → human QA → MCP upload to Drive or SharePoint.

Why this matters

Demonstrates Skills + MCP production pattern from Ch 1 and Ch 8.

Prompt: 'Run competitive-brief skill then pptx skill using BRAND.md.' Export artifact. MCP write to folder only after HITL tier T2 pass.

Workflow — do this next

  1. 01Enable skills + Drive MCP.
  2. 02Run pipeline on synthetic data first.
  3. 03Production with citation QA gate.

5.2

Vision + connector workflow

Screenshot → vision extraction → Jira ticket → Slack notification

Key takeaway

Capture UI bug screenshot → vision extracts repro steps → GitHub/Jira MCP creates ticket → Slack MCP drafts #eng post — human submits.

Why this matters

Common eng/QA path — ties Ch 3 vision to Ch 7 connectors.

Mobile capture → desktop Project continuation. Vision: structured repro table. MCP: create issue with image link. Slack: draft only.

Workflow — do this next

  1. 01Photo → upload to Project.
  2. 02Vision extraction prompt.
  3. 03MCP ticket + Slack draft.

5.3

Claude in Chrome — portal workflow

Legacy web portal data extraction, form assist, and competitive site research with approval gates

Key takeaway

Chrome extension: navigate SSO portal → extract table → artifact CSV → verify → internal wiki — step-by-step approval on submit actions.

Why this matters

Ch 1 introduced Chrome — this is the operational workflow.

Use low-risk account. Prompt: 'Extract visible table only; do not submit forms.' For submissions: explicit per-field approval. Log portal URL in artifact.

Workflow — do this next

  1. 01List 5 portal tasks without API.
  2. 02Pilot lowest-risk extraction.
  3. 03Document CAPTCHA/2FA blockers.

Real example

Procurement — vendor quote portal

Chrome agent extracted quote line items from vendor portal into CSV artifact. Human verified against PDF email. Saved 45 min copy-paste — no auto-submit used.

5.4

Cowork multi-app workflow

Email → spreadsheet → file system → calendar — desktop automation with plugins

Key takeaway

Cowork: intake email summary → update Excel model → save to folder → calendar hold — plugin provides MCP glue; human approves writes.

Why this matters

EA/ops workflows span apps — Cowork is the intended surface.

Number steps across apps before starting. Use read steps to validate state before write. Record macro failures for IT.

Workflow — do this next

  1. 01Map apps and accounts.
  2. 02Install Cowork plugin bundle.
  3. 03Pilot read-only full path first.

5.5

Computer use — controlled ops workflow

VM sandbox, legacy desktop app automation, and incident reproduction

Key takeaway

Computer use in VM: reproduce bug in legacy app → screenshot log → artifact steps → engineer handoff — max steps capped.

Why this matters

API-less internal tools need computer use with strict sandbox.

Dedicated VM snapshot. No credentials in prompt. Session recording on. Escalate to human if unexpected dialog.

Workflow — do this next

  1. 01Snapshot clean VM.
  2. 02Define max 15 steps.
  3. 03Engineer validates repro doc.

5.6

Extended thinking — executive decision workflow

Complex decision memo with thinking enabled — options, kill criteria, sensitivity

Key takeaway

Enable thinking → structured decision prompt (Ch 9.3.5) → critique pass → board artifact — thinking surfaces trade-offs invisible in fast mode.

Why this matters

Cross-chapter tie: thinking + analysis workflows.

Load decision context docs to Project. Thinking on. Output decision matrix artifact. Separate critic message before export.

Workflow — do this next

  1. 01Tag thread EXEC-DECISION.
  2. 02Enable thinking.
  3. 03Two-pass critique before export.

5.7

API + Skills customer-facing workflow

Product feature using Messages API + workspace skills + MCP tools

Key takeaway

Customer feature: API hosts skill-enabled agent + your MCP tools + caching on policy doc — eval before ship.

Why this matters

Bridges Ch 2 API economics to Ch 8 agent building.

Cache stable policy prefix. Attach workspace skills. Tool use for user-specific data only. Log skill invocations for debug.

Workflow — do this next

  1. 01Staging eval with golden questions.
  2. 02Load test with cache on.
  3. 03Progressive rollout with kill switch.

5.8

Cloud-deployed agent workflow

Bedrock/Vertex agent with IAM, VPC, and connector proxy — enterprise deployment pattern

Key takeaway

Bedrock/Vertex: Claude in VPC → internal MCP proxy → corporate IAM → audit to SIEM — no direct internet tool access without proxy policy.

Why this matters

Enterprise agents require cloud chapter patterns in practice.

MCP proxy inside VPC. Secrets from vault. Model via Bedrock with CloudWatch. Skills deployed via approved pipeline.

Workflow — do this next

  1. 01Architecture review with security.
  2. 02Deploy MCP proxy HA pair.
  3. 03Pen test before prod traffic.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Workflow registry entry

One row per production workflow in your team catalog.

Name: Weekly competitive brief
Owner: PM | Maturity: Production
Trigger: Monday 8am | Model: Sonnet
MCP: Web search, Notion write
HITL: Human approves before Notion publish
Prompt version: v3.2 | Last tested: 2026-06-15
ROI: ~2h/week analyst time saved

HITL classification guide

AUTONOMOUS OK: internal drafts, research extracts, branch code suggestions
REVIEW REQUIRED: client-facing copy, financial figures, legal flags
HUMAN EXECUTES: production deploy, send email, merge PR, incident remediation

Five-stage workflow canvas

TRIGGER: [event / schedule]
INPUT PREP: [sources, cleaning, chunking]
CLAUDE CONFIG: [model, Project, tools, prompt template]
OUTPUT HANDLING: [format, validation, storage]
DOWNSTREAM: [who/what acts on result]

Workflow documentation template

# Workflow: [name]
Owner: | Last tested: | Prompt v:

## Purpose
## Trigger
## Inputs (with example)
## Claude configuration
Project / model / tools / temperature

## Steps (numbered)
## Output schema
## Downstream actions
## Failure runbook
## Idempotency notes
## Change log

Decision matrix prompt

Decision: [question]
Options: A, B, C
Criteria (weights must sum 100%): ...
For each cell: score 1-5 + one-line evidence
Output: weighted table, winner, sensitivity if top weights ±10%, kill criteria check

ADR output template

# ADR-NNN: [title]
## Status: Proposed
## Context
## Decision
## Options considered
## Consequences
## Follow-ups

B2B marketing team — from prompts to portfolio

12-person marketing org used Claude ad hoc — strong writers, inconsistent quality, no audit trail, duplicate effort on repurposing and reports.

Before

Slack prompt pins, no workflow docs, accidental off-brand client draft sent once, 6h/week reinventing research synthesis.

After

Workflow portfolio in Notion: brief-to-draft (2.1), repurposing (2.5), editorial calendar (2.8). Gmail MCP triage with send queue. Registry with owners; quarterly prompt version review.

  • Content production cycle → 40% faster on long-form
  • Off-brand external sends → zero post-HITL policy
  • Repurposing time per article → 4h to 45min
  • New hire time-to-first-published → 3 weeks to 5 days

What goes wrong

One giant prompt for entire pipeline.

Split into stages with validation between (1.2, 2.1).

Auto-send external content without review.

HITL queue pattern (1.5); classify outputs.

MCP writes duplicate records on retry.

Idempotency keys and cursors (1.4).

Workflow knowledge lives in one person's head.

Workflow doc template + portfolio registry (1.7, 1.8).

Portrait of Krishna Kumar, Curator

Vetted by Krishna KumarCurator, FactorBeam

Discussion

Discussion coming soon

Shared comments for this playbook are not live yet. When they are, you'll be able to ask questions, share what worked, and see replies from other readers.