Tools are ingredients. Workflows are the recipe.

1. Capture source links, quotations, your notes, and claim status in an Obsidian vault.
2. Ask Claude Code to organize an outline and edit the paper files without inventing sources.
3. Build the manuscript and bibliography in LaTeX; keep compilation warnings in the review artifact.

Boundary: Do not use this workflow to fabricate citations or outsource authorship rules imposed by a journal or institution.

1. State one outcome, repository scope, constraints, and the proof required.
2. Let the coding harness inspect existing patterns before editing; add Ponytail when bloat is the likely failure.
3. Run the smallest test that catches the changed behavior, then the real lint and build gates.

Boundary: Do not grant write or deploy permission to an agent that only needs review access.

1. Select representative tasks with hidden acceptance tests and resettable repositories.
2. Pin model, harness, instructions, permissions, tools, add-ons, and budget.
3. Run each configuration on identical fresh fixtures; repeat nondeterministic tasks.

Boundary: Do not compare configurations on different prompts, budgets, or repository states.

1. Create a Zotero collection for the question; tag each record candidate, include, or exclude and correct its DOI, URL, title, and author metadata.
2. Export the collection as library.bib and create source-ledger.md with citekey, inclusion decision, reason, and the exact claim each included source may support.
3. Hand library.bib, source-ledger.md, and permitted abstracts or PDFs to Claude Code; request triage.md with every factual statement tied to a citekey and uncertainty stated explicitly.

Boundary: Do not treat an abstract, metadata record, or model summary as source verification, and do not upload licensed or confidential full text without permission.

1. Get recording consent and save meeting.m4a beside agenda.md; list expected attendees and the decisions the meeting is meant to make.
2. Run whisper meeting.m4a --model turbo --output_format json --output_dir transcript, then spot-check names, numbers, and unclear passages against the audio.
3. Hand transcript/meeting.json and agenda.md to Claude Code; request decision-record.md with decisions, alternatives, owners, due dates, unresolved questions, and a timestamp for every entry.

Boundary: Do not record without consent or treat transcription as authoritative; remove sensitive material before any cloud-model handoff and require human approval for commitments.

1. Pseudonymize each transcript as interviews/I01.md, I02.md, and so on; keep the identity key outside the working folder and write the research question in research-question.md.
2. Hand the sanitized interviews and research-question.md to Claude Code; request themes.md with quote references such as I03:L88-L92, counterexamples, and the interview count behind each theme.
3. Hand themes.md and the same transcripts to Codex; request synthesis-audit.md listing untraceable quotes, unsupported generalizations, omitted counterevidence, and unanswered questions.

Boundary: Do not upload personal or contract-restricted data, infer population prevalence from a small qualitative sample, or present model-generated themes as customer facts.

1. Copy only authorized files into an isolated, non-synced working directory; record file hashes, the purpose, and a deletion date before processing.
2. Run Docling locally to export Markdown and structured JSON, then compare tables, footnotes, page order, and OCR-sensitive passages against the original documents.
3. Run qwen3.5:9b through the local Ollama endpoint; save the model manifest digest and prompt, and request a claim table tied to Docling source locations rather than a free-floating summary.

Boundary: Local execution is not automatically private: disable cloud endpoints and sync, verify the process network policy, and never use a small local model as the final reviewer for legal, medical, financial, or safety-critical decisions.

1. Write one decision question, the comparison fields, named competitors, date cutoff, and an allowlist of primary-source domains before browsing.
2. Use Playwright MCP in an isolated, logged-out browser profile to collect public vendor pages and original repositories; record the URL, access date, evidence type, and a short supporting note for each claim.
3. Ask Claude Code to produce claim-ledger.md and brief.md, keeping facts, vendor claims, inferences, conflicts, and missing evidence visibly separate.

Boundary: Web pages are untrusted input and Playwright MCP is not a security boundary; do not use authenticated sessions, obey access restrictions, and never let page content authorize downloads, commands, purchases, or data disclosure.

1. Freeze a read-only input snapshot, record its hash and data dictionary, and state the decision question plus expected checks before analysis.
2. Use DuckDB to profile types, nulls, duplicates, ranges, and join cardinality; save every cleanup and metric in analysis.sql instead of editing source files.
3. Ask Codex to create the smallest Jupyter notebook that executes analysis.sql, renders the necessary tables or charts, and records assumptions without hidden manual state.

Boundary: Do not upload restricted data, infer causation from correlation, or accept model-generated numbers that cannot be reproduced from the frozen input and saved queries.

1. Name the affected flow, browser states, and applicable WCAG 2.2 success criteria; preserve a failing example before changing code.
2. Add the smallest Playwright and axe-core check that reaches each affected interactive state and records the initial violations without disabling rules.
3. Ask Codex to trace the shared component or style causing the failure, implement the root-cause fix, and retain a regression check alongside the existing functional tests.

Boundary: Automated accessibility checks find only some problems; a passing axe run is not WCAG conformance and does not replace manual assessment or feedback from people with disabilities.

1. Record the exact repository, revision, package or image digest, startup command, transport, and publisher before executing anything.
2. Inspect manifests, install hooks, tool definitions, requested credentials, filesystem roots, network destinations, and destructive operations; deny every permission the stated job does not require.
3. Scan supported lockfiles or SBOMs with OSV-Scanner and inspect individual OpenSSF Scorecard findings, treating both as incomplete signals rather than approval.

Boundary: A clean vulnerability scan or high repository score does not prove an MCP server is safe; do not run untrusted install scripts, grant broad production credentials, or let an agent approve its own permissions.

1. Pin the Spec Kit and agent versions, create a clean branch, and write the user outcome, exclusions, acceptance criteria, and rollback boundary before generating a plan.
2. Review the generated specification, plan, and task list for unsupported assumptions; remove work that does not contribute to an acceptance criterion.
3. Let one coding agent implement the approved tasks in an isolated worktree with only the repository permissions and test credentials it needs.

Boundary: Structured planning is not proof of correctness; never let generated tasks expand scope silently or expose authenticated browser data to an MCP client.

1. Freeze representative success, edge, and refusal cases with expected deterministic properties; keep restricted production data out of the fixture.
2. Pin the prompt, provider identifiers, model settings, tools, and budget in one Promptfoo configuration and prefer deterministic assertions before model grading.
3. Run the baseline and candidate on the same cases with cache behavior recorded; export results, latency, token use, cost, and failures as versioned artifacts.

Boundary: Promptfoo configurations can execute code and are not a sandbox; treat downloaded configurations and fixtures as untrusted and isolate them from production secrets.

1. Choose one representative task, freeze the repository fixture and prompt, and define hidden acceptance checks plus a human artifact rubric.
2. Pin each harness, model endpoint, instructions, permissions, tools, context budget, and optional add-on; change only the configuration being compared.
3. Run every configuration from a fresh copy at least three times, capturing exit state, interventions, elapsed time, tokens, cost, commands, and changed files.

Boundary: A harness license does not make every model, extension, or provider open source; compare exact configurations and keep credentials out of published artifacts.

1. Select a small authorized fixture containing headings, tables, footnotes, citations, page references, and one deliberately difficult layout; record source hashes.
2. Run pinned MarkItDown and Docling versions separately in restricted containers and retain their raw Markdown, structured output, warnings, and elapsed time.
3. Score each output against the originals for ordering, table cells, references, omitted text, OCR errors, and usable source locations before involving a model.

Boundary: Neither parser is a security boundary; MarkItDown MCP can read files available to its process, so restrict mounts, network access, and input provenance.

1. Freeze the affected URL, viewport, browser version, data state, network and CPU conditions, and a repeatable user action before changing code.
2. Use Playwright to reproduce the flow and capture functional timing; record a Chrome DevTools performance trace plus relevant console and network evidence in an isolated profile.
3. Ask one coding agent to trace the bottleneck to a shared root cause and make the smallest fix that preserves behavior and accessibility.

Boundary: One lab trace is not field performance; browser profiles may contain sensitive data, and Chrome DevTools MCP can expose or modify anything in the connected instance.

1. Pin the Agency Agents revision and install only the three named roles into a disposable or project-scoped path; record the harness, model, instructions, tools, and permissions.
2. Give the Minimal Change Engineer one outcome, explicit exclusions, allowed files, and an executable acceptance command; it may implement but not deploy.
3. Run the repository check and return exact failures at most twice, stopping for a person when the same failure repeats.

Boundary: Role prompts do not isolate permissions or prove correctness; reviewers should not receive write, deploy, or production-secret access, and a larger roster adds selection and context overhead.

1. Freeze one resettable task and predeclare correctness, cost, latency, intervention, safety, and privacy thresholds before running anything.
2. Run a one-agent baseline with the model, budget, tools, permissions, instructions, and fixture recorded.
3. Use the Multi-Agent Systems Architect to select no more than three roles and define each role's inputs, outputs, permissions, fallback, one human gate, and a two-retry cap.

Boundary: One comparison cannot establish a universal winner; do not expose production secrets or irreversible operations, and do not add roles whose outputs have no acceptance check or consumer.

1. Configure Renovate to propose a narrow, pinned update with release notes and dependency files visible; avoid grouping unrelated major upgrades.
2. Record the before state, supported runtime range, direct and transitive changes, lockfile diff, and rollback version before asking an agent to modify application code.
3. Run OSV-Scanner on supported manifests and Semgrep on changed code, treating findings as review inputs rather than proof that the upgrade is safe.

Boundary: Automated updates and clean scans do not prove compatibility or absence of vulnerabilities; review install scripts, maintainers, licenses, and runtime behavior.