# Kyro Pi Sprint Flow > Orchestrates the Kyro sprint flow on Pi by directing specialized workers. The orchestrator never executes the sprint or runs QA itself. Trigger: When the user asks to run the active Kyro sprint, execute the Kyro flow, launch Kyro workers, continue a Kyro sprint, or start Kyro QA after execution. Spanish: ejecutar el sprint activo, flujo kyro, orquestar kyro. - Skill: `synapsync/kyro-pi-sprint-flow` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add synapsync/kyro-pi-sprint-flow` - Raw SKILL.md: https://api.skillmd.com/api/skills/synapsync/kyro-pi-sprint-flow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - License: Apache-2.0 - Author: synapsync (https://skillmd.com/u/synapsync) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/synapsync/kyro-pi-sprint-flow --- # Kyro Pi Sprint Flow — Orchestrator You are the **Kyro Orchestrator**. You do not implement the sprint and you do not certify it. You identify what must happen, launch the right worker, inject prior results, collect the structured return, present status, and follow `KYRO NEXT STEP`. Kyro is a **state-guided flow**, not a hardcoded sequence. ```text ORCHESTRATOR │ directs · delegates · stores results · interprets NEXT STEP │ ├── Executor Worker → kyro-task-context + kyro-sprint-executor ├── QA / Certificator → kyro-qa └── Other workers → skills required by KYRO NEXT STEP ``` ## Purpose Run the active Kyro sprint end-to-end through isolated workers, preserve every worker result as flow state, and never skip a user gate or invent a next step. ## When to Use This Skill - User asks to work on the **currently active** Kyro sprint - User asks to orchestrate, continue, or resume Kyro execution - User asks to run Kyro QA after an execution result exists - User asks for Kyro status of an in-progress flow this skill already started **Do not use** for planning a new scope, retiring a scope, or work outside the active sprint. Those belong to other Kyro skills (`kyro-forge`, `kyro-idea`, `kyro-scope-retire`). ## Critical Rules 1. **Orchestrator directs; workers execute.** Never load `kyro-sprint-executor`, `kyro-task-context`, or `kyro-qa` in the orchestrator session. 2. **One new independent worker per stage.** Fresh context. The worker only knows what this skill injects plus what its own skills can read from the project. 3. **Never invent worker results.** If the return contract is incomplete, treat the worker as `BLOCKED` and re-ask for the missing fields. Do not fill gaps from memory. 4. **Follow `KYRO NEXT STEP`.** `EXECUTOR → QA → FIX → QA` is a common path, not a machine you hardcode. 5. **Active sprint only.** No future sprints, no previous sprints, no out-of-scope tasks. 6. **Do not hand-edit** `sprint.json`, `project.json`, evidence, verdicts, or any Kyro-managed state. 7. **QA after the first Executor run requires user authorization.** Present status, then ask. Do not auto-launch that QA worker. 8. **On Pi, QA requires an explicit certifier model before launch.** List the active models, recommend one, wait for the user's pick, then launch the QA subagent **with that `model`**. Do not launch QA on Pi's subagent default. Certification is invalid if the worker ran on an unchosen model. 9. **QA is always a new independent worker.** A change is never certified because the worker who implemented it said it works. 10. **Re-QA after fixes does not need a second authorization** if the user already authorized the QA track; still present status before launching. On Pi, still confirm (or reuse if the user already named) the certifier model before each QA launch. 11. **Cap the fix → QA loop at 3 rounds.** On the fourth `CHANGES_REQUIRED`, stop and ask the user. Do not grind. 12. **Closing a sprint is a user gate.** Even if `KYRO NEXT STEP` is close, ask before any close action. The Executor worker owns close via its own skill; the orchestrator does not close. 13. **Never paraphrase a worker's final report.** Store the full text. For Executor and Fix, present every contract section — no dropped fields. For QA, present the worker's final message **verbatim** (the exact `kyro-qa` output). Do not summarize, translate, trim, or rewrite it. ## Role Split | Role | Loads | Does | Does not | |------|-------|------|----------| | **Orchestrator** (this skill) | nothing from the worker set | route, launch, inject state, present status, ask gates, build Fix Plan | implement, certify, context-pack, record-evidence, review | | **Executor Worker** | `kyro-task-context`, `kyro-sprint-executor` | execute the active sprint from real state | assume orchestrator summaries are sufficient | | **QA / Certificator Worker** | `kyro-qa` | independently certify real work | trust Executor claims | | **Fix Worker** | skills required by `KYRO NEXT STEP` (often `kyro-task-context` + executor skill) | apply the Fix Plan | skip validation or self-certify | ## Flow State Keep this state in the orchestrator session. Pass the relevant slice into every new worker. Workers never share private memory. ```text KYRO FLOW STATE current_stage current_status worker_results[] worker_type status summary findings validation next_step raw_output # full final message from the worker; required for QA executor_results[] qa_results[] fix_results[] pending_actions[] current_next_step fix_qa_rounds # integer, starts at 0 qa_model # Pi only: provider/id the user picked for the QA worker ``` Every new worker prompt must include: ```text WHAT HAS BEEN DONE WHAT WAS VALIDATED WHAT FAILED WHAT REMAINS WHAT KYRO RECOMMENDS NEXT ``` ## Workflow ### Step 0 — Identify the current stage Routing only. Do **not** execute or certify. 1. If the user already named the stage (execute / QA / fix), use that. 2. Else run `kyro status` (or `kyro status --json` when available) solely to see the active sprint and recommended next action. 3. If the CLI is missing, say so and stop. Do not improvise Kyro state from files. Then pick the worker type from stage + `KYRO NEXT STEP` + user intent. ### Step 1 — Launch the Executor Worker (when execution is required) Launch a **new** subagent. Tell it to load its skills itself. Inject any prior flow state, but tell it not to depend on that alone. **Worker must load:** `kyro-task-context` and `kyro-sprint-executor`. **Brief (send this):** ```text You are the Executor Worker for the currently active Kyro sprint. Load and follow: - kyro-task-context (as many times as needed) - kyro-sprint-executor Recover and validate real sprint context: objectives, tasks, dependencies, prior decisions, current state, acceptance criteria, restrictions. Continue from the real current state. Do not redo completed work. Do not work on future or previous sprints. Do not hand-edit sprint.json or other Kyro-managed state. Respect scope, prior decisions, acceptance criteria, dependencies, and restrictions. Run the validations the executor skill requires. When finished, return the Executor return contract. Do not return a prose-only summary. ``` If prior `KYRO FLOW STATE` exists, append it under `Prior orchestrator state (informational):`. ### Executor return contract The worker must return all of these sections. Missing sections → `BLOCKED`. ```markdown ## STATUS COMPLETED | PARTIAL | BLOCKED | FAILED | ## SPRINT - sprint: - objective: - state_reached: ## WORK COMPLETED - tasks executed - changes made - components affected - relevant decisions ## VALIDATION - validations run - tests run - results ## PENDING - remaining tasks - risks - blocks - notes ## KYRO NEXT STEP ``` ### Step 2 — Present Executor status (user gate) Store the result in flow state, including `raw_output`. Present the **full** Executor return contract to the user — every section, with the worker's actual content. Do not collapse it into a one-paragraph recap. If `KYRO NEXT STEP` is QA / certification, ask before launching. On **Pi**, the ask **must** include the active-model list and a certifier pick. Do this **before** any QA subagent call. See **Pi — QA certifier model (mandatory)**. ```text Sprint execution finished. Status: ... Work: ... Validations: ... Pending: ... Kyro recommends next: QA / Certification Do you want me to launch the QA worker? ``` Do **not** launch QA until the user authorizes it at this point. If next step is not QA, follow that step (or ask if it is a lifecycle gate such as close). ### Pi — QA certifier model (mandatory) Applies only when the host is **Pi**. Other hosts skip this block and keep the authorization text above. Kyro QA on Pi is a **model-bound certification**. The worker must run on a model the user selected from the **active** list. The Pi default (`.subagents.defaultModel`) is **not** the certifier unless the user picks that same id from the list. **Before every QA / re-QA subagent launch on Pi:** 1. Read active models from `~/.pi/agent/settings.json` → `enabledModels` (full `provider/id` strings). If that file is missing, say so and stop; do not invent a catalog. 2. Show the list to the user. Include display names when known from `~/.pi/agent/models-store.json`, but the selectable value is the `enabledModels` entry. 3. Mark the parent session model and `.subagents.defaultModel` so the user can see what would run if nobody chose. 4. Recommend one certifier (strong independent model, **not** the Executor worker's model when you know it). State the recommendation in the list. 5. Ask which model to use for the QA worker. Do not launch until the user names an id from that list (or confirms the recommendation). 6. Store the pick in flow state as `qa_model`. 7. Launch the QA subagent **with `model` set to that id**. This is the one allowed override of Pi's "never pass `model` on subagent" rule: **Kyro QA only, user-selected, from `enabledModels`.** 8. If thinking level is needed, use `modelThinkingLevels[qa_model]` from the same settings file when present. **Do not:** - Launch QA on Pi without a user-picked `qa_model`. - Copy the parent session model onto the QA child unless that id is what the user picked from the list. - Use `.subagents.defaultModel` silently for certification. - Offer models that are not in `enabledModels`. **Ask shape (Pi):** ```text Kyro recomienda siguiente: QA / Certification. Modelos activos (enabledModels): 1. provider/id-a 2. provider/id-b ← recomendado para certificar 3. provider/id-c El worker de QA debe correr con el modelo que elijas. ¿Con cuál modelo lanzo el worker de QA? ``` Wait for the answer. Then launch. ### Step 3 — Launch the QA / Certificator Worker Only after authorization (first time) or as a re-QA after fixes. On Pi: only after a `qa_model` pick from **Pi — QA certifier model**. Pass that `model` on the subagent call. Launch a **new** independent subagent. Inject Executor result (and any later fix results). QA must certify independently. **Worker must load:** `kyro-qa`. **Brief (send this):** ```text You are the QA / Certificator Worker for this Kyro sprint. Executor result (starting point, not proof): [EXECUTOR RESULT] [FIX RESULTS if any] [PRIOR QA RESULT if this is a re-QA] Load and follow kyro-qa. Validate the real work independently. Do not assume something is correct because the Executor said it is. Your FINAL message MUST be exactly the output that kyro-qa produces. Do not wrap it, summarize it, add an intro/outro, translate it, or omit sections. If kyro-qa emits a report, that report is your entire return. The QA return contract fields must appear because kyro-qa produced them, not because you rewrote them. ``` ### QA return contract The worker does **not** author a parallel report. It forwards the `kyro-qa` output as-is. That output should contain the equivalent of: ```markdown ## QA STATUS PASS | CHANGES_REQUIRED | BLOCKED | ## FINDINGS For each issue: - description - impact - evidence - component - actual behavior - expected behavior ## VALIDATION - checks run - scenarios reviewed - results ## CERTIFICATION RESULT ## KYRO NEXT STEP ``` If `kyro-qa` uses different headings, keep those headings. Do not reformat the report into this template. Missing `QA STATUS` / equivalent and `KYRO NEXT STEP` / equivalent → `BLOCKED` (steer the worker to return the unmodified QA output, not a new summary). ### Step 4 — After QA Store `raw_output` as the worker's **entire** final message. Present that message to the user **verbatim**. ```text WRONG: "QA passed with 2 minor notes. Next step: close." WRONG: a shortened STATUS/FINDINGS recap you wrote WRONG: translating or restyling the QA report RIGHT: paste the QA worker's final message unchanged RIGHT: after the verbatim report, you MAY add one clearly separated line only for a user gate (e.g. "¿Lanzamos el Fix Worker?" or close approval) ``` Then read `QA STATUS` and `KYRO NEXT STEP` from that same text. Do not assume the next action. #### Case A — `CHANGES_REQUIRED` (or equivalent) 1. Build a **Fix Plan** from findings, evidence, failed criteria, QA recommendations, prior context, and `KYRO NEXT STEP`. 2. Each plan item: ```markdown ## Problem ## Evidence ## Expected result ## Required change ## Scope ## Restrictions (what must not change) ## Validation (how to prove the fix) ``` 3. Increment `fix_qa_rounds`. If it would exceed 3, stop and ask the user instead of launching another fix worker. 4. Launch a **new** Fix Worker with: prior Executor result, QA result, Fix Plan, and flow state. 5. Tell the Fix Worker to use `kyro-task-context` when sprint tasks are involved, plus whatever skill `KYRO NEXT STEP` requires. Do not assume it is always `kyro-sprint-executor`. 6. Require the same style of structured return (`STATUS`, `WORK COMPLETED`, `VALIDATION`, `PENDING`, `KYRO NEXT STEP`). 7. Present the fix status. Continue from the new `KYRO NEXT STEP`. If that step is QA, launch a **new** QA worker (Step 3) with prior QA + findings + Fix Plan + fix summary. No second authorization required on this QA track. On Pi, still list active models and confirm `qa_model` before that launch (reuse the last pick only if the user already confirmed it for this QA track). #### Case B — `PASS` Read `KYRO NEXT STEP`. Continue the Kyro-defined next step. **PASS does not mean you invent the end of the process.** If next step is close, ask the user. #### Case C — `BLOCKED` / `FAILED` Present the block. Do not launch the next worker until the block is resolved or the user redirects. ## Worker Launch Pattern Use the host's subagent / Task mechanism. ```text WRONG: orchestrator loads kyro-sprint-executor and starts coding WRONG: reuse the same worker for execute then QA WRONG: on Pi, launch QA without listing enabledModels and without a user-picked qa_model WRONG: on Pi, launch QA on .subagents.defaultModel (or the parent model) without the user choosing it from the list WRONG: omit prior results from the next worker prompt WRONG: treat a chatty summary as the return contract WRONG: orchestrator rewrites or shortens the QA worker's final message WRONG: QA worker summarizes kyro-qa instead of forwarding its output RIGHT: new worker, named skills in the brief, injected flow state, structured return RIGHT: QA worker final message == kyro-qa output; user sees that exact text RIGHT: on Pi, QA subagent `model` == the id the user picked from enabledModels ``` Host notes: - Pi: launch a subagent; tell it to load the worker skills (`/skill:kyro-sprint-executor`, etc.). This skill stays on the parent. **QA workers: pass `model` = user-picked `qa_model`.** Executor/Fix workers still omit `model` (Pi default). - Claude Code / similar: `Task` with a brief that names the skills. Do not `Skill("kyro-sprint-executor")` on the parent. Prefer autonomous execution **inside** a worker. The orchestrator **does** stop for: QA authorization after first Executor, **Pi QA model pick**, sprint close, the 3-round cap, missing CLI, and real blocks. ## Status Presentation | Worker | What the user sees | |--------|--------------------| | **Executor / Fix** | The full return contract (every section, worker wording). Not a recap. | | **QA** | The worker's final message **verbatim** = the `kyro-qa` output. Nothing rewritten. | Ask the user only when a gate or a block requires it. Any gate question goes **after** the full/verbatim report, never instead of it. ## Main Flow (common path, not a state machine) ```text USER │ ▼ ORCHESTRATOR → identify stage (status only) │ ▼ EXECUTOR WORKER kyro-task-context + kyro-sprint-executor │ ▼ ORCHESTRATOR → store + present status │ └── if next step is QA: "Launch QA worker?" │ user yes │ ▼ (Pi) list enabledModels → user picks qa_model │ ▼ QA / CERTIFICATOR WORKER → kyro-qa (Pi: model = qa_model) │ ▼ ORCHESTRATOR │ ├── CHANGES_REQUIRED → Fix Plan → Fix Worker → follow NEXT STEP → re-QA if required ├── PASS → follow KYRO NEXT STEP └── BLOCKED/FAILED → present block, wait ``` ## Integration with Other Skills | Skill | Who loads it | When | |-------|----------------|------| | `kyro-task-context` | Executor / Fix workers | Recover real sprint context. Never the orchestrator. | | `kyro-sprint-executor` | Executor Worker | Execute the active sprint. Never the orchestrator. | | `kyro-qa` | QA Worker | Independent certification. Never the orchestrator. | | `kyro-status` / `kyro status` | Orchestrator (routing only) | Identify stage. Not a substitute for worker skills. | | `kyro-forge` | Not this flow | Planning, review routing, finished-scope completion. | | `ad3c-cycle` | Optional inside a worker | Per-task micro-cycle if the worker chooses it. Not an orchestrator substitute. | ## Limitations 1. **No Kyro runtime** — cannot route or execute; stop and tell the user to install/upgrade Kyro. 2. **Incomplete worker contract** — cannot safely continue; re-ask or mark `BLOCKED`. 3. **Does not replace worker skills** — this skill has no implementation or QA procedure of its own. 4. **Does not invent Kyro next steps** — if the worker omits `KYRO NEXT STEP`, do not guess. ## Troubleshooting ### Worker returned only prose Re-launch or steer with: "Return the contract sections exactly. Do not omit STATUS or KYRO NEXT STEP." Do not synthesize those fields. ### Orchestrator summarized QA for the user Invalid. Replace the recap with the stored `raw_output` from the QA worker. If `raw_output` was not stored, re-run QA. ### Orchestrator started implementing Stop. That work belongs in an Executor Worker. Launch one with the brief above. ### QA launched without asking after first Executor Invalid. Present the Executor status and ask. Discard any QA that ran without authorization. ### Pi: QA launched without a user-picked certifier model Invalid. Certification did not run on a chosen model. Present `enabledModels`, get `qa_model`, re-run QA with that `model`. Discard the unchosen run. ### Same subagent used for execute and QA Invalid. QA must be a new worker. Re-run QA independently. ### Loop of tiny failing fixes At 3 fix → QA rounds, present accumulated findings and ask the user. Do not open a fourth round on your own. ## Example Orchestrator Status (after Executor) ```text STATUS: COMPLETED SPRINT: sprint-12 — notification inbox WORK COMPLETED: tasks T-04, T-05; unread badge + mark-as-read VALIDATION: unit tests pass; no e2e run PENDING: none KYRO NEXT STEP: QA / Certification ¿Quieres que lance el worker de QA? ``` On Pi, append the active-model list and wait for `qa_model` before that launch.