REACH + OCTO

Appearance

What is REACH? ​

REACH — Runtime Executable Adaptive C# Handler.

A local workflow practice where you declare what you want to reach into, and Claude compiles it to typed C# that runs against your live systems. No pre-built connectors. No fixed implementations. The capability surface is unlimited because Claude picks the right NuGet library for each task, not you.

The Idea in One Paragraph ​

You have intent. You know what system you want to reach into and what you want to find there. What you don't want to do is spend time choosing the right library, writing COM Interop boilerplate, handling connection strings, or parsing output formats. That's implementation. REACH separates the intent from the implementation: you write the .reach file, Claude compiles it to typed C#, runs it, reads what came back, and continues the conversation with findings.

How It Works ​

dotnet run task.cs

Each reach is a single .cs file. Dependencies declared inline — no .csproj, no scaffolding:

csharp
#:package Microsoft.Office.Interop.Outlook@15.0.4797.1004

using Outlook = Microsoft.Office.Interop.Outlook;

var app = new Outlook.Application();
var inbox = app.ActiveExplorer().Session.GetDefaultFolder(
    Outlook.OlDefaultFolders.olFolderInbox);
// ...

Claude writes the file, runs it, reads stdout/stderr, fixes compile errors, reruns. You see the findings — not the plumbing.

The Three Modes ​

READ   →  reach into sources, return findings
           no side effects, runs freely

ACT    →  change state — launch, draft, post
           low-risk acts run freely; writes need a prompt gate

PAUSE  →  surface a prompt, wait for human, continue
           the default for all write operations

Reads run without asking. Writes pause by default. The prompt gate is not a safety check bolted on — it's the conscience of the automation, built into the language.

The Iteration Loop ​

Claude follows this loop for every reach:

1. Understand intent from the .reach file or conversation
2. Write task.cs with appropriate #:package directives
3. dotnet run task.cs
4. Read stdout / stderr
5. Compile error  → fix types, rerun
6. Runtime error  → adjust logic, rerun
7. Wrong output   → reason about it, adjust, rerun
8. Return findings or continue conversation

Compile errors are features. They surface immediately and are typed. Claude fixes them faster than debugging silent script failures.

The Artifact ​

Every meaningful reach writes a .reach-artifact — the typed, human-readable, git-diffable record of what was found.

REACH      sprint-cadence-review
ID         proj.2026.sprint-10
DATE       2026-06-11
─────────────────────────────────────────
period:    2026-04-01 to 2026-06-11
rpm:       all-red
after-hours: 30%
target:    10-15%

finding: |
  Sustained redline across all 10 weeks.
  30% after-hours structural, not occasional.

recommendation:
  recovery: open-valley-week

Plain text. No server. No database. Lives in your project. Git tracked. Claude reads it next sprint without re-running everything.

What Claude Never Shows You ​

Working in REACH, you never see:

  • NuGet package names (Claude chooses them)
  • COM Interop calls and casting
  • Playwright startup and teardown
  • SqlClient connection boilerplate
  • WinForms plumbing for prompt dialogs

You see intent. You see findings. You see the right pause at the right moment.

Named Reaches — The Sharing Unit ​

A .reach file defines a reusable pattern:

# sprint-review.reach

name        sprint-cadence-review
description Read sprint health across email, calendar, and commits

reach outlook.inbox + outlook.calendar + git.commits
  since     10-weeks-ago
  analyze   rpm
  benchmark after-hours 15%
  output    report

Share it. Fork it. Someone else changes the project name and runs it. That's the adoption path — a file, not a framework.

Next ​