On The Record banner
tokenmaxxxer tokenmaxxxer

On The Record

Git community

Description

Everything on the record: a requirement is an issue, a decision is an approval comment, work is a PR, rationale is that PR's record. The orchestrator relays conversation to GitHub and spawns sandboxed role sessions, each with only its own rulebook.

Installation

This entry records only its repository, not the path inside it, so there is no exact command to give. Open the source below and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

README

tokenmaxxxer / on-the-record

*[한국어](README.ko.md)*

Quickstart

gh auth login

In your conversational session:

/plugin marketplace add tokenmaxxxer/on-the-record
/plugin install on-the-record@tokenmaxxxer
/on-the-record:run

No separate clone or secret setup is required for on-the-record, rulebooks, or tokenmaxxxer-core. **skill-repository is the exception**: all roles resolve their guidance from it, and it needs a manual clone with `MUSTER_SKILL_REPO` pointed at the checkout's `skills/` directory (or a sibling clone for zero-config) — see the skill-repository step in [`docs/handbooks/setup.md`](docs/handbooks/setup.md) (see "Getting started").

Full requirements and optional setup (agent account, model pinning, project init) are documented in [`docs/handbooks/setup.md`](docs/handbooks/setup.md).

Interaction flow

This section describes the mechanics after install: issues, PRs, branches, records, gates.

The user-facing loop

The user states a need in conversation. The orchestrator drafts an issue and relays it to GitHub under the user's account. The user confirms in conversation. From that point, user input and AI activity are each recorded in one fixed location: a requirement is an issue, a decision is an approval comment, work is a PR on an `issue-/` branch, and the rationale is that PR's record document. A role ships phase 1 (proposal) first; phase 2 (delivery) opens only after the user approves. The user does not write to GitHub directly. Every decision is made in conversation with the orchestrator, which relays it to GitHub under the user's account: feedback as a comment, approval as an `APPROVE issue-/` comment, acceptance as a merge, rejection as a close. The orchestrator also watches for each PR the role opens and reports its contents back to the user in conversation before the user decides.

sequenceDiagram
    participant U as User
    participant O as Orchestrator
    participant R as Role sessi