| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <meta charset="utf-8"> | |
| <title>Reverse-Engineer Repo into Capability Spec — Reusable Prompt</title> | |
| <style> | |
| :root { | |
| --bg: #ffffff; | |
| --fg: #1a1a1a; | |
| --muted: #5c5c5c; |
A pattern for autonomous multi-turn CLI work in Chamber, using the task tool to orchestrate a cli_delegate session without manual polling.
cli_delegate in safe mode runs a real CLI session with approval gates on every command. But it's multi-turn — it goes idle or awaits approval, and someone needs to keep checking on it, approving commands, and sending follow-ups. In a normal conversation, that means the user has to keep prompting the agent to check status. Terrible UX.
| description | Principal-level software engineering guidance channeling Robert C. Martin — Clean Code, Clean Architecture, SOLID principles, and the discipline of craftsmanship. |
|---|---|
| name | Uncle Bob |
You are in principal software engineer mode, channeling Robert C. Martin. You believe that software is a craft, that the only way to go fast is to go well, and that the mess is never worth making.
Read .github/copilot-instructions.md first. It defines the Dependency Rule for this codebase. That rule is not a suggestion.
A split-screen presentation mode using the canvas extension. Slide area on the left, navigable history sidebar on the right. The agent drives slides from the terminal via canvas_show / canvas_update. No microui binary, no responses extension — just standard canvas tooling.
Adapted from the [[Genesis Frontier Capabilities]] MicroUI presenter pattern (genesis-frontier/.github/extensions/microui/pages/presenter.html). That version uses a native window with a chat sidebar hitting the responses API on port 15210. This canvas version replaces the live chat with a clickable history panel — the agent's terminal conversation IS the chat — and uses canvas_update to push the full deck state on each slide change.
Send and read Microsoft Teams messages from any genesis agent using the Agency MCP Teams proxy.
Install Agency (one-time):
Reverse-engineered from source: letta-ai/claude-subconscious v2.0.2
Generated: 2026-03-28
Claude Code is an AI coding assistant that operates in ephemeral sessions. Every session starts from zero — no memory of past conversations, learned user preferences, project context, or unfinished work. Users must re-explain their codebase, repeat preferences, and re-establish context every time.
F1ReplayTiming pulls its data from four distinct external sources and uses two storage backends to persist processed data. The primary data source is the FastF1 Python library, which itself wraps the official F1 timing API (livetiming.formula1.com) to supply historical session data — laps, telemetry, weather, race control messages, driver/team metadata, circuit geometry, and event schedules. For live sessions, the app connects directly to the F1 SignalR real-time stream (wss://livetiming.formula1.com/signalrcore) via WebSocket. A photo-based broadcast sync feature uses the OpenRouter AI API (specifically Gemini Flash vision model) to extract leaderboard data from screenshots. Pre-computed session data is stored either on the local filesystem or in Cloudflare R2 (S3-compatible object storage).
A nightly cron job that reconciles an agent's constitutional memory (memory.md) against
its evolving knowledge graph (Myelin).
This is "Approach A" in the Procedural Memory Graduation design — external reconciliation. It works, but it curates rather than discovers. The emergent graduation mechanism (Approach B) would complement this by auto-promoting stable graph knowledge.
Write a spec for your cron scheduler. Model it in Lean as a pure state machine — simple, obviously correct. Prove the key invariants: one-shot jobs fire at most once, running jobs can't be scheduled concurrently. AI generates the production C# from the spec. Then FsCheck generates thousands of random event sequences — AddJob, TimerTick, Restart, ClockSkip — and runs each one through both the Lean model and the C# code, step by step. After every event, compare the state: which jobs fired, how many times, what's their status. If the C# scheduler says a one-shot job fired twice and the Lean model says that's impossible, the test fails and tells you exactly which event sequence caused the disagreement. The Lean proofs guarantee the model is correct. The property tests guarantee the C# matches.
The full solution — proving C# correct directly in Lean — requires formally modeling C#'s async runtime, null semantics, exception propa
