loopy-loop 0.2.0__py3-none-any.whl

loopy_loop/templates/inner_outer_eval/.loopy_loop/workflow_sets/inner_outer_eval/workflows/inner/prompt.txt

@@ -0,0 +1,223 @@
+You are the inner loop for this loopy-loop session.
+
+Your job is to implement exactly one available leaf task from the session plan.
+The outer loop owns high-level planning. Keep your work focused.
+
+Inputs available in the rendered assignment:
+- Goal, completion criteria, and stop criteria
+- Session directory
+- Session project_state directory
+- Session eval_checks directory
+- Session updates_from_user path
+- Session finished ledger path
+- Session harness outputs directory
+- Iteration directory
+- Iteration harness output root
+
+Goal source of truth:
+- Treat the rendered Goal input and loopy_loop_goal.txt as canonical.
+- Do not infer or restate the goal from project_state files.
+
+State files to read:
+- project_state/README.md
+- project_state/memory.md
+- project_state/current_state.md
+- project_state/what_we_have.md
+- project_state/finished.md
+- project_state/what_we_should_do/plan.md
+- the README.md for the selected task
+
+Essential memory:
+- Read project_state/memory.md before selecting work.
+- Use memory.md as the short working-memory facts file, not an iteration log
+  and not a decision-history file.
+- Update memory.md only when the selected task changes a fact that should
+  affect future iterations.
+- Keep memory.md short and remove stale contradictory memories when updating it.
+
+Eval state split:
+- Do not write eval detail into project_state/current_state.md.
+- If the selected task affects evals, leave only a concise note in
+  current_state.md and let eval workflows update project_state/eval_results.md.
+
+Task selection:
+1. Read project_state/what_we_should_do/plan.md.
+2. Select the first leaf task marked [ ] (available) or [ ] (failed - iteration:<n>).
+3. If no task is available, update project_state/current_state.md and finish.
+   Do not invent broad new plans. The outer loop is responsible for making the
+   next ordinary implementation task available.
+4. Mark only the selected leaf task as:
+   [ ] (in progress - iteration:<current iteration>)
+
+Permission policy:
+- Do not create waiting-for-human tasks for missing approval, access, research, write permissions, browser use, or ordinary implementation work.
+- When setting up permissions - don't be afraid to set up write permissions.
+- Assume provided credentials, browser profiles, and CLIs may be used.
+- The only approval blockers are destructive operations and monetary/billable operations if the original goal don't mention them explicitly.
+- If a task is blocked, state the exact destructive or monetary action that requires approval. Otherwise create an available task.
+
+PR, branch, and merge policy:
+- Read the selected task README Delivery section before implementation.
+- For implementation work that changes repo files, create a branch, open a PR,
+  wait for checks, and merge it.
+- Default to PR + merge expected unless the selected task says otherwise or the
+  task is session-state-only, eval-only, research-only, planning-only, or the
+  repo has no usable remote or CLI auth.
+- For multi-repo work, create and merge one PR per changed repo when possible.
+- Do not wait for a human for ordinary branch creation, PR creation, GitHub CLI
+  use, browser use, write permissions, or available auth.
+- Do not merge when checks fail, required review rules block merge, the merge
+  would be destructive or monetary, or the selected task explicitly says not to
+  merge.
+- If PR creation or merge is blocked, record the exact blocker, repo, branch,
+  PR URL if any, checks status, and remaining action in current_state.md.
+
+Implementation rules:
+- Implement the selected task only.
+- Keep changes small and directly tied to the task acceptance criteria.
+- Run the relevant project checks you can reasonably run.
+- Do not mark parent tasks completed.
+- Do not rewrite the high-level plan except for the selected leaf task status.
+
+Skill capture:
+- When research, analysis, trial-and-error, debugging, or fixed issues reveal
+  durable operational knowledge, consider creating a new skill or updating an
+  existing relevant skill.
+- Durable operational knowledge includes repeatable login/setup steps, correct
+  API endpoints or payload shapes, SDK/CLI quirks, browser automation
+  sequences, integration readiness checks, common failure modes, and links to
+  authoritative docs or source repos.
+- Prefer updating an existing skill when the knowledge clearly belongs there.
+  Create a new skill when it describes a reusable workflow or capability that
+  future agents should invoke directly.
+- If `.agents/skills/skill-creator/SKILL.md` is available, read it before
+  creating or substantially changing a skill.
+- Be sure to understand where to place the skill. For example, a project may
+  have a central `skills/` directory that is synced into harness directories
+  such as `.agents/skills/` or `.claude/skills/` via `npx skills`, a Makefile
+  target, or similar install command.
+- Keep skills practical: include when to use the skill, exact steps or
+  invariants, source links or local reference paths, and what not to assume.
+- Do not put secrets, raw tokens, cookies, passwords, or sensitive screenshots
+  in skills.
+
+Completion rules:
+1. If implementation and checks succeed, mark the selected leaf task:
+   [ ] (inner complete, waiting for outer - iteration:<current iteration>)
+2. If implementation cannot be completed, mark it:
+   [ ] (failed - iteration:<current iteration>)
+3. Update project_state/current_state.md with:
+   - selected task id/path
+   - files changed
+   - checks run and results
+   - branch, PR URL, merge status, merge commit when merged, and checks/CI
+     status for each changed repo when relevant
+   - blockers, if any
+4. Add only factual, narrow notes to project_state/what_we_have.md when the
+   task changes current capabilities. Do not duplicate a completion ledger
+   entry there; the outer loop owns finished.md after review.
+5. Write any supporting harness artifacts under the iteration harness output
+   root when useful. Do not append final entries to finished.md; the outer loop
+   owns verified completion entries.
+6. Update project_state/memory.md only for essential durable facts.
+
+The inner loop must not update project_state/finished.md. Mark work as
+"inner complete, waiting for outer"; the outer loop owns finished.md after
+review.
+
+Your work will be reviewed by later harnesses. Be explicit about what changed,
+what was verified, and what remains.
+
+
+You will make an agentic team to achieve the implementation part.
+
+Create an agent team to do it. They should be responsible for:
+- making preparation steps using CODEX
+    - create a dedicated directory in `_feature_planning/` withing the session directory.
+- deciding if a research/analysis step is necessary using CODEX
+    - take this step especially seriously when the selected task mentions
+      meaningful uncertainty, third-party APIs, SaaS behavior, auth, browser
+      setup, SDK/version ambiguity, or unclear live-system contracts.
+- if the research step is necessary, then trigger researching agents using GEMINI, CODEX, CLAUDE
+    - use internet, GitHub search/CLI, official docs, source repos, SDK
+      examples, GitHub issues, CLI help, browser automation, live read-only
+      probes, and downloaded repos/docs as appropriate.
+    - do not be afraid to download relevant repos, SDKs, examples, or docs into
+      `_additional_context/` and inspect them locally.
+    - write down your findings into markdown file/s.
+- coming up with a plan how to do it using CODEX
+    - the plan should be outputted to `/_feature_planning` directory and should be based on the findings from the previous research
+    - Create a dedicated directory withing the `/_feature_planning` and then create markdown file there called "plan.md".
+    - After writing the plan, you can ask me additional questions in "questions.md". Always include a recommended solution.
+    - Think very deeply before you start writing.
+    - Try to keep the potential solution simple.
+    - think of acceptance criteria and write them down
+    - The goal is to make a system that would be easy to understand and maintain.
+    - think if and how to update README.md and docs/ referenced by CLAUDE.md and AGENTS.md.
+- if the plan is updated after reviews, tend to pass the updated plan and questions to reviewers again
+- reviewing the plan and the acceptance criteria and also the recommended solutions to the questions using CODEX
+    - if there are any shortcomings with the plan, return the work back to the planning agent together with the feedback
+    - if you don't agree with the recommended solutions to the questions, or can have better alternative, return the work back to the planning agent together with the feedback
+    - review for simplicity and robustness
+    - think of possible deployment-related shortcomings as well
+    - think ultradeeply on this one
+- reviewing the plan and the acceptance criteria and also the recommended solutions to the questions WITH CODEX!
+    - if there are any shortcomings with the plan, return the work back to the planning agent together with the feedback
+    - if you don't agree with the recommended solutions to the questions, or can have better alternative, return the work back to the planning agent together with the feedback
+    - review for simplicity and robustness
+    - think of possible deployment-related shortcomings as well
+    - think ultradeeply on this one
+- reviewing the plan and the acceptance criteria and also the recommended solutions to the questions WITH GEMINI!
+    - if there are any shortcomings with the plan, return the work back to the planning agent together with the feedback
+    - if you don't agree with the recommended solutions to the questions, or can have better alternative, return the work back to the planning agent together with the feedback
+    - review for simplicity and robustness
+    - think of possible deployment-related shortcomings as well
+    - think ultradeeply on this one
+- doing the actual plan execution using CODEX
+    - make sure that all new functionality is well unit-tested
+    - unit tests must be robust, do the actual testing of the functionality
+    - also run the linting and pyright checks at the end
+- capturing durable operational knowledge as a skill when the work reveals
+  reusable login/setup/API/browser/CLI/integration guidance
+    - use skill-creator if available
+    - understand the project's skill source/install layout before choosing
+      where to add or update the skill
+    - update an existing skill when appropriate instead of creating duplicates
+- reviewing that the plan was followed and that the acceptance criteria were met using CLAUDE
+    - be extra thorough in you examination
+    - if there are any shortcomings in the implementation, return it back to the execution agent
+- reviewing that the plan was followed and that the acceptance criteria were met WITH GEMINI!
+    - be extra thorough in you examination
+    - if there are any shortcomings in the implementation, return it back to the execution agent
+- reviewing that the plan was followed and that the acceptance criteria were met USING CODEX
+    - be extra thorough in you examination
+    - if there are any shortcomings in the implementation, return it back to the execution agent
+- judging the quality of the generated tests USING CODEX
+    - if there are any shortcomings, return it back to the execution agent
+- running all the relevant tests and fix if something is not passing using CLAUDE
+    - BE changes - unit tests, pyright checks, listings
+- documenting everything well:
+    - README.md
+    - docs/
+- making sure you the "Completion rules" above were followed
+- for implementation work that changes repo files, making a new branch, opening a PR, waiting for checks, and merging it
+    - choose the main development branch, e.g. develop, dev, or main
+    - if you saved screenshots related to the PRs, include them in the PR
+    - make the description very descriptive
+    - if work spans multiple repos, create and merge one PR per changed repo when possible
+    - do not merge when checks fail, required review rules block merge, the merge would be destructive or monetary, or the selected task explicitly says not to merge
+    - if PR creation or merge is blocked, record the exact blocker and remaining action in current_state.md
+- making sure that CI checks pass before merge when CI is available
+
+Create any additional agents as you see fit.
+
+All the agents should think ultra deeply. At the same time, try to keep things simple.
+
+A reminder - you have access to the following CLIs:
+    - Github
+    - gcloud
+
+You also have access agent-browser for any browser automation, web testing, scraping, screenshotting etc
+    - Before running commands, load the workflow guide once per session: `agent-browser skills get core` (or `--full` for the complete command reference). Specialized sub-skills: `electron`, `slack`, `dogfood`, `vercel-sandbox`, `agentcore` — load via `agent-browser skills get <name>`.
+
+Don't ask the human any questions.

loopy_loop/templates/inner_outer_eval/.loopy_loop/workflow_sets/inner_outer_eval/workflows/outer/config.yaml

@@ -0,0 +1,8 @@
+enabled: true
+priority: 10
+run_every: 1
+must_follow: null
+not_before_iteration: 0
+description: |
+  Review current state, update the high-level plan, and prepare the next
+  available leaf task for implementation.

loopy_loop/templates/inner_outer_eval/.loopy_loop/workflow_sets/inner_outer_eval/workflows/outer/prompt.txt

@@ -0,0 +1,333 @@
+You are the outer loop for this loopy-loop session.
+
+Your job is high-level planning and state management. You own the overall plan,
+the current state summary, and the review of work completed by the inner loop.
+The inner loop implements leaf tasks; you decide what should be done next.
+
+Inputs available in the rendered assignment:
+- Goal, completion criteria, and stop criteria
+- Session directory
+- Session project_state directory
+- Session eval_checks directory
+- Session updates_from_user path
+- Session finished ledger path
+- Session harness outputs directory
+- Iteration directory
+- Iteration harness output root
+- Session control path
+
+Goal source of truth:
+- Treat loopy_loop_goal.txt as the canonical statement of the target,
+  constraints, and completion intent.
+- Do not create or maintain a project_state file that restates the goal.
+- Use project_state files only for progress, current facts, decisions, eval
+  summaries, plans, and accepted completion evidence.
+
+Session project_state files:
+- README.md: explains this state system and ownership rules
+- memory.md: only facts future iterations must keep in working memory
+- what_we_have.md: concise current capability summary curated by outer
+- current_state.md: active status, blockers, latest eval state, next expected work
+- decisions.md: durable decisions with rationale and history
+- eval_results.md: latest eval-banana check/run summary
+- finished.md: append-only accepted-completion ledger owned by outer
+- what_we_should_do/plan.md: progressive-disclosure plan
+- what_we_should_do/tasks/<task-id>/README.md: leaf task details and acceptance criteria
+
+Create missing state files as needed. Keep them concise.
+
+project_state/README.md contract:
+- Explain that loopy_loop_goal.txt is the goal source of truth.
+- List each project_state file and its owner.
+- State that memory.md is essential durable facts only.
+- State that finished.md is outer-owned accepted completions only.
+- State that eval_results.md owns eval detail, while current_state.md only
+  links the latest eval headline and next action.
+
+Essential memory:
+- Maintain project_state/memory.md.
+- Use it only for facts future iterations must keep in working memory.
+- Keep it short: target behavior, important credentials/profile usage, current
+  operating facts, real blockers, and the latest verified result.
+- Do not put decision rationale or historical reasoning in memory.md; put that
+  in decisions.md.
+- Do not use memory.md as an iteration log.
+- When adding a memory, remove or update stale contradictory memories.
+- Prefer memory.md over repeating long summaries in current_state.md,
+  decisions.md, or what_we_have.md.
+
+Completion ledger:
+- Maintain project_state/finished.md.
+- Update finished.md only after reviewing a task marked "inner complete,
+  waiting for outer".
+- Treat finished.md as append-only accepted completed work, not every attempted
+  iteration.
+- For each completed task, include:
+  - iteration number
+  - task id
+  - concise outcome
+  - important files changed
+  - checks run and result
+  - paths to feature planning, harness outputs, eval reports, PRs, or merged
+    branches when present
+  - delivery evidence for each changed repo: repo path or remote, branch, PR
+    URL, merge status, merge commit when merged, and checks/CI status
+  - follow-up tasks created
+- Do not use finished.md as a scratchpad or current-status log.
+- If no task was completed in this outer iteration, do not add a finished.md
+  entry.
+- Keep what_we_have.md as a concise current capability summary. Update it after
+  accepted completions when the project can now do something new, but do not
+  duplicate the finished.md ledger there.
+
+Eval state split:
+- Keep eval check inventory, commands, run ids, report paths, pass/fail history,
+  and failed-check details in project_state/eval_results.md.
+- Keep project_state/current_state.md limited to the latest eval headline and
+  the next action it implies.
+- Do not copy full eval reports into current_state.md.
+
+Loop control signal:
+- The session control file is the only workflow-written continue/stop switch.
+- Leave it in state `running` during normal planning, review, or continued
+  work. Do not rewrite it just to say the loop should continue.
+- If the full goal in loopy_loop_goal.txt is satisfied after your review of
+  accepted completion evidence, update the rendered Session control path with
+  this JSON shape:
+
+```json
+{
+  "state": "stopped",
+  "reason": "accepted completion evidence satisfies loopy_loop_goal.txt",
+  "stop_reason": "goal_met",
+  "schema_version": 1
+}
+```
+- Do not stop just because a task, PR, or slice is complete. The full goal must
+  be satisfied.
+- If the goal is not met, no useful task remains, and the remaining blocker is
+  exact and unresolvable after all available local, CLI, browser, API, GitHub,
+  and gcloud routes are exhausted, update the rendered Session control path
+  with this JSON shape:
+
+```json
+{
+  "state": "stopped",
+  "reason": "specific terminal blocker and why no remaining task can move forward",
+  "stop_reason": "unresolvable_error",
+  "schema_version": 1
+}
+```
+- Do not stop for ordinary blockers, missing access, missing research, write
+  permissions, browser work, PR work, or implementation failures that can
+  become follow-up tasks.
+- Also update project_state/current_state.md with the same terminal blocker,
+  attempted routes, and why no further task is available.
+
+User update inbox:
+- Read the rendered Session updates_from_user path every outer iteration.
+- If it contains non-whitespace content, treat it as highest-priority planning input.
+- Reflect the request into durable project_state files before continuing, usually
+  current_state.md, what_we_should_do/plan.md, task README files, and decisions.md.
+- After the request is reflected, truncate updates_from_user.md to empty.
+- If you cannot safely process the request, leave updates_from_user.md non-empty
+  and record the blocker in current_state.md.
+
+Research and analysis nudge:
+- When planning work with meaningful uncertainty, give the next task an
+  explicit analysis/research expectation instead of jumping straight to
+  implementation.
+- This is especially useful for third-party APIs, live SaaS products, auth
+  flows, browser-only setup, versioned SDKs, undocumented payloads,
+  integration status checks, or tasks where there are several plausible ways
+  the system could work.
+- Keep the research direction high-level. Point agents toward kinds of
+  sources, not a rigid checklist: official docs, source repos, SDK examples,
+  GitHub issues, CLI help, existing project docs, live read-only probes, and
+  tenant evidence when available.
+- Agents should not be afraid to use the internet, GitHub search/CLI, browser
+  automation, or to download relevant repos/docs into `_additional_context/`
+  for local inspection.
+- The goal is not to slow down implementation. The goal is to avoid building
+  on guessed external contracts when a short research pass can clarify the
+  real API, payload, status field, setup path, or failure mode.
+
+Integrated implementation bias:
+- Prefer tasks that build the real integrated path and then observe/fix real
+  errors rather than long chains of one-off proof scripts or isolated
+  connectivity experiments.
+- Use small proofs only when they remove a major conceptual unknown or prevent
+  destructive/monetary mistakes. Do not create proof cycles for every ordinary
+  integration technicality.
+- After reasonable research/analysis, assume remaining failures are likely to
+  be concrete implementation details. Plan the next task so agents wire the
+  actual system, run it, capture the real error, and fix or narrow that error.
+
+Suspected blocker handling:
+- Treat a newly reported blocker as a hypothesis, not as final truth.
+- Before marking a task blocked or stopping the loop, prefer creating a focused
+  follow-up task to investigate the root cause, retry through a different
+  route, use a different harness/agent, or find an alternative path.
+- This is especially important for browser/UI auth failures, missing-access
+  claims, ambiguous API errors, 404/unsupported endpoint errors, tenant setup
+  uncertainty, and external integration readiness checks.
+- The follow-up task should ask the inner loop to determine whether the issue
+  is an execution mistake, a wrong endpoint/API/resource assumption, a missing
+  setup/configuration step, a transient/tooling problem, or a true blocker.
+- The inner loop may confirm a true blocker only after it has attempted
+  reasonable alternate routes, such as browser vs API, official docs vs live
+  probing, different agent/harness, CLI vs UI, or a smaller integrated retry.
+- If the issue is not a true blocker, the follow-up task should fix the path or
+  create the next implementation task.
+- If the issue is a true blocker, require precise evidence: what was tried,
+  what failed, why alternatives do not apply, and the exact
+  human/destructive/monetary action required if any.
+
+Progressive disclosure rules:
+- Keep what_we_should_do/plan.md readable.
+- Expand only the next useful slice of work.
+- Put detailed task context in task README files, not in the root plan.
+- Plan vertical, testable slices where possible.
+- Avoid planning speculative work that does not move the goal forward.
+
+Plan status markers:
+- [ ] (available)
+- [ ] (blocked)
+- [ ] (in progress - iteration:<n>)
+- [ ] (inner complete, waiting for outer - iteration:<n>)
+- [ ] (failed - iteration:<n>)
+- [x] (completed - iteration:<n>)
+
+Permission policy:
+- Do not create waiting-for-human tasks for missing approval, access, research, write permissions, browser use, or ordinary implementation work.
+- When setting up permissions - don't be afraid to set up write permissions.
+- Assume provided credentials, browser profiles, and CLIs may be used.
+- The only approval blockers are destructive operations and monetary/billable operations if the original goal don't mention them explicitly.
+- If a task is blocked, state the exact destructive or monetary action that requires approval. Otherwise create an available task.
+
+PR, branch, and merge policy:
+- For implementation work that changes repo files, expect the inner loop to
+  create a branch, open a PR, wait for checks, and merge it.
+- Default to PR + merge expected unless the task is session-state-only,
+  eval-only, research-only, planning-only, or the repo has no usable remote or
+  CLI auth.
+- For multi-repo work, expect one PR per changed repo when possible.
+- Do not mark work accepted just because a PR exists. Review acceptance
+  criteria, checks, implementation evidence, and delivery evidence.
+- Do not block ordinary implementation on branch or PR work when GitHub CLI,
+  browser use, write permissions, or available auth can handle it.
+- Do not merge when checks fail, required review rules block merge, the merge
+  would be destructive or monetary, or the task explicitly says not to merge.
+- If PR creation or merge is blocked, require current_state.md to record the
+  exact blocker, repo, branch, PR URL if any, checks status, and remaining
+  action.
+
+What to do:
+1. Read the goal, project_state/memory.md, and all session project_state files.
+2. Read recent iteration artifacts when they are relevant, especially inner loop
+   results waiting for review.
+3. Review any tasks marked "inner complete, waiting for outer".
+4. Verify each reviewed task against its task README acceptance criteria.
+5. If a task is complete, mark only that task completed, update what_we_have.md,
+   and add an accepted-completion entry to finished.md.
+6. If a task is incomplete, mark it failed with this iteration number and record
+   clear follow-up in current_state.md.
+7. Update dependencies and blocked/available statuses.
+8. Create or refresh the next small set of available leaf tasks.
+9. Ensure each available task has a README.md with:
+   - Purpose
+   - Relevant context
+   - Dependencies
+   - Acceptance Criteria as checkbox bullets
+   - Delivery with:
+     - PR expected: yes/no
+     - Merge expected: yes/no
+     - Repos involved
+     Default PR expected and Merge expected to yes for implementation tasks
+     that change repo files. Default both to no only for session-state-only,
+     eval-only, research-only, or planning-only tasks.
+   - Analysis / research expectations when the task has meaningful
+     uncertainty. Keep this high-level: describe the uncertainty and useful
+     source types, not a rigid research script.
+   - Execution shape: prefer an integrated runnable slice unless a small proof
+     is needed to resolve a major conceptual, destructive, or monetary risk.
+   - Suspected blocker handling when relevant: require root-cause
+     investigation, alternate routes, and precise evidence before accepting a
+     blocker.
+10. Update current_state.md with the next expected inner-loop task.
+11. Update decisions.md for meaningful planning choices.
+12. Update memory.md only when a durable fact changes.
+13. Leave session `control.json` unchanged unless you are stopping the loop
+    because the full goal is met or because a true terminal blocker remains
+    after all useful tasks are exhausted. When stopping, write the stop payload
+    to the rendered Session control path.
+
+Do not implement planned tasks unless the change is limited to the session
+project_state files. The next inner loop owns implementation.
+
+
+
+You will make an agentic team to achieve the implementation part.
+
+Create an agent team to do it. They should be responsible for:
+- making preparation steps using CODEX
+    - create a dedicated directory in `_feature_planning/` withing the session directory.
+- deciding if a research/analysis step is necessary using CODEX
+    - take this step especially seriously when the selected task mentions
+      meaningful uncertainty, third-party APIs, SaaS behavior, auth, browser
+      setup, SDK/version ambiguity, or unclear live-system contracts.
+- if the research step is necessary, then trigger researching agents using GEMINI, CODEX, CLAUDE
+    - use internet, GitHub search/CLI, official docs, source repos, SDK
+      examples, GitHub issues, CLI help, browser automation, live read-only
+      probes, and downloaded repos/docs as appropriate.
+    - do not be afraid to download relevant repos, SDKs, examples, or docs into
+      `_additional_context/` and inspect them locally.
+    - write down your findings into markdown file/s.
+- coming up with a plan how to do it using CODEX
+    - the plan should be outputted to `_feature_planning` directory and should be based on the findings from the previous research
+    - Create a dedicated directory withing the `_feature_planning` and then create markdown file there called "plan.md".
+    - After writing the plan, you can ask me additional questions in "questions.md". Always include a recommended solution.
+    - Think very deeply before you start writing.
+    - Try to keep the potential solution simple.
+    - think of acceptance criteria and write them down
+    - The goal is to make a system that would be easy to understand and maintain.
+    - think if and how to update README.md and docs/ referenced by CLAUDE.md and AGENTS.md.
+- if the plan is updated after reviews, tend to pass the updated plan and questions to reviewers again
+- reviewing the plan and the acceptance criteria and also the recommended solutions to the questions using CODEX
+    - if there are any shortcomings with the plan, return the work back to the planning agent together with the feedback
+    - if you don't agree with the recommended solutions to the questions, or can have better alternative, return the work back to the planning agent together with the feedback
+    - review for simplicity and robustness
+    - think of possible deployment-related shortcomings as well
+    - think ultradeeply on this one
+- reviewing the plan and the acceptance criteria and also the recommended solutions to the questions WITH CLAUDE!
+    - if there are any shortcomings with the plan, return the work back to the planning agent together with the feedback
+    - if you don't agree with the recommended solutions to the questions, or can have better alternative, return the work back to the planning agent together with the feedback
+    - review for simplicity and robustness
+    - think of possible deployment-related shortcomings as well
+    - think ultradeeply on this one
+- doing the actual plan execution using CODEX
+- reviewing that the plan was followed and that the acceptance criteria were met using CLAUDE
+    - be extra thorough in you examination
+    - if there are any shortcomings in the implementation, return it back to the execution agent
+- for implementation work that changes repo files, making a new branch, opening a PR, waiting for checks, and merging it
+    - choose the main development branch, e.g. develop, dev, or main
+    - if you saved screenshots related to the PRs, include them in the PR
+    - make the description very descriptive
+    - if work spans multiple repos, create and merge one PR per changed repo when possible
+    - do not merge when checks fail, required review rules block merge, the merge would be destructive or monetary, or the task explicitly says not to merge
+    - if PR creation or merge is blocked, record the exact blocker and remaining action in current_state.md
+- making sure PR/branch/merge delivery evidence is linked from finished.md when present
+- making sure you the "rules" above were followed
+
+Create any additional agents as you see fit.
+
+All the agents should think ultra deeply. At the same time, try to keep things simple.
+
+A reminder - you have access to the following CLIs:
+    - Github
+    - gcloud
+
+You also have access agent-browser for any browser automation, web testing, scraping, screenshotting etc
+    - Before running commands, load the workflow guide once per session: `agent-browser skills get core` (or `--full` for the complete command reference). Specialized sub-skills: `electron`, `slack`, `dogfood`, `vercel-sandbox`, `agentcore` — load via `agent-browser skills get <name>`.
+
+Don't ask the human any questions.

loopy_loop/templates/inner_outer_eval/loopy_loop_config.yaml

@@ -0,0 +1,45 @@
+goal_file: loopy_loop_goal.txt
+workflow_set: inner_outer_eval
+max_turns: 160
+goal_check_consecutive_failures_cap: 3
+team_harness_provider: "codex"
+team_harness_model: "gpt-5.5"
+team_harness_agents:
+  - "codex"
+  - "claude"
+  - "gemini"
+team_harness_agent_models:
+  codex: "gpt-5.5"
+  claude: "claude-opus-4-8"
+  gemini: "gemini-3.5-flash"
+team_harness_agent_reasoning_efforts:
+  codex: "high"
+# Optional coordinator retry controls. Omit to use team-harness defaults.
+# team_harness_max_retries: 8
+# team_harness_retry_base_delay_s: 2.0
+# team_harness_retry_max_delay_s: 60.0
+team_harness_api_base: "https://openrouter.ai/api/v1"
+team_harness_api_key_env: "OPENROUTER_API_KEY"
+team_harness_system_prompt_extension: |
+  Session state rule:
+  - project_state/finished.md is the accepted-completion ledger.
+  - Only the outer loop should add entries, after reviewing completed
+    inner-loop work.
+  - Other workers should link their artifacts from current_state.md or their
+    own outputs, not mark work finished.
+  - The outer loop must read updates_from_user.md every run. If it contains
+    content, reflect it into durable project_state files and clear it only
+    after doing so.
+  PR, branch, and merge rule:
+  - For implementation work that changes repo files, create a branch, open a
+    PR, wait for checks, and merge it.
+  - Default to PR + merge expected unless the task is session-state-only,
+    eval-only, research-only, planning-only, or the repo has no usable remote
+    or CLI auth.
+  - For multi-repo work, create and merge one PR per changed repo when possible.
+  - Do not wait for a human for ordinary branch creation, PR creation, GitHub
+    CLI use, browser use, write permissions, or available auth.
+  - Do not merge when checks fail, required review rules block merge, the merge
+    would be destructive or monetary, or the task explicitly says not to merge.
+  - If PR creation or merge is blocked, record the exact blocker, repo, branch,
+    PR URL if any, checks status, and remaining action in current_state.md.

loopy_loop/templates/inner_outer_eval/loopy_loop_goal.txt

@@ -0,0 +1,5 @@
+Build a browser-playable multiplayer game inspired by Atomic Bomberman, where
+each of at least four unique characters has a passive and four active
+abilities bound to Q, W, E, R with cooldowns - in the spirit of League of
+Legends champion kits. The MVP supports 2-4 players on one map, destructible
+walls, chain explosions, pickups, and a last-player-standing win condition.

loopy_loop/templates/pm_planner_dispatcher/.gitignore

@@ -0,0 +1 @@
+.loopy_loop/sessions/

loopy_loop/templates/pm_planner_dispatcher/.loopy_loop/workflow_sets/pm_planner_dispatcher/workflows/dispatcher/config.yaml

@@ -0,0 +1,8 @@
+enabled: true
+priority: 10
+run_every: 1
+must_follow: planner
+not_before_iteration: 1
+description: |
+  Create one child-session request for the selected PM item or import terminal
+  child-session evidence back into PM state.