Target organization: <ORG> (exists, 0 agent(s) besides root; apply_org adds to it)

Show the block below to the user exactly as written, from its first line up to (not including) the marker line; one plain-words intro line before it is fine.

PLAN FOR YOU
Goal: Sample text
What I understood you need:
- Scope: Sample text
- Quality bar: Tests pass from a clean checkout; no network use at runtime.
- Workspace: <CWD>/proj
- Tests / packaging / commits: tests: pytest, at least one test per acceptance criterion; packaging: uv with a pyproject.toml; commits: local commits per feature; never push
- Models: claude-sonnet-5.5 for every agent
Team (4 agents):
- lead (Manager, model claude-sonnet-5.5): directs the team; does not produce the work itself; can read files in <CWD>/proj and the organization's own files; changes files only in <CWD>/proj; can run commands, which are NOT confined: it is told to stay in <CWD>/proj, but nothing enforces that
  - dev (Engineer, model claude-sonnet-5.5): can read files in <CWD>/proj and the organization's own files; changes files only in <CWD>/proj; can run commands, which are NOT confined: it is told to stay in <CWD>/proj, but nothing enforces that
  - qa (Tester, model claude-sonnet-5.5): can read files in <CWD>/proj and the organization's own files; changes files only in <CWD>/proj; can run commands, which are NOT confined: it is told to stay in <CWD>/proj, but nothing enforces that
  - cr (Code Reviewer, model claude-sonnet-5.5): can read files only in <CWD>/proj and the organization's own files; can run commands, which are NOT confined: it is told to stay in <CWD>/proj, but nothing enforces that
Budget: up to 23 runs per request (one run = one working session of one agent), your cap per request is 30; the minimum for one review and rework is 18. Unspent runs come back to you.
  lead starts with 23, hands down dev 5, qa 3, cr 3 and keeps 12 for planning, checking and rework.
If a check still fails after one rework, I'll come back to you with options before spending the reserve; nothing beyond a request's budget is spent without your OK.
Checking: qa, cr review the work independently (they did not write it); required changes go back to the author. I then re-check the final result against every service check below.
Services (kept ready, requested whenever you want):
- my-service: Sample text
  You provide: topic (required)
  Each request: up to 23 runs
  Checks:
    1. `uv run pytest -q` passes, including at least one new test for the requested change.
    2. Sample text
    3. The tester ran the software against every criterion and the engineer applied every required change.
    4. The change is committed locally in the workspace and nothing was pushed.
  Delivered to: the workspace <CWD>/proj (the team works and commits there)
After each request the lead records lessons; before the next one it reviews them with your feedback and may improve how the team works (its playbook). It cannot change these checks: only you can, through me.
Nothing runs until you ask for a request: approving only creates the team and the services.
Checkpoints: approval - Plan first; ask before any spend beyond the budget; progress - One line when I ask; any spend beyond the budget needs your OK.
Warnings (2):
- lead, lead/dev, lead/qa, lead/cr hold shell. kiro cannot confine shell by path: staying inside the workspace (and leaving inputs alone) is instructed in the charter and prompt, not enforced. Built-in read/write ARE confined; only shell is not
- 'Sample text' is not checkable; state the exact number, section, format or path that decides pass/fail
Nothing is created or started until you approve. Reply 'approve', or tell me what to change.

--- machine marker: the user block ends above; do not show this line or anything below it ---

Details (the full plan, for you; the user need not read it):
# Plan for approval

Goal: Sample text

Needs as understood:
- Scope: Sample text
- Deliverable: per service (see Services below)
- Quality bar: Tests pass from a clean checkout; no network use at runtime.
- Sources / tools: (not specified)
- Workspace: <CWD>/proj
- Tests / packaging / commits: tests: pytest, at least one test per acceptance criterion; packaging: uv with a pyproject.toml; commits: local commits per feature; never push
- Model policy: one model for all
- Review: required

Organization (4 agents):
- lead [manager] Manager: model=claude-sonnet-5.5, tools=read,shell,write ws=<CWD>/proj
  Access: kiro write only in <CWD>/proj; kiro read only in <CWD>/proj and in the organization's own files (read-only); shell NOT confined (instructed only)
  - dev [engineer] Engineer: model=claude-sonnet-5.5, tools=read,shell,write ws=<CWD>/proj
    Access: kiro write only in <CWD>/proj; kiro read only in <CWD>/proj and in the organization's own files (read-only); shell NOT confined (instructed only)
  - qa [tester] Tester: model=claude-sonnet-5.5, tools=read,shell,write ws=<CWD>/proj
    Access: kiro write only in <CWD>/proj; kiro read only in <CWD>/proj and in the organization's own files (read-only); shell NOT confined (instructed only)
  - cr [code-reviewer] Code Reviewer: model=claude-sonnet-5.5, tools=read,shell ws=<CWD>/proj
    Access: kiro read only in <CWD>/proj and in the organization's own files (read-only); shell NOT confined (instructed only)

Budget per request (your cap: 30), estimate 18 for one pass + one review/rework cycle:
  A ceiling: runs the team does not spend come back automatically with the final report of each request.
  service my-service: 23 runs per request
    lead: starts with 23, hands down dev 5, qa 3, cr 3 (each includes its rework/re-check run), keeps 12 (own 7 + slack 5)
    lead/dev: 5 runs (4 work + 1 rework)
    lead/qa: 3 runs (2 work + 1 rework)
    lead/cr: 3 runs (2 work + 1 rework)

Review / verification:
- lead/qa, lead/cr check the work of lead/dev independently; findings go to their manager, who sends required changes back to the author (nobody edits another agent's file).
- the assistant re-checks the final deliverable against every acceptance criterion before telling you it is done

Deliverable:
- per service (see Services below)

Services (1), offered by lead and defined by root (the contract: only root can change it):
- my-service: Sample text
  inputs: topic (required)
  budget: 23 runs per request
  deliverable: Sample text [code and tests in the workspace]; delivered to: the workspace <CWD>/proj (the team works and commits there)
  acceptance (the contract, travels with every request):
    1. `uv run pytest -q` passes, including at least one new test for the requested change.
    2. Sample text
    3. The tester ran the software against every criterion and the engineer applied every required change.
    4. The change is committed locally in the workspace and nothing was pushed.
  playbook v1: generated from the team (steps, budget plan, pitfalls):
    ## Steps
    1. Read the request in your prompt: its inputs, every acceptance criterion and the deliverable. The criteria come from the contract and can only be met, never changed; copy the relevant ones verbatim into every task you delegate.
    2. Delegate to `dev` (Engineer) with `budget=5`: its part of the request, with the criteria it must meet. On this first run delegate only the steps that need nothing from a teammate.
    3. When the work exists, delegate to `qa` (Tester) with `budget=3` to check the final file independently against every criterion. It reports findings and required changes to you and never edits the author's file.
    4. When the work exists, delegate to `cr` (Code Reviewer) with `budget=3` to check the final file independently against every criterion. It reports findings and required changes to you and never edits the author's file.
    5. If a check fails: send the required changes, quoted verbatim, to the AUTHOR of the failing file (`delegate(to=<author>, revises=<that author's task id>, budget=1)`; for the deliverable usually `dev`), then have the checker re-check that same file (`delegate(to=<checker>, revises=<the checker's task id>)`). One rework and one re-check; if it still fails, report `blocked` with options and the checker's final line instead of starting another cycle.
    6. Read the final artifact yourself and check it against EVERY criterion of the request, quoting counts from your own `read` output, and paste the checker's final coverage line verbatim.
    7. Report: `done` only if every criterion is met (else `blocked` with the deviation and a recommended decision). Name the deliverable's path and pass `lessons`: 1-3 lines for the next request - what worked, what to change in this playbook, and the evidence (runs used, rework, review findings).
    
    ## Budget plan
    Request budget: 23 runs (the contract's). Hand down no more than this up front, each with `budget=` set explicitly:
    - dev: 5 runs (4 work + 1 rework or re-check)
    - qa: 3 runs (2 work + 1 rework or re-check)
    - cr: 3 runs (2 work + 1 rework or re-check)
    - you (lead): keep 12 runs: your own 7 (plan, process each result, final check, report, one rework cycle) and 5 of slack.
    Unspent runs return to your parent with your final report.
    
    ## Pitfalls
    none yet: add them from lessons and feedback
After each request the lead records lessons; before the next one it reviews them with your feedback and may improve how the team works (its playbook). It cannot change these checks: only you can, through me.
No first task: nothing runs until you ask for a request (request(service, inputs), then start()).

Checkpoints:
- Approval: Plan first; ask before any spend beyond the budget.
- Progress: One line when I ask.
- Any spend beyond the budget needs your OK.

Warnings (2):
- agents: lead, lead/dev, lead/qa, lead/cr hold shell. kiro cannot confine shell by path: staying inside the workspace (and leaving inputs alone) is instructed in the charter and prompt, not enforced. Built-in read/write ARE confined; only shell is not
- services[my-service].acceptance[2]: 'Sample text' is not checkable; state the exact number, section, format or path that decides pass/fail

Reply 'approve' or tell me what to change.

plan_id: <PLAN_ID>
Next: show the PLAN FOR YOU block above to the user exactly as written (a plain-words intro line before it is fine) and wait for their explicit approval. Then apply_org(blueprint=<this exact YAML>, approved=True, plan_id="<PLAN_ID>"). If you change the blueprint, call propose_org again: the plan_id changes.