Core Concepts
The working loop, the small-surface philosophy, session and worktree isolation, model routing, and durable verification that define how Gajae-Code operates.
Gajae-Code (gjc) keeps the public agent surface intentionally small while making the runtime around it dependable. A handful of ideas explain how it behaves — and why the harness improves by making one method better instead of growing a skill zoo.
The working loop
Gajae-Code focuses on one useful loop rather than a sprawling default surface:
deep-interview -> ralplan -> ultragoal
└─ optional team execution when parallel tmux workers helpdeep-interviewremoves ambiguity before any planning or code change.ralplanbuilds and critiques a plan before mutation.ultragoalcarries the work through implementation, revision, verification, and an evidence summary.teamis an optional execution mode that coordinates tmux-backed parallel workers — not a required handoff step.
The sequence describes the operator flow, not hidden automation: the agent still reports what it changed, what it revised after findings, what checks ran, and what evidence supports the result.
A concrete bug-fix pass might look like this:
/skill:deep-interview clarify the bug, affected behavior, non-goals, and acceptance checks
/skill:ralplan turn the clarified bug report into a reviewed fix plan
gjc ultragoal create-goals --brief-file <approved-plan>
# Optional only for parallel work:
gjc team 2:executor "split implementation and verification for this bug fix"
gjc ultragoal complete-goalsWorkflow routing
Use the smallest workflow that satisfies the request:
- Direct implementation for clear, low-risk edits.
deep-interviewwhen intent, scope, or acceptance criteria are ambiguous.ralplanwhen requirements are clear enough to plan but architecture, sequencing, or verification needs consensus.ultragoalwhen work should be split into durable goals with an auditable ledger.teamwhen approved work benefits from parallel workers.
Planning artifacts stay pending approval until you explicitly approve execution — deep-interview and ralplan do not start implementation on their own.
The small-surface philosophy
Gajae-Code ships exactly four default workflow skills and four bundled role agents. There is no sprawling default skill zoo: the harness improves by making this small method better.
| Workflow skill | What it does |
|---|---|
deep-interview | Removes ambiguity before planning or code changes. |
ralplan | Builds and critiques a plan before mutation. |
team | Optionally coordinates tmux-backed parallel execution when the work benefits from multiple workers. |
ultragoal | Tracks durable goals through implementation, revisions, verification, and evidence summaries. |
| Role agent | What it does |
|---|---|
executor | Bounded implementation, fixes, and refactors. |
architect | Read-only architecture and code-review assessment. |
planner | Read-only sequencing and acceptance criteria. |
critic | Read-only plan critique and actionability review. |
The result is a compact CLI that stays easy to reason about, but still gives you session state, worktree isolation, tmux orchestration, model routing, tool execution, and persistent evidence when the work needs it.
Sessions and worktree isolation
Each run is a session with durable state — history, model changes, and evidence are recorded. For safer, branch-local work, run inside an isolated Git worktree:
gjc --tmux --worktree my-task-branch--worktree takes a branch-like name. If you already have a worktree path, enter that directory first and launch gjc --tmux.
See Sessions & worktrees for the full lifecycle.
Model routing
Gajae-Code keeps every concrete provider model and builds a canonical layer above them, so you can pin an exact provider/model or select a canonical id that coalesces across providers. Context promotion recovers from context-overflow errors by switching a small-context model to a larger-context sibling before falling back to compaction.
See Model routing & providers and Context promotion & compaction.
Durable verification and evidence
The loop does not stop at "wrote some code." ultragoal tracks goals through implementation, revision, verification, and a final evidence summary, so a finished task comes with the checks that ran and what they showed. Workflow ledgers, plans, and specs persist under .gjc/ so the trail is auditable later.
See Memory: recall & retain for how durable knowledge carries across sessions.