| name | prise | |
|---|---|---|
| description | Load prise fork development context for Zig/Lua work | |
| argument-hint |
|
|
| allowed-tools | Bash(pairctl:*), Bash(knowctl:*), Bash(summaryctl:*), Bash(claudectl:*), Bash(zigdoc:*), Bash(prise-build:*), Bash(zig:*) |
{% set include_web_tools = false %} {% include '_partials/core.md.tmpl' %} {% include '_partials/tool-summaries.md.tmpl' %} {% include '_partials/dev-env.md.tmpl' %}
Before starting any work, read ~/src/possibilities--prise/AGENTS.md for Zig/Lua coding conventions, build commands, and test patterns.
Prise has three separate Lua codebases — always be explicit about which one you're discussing:
- User config (
~/code/dotfiles/prise/.config/prise/, stowed to~/.config/prise/): Keybindings, dialogs, tab bar rendering, etc. Edit freely like any other dotfile. - ArtHack config (
~/code/arthack/system/prise/.config/prise/conf.d/arthack.lua, stowed to~/.config/prise/conf.d/): ArtHack-specific prise extensions — agent PTY adoption, session routing, tab management. Lives in this repo. - Prise fork (
~/src/possibilities--prise, brancharthack-prod): The multiplexer itself — Zig core + built-in Lua modules (e.g.src/lua/tiling.lua). This is a separate repo with its own upstream. Never modify the fork without explicit human approval. If a fix requires changes there, describe what needs to change and ask first.
Treat prise as our own project. When a change belongs in the multiplexer itself — a new API, a bug fix, a behavior change — propose a fork patch. Don't hack around missing fork functionality by cowboying it into init.lua or arthack.lua. Config layers are for configuration and integration glue, not for reimplementing things that should live in the core. The approval gate exists so the human can review fork changes, not to discourage them.
When talking about prise Lua code, always specify which location: "in the dotfiles config", "in arthack.lua", or "in the prise fork (~/src/possibilities--prise)". The built-in tiling.lua in the fork exposes the API that the user config and arthack.lua consume — conflating the three leads to edits in the wrong place.
| Repo | Location | Purpose |
|---|---|---|
| Upstream | ~/src/rockorager--prise |
Tracks main from upstream |
| Fork | ~/src/possibilities--prise |
Our patches, has upstream remote pointing to rockorager |
The fork has one branch per patch and an integration branch (arthack-prod) that merges them all. To see the current branches, run git branch in the fork repo. The prise-build script discovers branches automatically. Branches listed in ~/.config/dotfiles/config.yaml under prise.exclude_branches are experimental work that gets skipped during build — they exist in the repo but don't ship to arthack-prod.
- Always base new branches off
main, notarthack-prod.arthack-prodmerges all patch branches together — basing off it means your branch carries every other patch's commits, causing rebase conflicts with unrelated code whenprise-buildtries to rebase againstmain. A branch based onmainrebases cleanly. - Create a new branch off
mainfor each logically independent patch (e.g.feat/paste-in-modals) - If the change is really a refinement of an existing patch, commit on that patch's branch instead — but check whether that patch has an open or merged PR upstream first. Amending a PR'd branch requires human involvement (force-push, PR update, possible rebase). Always ask before touching a branch that has been PR'd.
- After the patch branch is ready, run
prise-buildto rebuildarthack-prodfrom all branches. Do not build withzig buildyourself —prise-buildhandles the full cycle: rebase all branches againstmain, rebuildarthack-prod, compile, and install. It also resolves merge conflicts via rerere when possible. - Every fork change should include tests and documentation updates. Prise uses Zig's built-in test framework — add or update tests that cover the changed behavior. Run
zig build testfrom the fork repo to verify tests pass before runningprise-build. Update or improve relevant docs (README, inline doc comments, help text) so the change is self-explanatory to upstream reviewers. - Always delete remote branches when deleting local ones (
git push origin --delete <branch>). Local and remote must stay in sync.
Each branch should be a clean, coherent unit of work sized for an upstream PR. Branches that aren't attached to an open upstream PR are fair game for reorganization — split oversized branches, merge related small ones, rewrite history, whatever produces the best shape for review. Be aggressive about this: optimize for the eventual PR, not for preserving current branch structure.
Once a branch has an open or merged upstream PR, it's frozen — don't reorganize, rebase destructively, or fold other work into it without human approval.
Never open a PR to upstream unless the human explicitly asks. Preparing branches for PR is normal work; actually submitting them is a human decision.
When the human does ask for a PR, write the title and description in the voice of arthacker — terse, direct, no filler. Follow ~/code/voice-of-arthacker/VOICE.md for tone. Lead with what the patch does, not why it exists. Skip "this PR" openers. Always show the PR title and body to the human for approval before submitting.
When a PR branch needs code from another patch branch that doesn't have its own upstream PR yet:
feat/<name>— the upstream-clean branch for the PR. No dependencies on other local patches.local/<name>— overlay branch with local-only additions. Merged intoarthack-prodvialast_branchesin config.yaml.
Workflow: changes go to feat/ first, then rebase local/ on top and re-add overlay commits. The config excludes the clean branch from arthack-prod and includes the local one as a late merge. prise-build handles the rest.
To see which dual branches currently exist, check git branch in the fork repo and ~/.config/dotfiles/config.yaml under prise.last_branches and prise.exclude_branches.
If no instructions are provided below, respond only with "Ready."
$ARGUMENTS