Standalone article · part of a sequenced guide
What you'll unlock: Schedule only tested Skills — time, event, and condition triggers each need different guardrails; pipelines fail loud with manifest handoffs, not silent mega-prompts.
Scheduling Skills on Autopilot
The automation layer — how to schedule Skills to run without you, what triggers them, and how to manage the results
Chapter context
You have Skills that pass manual tests — but you still open Cowork every Monday to kick off the same chain. Chapter 3 is how scheduled automation replaces heroic calendar rituals.The scheduling mindset inventory (§1.8) and eight workflow templates (Concept 2) give you copy-paste designs; pipelines (Concept 3) show how to chain Skills without rebuilding monolithic prompts.
Is this chapter for you?
Does this task happen on a predictable cadence with stable inputs?
Start with time-based schedule (§1.2) — stagger away from other heavy jobs.
Does work arrive unpredictably when files land in a folder?
Event trigger with debounce + idempotency (§1.3) — inbox workflow (§2.2).
Does upstream export timing vary but a flag signals readiness?
Condition trigger (§1.4) — avoid empty cron runs.
Are multiple Skills involved in one operational SOP?
Build pipeline with manifest handoffs (§3.3) — fail-fast default (§3.5).
Chapters 1–2 gave you the COO mental model and Skills as contracts. Chapter 3 turns contracts into autopilot — workflows that run while you focus on work only you can do.You will master trigger types, eight reference autopilot workflows, and Skill pipelines from intelligence briefings to inbox-to-action and data-to-decision.
Chapter insight
Schedule only tested Skills — time, event, and condition triggers each need different guardrails; pipelines fail loud with manifest handoffs, not silent mega-prompts.
Reference diagrams
Three trigger types
Pick trigger by how work arrives — not by what's easiest in the UI.
Skill pipeline DAG
One TAR per node — manifest handoffs between steps.
Implementation paths
Night shift runs Cowork; morning triage runs you — three minutes on dashboard + history.
Concept 1
Scheduling Foundations
How Cowork scheduling works — the mechanics before you set your first automated run
1.1
What scheduling means in Cowork
Running a Skill automatically based on time, event, or condition — the three trigger types
Key takeaway
Scheduling attaches a tested Skill to a trigger — time, event, or condition — so Cowork runs your SOP without you opening the app.
Why this matters
Operators who skip trigger taxonomy schedule the wrong thing (cron on a reactive task) and wonder why automation feels brittle.
In Cowork, scheduling means a Skill runs on its own when a rule fires. Three trigger families cover almost all ops work: time-based, event-based, and condition-based.
Each scheduled run creates a run record in history. Scheduling does not change the Skill — it only decides when to invoke it. If the Skill failed manual testing, scheduling amplifies the failure.
Workflow — do this next
- 01Classify your pilot task: time, event, or condition trigger.
- 02Confirm Skill passed five-run test matrix (Ch 2 §1.8).
- 03Create schedule in sandbox with notify-on-failure only.
- 04Observe three trigger cycles before production paths.
Real example
Three triggers, one Skill library
FINANCE_NORMALISE_INVOICE_v2: event trigger on ~/Finance/inbox/*.pdf. WEEKLY_SALES_MEMO_v1: time trigger Mon 6:30am. PIPELINE_CATCHUP_v1: condition trigger when ~/Sales/staging/has_pending.flag exists.
1.2
Time-based scheduling
Recurring schedules, specific times, and calendar-based triggers — the options and how to configure them
Key takeaway
Time triggers need timezone, blackout windows, and overlap policy — two runs of the same Skill must not stomp each other.
Why this matters
Monday 6am jobs that overlap with manual exports or duplicate cron entries are the most common scheduled failure in ops teams.
Configure: cron expression or picker, timezone, max runtime, and overlap policy
Calendar-aware schedules: month-end close, board week, fiscal quarter — use named calendar anchors in workflow metadata rather than magic dates in cron. Document 'does not run on US federal holidays' in workflow SOP.
Workflow — do this next
- 01Pick local timezone and document in WORKFLOW_SOP.
- 02Set overlap: skip if running (default for file writes).
- 03Stagger heavy jobs — not all at 6:00.
- 04Add blackout window during known manual exports.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Time schedule spec block
schedule: Mon-Fri 06:30 America/New_York overlap: skip_if_running max_runtime_min: 45 blackout: Sun 22:00 - Mon 05:00 (manual export window) notify: on_failure → #ops
1.3
Event-based triggers
File creation, folder changes, and system events that trigger Skill execution — the reactive automation pattern
Key takeaway
Event triggers need debounce and batch rules — one PDF drop should not spawn twelve overlapping runs.
Why this matters
Reactive automation without debounce burns tokens and corrupts outputs when users drag 20 files at once.
Common events: file created, file modified (use carefully), folder non-empty. Configure glob filter, debounce window, and batch limit
Event triggers pair with document inbox workflows (Concept 2 §2.2). Skill must be idempotent: re-processing same filename should not duplicate outputs — use manifest or move-to-processed pattern.
Workflow — do this next
- 01Define watch path + glob + exclude patterns.
- 02Set debounce 30–120s for bulk drops.
- 03Implement move-to-processed or manifest idempotency.
- 04Test with 1 file, 10 files, and duplicate drop.
Real example
INBOX_WATCH_v1
Watch ~/Ops/inbox/ for *.pdf; debounce 90s; max 5 files/run; on success move to ~/Ops/processing/{run_id}/; on fail leave in place + ERROR sidecar.
1.4
Condition-based triggers
Skills that run when a defined condition is met — the logical trigger
Key takeaway
Condition triggers express business logic in files or flags — readable by humans and Cowork alike.
Why this matters
Polling cron for 'maybe there is work' wastes runs; conditions make automation event-like without fragile filesystem watchers.
Patterns: flag file, count threshold, staleness. Condition evaluator runs lightweight check every N minutes; only invokes heavy Skill when true.
Clear conditions in SOP: who creates the flag, who clears it, what happens if flag stuck true for 48h (alert + auto-expire). Avoid conditions that require subjective judgment — 'CEO seems busy' is not a condition.
Workflow — do this next
- 01Write condition in plain English + machine check.
- 02Define flag lifecycle (create, consume, expire).
- 03Test: condition false (no run), true (run), stuck flag (alert).
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Condition trigger spec
poll_every: 15m
condition: exists(~/Sales/staging/has_pending.flag)
AND count(~/Sales/staging/*.csv) > 0
on_true: run PIPELINE_CATCHUP_v1
on_false: noop
stuck_flag_alert: 48h1.5
Schedule reliability
What happens when a scheduled Skill fails to run, runs late, or encounters an error — the reliability model
Key takeaway
Assume failure — design for missed runs, partial completion, and retry with backoff; never silent skip.
Why this matters
Executives trust automation once — a silent miss on board week destroys the program.
Failure modes: machine asleep, Skill error, timeout, overlap skip
Reliability policy per workflow: retry count, backoff, dead-letter folder, escalate to human. Fail loud. Document 'manual catch-up procedure' when automated run missed.
Workflow — do this next
- 01Define retry: 2 attempts, 15m backoff.
- 02Dead-letter: ~/Cowork/failed/{workflow}/{date}/.
- 03Alert channel + owner on-call rotation.
- 04Write catch-up SOP for missed Monday run.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Schedule reliability policy
retries: 2, backoff 15m on_final_fail: notify #ops + write FAILED.json overlap_skip_alert: if 2 consecutive skips missed_run: manual catch-up SOP link
1.6
Resource management in scheduled Skills
How to prevent scheduled Skills from consuming excessive tokens or system resources
Key takeaway
Cap files per run, model tier per Skill, and weekly token budget per workflow — finance should predict cost, not discover it.
Why this matters
Unbounded event triggers on large folders have caused real invoice shocks — resource limits are ops requirements, not optional tuning.
Controls: max_files / max_pages, model routing, chunking, weekly budget alert
Stagger schedules so CPU-heavy OCR and web-research Skills do not collide. Use condition triggers to avoid empty cron runs that still invoke Claude.
Workflow — do this next
- 01Set per-workflow token estimate from manual runs.
- 02Apply max_files and max_runtime from §1.2.
- 03Weekly digest of token use by workflow to finance.
- 04Review budgets quarterly — adjust or split Skills.
1.7
Monitoring scheduled Skills
How to know what ran, when, and what it produced — without being in front of the computer
Key takeaway
Morning triage: dashboard status + run history + output manifest — three minutes to know if the night shift succeeded.
Why this matters
Automation without monitoring is optimism — you need the same visibility you'd expect from a human contractor.
Monitoring stack: Cowork dashboard, run history, output manifest, optional digest notification
Define SLI per workflow: 'completed by 7am with ≥1 output file' or 'zero HIGH flags.' Alert when SLI breached two consecutive days.
Workflow — do this next
- 01Pin dashboard workflows by priority.
- 02Subscribe to failure notifications only (default).
- 03Add daily 7:15am calendar triage — 3 min.
- 04Weekly review: failed runs + near-miss timeouts.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Morning triage checklist
[ ] Dashboard: any red workflows? [ ] History: failures since yesterday? [ ] Manifest: expected outputs present? [ ] Staging: human review queue size OK? [ ] Token digest: within budget?
1.8
The scheduling mindset
Thinking about your week as a set of recurring workflows that Cowork can run for you — the inventory exercise
Key takeaway
Map your calendar to workflows — if it happens every week at the same rough time, it is a schedule candidate.
Why this matters
Random automation ('let's schedule something cool') fails; calendar-driven inventory produces ROI in week one.
Exercise: list every recurring task for 7 days — who, what input, what output, what day/time. Mark automate-now (tested Skill), automate-next (needs Skill), human-only (judgment/legal). Target 3 automate-now schedules in 14 days.
Think night shift not magic replacement
Workflow — do this next
- 01Download weekly calendar + standup notes — extract repeats.
- 02Fill SCHEDULE_INVENTORY table.
- 03Pick lowest-risk weekly job with existing Skill.
- 04Schedule sandbox; promote after 2 weeks clean.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Weekly schedule inventory
| Task | Cadence | Input | Output | Skill | Trigger | HITL | |------|---------|-------|--------|-------|---------|------| | Sales memo | Mon AM | CSV export | memo.md | WEEKLY_SALES_MEMO_v1 | cron | T2 |
Concept 2
Designing Autopilot Workflows
The workflows that run while you're doing other things — the design principles and the concrete examples
2.1
The daily briefing workflow
Cowork reads your inputs overnight and delivers a structured morning briefing — the complete design
Key takeaway
Briefing workflow = ingest overnight inputs → synthesise one template → deliver to staging + notification — never 12 separate chats.
Why this matters
Leaders drown in tabs; a single morning brief with consistent sections beats five different AI summaries.
Inputs: calendar export, overnight emails flagged, CRM snapshot, news watch output, yesterday's run manifests. Schedule: 5:30am weekdays. Skills chain: INGEST_OVERNIGHT → SYNTH_BRIEF_v1 → NOTIFY_DIGEST.
Output template sections: Today, Overnight, Risks, Decisions needed
Workflow — do this next
- 01List true overnight inputs — remove vanity feeds.
- 02Define BRIEF_TEMPLATE.md with word limits.
- 03Schedule 90 min before your work start.
- 04HITL T1: read brief, do not auto-send externally.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Daily brief output template
# Brief — {date}
## Today (3 bullets max)
## Overnight automation
## Risks / flags
## Decisions waiting on you
## Calendar highlights2.2
The document inbox workflow
A folder-monitored Skill that processes every document dropped into it — extraction, summary, and filing
Key takeaway
Inbox workflow: watch → extract → summarise → route to domain folders — with move-to-processed idempotency.
Why this matters
Shared 'drop zone' folders without automation become digital piles; inbox workflow is the highest-ROI pattern for document-heavy teams.
Architecture: ~/Cowork/inbox/ event trigger → CLASSIFY_DOC_v1 → EXTRACT_* by type → SUMMARY_v1 → ROUTE_v1 to ~/Finance|Legal|Ops/.
Sidecar outputs: {filename}.json (structured), {filename}.summary.md, processing.log. Failed files stay in inbox with ERROR.md — never silent delete.
Workflow — do this next
- 01Create inbox + processed + failed folders.
- 02Deploy classify + extract Skills per doc type.
- 03Train team: drop only, never edit in inbox.
- 04Weekly failed-folder review.
Real example
INBOX_PIPELINE_v1
PDF invoice → Finance/staging; contract → Legal/staging; misc → Ops/review with classification confidence in json.
2.3
The weekly report workflow
Aggregating inputs from the week and producing a structured summary report — the recurring intelligence workflow
Key takeaway
Weekly report = defined input window (Mon–Sun) + aggregation Skill + narrative Skill + staging for leadership review.
Why this matters
Friday panic reports are a calendar problem — Monday-ready reports come from scheduled aggregation, not heroics.
Collect inputs from fixed paths: sales CSV, support export, project status md files. AGGREGATE_WEEK_v1 produces metrics.json; NARRATE_WEEKLY_v1 fills report template. Schedule Sunday 8pm or Monday 5am based on when exports land.
Include week-over-week and 'data completeness' section — list missing inputs so readers trust the narrative.
Workflow — do this next
- 01Document which exports must land before schedule fires.
- 02Use condition trigger if upstream export is flaky.
- 03Golden test against last manual report.
- 04Publish to ~/Reports/weekly/{iso_week}/ only after HITL.
2.4
The email draft workflow
Scheduled Skills that prepare draft responses or outreach based on defined criteria
Key takeaway
Email workflows stop at draft in staging — criteria-driven, sensitivity-guarded, never auto-send in v1.
Why this matters
One automated send to a customer or board member ends the Cowork program — drafts-only is the production default.
Patterns: weekly customer check-in drafts from CRM segment; follow-up drafts from stale opportunities; internal status from pipeline analysis. Inputs: CRM export + style card. Output: drafts/{recipient_id}.md with subject line suggestion.
Sensitivity guard (Ch 2 §3.6): legal, HR, termination keywords → REVIEW_REQUIRED.txt instead of draft. Schedule after analysis workflows complete.
Workflow — do this next
- 01Define recipient criteria in SQL-like plain language.
- 02Output to drafts folder only.
- 03Human sends from mail client after edit.
- 04Pilot DM-to-self or drafts mailbox 2 weeks.
2.5
The content monitoring workflow
Skills that track specified topics, sources, or competitors and surface relevant developments
Key takeaway
Monitoring = scheduled research Skill with allowlist + diff against yesterday — surface only what changed.
Why this matters
Daily full re-research duplicates noise; diff-based monitoring respects token budgets and attention.
Configure topic list, allowlisted domains, competitor URLs. COMPETITOR_SCAN_v1 runs daily; writes scan/{date}.json; DIFF_v1 compares to prior day; digest includes only new items with citations.
Store raw fetches for audit; cap sources per run. Pair with briefing workflow (§2.1) as Overnight section input.
Workflow — do this next
- 01Define 5–10 monitored entities max for v1.
- 02Allowlist domains; require citations.
- 03Diff against previous scan artifact.
- 04Feed digest into daily brief — do not separate alert spam.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Monitoring diff output shape
{
"date": "2026-06-22",
"new_items": [{ "entity", "headline", "url", "relevance" }],
"unchanged_count": 12
}2.6
The data refresh workflow
Skills that pull updated data, process it, and update a report or dashboard on schedule
Key takeaway
Refresh workflow: fetch or wait for drop → validate schema → transform → update canonical staging → regenerate dependent report.
Why this matters
Stale dashboards erode trust; automated refresh with schema gates beats manual export when the export is already automated.
Two variants: (A) external pull via MCP/API where allowed; (B) watch folder for BI export. VALIDATE_SCHEMA always runs before transform. Dependent REPORT_REGEN_v1 triggers via condition on successful refresh flag.
Version data files with date suffix — never overwrite sole copy. Keep last 4 weeks for rollback.
Workflow — do this next
- 01Map data lineage: source → clean → metrics → report.
- 02Schema test on every refresh.
- 03Condition-trigger report regen on success flag.
- 04Alert if refresh misses SLA (e.g. by 8am).
2.7
The quality check workflow
Skills that review outputs from other processes and flag issues — the automated QA layer
Key takeaway
QA Skill runs after primary workflow — rule-based checks + spot anomalies — writes QA_REPORT not fixed silently.
Why this matters
Automation without QA ships confident errors; a lightweight QA Skill is cheaper than executive distrust.
QA checks: row counts vs prior week, totals reconcile, required fields non-null, filename conventions, banned PII patterns in outputs. QA_SKILL_v1 reads staging outputs; emits qa/{run_id}.json with PASS/FAIL per check.
On FAIL: block promote-to-production step in pipeline; notify owner. QA does not auto-fix — flags for human or upstream Skill revision.
Workflow — do this next
- 01List 5 deterministic checks for pilot workflow.
- 02Run QA after primary, before notify.
- 03Define FAIL → stop pipeline policy.
- 04Review QA false positives weekly — tune thresholds.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
QA check definitions
checks: - row_count_within: 0.2 of prior_week - total_revenue_matches: source_csv.sum - no_null: [region, amount] - no_pii_pattern: email in output
2.8
The notification workflow
Skills that generate summaries or alerts and push them to specified destinations on a schedule
Key takeaway
Notification workflow is the last mile — summarise run manifests, respect quiet hours, fail loud / succeed quiet.
Why this matters
Alert fatigue and alert silence are the same mistake at different volumes — notification design is ops policy.
Patterns: failure → immediate Slack #ops; success → daily digest at 8am; HIGH flags → @owner. Include run_id, workflow name, links to output paths, one-line status. Never attach full PDFs to chat — link to staging.
Quiet hours: no non-critical pings 10pm–7am. Critical = money-moving failure, security, missed board input.
Workflow — do this next
- 01Map severity tiers to channels.
- 02Digest bundles successes; failures always immediate.
- 03Template notifications — consistent parseable format.
- 04Monthly alert audit: mute or fix noisy workflows.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Notification message template
[Cowork] {workflow} — {status}
run_id: {id} | Skill: {version}
outputs: {paths}
action: {review_link | none}Concept 3
Chaining Skills into Pipelines
How to connect multiple Skills into end-to-end pipelines — the workflow architecture that creates genuine operational automation
3.1
What a Skill pipeline is
Multiple Skills connected so the output of one is the input of the next — the automation chain
Key takeaway
A pipeline is a workflow DAG of Skills — each node has one TAR contract; edges are handoff files or manifests.
Why this matters
Monolithic mega-Skills hide failures; pipelines give you run history per step and reusable nodes.
A Skill pipeline turns operational SOPs into executable graphs. Cowork workflow builder connects Skills; each invocation logs separately. Pipelines compose Skills from your library (Ch 2 §3.7) — do not duplicate instructions.
Minimum pipeline metadata: pipeline_id, owner, version, node list, handoff schema, global failure policy.
Workflow — do this next
- 01Draw pipeline on paper — one box per Skill.
- 02Name handoff files between boxes.
- 03Implement and test each node alone first.
- 04Chain in builder; run end-to-end golden test.
3.2
Sequential vs parallel Skill execution
When Skills must run in order vs when they can run simultaneously — the pipeline architecture decision
Key takeaway
Sequential when step B needs A's output; parallel only when inputs are independent and resources allow.
Why this matters
Parallelising dependent steps produces race conditions; serialising independent research burns wall-clock time unnecessarily.
Sequential default: ingest → transform → emit. Parallel example: three competitor scans on different allowlists — merge in SYNTH_v1. Parallel requires join step and resource caps (Ch 3 §1.6).
Never parallel-write same output folder. Use branch subdirs: staging/{run_id}/branch_a/. Merge step owns final canonical write.
Workflow — do this next
- 01Mark each edge sequential or parallel in PIPELINE_SPEC.
- 02Add JOIN node after parallel branches.
- 03Load-test parallel with max concurrent branches.
Real example
Parallel research, sequential emit
SCAN_A || SCAN_B || SCAN_C → JOIN_DIGEST → FORMAT_BRIEF → NOTIFY. Three scans parallel; brief waits for join.
3.3
Handoff design
How to format the output of one Skill so the next Skill can reliably use it as input
Key takeaway
Handoffs are APIs — versioned JSON manifests with schema, run_id, and producer Skill version.
Why this matters
Ad hoc markdown handoffs break downstream parsers; implicit 'read the folder' contracts fail when filenames change.
Standard handoff package: manifest.json plus payload files. Downstream Skill reads manifest first; validates schema_version; rejects on mismatch.
Document HANDOFF_SCHEMA in both Skills' TAR specs. Bump schema_version on breaking changes — downstream must accept N and N-1 during migration.
Workflow — do this next
- 01Define manifest.json schema v1.
- 02Upstream writes manifest on every emit.
- 03Downstream VERIFY manifest before processing.
- 04Integration test with golden handoff fixture.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Handoff manifest.json
{
"pipeline_id": "intel-to-brief",
"run_id": "2026-06-22T05:30:00Z",
"step": 2,
"producer": "EXTRACT_SOURCES_v1",
"schema_version": 1,
"outputs": ["staging/run_abc/items.json"]
}3.4
Conditional branching in pipelines
How to design a pipeline that takes different paths based on Skill output
Key takeaway
Branch on explicit enum in handoff — HIGH/MEDIUM/LOW, PASS/FAIL — never on free-text model prose.
Why this matters
Parsing natural language branch decisions in pipelines is fragile; structured flags are testable.
Pattern: CLASSIFY_v1 writes route.json with { path: 'escalate' | 'standard' | 'skip' }. Workflow router reads route.json — escalate → DRAFT_URGENT_v1; standard → DRAFT_NORMAL_v1; skip → log only.
Always include default branch for unknown values → human review queue. Test all branch paths in pipeline test matrix.
Workflow — do this next
- 01Define route enum in classifier Skill Result.
- 02Map each enum to downstream Skill.
- 03Default branch → REVIEW_QUEUE.
- 04Test one fixture per branch.
3.5
Error propagation in pipelines
What happens when a Skill in the middle of a pipeline fails — the failure containment design
Key takeaway
Fail-fast default — stop pipeline, preserve partial artifacts in failed/{run_id}/, notify with step number.
Why this matters
Downstream steps on bad data amplify errors; 'best effort' completion without flags is worse than clean stop.
Policies: fail-fast, optional branch, retry step. Write PIPELINE_STATUS.json at halt: { failed_step, error, partial_outputs }.
Never auto-run compensation (delete files, send retraction email) without human approval tier T3.
Workflow — do this next
- 01Set fail-fast as default in PIPELINE_SPEC.
- 02Preserve inputs + partial outputs on failure.
- 03Notification includes failed_step + run_id.
- 04Document manual resume from step N procedure.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
PIPELINE_STATUS.json on failure
{
"status": "failed",
"failed_step": 3,
"skill": "SYNTH_BRIEF_v1",
"error": "schema_version_mismatch",
"partial_outputs": ["staging/run_abc/items.json"]
}3.6
Pipeline example: intelligence to briefing
Monitor → extract → synthesise → format → deliver — the complete pipeline design
Key takeaway
Intel-to-brief is the reference pipeline — five Skills, manifest handoffs, QA before notify.
Why this matters
Walking one complete pipeline teaches handoffs, branching, and monitoring better than abstract rules.
Nodes: (1) MONITOR_SCAN_v1 — diff new items; (2) EXTRACT_DETAIL_v1 — fetch summaries for new only; (3) SYNTH_INTEL_v1 — theme clustering; (4) FORMAT_BRIEF_v1 — daily template; (5) NOTIFY_DIGEST_v1. Schedule 5:30am; condition: new_items.count > 0 OR force_run flag.
QA_SKILL_v1 after SYNTH checks citation count ≥ new_items. HITL T2 on FORMAT output before external forward.
Workflow — do this next
- 01Build nodes 1–2; test handoff manifest.
- 02Add SYNTH + FORMAT; golden week test.
- 03Add NOTIFY + QA; fail-fast enabled.
- 04Run 5 consecutive days before marking prod.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Intel → brief pipeline spec
MONITOR_SCAN → EXTRACT_DETAIL → SYNTH_INTEL → QA_CHECK → FORMAT_BRIEF → NOTIFY handoff: manifest.json per step trigger: cron 05:30 + condition new_items>0 failure: fail-fast, notify #ops
3.7
Pipeline example: inbox to action
Read → classify → draft → queue → send — the communication pipeline
Key takeaway
Inbox-to-action stops at queue — send is human or separate approval workflow with T3 gate.
Why this matters
Communication pipelines have the highest blast radius — design stop points before auto-send fantasies.
Nodes: READ_INBOX → CLASSIFY_INTENT_v1 → route.json branch → DRAFT_REPLY_v1 (per intent) → QUEUE_REVIEW_v1 (review.md list) → optional SEND_v1 only with approval flag file present.
High-risk intents (legal, churn, executive) always branch to ESCALATE_HUMAN — no draft auto-generation.
Workflow — do this next
- 01Implement through QUEUE only.
- 02Human review UI = folder of review.md files.
- 03Pilot 30 days drafts-only.
- 04SEND node requires approval.flag per message id.
Real example
route.json branch
{ intent: 'support' | 'sales' | 'legal' | 'spam' } — legal → escalate; support → DRAFT_SUPPORT_v1; spam → archive log only.
3.8
Pipeline example: data to decision
Ingest → clean → analyse → interpret → report — the analytical pipeline
Key takeaway
Data-to-decision separates COMPUTE from NARRATE — numbers in JSON, story in markdown, both from same run_id.
Why this matters
Mixed compute+narrate Skills drift metrics; split nodes make reconciliation and QA tractable.
Nodes: INGEST_EXPORT_v1 → CLEAN_NORMALISE_v1 (schema + dedupe) → ANALYSE_METRICS_v1 (metrics.json) → INTERPRET_FLAGS_v1 (flags + explanations) → REPORT_COMPOSE_v1 (template from metrics + flags). QA reconciles metrics.json to source.
Schedule after upstream export condition true. Report lands ~/Reports/decisions/{date}/ with metrics.json, report.md, QA_PASS.json.
Workflow — do this next
- 01Golden test: metrics match spreadsheet.
- 02INTERPRET only reads metrics.json — not raw CSV.
- 03REPORT cites metric keys inline.
- 04Weekly ops review of flags false-positive rate.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Data → decision pipeline spec
INGEST → CLEAN → ANALYSE → INTERPRET → QA → REPORT artifacts: metrics.json, flags.json, report.md trigger: condition export_ready.flag SLI: QA PASS by 7am Mon
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Weekly schedule inventory
Map calendar repeats to automate-now vs human-only.
| Task | Cadence | Skill | Trigger | HITL |
Pipeline handoff manifest
Versioned contract between Skills.
manifest.json: pipeline_id, run_id, step, producer, schema_version, outputs[]
Morning triage checklist
Three-minute dashboard + history review.
Dashboard red? History failures? Manifests present? Budget OK?
Time schedule spec block
schedule: Mon-Fri 06:30 America/New_York overlap: skip_if_running max_runtime_min: 45 blackout: Sun 22:00 - Mon 05:00 (manual export window) notify: on_failure → #ops
Condition trigger spec
poll_every: 15m
condition: exists(~/Sales/staging/has_pending.flag)
AND count(~/Sales/staging/*.csv) > 0
on_true: run PIPELINE_CATCHUP_v1
on_false: noop
stuck_flag_alert: 48hSchedule reliability policy
retries: 2, backoff 15m on_final_fail: notify #ops + write FAILED.json overlap_skip_alert: if 2 consecutive skips missed_run: manual catch-up SOP link
Morning triage checklist
[ ] Dashboard: any red workflows? [ ] History: failures since yesterday? [ ] Manifest: expected outputs present? [ ] Staging: human review queue size OK? [ ] Token digest: within budget?
Weekly schedule inventory
| Task | Cadence | Input | Output | Skill | Trigger | HITL | |------|---------|-------|--------|-------|---------|------| | Sales memo | Mon AM | CSV export | memo.md | WEEKLY_SALES_MEMO_v1 | cron | T2 |
Daily brief output template
# Brief — {date}
## Today (3 bullets max)
## Overnight automation
## Risks / flags
## Decisions waiting on you
## Calendar highlightsMonitoring diff output shape
{
"date": "2026-06-22",
"new_items": [{ "entity", "headline", "url", "relevance" }],
"unchanged_count": 12
}QA check definitions
checks: - row_count_within: 0.2 of prior_week - total_revenue_matches: source_csv.sum - no_null: [region, amount] - no_pii_pattern: email in output
Notification message template
[Cowork] {workflow} — {status}
run_id: {id} | Skill: {version}
outputs: {paths}
action: {review_link | none}Handoff manifest.json
{
"pipeline_id": "intel-to-brief",
"run_id": "2026-06-22T05:30:00Z",
"step": 2,
"producer": "EXTRACT_SOURCES_v1",
"schema_version": 1,
"outputs": ["staging/run_abc/items.json"]
}PIPELINE_STATUS.json on failure
{
"status": "failed",
"failed_step": 3,
"skill": "SYNTH_BRIEF_v1",
"error": "schema_version_mismatch",
"partial_outputs": ["staging/run_abc/items.json"]
}Intel → brief pipeline spec
MONITOR_SCAN → EXTRACT_DETAIL → SYNTH_INTEL → QA_CHECK → FORMAT_BRIEF → NOTIFY handoff: manifest.json per step trigger: cron 05:30 + condition new_items>0 failure: fail-fast, notify #ops
Data → decision pipeline spec
INGEST → CLEAN → ANALYSE → INTERPRET → QA → REPORT artifacts: metrics.json, flags.json, report.md trigger: condition export_ready.flag SLI: QA PASS by 7am Mon
Ops lead — Monday without opening exports
A 25-person B2B company ran Monday sales, support, and pipeline rituals manually — three leaders, 4+ hours, frequent 'which CSV is latest?' Slack threads.
Before
Skills existed but no schedules; event inbox had no debounce; one failed run went unnoticed until the board pre-read.
After
Chapter 3 rollout: condition-triggered data refresh, Sunday night weekly aggregation, 5:30am intel-to-brief pipeline, QA gate before notify, morning triage checklist.
- Monday prep → 4 hr collective to 45 min review
- Missed refresh SLA → alerted by 7:15am (was discovered at noon)
- Pipeline fail-fast → zero downstream reports on bad data
- Token spend → predictable; staggered schedules cut overlap 40%
What goes wrong
Cron on flaky upstream — empty runs burn tokens daily.
§1.4 condition triggers; export_ready.flag lifecycle.
File drop triggers 20 overlapping runs.
§1.3 debounce + batch limits + skip_if_running.
Silent pipeline failure — downstream report looks fine, numbers wrong.
§3.5 fail-fast + §2.7 QA_SKILL before notify.
Alert fatigue — team mutes #ops.
§2.8 fail loud / succeed quiet; monthly alert audit.
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.