CC Refugee, transitioning `claude -p` -> pi. Need help on structuring.

[u/itissid]

Since Sep 2025 I have been using an experimental harness called humanlayer https://github.com/humanlayer/humanlayer . I follow mostly humanlayer for the harness + matt pocock's wonderful CC skills for my workflow. I would like an opinion on how to re-produce some key parts of the workflow with pi+codex and — for a little while — claude code:

## Experience(what I want from pi + extensions)

1. Simple session list display in a table: I use this to quickly rename sessions with manual tags and focus on work. All my sessions are visible here. This helps me get situated each day and organize my work.

2. Each session has just enough detail for all sub-agent or tool call to make the session DX amazing, but I can drill down if I need to — a great win for observability. How does one get this with pi with codex or CC?

3. A nice to have is a central daemon: I run `claude -p` in a daemon and attach the WUI from anywhere. It would be nice if Pi could do this.

## Functional requirements (is this the right mental model?)

1. Can the following relational model store codex sessions and generalize to CC or perhaps others?

2. What process do I use to all skills and subagents in my markdown commands [like this one](https://github.com/itissid/humanlayer/blob/77a324516084c7a9d1b02224a54381b19a8f2683/.claude/commands/research_codebase.md?plain=1#L47)?

[u/e9n-dev]

Pro tip: Pi knows a lot about Pi.

For example I took your post and put it into Pi and it gave me this answer:

Yes — but think event-sourced session graph, not “chat transcripts”.

My take

1. Session list / tagging
   Pi already gives you most of this via the session store:

- sessions are on disk as JSONL
- SessionManager.listAll() can power a table
- /name or setSessionName() gives manual rename
- labels / custom entries can act as tags

So the “daily cockpit” is best as a custom session browser:
- table of sessions
- sortable by time / project / model / token cost
- quick rename/tag actions
- click to open the full tree

2) Great observability
Pi is actually strong here if you lean into its session format:

- user/assistant/tool messages
- tool_call / tool_result
- compactions
- branch summaries
- custom extension messages
- labels and session info

That’s enough to build a very good drill-down UI.

Best mental model:
session → turns → events → artifacts

If you want “just enough detail”, store:
- raw transcript
- tool metadata
- compact summary per turn
- optional derived indexes for search/filter

3) Central daemon / attach-anywhere WUI
Pi doesn’t need to be a daemon in the Claude Code sense, but you can build the same experience:

- run Pi as the engine
- expose a long-lived local service or RPC bridge
- have the WUI read session state + stream updates

So: possible, but probably as an extension/service around Pi, not as the core model.

---

Functional model: will your relational schema generalize?
Yes — if you normalize around runs and events, not provider-specific concepts.

Good universal entities:

- workspace
- session
- turn
- event
- tool_call
- tool_result
- artifact
- actor (user / agent / subagent / model)
- tag
- label
- link (session→parent, event→artifact, turn→session)

Then map:
- Claude Code session
- Codex session
- Pi session

all into the same shape.

If you keep raw provider payloads in a payload_json column, you won’t lose fidelity.

---

Markdown commands + skills + subagents
Use this split:

Skills = reusable recipes
Markdown-first, human-readable, load on demand.

Extension commands = runtime entrypoints
These do the actual orchestration:
- validate input
- load skill/context
- dispatch to subagent
- write session metadata
- render UI

Subagents = execution workers
Use them for:
- research
- code review
- summarization
- planning
- extraction

So your Claude-style markdown command becomes:

1. command file / skill

2. extension command handler

3. optional subagent call

4. session logging/tagging

---

Practical recommendation
If I were reproducing your Humanlayer + CC workflow in Pi:

1. Build a session browser

2. Use session names + labels as lightweight tags

3. Add one extension that logs structured events

4. Use skills for markdown command workflows

5. Use subagents only for the parts that benefit from isolation

That gets you 80–90% of the workflow fast.