Choose your settings

Give Shaka a task:

$shaka <task or issue link>

If the project has no Shaka setup, the agent asks whether to prepare individual or team settings. It finds your existing checks, explains the AI review choices, and defaults to Ask. The settings reference owns the options and defaults.

Where Shaka keeps things

Using Shaka is separate from your team adopting it. You can use Shaka on any repository without changing it, and adopt it as a team later through an ordinary PR.

What	Where	Who decides
Shaka itself	Your Shaka installation, linked into your coding agent	You, when you install or update
Individual settings	.agents/shaka/ in your copy of the repository, kept out of commits	You, until the team adopts Shaka
Team settings	.agents/shaka/, committed on the default branch	Your team, through settings PRs

Each task uses one of these settings sources, never a mix. See which settings apply.

Use individual or team settings

Individual setup lets you try Shaka before your team adopts it. Your choices stay in your local copy of a repository without shared Shaka settings, outside commits. To choose it upfront:

$shaka <task or issue link>
Set up Shaka just for me. Go.

Individual settings support the same choices as shared settings: reviewers, custom code-review instructions, checkpoint choices, writing limits, opening instructions, and WIP preferences. See current experience and recovery limits.

For shared team settings:

$shaka Set up Shaka for this repository.

The agent opens a settings PR for you to review. Its choices become the team's defaults after it merges into the default branch. Individual settings do not override team settings.

Merged #426 lets you try a settings PR on one task before adoption. The PR keeps the experiment visible.

Change your team's settings

Settings changes get their own PR. Shaka's checks before push and its PR description publisher both refuse a feature PR that also changes files under .agents/shaka/, so a settings change never hides inside other work.

1. Ask for the change, for example:

   $shaka Propose using Codex first for local reviews in this repository.

   The agent prepares the change as its own settings PR. You can also edit .agents/shaka/config.yml in a PR yourself.

2. To try it before it merges, select it for your tasks. Teammates can select the same PR:

   $shaka <task or issue link>
   Use settings from PR #123.

3. Merge the settings PR. Its choices become the team's defaults.

Common situations

Situation	What to do
Try Shaka on a repository your team has not adopted	Ask for individual setup. Feature PRs contain no Shaka files.
Share a trial setup with a teammate	Put the settings in a settings PR; each of you selects it for your tasks.
Adopt Shaka as a team	Ask Shaka to set up the repository; review and merge its settings PR.
Change one setting for one task	Say it in the request, such as Use Ask for this task, where the setting allows it.
Change a team setting for good	Follow change your team's settings.

Choose a merge policy

With Ask, review the ready PR, then merge it yourself or tell the agent to merge. With Auto, the agent merges after required checks, reviews, and approvals. Some changes still need your decision.

$shaka <task or issue link>
Use merge policy Auto. Go.

Go starts work; it does not authorize merging. See merge choices.

Choose AI reviewers

A separate AI session reviews the code before publication. Choose reviewers you can access through their tools or API credentials:

$shaka Prefer Claude for code review.

Shaka first prefers a provider that did not implement the change, then follows your configured order. The list supplies choices; the reviewer count determines how many run. Reviews can run concurrently. Additional reviewers add cost and may increase elapsed time. A fresh context does not guarantee a better review.

For custom instructions:

$shaka Focus code reviews on compatibility.

The agent starts from Shaka's defaults when preparing replacement instructions. Use one prompt for all local reviewers or one for a particular reviewer. Team instructions come from the default branch; individual instructions stay in your local settings folder. See custom review instructions.

Keep PR explanations useful

$shaka Keep PR descriptions under 200 words.

Shaka checks writing limits before publishing descriptions and code walkthroughs, including with individual settings. Recommendations and review replies follow agent instructions; code does not check their length.

An opening check advises whether the first sentence of a description or walkthrough leads with what improves for the reader. It does not verify the whole text. Merged #425 added independent opening reviewer choices and a way to disable the check completely after #420. Both team and individual settings support these options.

Decide what happens next

Shaka recommends what to do next at a checkpoint and records the owner's choice for later. See that guide for the terms and current report labels. Checkpoint settings choose who evaluates the result, with team or individual setup.

Add your own PR requirements

$shaka Add project guidance: before merge, confirm the database backfill plan.

The agent reads your PR evidence, merge-readiness, and walkthrough guides when it writes the PR description and the code walkthrough, and before the checkpoint.

Resume unfinished work

WIP Details records the chat locator, checkout path, state, and next action. A locator helps you resume the owning chat when your host can reach it. The checkout-path setting hides the path and keeps the locator.