Settings
PP Core reads its behavior from a small set of configuration values that control everything from how much it pauses for your approval to how many tasks it carves a phase into. This page covers where those settings live, how to change them, and what each one does.
Where Settings Live
Configuration is stored per project in a JSON file:
.planning/config.json
This file travels with the repository, so a checkout on another machine inherits the same workflow. You can also keep an optional baseline that seeds every new project you create:
~/.pp/defaults.json
When PP Core resolves a setting, project-level values in .planning/config.json always win over the global defaults. Anything absent from both falls back to the built-in default listed below.
How to Change Settings
You have three ways to edit configuration, from most guided to most direct:
/pp-settings— an interactive wizard that walks you through the major sections one at a time. Best when you want to review everything at once./pp-config— a targeted command for adjusting specific areas without the full wizard.- Hand-editing
.planning/config.json— fastest when you already know the key you want.
The /pp-config command accepts flags to jump straight to a section:
/pp-config # common workflow toggles
/pp-config --advanced # power-user knobs
/pp-config --integrations # API keys and external routing
/pp-config --profile budget # switch the active model profile
Core Settings
These top-level keys shape the overall run.
| Setting | Default | Options | Description |
|---|---|---|---|
mode | interactive | interactive, yolo | Approval flow. interactive asks before acting; yolo proceeds without prompts. |
granularity | standard | coarse, standard, fine | How finely a phase is split: roughly 2–4, 4–6, or 6–10 tasks respectively. |
model_profile | balanced | quality, balanced, budget, adaptive, inherit | Maps agents to model tiers. See the Model Profiles page. |
runtime | (none) | claude, codex, gemini, qwen, opencode, and others | The active AI runtime used when resolving a profile. |
context_window | 200000 | any integer | Token budget per agent. Values at or above 500,000 unlock adaptive context enrichment. |
response_language | (none) | language codes such as pt, ko, ja | Forces all agent output into the chosen language. |
A minimal config might look like this:
{
"mode": "interactive",
"granularity": "standard",
"model_profile": "balanced",
"context_window": 200000
}
Workflow Toggles
The workflow section turns individual stages of the phase loop on or off. Each toggle defaults to enabled unless noted, so you only need to list the ones you want to change.
| Setting | Default | Description |
|---|---|---|
workflow.research | true | Run domain investigation before a phase is planned. |
workflow.plan_check | true | Verify the plan in a loop of up to three iterations before execution. |
workflow.verifier | true | Check finished work against the phase goals. |
workflow.auto_advance | false | Chain discuss, plan, and execute together without stopping. |
workflow.tdd_mode | false | Sequence behavior tasks as red, green, refactor. |
workflow.code_review | true | Enable the /pp-code-review pass and its fix pipeline. |
workflow.security_enforcement | true | Verify security against the phase threat model. |
To disable research and enable test-driven execution, for example:
{
"workflow": {
"research": false,
"tdd_mode": true
}
}
Choosing Sensible Defaults
If you are new to PP Core, leave mode on interactive until you trust a project's rhythm, then switch to yolo for routine work. Keep granularity at standard for most phases; drop to coarse for small, well-understood changes and raise it to fine when a phase has many moving parts that benefit from tighter, individually verifiable tasks.