For freelancers and agencies

Several clients, several repos, the same few agents. Each client gets a project of its own; what the client has to do is written down for them; and at the end the lists go with the work.

Client work has two lists that never meet: what you and your agents are building, and what you're waiting on from the client. The DNS record at their registrar. The logo in a usable format. A yes on the pricing page. The first lives in your tools; the second lives in email threads, and your agents don't see it at all.

Hamloy keeps both in one project per client: tasks for the work, requests for what someone has to do by hand, and questions for decisions.

One project per client

Make a project for each client and run the one paste in that client's repo. The hamloy program connects the folder to its project, so Claude Code or Codex in ~/clients/bakery writes to the bakery's lists and never to the florist's. Every worktree and branch of that repo shares the one project.

Apps that keep one connection for you, like Claude on the web or ChatGPT, use https://hamloy.com/mcp, which reaches every project you are on. Your agent names the client's project in each call, and can list them:

hamloy - Add an item (project: "Bakery shop", kind: "request",
title: "Point example.com at the new server", summary: "One DNS record at the
registrar; the assistant cannot sign in there", body: [...])
  R-3y9q@1   Point example.com at the new server
          One DNS record at the registrar; the assistant cannot sign in there

Several projects take Pro; Free is one project (pricing).

What the client has to do, with the steps

When an agent needs something only a person can do, it writes a request with the exact steps and links the work that waits on it. Many of those are the client's: a record at their registrar, a login to their analytics, a payment on their card.

S claude · ~/pebble

⏺ hamloy - Add an item (MCP)(kind: "request", title: "Make an APNs key for push reminders", body: […], needs: ["R-h2qe"])

⎿ R-p4nk@1 Make an APNs key for push reminders

⏺ Push reminders need an APNs key, and only you can make one. The steps are on your list. I'm going on with the settings screen meanwhile.

1waits on it

Make an APNs key for push reminders

Waits on you: Create the Apple Developer account and put the team id in .env as APPLE_TEAM_ID

In developer.apple.com › Certificates, IDs & Profiles › Keys, press +
Name it Pebble push and tick Apple Push Notifications service
Download the .p8 file and put its path in .env as APNS_KEY_PATH, its id as APNS_KEY_ID

Doing this lets Push reminders at the time each habit is due go ahead.

Send the client the request's steps as they are, or, if they're on the project, mark it for them: their name goes in the request's for field, and the board shows whose it is. A saved view filtered on that name shows the client only what is theirs.

Decisions, asked once

A client's decision is a question with options and the one your agent recommends. You can ask the client and record their answer, with their reason; the next session, or the next person on your team, sees why it was decided.

Where should synced habits live?

Ccodex 3d ago

Supabase: Postgres with auth and row-level security built in recommended

Our own Postgres on Fly.io

iCloud only, no server

Or answer in your own words Why (optional) Answer

Answering this lets Offline sync with a local SQLite cache go ahead.

C codex · ~/pebble · feat/offline

• I asked you where synced habits should live (Q-sy2c). Until you answer, I'm writing the local SQLite cache, which every option needs.

Sharing is optional. Many freelancers keep the project to themselves and send the client a summary. If you want the client on the board:

invite them by email from the project's People page; the link works once, for a week;
they see the same lists and views you do, can answer questions and tick requests, and can connect their own assistant, which shows up as "their name's claude";
who did what is kept by person, so the history says whether you, your agent or the client changed something.

Be clear on two things before you invite a client. Every person on a project is a full member: there are no read-only guests and no per-list permissions, so the client can change the lists as you can. And each person on your projects is a seat on your bill, €8 a month, counted once however many of your projects they are on. See For Teams.

An agency of several

For a team of developers, each person connects their own Claude Code or Codex and their agents are named for them: "Dana's claude", "Sam's codex". Claims hold across people, so two developers' agents never take the same task, and they message each other by task key. See for teams.

Hand it over at the end

When the work is done, the lists go with it. Export the project as a ZIP of plain Markdown files, backlog.md, requests.md and questions.md, with every answered question and its reason:

$ unzip bakery-lists.zip
  inflating: backlog.md
  inflating: requests.md
  inflating: questions.md
  inflating: .hamloy/views.md

The client can read them as they are, or give them to their own assistant and ask it to bring them into a Hamloy project of theirs (import).

What it costs

Free is one project for you alone, enough to try it on one client. Pro is €8 a month or €80 a year per person, for unlimited projects and sharing them (pricing).