Build one loop first.

Phase plan

Build sequence.

1. Phase 1: Inventory. List inputs, systems of record, recurring reports, approval points, and painful handoffs.
2. Phase 2: Choose one workflow. Good first choices are leasing follow-up, daily maintenance triage, owner brief prep, or delinquency review.
3. Phase 3: Run dry. Let the system classify and draft, but do not let it send, dispatch, pay, delete, or change official records.
4. Phase 4: Add receipts. Every run should leave proof: source data, draft, decision, approval, final action, and log.
5. Phase 5: Add the scheduler. Put recurring judgment work on an agent schedule. Put boring syncs and health checks in system services.
6. Phase 6: Add memory. Write lessons into the playbook so the next run uses the current truth instead of old assumptions.
7. Phase 7: Expand lanes. Add the next workflow only after the first one is boring, visible, and easy to turn off.

Stack build order

Put the pieces in this order.

Models

Pick model roles first: OpenAI/Codex-style coding support, Claude-style reasoning, fast classification, and retrieval/search.

Control

Add a Hermes-style control plane: agents, tools, gateway, dashboard, approvals, logs, and memory startup.

Records

Connect systems of record: AppFolio or your property platform, Google Sheets/Docs, accounting exports, and a task manager if you use one.

Comms

Add communication APIs: Telegram for approvals, Gmail for inbox signals, ElevenLabs/Twilio for voice/SMS intake, and business-text reminders if needed.

Schedules

Use cron for recurring agent judgment and LaunchAgents/system services for background polling, syncs, watchdogs, backups, and drains.

Proof

Use browser automation, logs, receipts, screenshots, returned records, and dashboards to prove each run worked.

Templates

Copy these worksheets.

Model layer

AI models are split by job.

Control layer

Hermes is the operator hub.

APIs and software

What sits around Hermes.

Schedules

Cron and LaunchAgents do different jobs.

The rule is simple: if the job needs judgment, put it in the agent scheduler. If it mostly checks, syncs, drains, watches, or keeps something alive, make it a boring service.

Current job families

What the recurring work covers.

The real setup has 32 scheduled jobs. Publicly, they are best understood as job families instead of exact private schedules.

Always-on families

What LaunchAgents cover.

Six Mac background services keep the always-on pieces running.

Lyra

Customer service is a workflow, not just a voice bot.

Call

A prospect, resident, vendor, or other caller reaches the intake line.

Voice AI

ElevenLabs gives Lyra a natural conversation layer. Lyra asks questions and identifies intent.

Tools

Scoped backend tools check availability, property info, tenant lookup, tenant verification, emergency alerts, caller history, tour requests, and warm transfer; the call log is written automatically after the call.

Knowledge

Maintained property notes and customer-service rules tell Lyra what she may say and what she must hand off.

Queue

The call becomes a summary, queue item, alert, or follow-up request.

Human

Maintenance dispatch, legal/payment/account issues, emergencies, uncertain answers, and sensitive follow-up stay human-owned.

Parts list

The pieces, in plain English.

Rule of thumb

Use AI for judgment, not blind action.

Battle-tested

The prompts I actually use.

These are the ones that ship — pulled directly from my Claude behavioral file, the wiki schema, and the scheduled jobs that run every day. Copy what fits, adjust for your work.

Operator behavior

Make Claude (or Codex) actually useful.

This is the pattern I put at the top of any session that involves building something. It changes the AI from “eager assistant” to “careful collaborator.”

Before you write code or take action:
1. State your assumptions explicitly. If uncertain, ask.
2. If multiple interpretations exist, present them — don't pick silently.
3. For non-trivial work (3+ steps or architectural decisions),
   propose an approach and wait for confirmation before editing.
4. If a fix feels hacky, pause and ask "is there a more elegant way?"
5. If something goes sideways, STOP and re-plan — don't keep pushing.

Style:
- Terse. State results directly. No trailing summaries of what
  you just read or did.
- Define success criteria. Verify before claiming done.
- After edits to runnable code: run tests, type-check, or lint
  as appropriate. Don't claim done based on "it looks right."
- Reconcile against LIVE state (files, processes, deployed code),
  not narrative reports.
- On correction passes: retract plainly, don't rationalize.

Don't add features, refactor, or introduce abstractions beyond
what the task requires. Three similar lines is better than a
premature abstraction.

Two-AI review

When you want a real second opinion.

This is the prompt I use when Claude has just produced something I'm about to ship — before sending it through Codex for review (or vice versa).

Read the diff/output above. Don't validate it — review it.

Specifically:
- Are there assumptions baked in that could be wrong?
- Is there an edge case the code doesn't handle?
- Is there a simpler way that I'm missing?
- Is anything overcomplicated for the actual task?
- If you were reviewing this for a senior engineer to ship,
  what would you push back on?

Be specific. Quote line numbers. If you'd ship as-is, say
so plainly. Don't soften your critique to be polite.

Weekly review

The Friday afternoon pattern.

My memory agent runs this every Friday at 5 PM. The result lands in my Telegram thread and gets appended to the planning wiki.

Pull the last 7 days of:
  - decisions made (from the decisions log)
  - things that broke (from the ops Telegram channel)
  - cron failures (from launchd logs)
  - any new project pages or playbooks

For each one, answer:
  1. What was the actual outcome? (vs. the intended outcome)
  2. Is there a pattern with previous weeks?
  3. What rule or playbook should be updated as a result?
  4. What's worth telling future-me even if it seems obvious now?

Be honest about what didn't work. Don't summarize for the
sake of summarizing — if a week was uneventful, say so in
one line.

Append the output to wiki/log.md with this week's date.

Wiki ingest

Turn raw notes into durable knowledge.

When I dump a chunk of session transcripts or rough notes into my wiki's raw/ folder, this prompt processes them into structured project pages.

Read all new files in raw/ that I haven't ingested yet.

For each one, extract:
  - Decisions made (date them, link to source line)
  - Risks identified (separate from decisions)
  - Action items with explicit owners
  - Facts worth remembering (gotchas, working recipes, gotchas about gotchas)

Then for each affected project page in wiki/projects/:
  - Update Current State if it changed
  - Append to Decisions section (don't overwrite history)
  - Add new risks to Risks and Blockers
  - Update Next Checkpoint

Rules:
  - Never delete historical decisions unless I tell you to.
  - If new content contradicts old content, KEEP BOTH and
    mark the contradiction. Add "superseded by" if applicable.
  - Mark uncertain claims as "Status: tentative".
  - Cite source files for every non-trivial claim.

When done, append a timestamped entry to wiki/log.md
summarizing what changed.

Pre-commit safety

Keep the AI from doing something destructive.

This is the explicit guardrail block I include in any session that has shell or git access. Pulled directly from my CLAUDE.md.

Destructive Action Guardrails:
- Never `rm -rf`, `git reset --hard`, force-push, drop tables,
  or kill shared processes without explicit confirmation.
- Never skip hooks (--no-verify), bypass signing, or disable
  safety checks as a shortcut.
- Never commit .env, credentials, or token-bearing files.
- If state looks unfamiliar (stray files, unknown branches),
  investigate — don't delete.
- Before running destructive operations, consider whether there
  is a safer alternative. Only use destructive operations when
  they are truly the best approach.
- Approval in one context doesn't extend to the next. Confirm
  before each new destructive action.

Project planning

Get to a real plan before you write a line of code.

For anything bigger than a 30-minute task, I use this to force Claude into planning mode first.

Don't write code yet. Help me plan.

The task: [DESCRIBE IT]

Walk me through:
  1. What this actually needs to do (re-state in your own words)
  2. The 3-5 main steps, in order
  3. Each step's:
     - Files that need to change
     - What can go wrong
     - How to verify it worked
  4. Risks I'm not thinking about
  5. Questions you have for me before starting

If the task feels under-specified, ask me clarifying
questions instead of guessing.

After I confirm the plan, you can start.

Lyra-style intake

The system prompt for a voice agent.

A simplified version of what runs Lyra. Adapt the property-specific bits for your domain.

You are [NAME], an inbound assistant for [BUSINESS].

Your job:
  - Answer the call warmly. Identify yourself once.
  - Understand what the caller actually needs (not what they
    first say — listen for intent).
  - Use the tools available to look up real information.
  - For anything sensitive (account data, money, legal),
    verify the caller's identity before sharing details.
  - For anything urgent (emergency, safety), use the
    emergency_alert tool immediately, then keep talking
    to the caller.
  - For anything you can't resolve, get the details and
    promise a callback. Don't make commitments on behalf
    of the business.

What you DON'T do:
  - Make pricing exceptions.
  - Promise outcomes you can't deliver.
  - Send messages or take actions the user can't see.
  - Continue trying to "solve" when the caller wants a human.

If the caller is frustrated, acknowledge it directly. Don't
keep offering options when they want escalation.

Always log the call summary at the end with: who, what,
intent, urgency, what I told them, what's outstanding.

Original prompts (still useful)

Generic build prompts.

The original generic prompts from earlier versions of this playbook — useful for setting up a new system from scratch.

You are helping me build a local-first workflow operating system for a portfolio management team.

Explain everything in plain language.

The system should have:
- AI model roles for coding, reasoning, classification, retrieval, and review.
- A local control plane like Hermes with agents, tools, approvals, logs, and memory.
- Operating lanes for customer intake, leasing, maintenance, finance, collections, reliability, and memory.
- Software/API connections for our systems of record, inboxes, task tools, voice/SMS tools, dashboards, and documentation.
- Cron-style recurring jobs for agent-owned judgment work.
- LaunchAgent/system-service-style jobs for background polling, syncs, backups, watchdogs, and cleanup.
- Human approval gates before any send, dispatch, payment, legal step, official-record change, deletion, or public action.
- Receipts and logs for every run.

Do not design silent automation.
Start with one workflow in dry-run mode.
Ask me questions until you can produce a build plan, a risk list, and the first workflow card.

Discovery

Map the current business.

Stack prompts

Ask for the real pieces.

Build prompts

Design the first loop.

Dry run

Prompt: Design a dry-run version of this workflow. It may read data, classify, summarize, and draft next steps, but it may not send messages, dispatch work, change records, move money, or delete anything.

Receipts

Prompt: Define the receipt this workflow must produce. Include source records checked, decision made, draft output, approval status, final action, and where the log should live.

Approval

Prompt: Write a human approval policy for this workflow. Specify what needs approval, who can approve, what phrase or button counts as approval, and what should happen if approval is missing.

Schedule

Prompt: Decide whether this workflow belongs in an agent schedule or a background service. If it needs judgment, keep it agent-owned. If it mostly checks or syncs, make it a boring service.

Memory

Prompt: After this run, write a short memory note: what changed, what was proven, what failed, what should be checked next time, and what rule should be updated.

API prompts

Connect software without making a mess.

Lyra-style prompt set

Build customer-service intake.