bip-tuckin

Files (1)

• SKILL.md

SKILL.md (first lines)

# /bip-tuckin

One entry point for persisting session state before `/clear`.
It determines the session's role, runs the matching tuckin, and that skill writes the role-keyed continuation prompt (`docs/guides/continuation-prompt.md`) which `/bip-continue` reads in the next session.
Whatever role it is, knowledge that must outlive the next session goes to its durable home first (the EPIC body, the paper, an issue or PR, a skill via `/bip-kaizen`); the continuation prompt only points at it and keeps the next steps front of mind.

## Choosing the tuckin

If `$ARGUMENTS` names a role — `ms`, `spawn`, `epic`, `conductor`, `staff`, or `generic` — use it.

Otherwise determine the role per `docs/guides/continuation-prompt.md` ("Determining the role"): this session's `ListAgents` name against the `Session:` line of `_ignore/CONTINUE-epic-<N>.md` and `$CLONE_ROOT/.conductor-session`, then the marker file (`.ms-config.json` → `ms` when its `session` field is this session's name or absent, `.epic-status.json` → `spawn`), then ask.
Never infer the role from what the session has been discussing.

Map the role to its skill and invoke it with the Skill tool — do not reimplement it:
`ms` → `/bip-ms-tuckin`, `spawn` → `/bip-spawn-tuckin`, `epic` → `/bip-epic-tuckin`, `conductor` → `/bip-conductor-tuckin`.
`staff` has no tuckin of its own: run the generic fallback below, committing `rulings.md` and `briefs/`, and write `_ignore/CONTINUE-staff.md` naming `/bip-staff`.

## Generic fallback

For a session that is none of the four — an ad-hoc or adjudicator session — there is no specialised tuckin, so do the minimum that makes a reset safe:

1. Commit and push anything this session owns; branch first if on `main`, and leave the pooled-slot branches a conductor manages alone. Report what is unpushed rather than forcing it.
2. Put what this session learned that must outlive it in its durable home (above).
3. Write `_ignore/CONTINUE-generic-<name>.md` per the guide.
4. Report what was committed and that the prompt is written; then it is safe to reset.

From matsen/bipartite, MIT.

More from matsen/bipartite