Personal pi coding agent configuration.

pi install git:git@github.com:bitmonk8/pi-config

• subagent — Delegate tasks to specialized subagents with isolated context windows. Supports single, parallel (up to 16, 8 concurrent), and chained execution.
• slack — Hybrid Slack integration: read tools route through Slack's MCP server (Claude Code OAuth token), write tools call the Slack Web API directly with a bot token from ~/.pi/slack-config.json.
• freepik — Generate imagery from text prompts via the Freepik API. Supports Nano Banana Pro (default, Google Gemini 3 — best for technical diagrams/text-heavy compositions), Nano Banana Pro Flash (Gemini 3.1 Flash, faster/cheaper), Seedream 4.5 (typography & posters), Flux Kontext Pro (reference-image design), and Mystic (photorealistic). Set FREEPIK_API_KEY in your environment.
• work-profile — Switch between work/personal/custom profiles and model tiers. Profiles map each tier (fast, balanced, smart) to an explicit provider/model; subagents resolve active/<tier> aliases from the active profile.
• package-location — Tells every session where this pi-config package lives on disk. It resolves its own install path at load time (no hard-coded path) and appends it to the system prompt via before_agent_start, so agents stop hunting the filesystem for their own configuration. Disable with PI_PACKAGE_LOCATION_DISABLE=1.

profiles.json uses tier-level providers so the custom profile can mix providers:

{
  "custom": {
    "autoUpdate": false,
    "tiers": {
      "fast": { "provider": "openrouter", "id": "google/gemini-2.5-flash" },
      "balanced": { "provider": "unity-pilot", "id": "claude-sonnet-4-6" },
      "smart": { "provider": "openai", "id": "gpt-5.1" }
    },
    "default": "balanced"
  }
}

Use /custom-profile for an interactive provider/model picker for all three custom tiers, or /custom-profile fast to configure one tier. Use /profile custom to activate it. /tier fast|balanced|smart switches the main session model. Subagent definitions keep using model: active/fast, model: active/balanced, or model: active/smart; the subagent extension resolves those aliases to the active profile's tier provider/model before spawning child pi.

Model tier is set per lens by its **Tier:** tag, not fixed at Haiku — see the routing convention in docs/reference/pipeline-machinery.md §Lens model-tier routing (Tier 1 → smart, Tier 2/3 → balanced by default; no lens runs on fast/Haiku).

Run before /implement to catch problems in a spec while it is still cheap to fix.

Run after /spec-review is clean and before /implement. Each agent receives both the spec (as source of truth) and the plan (as artifact under review).

/plan-review also reuses these existing lenses against the plan: spec-lens-clarity, spec-lens-consistency, spec-lens-traceability, spec-lens-cruft, spec-lens-naming, spec-lens-placement, spec-lens-assumptions, spec-lens-implementability, spec-lens-codebase-grounding-broad, spec-lens-doc-alignment-broad.

The /*-fix-findings-loop prompts and their helper agents (spec-review-fixer, spec-review-shape-single-picker, spec-review-recommendation-applier, plan-review-fixer, plan-review-shape-single-picker, plan-review-recommendation-applier, spec-diff-fixer, plan-diff-fixer) are project-agnostic. Each project they run against keeps a small .pi/project-config.md at its root declaring spec/plan paths, project name, topic-folder layout, stable-ID allocation policy, and any extra do-not-touch paths.

See docs/reference/project-config.md in this package for the full schema and two complete examples (a single-repo project with flat topics and no stable IDs; a subproject of a larger worktree with subfoldered topics and allocate-at-write IDs).

The spec/plan review pipelines (/spec-review, /plan-review) shape a document into the right form by raising findings through review lenses (agents/spec-lens-*.md, agents/plan-lens-*.md) and then fixing them — a stick. The matching carrots describe the target shape up front, so an author (often an agent) writes a good spec or plan the first time and sails through review:

• docs/reference/spec-guide.md — what a good spec looks like: structure, authoring principles (the positive form of each spec lens), anti-patterns, and a pre-flight self-check.
• docs/reference/plan-guide.md — what a good plan looks like: ordered atomic steps, spec coverage/fidelity, validation gates, risk handling, plus a pre-flight self-check.

Both guides are deliberately consistent with the review lenses and with the binding rules in docs/reference/spec-principles.md (SP-1 boundary discipline, SP-2 directional/advisory fields, SP-3 amplification traps) — following a guide will not steer you into a shape a lens later rejects. Where a guide and spec-principles.md ever appear to differ, the principles doc wins. The content-authoring agents (spec-review-fixer, spec-diff-fixer, plan-review-fixer, plan-diff-fixer) are pointed at these guides and read them before writing spec/plan content.

pi update