Gajae-Code
Gajae-Codev0.9.1

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 help
  • deep-interview removes ambiguity before any planning or code change.
  • ralplan builds and critiques a plan before mutation.
  • ultragoal carries the work through implementation, revision, verification, and an evidence summary.
  • team is 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-goals

Workflow routing

Use the smallest workflow that satisfies the request:

  1. Direct implementation for clear, low-risk edits.
  2. deep-interview when intent, scope, or acceptance criteria are ambiguous.
  3. ralplan when requirements are clear enough to plan but architecture, sequencing, or verification needs consensus.
  4. ultragoal when work should be split into durable goals with an auditable ledger.
  5. team when 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 skillWhat it does
deep-interviewRemoves ambiguity before planning or code changes.
ralplanBuilds and critiques a plan before mutation.
teamOptionally coordinates tmux-backed parallel execution when the work benefits from multiple workers.
ultragoalTracks durable goals through implementation, revisions, verification, and evidence summaries.
Role agentWhat it does
executorBounded implementation, fixes, and refactors.
architectRead-only architecture and code-review assessment.
plannerRead-only sequencing and acceptance criteria.
criticRead-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.

Explore the concepts

On this page