Claude Desktop Performance Standards
& Operating Techniques

The biggest performance killer in Claude Desktop is the cold start problem — every session begins with zero memory of prior work. The context continuity system eliminates this by maintaining auto-updated CONTEXT.md files for every active project, read at session open before any work begins.

Hub Folder Structure

CONTEXT.md Format — Locked 4-Field Structure, Under 300 Words

Claude API Prompt — Context Generation (Zap Step 6)

All Claude Desktop operating rules are maintained in a single Cloudflare Worker — the live source of truth. Every session fetches it silently at startup, keeping all Cowork instances, Claude mobile, and Claude browser synchronized without manual updates.

Core Behavioral Rules

• Parallel Execution Always: Any tool calls that don't depend on each other's output must be issued simultaneously in one message. Sequential execution of parallelizable work is a performance failure — treat it as a bug.
• No Pre-Action Narration: Don't describe what you're about to do before doing it. Execute first, report results after. "I'll now do X, then Y, then Z" before any action is wasted time and context window.
• No Confirmation Gates on Low-Risk Actions: The dividing line is reversibility. Reads, drafts, sandbox code, calendar events — proceed immediately. Sends, deletes, deploys, external record modifications — always confirm first.
• Assume and Proceed: When intent is reasonably clear, make the most reasonable assumption, state it in one sentence, and execute. Only stop when ambiguity would materially change the output and can't be resolved from context.
• Fail Forward: If a tool call fails, immediately try the next best alternative. Don't stop to report failure — exhaust all paths first, then surface the gap.
• Verify Before Delivering: Math: compute programmatically. Dates/times: always run through bash — never reason from memory (Jason is Pacific Time, Oregon). Lookups: fetch from source. If it can be verified in 10 seconds, verify it.
• Response Compression: No preamble. No post-task summaries. Match depth to what was asked. A one-line question gets a direct answer, not a structured report.
• Tool Discovery First: Before asking Jason for anything, audit available MCP tools, check skills, attempt autonomously, search for missing connectors. Ask only when all options are exhausted.

Subagent Model Routing

Dispatch — Unattended Communication Protocol

Every major Google Drive folder contains a CLAUDE.md file that defines how Claude behaves in that workspace — folder purpose, key frameworks, confidentiality level, and auto-loading instructions. This is the primary mechanism for folder-scoped behavior injection.

Session Auto-Loading Sequence (Every Session Open)

Everything Claude builds — internal and external, reports and docs, audits and analyses — is built in HTML first. HTML is faster to generate, easier to iterate, renderable instantly in any browser, deployable as a live URL, and trivially convertible to any other format. Word and PDF are downstream of HTML, never the starting point.

HTML → Cloudflare Worker Publish Flow

What Goes Where

Cloudflare Workers is the infrastructure layer that turns HTML files into live, instantly-accessible URLs. It's a serverless edge platform — your code runs on Cloudflare's global network, not on a server you manage. For BOSSTORQUE, it serves one primary purpose: deploying client deliverables as live URLs that require no hosting infrastructure and cost essentially nothing.

How to Sign Up

• Step 1 — Create account: Go to dash.cloudflare.com → Sign up with email. No credit card required for the free tier. Account is ready immediately.
• Step 2 — Note your subdomain: Cloudflare assigns a *.workers.dev subdomain (e.g., jason-8ce.workers.dev). All Workers deploy under this subdomain by default. Custom domains can be attached later.
• Step 3 — Install Wrangler CLI: npm install -g wrangler — this is the command-line tool for deploying Workers. Requires Node.js.
• Step 4 — Generate an API token: Cloudflare Dashboard → My Profile → API Tokens → Create Token → "Edit Cloudflare Workers" template. Save the token to _COWORK_HUB/.env as CLOUDFLARE_API_TOKEN. Never hardcode it.
• Step 5 — Test a deploy: Create a minimal Worker script (see below), run wrangler deploy --no-bundle, and confirm the URL returns your content. Takes under 60 seconds end-to-end.

Pricing (April 2026)

Minimal Worker Script — HTML Report

Deploy Commands

Naming Convention

What Cloudflare Workers Can Do (Beyond Report Delivery)

Skills are structured folders that encode complete, repeatable workflows — locked report structures, connector sequences, QA checklists, math correction logs, and delivery protocols. They eliminate reinvention across sessions and preserve lessons learned from prior builds so mistakes aren't repeated.

Skill Folder Anatomy (Sperry Campaign Report — Production Example)

Sunday Automation Workflow (Fully Unattended)

Two complementary quality processes: Friction Logs capture obstacles during automation builds so they're never repeated. Design/QA Audits systematically prescribe fixes for output quality issues using a severity-based framework.

QA Severity Framework

Math Corrections Log — Standard Trap List (13 Documented)

• Median vs. average: Never use average when median is correct for skewed distributions (customer LTV, revenue per job, service ticket value).
• Baseline calculation: Use actual annualized sum from source system — never average × count. Only equivalent when distribution is uniform.
• ROI must be profit-based: (Gain × gross margin) ÷ campaign cost. Revenue-based ROI overstates returns and loses credibility with owners who know their margins.
• Rounding rules: Document the specific convention (floor/ceil/round) per metric. Never leave to judgment — inconsistency creates reconciliation gaps between report sections.
• Denominator mismatches: Verify numerator and denominator are from the same population. Kit subscriber counts and Jobber client counts are different populations — never mix them in a single rate calculation.
• No-data segment exclusion: Exclude no-data segments from conservative scenario projections (Scenario A). Include with proxy value in moderate/optimistic (B/C) — clearly labeled as estimated.

After any significant automation build, a structured security scan identifies leaks, over-permissioning, and hidden dependencies before they become production problems. Two formats: an interactive audit tool for system design review, and a post-build scan for live automation stacks.

5 Audit Dimensions — System Containment Framework

• Every scheduled task that hits a confirm-required action must Dispatch first, every time, without exception — even when previously authorized, even on a known schedule. Silence or timeout = abort and log. Never proceed on no response.
• Unexpected Dispatch pings are a security signal. If Jason receives a notification he didn't initiate, treat it as a potential unauthorized execution — not just a notification. Investigate before proceeding.
• Never accept API keys or tokens in chat. Store using the secure stdin pattern. Read at runtime from _COWORK_HUB/.env or .claude/secrets/. Never echo or log them.

Complete list of all MCP tools and connectors active in Claude Desktop as of April 2026. Organized by category. Permission levels follow the default rule: reads almost always auto-approved, writes almost always gated — exceptions documented.

Consistent output format defaults ensure that every deliverable — internal or client-facing — follows the same quality and branding standards without per-task decisions.

Output Format Decision Tree

BOSSTORQUE Brand Standards — All Deliverables

Three techniques developed from production Quicken automation work to handle blocked tasks without wasting iterations or stalling. The core lesson: most failed attempts are caused by repeating the same approach, not by lack of effort. Structure the retries, research before pivoting, and build auto-fix into every QA pass.

Combined Blocker Protocol — Decision Tree

• Attempt 1: First approach. If it fails, stop and research before attempt 2 — web search for the exact error, check docs, Reddit, Stack Overflow, GitHub Issues.
• Attempt 2: New method informed by research. If it fails, re-evaluate whether the path is fundamentally blocked or just incorrectly executed.
• Attempts 3–4: Two more materially different methods. Each must be a genuine architectural alternative, not a minor variation of what failed.
• Attempt 5: Final attempt. If this fails, send Dispatch with 2–3 concrete options. Skip the step if the task allows it; halt only if proceeding would corrupt state or produce wrong output.
• Post-build: After any significant build completes, run the self-healing QA pass. Find issues, fix them in-place, document with Issue IDs. Ship nothing that hasn't passed this pass.