✦
Pi-teams prompting and cheap executor lessons
operations / lessons/pi-teams-prompting-and-cheap-executor-lessons.md
project-doc Live smoke test — 2026-04-08 project-doc Knowledge Hub session log project-doc Knowledge Hub simplification plan capture Knowledge Hub session — pi-teams prompt modes and cheap executor experiment lesson Pi-teams prompting and cheap executor lessons playbook Cheap executor decision checklist playbook Pi team lead playbook unknown Operations
Home / operations / lessons / pi-teams-prompting-and-cheap-executor-lessons.md

Pi-teams prompting and cheap executor lessons

Properties
Type
lesson
Status
active
Curation state
canonical
Created
2026-04-08T02:30:48Z
Updated
2026-04-08T02:30:48Z
Tags
pi-teams lessons cheap-executor prompting knowledge-hub
ID
lesson-pi-teams-cheap-execution-001
Source agents
pi
Summary
Pi-teams prompting and cheap executor lessons
operations / lessons/pi-teams-prompting-and-cheap-executor-lessons.md

Pi-teams prompting and cheap-executor lessons

Summary

This session produced several durable lessons about running pi-teams on Knowledge Hub with outcome-first prompting and mixed model tiers.

What happened

1. We created reusable prompting/team infrastructure

  • Added project-local pi-teams templates for three prompt modes:
  • knowledge-hub-frontier-open
  • knowledge-hub-mixed-guided
  • knowledge-hub-budget-scaffolded
  • Added project-local agent definitions for architect, backend, frontend, skills, and reviewer roles.
  • Added a project-local prompting skill describing how to choose prompt openness by model capability, risk, and review cost.

2. Mixed-guided exposed a real integration gap

  • The first live tags-browser experiment looked mostly implemented in the current branch.
  • Even so, the run surfaced a real backend gap: tag links targeted /?q=&vault=<vault>&tag=<tag>, but the home route did not fully honor those filters when q was empty.
  • The backend fix landed and regression tests were added.

3. Cheap execution worked on a bounded UI slice

  • A repo audit identified a genuinely open, small, visible slice: the cross-vault quick switcher on the home page.
  • The first attempt with an unqualified mini-model ID failed because it resolved through the wrong provider path.
  • Retrying with explicit model openai-codex/gpt-5.4-mini succeeded.
  • The bounded UI slice passed review and the full test suite passed.

Lessons

Outcome-first prompting held up

The prompts stayed focused on: - objective - desired outcome - why it matters - necessary constraints with reasons - definition of done

That was enough for both the mixed-guided experiment and the cheaper executor experiment. The run did not justify moving toward procedural prompting.

Repo-state verification should come before roadmap-based assignment

The roadmap was useful but lagged the branch. Several candidate slices were already implemented or partially implemented. Future runs should verify current code and tests before assigning implementation work.

Use cheaper executors for bounded, visible, low-risk slices

A smaller model can be economical when: - the slice is easy to review - the blast radius is low - a stronger reviewer stays in the loop - a fallback implementer exists if needed

Provider-qualified model IDs matter

The mini-model failure was not a capability signal. It was a provider-resolution/configuration issue. For future cheap-executor experiments, use fully qualified model IDs up front.

Evidence from the repo

  • Commit 6d8825d improved tag-filtered search and cross-vault quick switcher behavior.
  • Commit f11997e added Knowledge Hub team prompting playbooks and prompt-mode infrastructure.
  • Keep prompts outcome-first by default.
  • Use mixed-guided for small contract-bearing slices.
  • Use cheaper executors for bounded UI polish or narrow integration fixes with strong review.
  • Verify the repo state before assigning roadmap slices.
  • Prefer explicit provider/model identifiers for cheaper-model experiments.