compozy/compozy

Before Local scripts → After Not checked yet

7ccc00670d1e → 14f57173e5ca

SKILL.md was removed.

- 1 ---
- 2 name: batuta-routing
- 3 description: Default cost/complexity routing table for the batuta conductor. Read at bootstrap as a starting point, validated against the live provider catalog, then stored as the per-workspace loop configuration; the stored workspace override is authoritative afterwards.
- 4 ---
- 5 
- 6 # Batuta Routing Table
- 7 
- 8 Batuta's core opinion: route every task to the cheapest executor that can
- 9 handle it. Lanes use the `complexity` vocabulary that `cy-create-tasks`
- 10 writes into task frontmatter (`low`, `medium`, `high`, `critical`) — the
- 11 same vocabulary `runtime_rules[].match.complexity` matches on.
- 12 
- 13 ## Lane semantics (the durable opinion)
- 14 
- 15 | Lane       | Intent                                | Selection rule                                             |
- 16 | ---------- | ------------------------------------- | ---------------------------------------------------------- |
- 17 | `low`      | Contained change, well-trodden paths  | Cheapest coding-capable model in the catalog               |
- 18 | `medium`   | New interfaces, moderate coordination | Mid-tier coding model; raise reasoning before raising cost |
- 19 | `high`     | New subsystem, heavy reasoning        | Strong coding model, premium tier acceptable               |
- 20 | `critical` | Cross-cutting, high regression risk   | The operator's most trusted frontier model                 |
- 21 
- 22 ## How batuta derives the concrete table (never copy an example)
- 23 
- 24 1. `compozy__provider_models_list` (with costs) is the ONLY source of
- 25    concrete provider/model IDs — it reflects the CLIs actually installed
- 26    and the models actually discovered on this machine. A provider absent
- 27    from the catalog is not installed; never route to it.
- 28 2. Map each lane's selection rule onto the catalog using the cost fields
- 29    (`input_per_million` / `output_per_million`) as evidence.
- 30 3. Model enablement is account-side and invisible to the daemon — present
- 31    the derived table (with costs) to the operator for confirmation before
- 32    storing; ask what their accounts enable when in doubt.
- 33 
- 34 ### Example only — derived on one machine on 2026-08-11, DO NOT reuse
- 35 
- 36 On that machine the derivation produced: `low → codex/gpt-5.6-luna`,
- 37 `medium → codex/gpt-5.6-terra@high`, `high → codex/gpt-5.6-sol`,
- 38 `critical → claude/claude-opus-4-8`. Your catalog will differ; derive, do
- 39 not copy.
- 40 
- 41 ## Canonical rule shape
- 42 
- 43 This is the exact JSON SHAPE batuta writes with `compozy__loop_configure`
- 44 (stored per-workspace override for `implement-tasks`) after deriving the
- 45 values from the catalog — the model/provider strings below are the same
- 46 dated example as above and MUST be replaced by the derived ones. The stored
- 47 override is what `run-loop` children resolve at execution — batuta never
- 48 sends per-run rules on dispatch, because per-run rules freeze into the run
- 49 and are not inherited by `run-loop` children anyway. Rule matching
- 50 precedence inside the stored layer: `id > type > complexity`.
- 51 
- 52 ```json runtime_rules
- 53 [
- 54   { "match": { "complexity": "low" }, "runtime": { "provider": "codex", "model": "gpt-5.6-luna" } },
- 55   {
- 56     "match": { "complexity": "medium" },
- 57     "runtime": { "provider": "codex", "model": "gpt-5.6-terra", "reasoning": "high" }
- 58   },
- 59   { "match": { "complexity": "high" }, "runtime": { "provider": "codex", "model": "gpt-5.6-sol" } },
- 60   {
- 61     "match": { "complexity": "critical" },
- 62     "runtime": { "provider": "claude", "model": "claude-opus-4-8" }
- 63   }
- 64 ]
- 65 ```
- 66 
- 67 ## Provider quirks
- 68 
- 69 - Some providers multiplex upstreams and require the model field to carry a
- 70   prefix — e.g. `opencode` only binds `opencode/kimi-k2.5`, never bare
- 71   `kimi-k2.5`. The catalog's exact `model_id` is authoritative; copy it
- 72   verbatim into the rule.
- 73 - A model can exist in the catalog and still be disabled for the operator's
- 74   account at the provider (invisible to the daemon). When a lane fails its
- 75   bind with zero tokens, ask the operator what their account enables.
- 76 
- 77 ## Escalation and reclassification
- 78 
- 79 - Repeated failure in a lane: write a surgical `id` rule one lane up into
- 80   the STORED override (`compozy__loop_configure` on `implement-tasks`, e.g.
- 81   `{"match":{"id":"task_NN"},"runtime":{...}}` prepended to the rules), then
- 82   re-dispatch `batuta-deliver`. `id` beats `complexity`; remove the rule
- 83   after the task lands.
- 84 - Operator reclassification in conversation ("use luna for this one")
- 85   becomes the same stored `id` rule before the next dispatch.
- 86 - The daemon persists `resolved_runtime` with per-field provenance on every
- 87   generation — routing decisions are auditable via `compozy__loop_status`,
- 88   never narrated.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

- 11 2. State the motivating problem, observable outcome, scope, and non-goals. Ask focused questions only for decisions the evidence cannot settle; apparent simplicity is not evidence. An approved direction satisfies the product checkpoint; do not repeat an interview or approval already completed. For an open-ended product interview, use the relevant branch of `references/grill-protocol.md`.
+ 11 2. State the motivating problem, observable outcome, scope, and non-goals. Ask focused questions only for decisions the evidence cannot settle, always in the format from `references/grill-protocol.md`; apparent simplicity is not evidence. An approved direction satisfies the product checkpoint; do not repeat an interview or approval already completed. For an open-ended product interview, use the relevant branch of `references/grill-protocol.md`.
- 16 7. Perform an inline self-check: verify that the motivating outcome is covered, public contracts agree across companions, changed interfaces use the project's language, each test invariant has an owning suite, and existing input/reference paths resolve in the target project or this skill's bundled resources. Mark new files and output destinations as planned; they need not exist before implementation. Record inapplicable sections and unresolved decisions explicitly. Check the earliest useful end-to-end outcome. Choose slice count from dependencies/risk; `slice_budget` is a planning preference, not a forced split or permission loop.
- 17 8. Save reviewable files and summarize unresolved decisions. After the user approves the saved spec, offer an optional independent review using the user's available reviewer or review process; include the saved spec and companion contracts, ask for concrete gaps and contradictions, and apply only user-selected findings. If no reviewer is available, report that limitation; the self-check above requires no external skill. Do not start implementation merely because spec writing is complete.
+ 16 7. Write `_slices.md`, the delivery order that spec delivery reads:
- 19 Templates are section guides: keep shared outcome/contract content, omit irrelevant sections or record a short reason where a downstream schema requires a slot. Read each reference when its branch is used, not the whole package. Maintain a concise File References index naming contract inputs and why each matters; tasks copy their relevant subset. Preserve requested scope; narrowing an accepted motivating problem requires the user's recorded decision.
+ 18    ```markdown
+ 19    | Slice | Layer    | Depends on | Scope           | Spec refs |
+ 20    | ----- | -------- | ---------- | --------------- | --------- |
+ 21    | S1    | backend  | none       | Export contract | US-001    |
+ 22    | S2    | frontend | S1         | Export dialog   | US-002    |
+ 23    ```
+ 24 
+ 25    One row per independently verifiable slice. `Layer` names the owning layer, `Depends on` lists slice IDs or `none`, and `Spec refs` cites the stories or sections it delivers. Choose slice count from dependencies and risk, and let unrelated slices run in parallel. The first slices should reach the earliest useful end-to-end outcome.
+ 26 
+ 27 8. Perform an inline self-check: verify that the motivating outcome is covered, public contracts agree across companions, changed interfaces use the project's language, each test invariant has an owning suite, every story belongs to a slice, slice dependencies are acyclic, and existing input/reference paths resolve in the target project or this skill's bundled resources. Mark new files and output destinations as planned; they need not exist before implementation. Record inapplicable sections and unresolved decisions explicitly. Check the earliest useful end-to-end outcome.
+ 28 9. Save reviewable files and summarize unresolved decisions. After the user approves the saved spec, offer the optional peer review in `references/peer-review.md`. Do not start implementation merely because spec writing is complete.
+ 29 
+ 30 Templates are section guides: keep shared outcome/contract content, omit irrelevant sections or record a short reason where a downstream schema requires a slot. Read each reference when its branch is used, not the whole package. Maintain a concise File References index naming contract inputs and why each matters; slice briefs copy their relevant subset. Preserve requested scope; narrowing an accepted motivating problem requires the user's recorded decision.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Not checked yet

7ccc00670d1e → 14f57173e5ca

SKILL.md was removed.

- 1 ---
- 2 name: cy-create-tasks
- 3 description: "Create or refine a task graph from an existing CompozyOS spec, with outcome, dependency, and test ownership."
- 4 ---
- 5 
- 6 # Create Tasks
- 7 
- 8 Decompose an existing requested spec into independently implementable outcomes. Reuse its decisions and file-reference index; a new task does not require starting research from zero.
- 9 
- 10 1. Start from the requested scope and `_spec.md` outcome/reference index. Reuse the accepted graph; read only the assigned test definitions and relevant surface/ADR sections needed to establish a task boundary or resolve a dependency. Expand into code when an ownership or contract question remains.
- 11 2. Choose outcomes and dependencies. Put the earliest useful solution to the motivating problem first. A foundation task names its consumer and verifies its boundary. Resolve a shared contract before dispatching its consumers, or keep the coupled work in one task. Size by risk and ownership; file count and a default five-slice quota do not decide the cut.
- 12 3. Use `references/task-context-schema.md` when creating or changing metadata/graph structure. `_tasks.md` owns dependencies; individual frontmatter owns task status/type/complexity. Preserve runtime routing and keep the display table consistent with the graph.
- 13 4. Use `references/task-template.md` for the task body. Include its outcome, relevant constraints/files, checks, and acceptance; omit empty or inapplicable sections. Link the owning compatibility/impact analysis and applicable ADR/external references instead of copying them.
- 14 5. Assign every existing test-contract ID exactly once to the task completing that behavior. Reuse its canonical suite. Missing cases need a concrete invariant/input/result; do not create tests merely to populate a template. A task with existing sufficient coverage records that evidence.
- 15 6. Assign task checks and remaining integration checks to one owner each. For named visual references, use the template's Visual Contract rows and evidence owner; ordinary UI edits do not acquire reference parity. A full delivery graph retains its QA planning/execution pair for remaining journeys/visual rows once, with current evidence reused. Full suites/labs follow actual scope or policy.
- 16 7. Generate the requested files using quoted/escaped YAML titles whose decoded values match their first H1. Before delivery, call the read-only `ext__spec_cycle__import_tasks` tool with `{"pattern":".compozy/tasks/<workflow>/task_*.md"}` against the generated task set; repair any parse/validation error and rerun. A successful import validates the package even when `passed` is false (that field means all tasks are completed). Compare imported pending task titles with their first H1 text. Check graph consistency, test ownership, outcome coverage, and applicable visual rows once. Preserve approval already given; a new decision is needed only when an unresolved scope/dependency choice blocks a correct graph. Update completed tasks only when their inputs changed.
- 17 
- 18 A missing spec or unresolved contract is reported concretely; gather available context before asking. Do not silently drop requested outcomes or test IDs, fabricate unavailable references, or repeat enrichment across already-grounded tasks.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Not checked yet

7ccc00670d1e → 14f57173e5ca

SKILL.md was removed.

- 1 ---
- 2 name: cy-execute-task
- 3 description: "Implement and verify an existing CompozyOS spec task, then update its tracking. Excludes review remediation."
- 4 ---
- 5 
- 6 # Execute Spec Task
- 7 
- 8 Complete the task's accepted outcome, applicable verification, and tracking. Continue through running the changed behavior and repairing failures within the authorized scope; the first implementation is not a review handoff unless the user requested one.
- 9 
- 10 ## Ground Once
- 11 
- 12 Read the task, applicable repository instructions, and the relevant `_spec.md`/graph context. Use the task's File References and any current contract inventory to find assigned tests, canonical examples, surface contracts, and relevant ADRs. Read those sections and follow their necessary dependencies; expand the survey only when the index is incomplete, stale, or ambiguous. A fresh native explorer and a full read of every sibling file are not mandatory.
- 13 
- 14 Canonical examples, typed constraints, assigned test cases, and approved visual artifacts outweigh a task-file paraphrase. Current user decisions and repository compatibility policy remain authoritative. Resolve ordinary discrepancies at the owning contract and record the decision briefly. A missing contract or unresolved product/authorization decision is a real blocker; do not invent a partial substitute and mark it complete.
- 15 
- 16 ## Implement and Verify
- 17 
- 18 1. Track deliverables, assigned test IDs, and applicable acceptance criteria in the existing task/checklist. A separate printed item-by-item checklist is unnecessary.
- 19 2. Capture or reuse the pre-change evidence needed for a bug/behavior claim. Implement only the task-owned changes, following nearby patterns and real dependency APIs.
- 20 3. For a named visual contract, inspect the reference and one representative implementation state early. Complete the required states/viewports using the target project's screenshot/comparison tooling at their assigned verification boundary: this task for standalone delivery, or the named integration/QA task in a loop. Production content, primitives, and host chrome retain their owners.
- 21 4. Review the changed diff before final validation. Run the checks that prove this task's outcome, plus required project gates, reusing current evidence for unchanged inputs. Apply `cy-final-verify` as the evidence standard within this step, not a second review/test/report cycle. A task checkpoint still follows repository commit policy.
- 22 5. Verify affected canonical facts and assigned test IDs; fix mismatches and failures at their owner. In a loop, record the focused result and flag affected QA scenarios with the remaining walks/visual rows and their workflow owner. Full QA, a new lab, both E2E suites, and a complete screenshot bundle are not automatic per-task requirements. Preserve an explicit task acceptance requirement for a live probe or visual proof; do not mark an unverified requirement complete.
- 23 
- 24 ## Tracking and Commits
- 25 
- 26 Use caller-provided memory/tracking paths. For long-running or handed-off work, update relevant decisions, changed surfaces, and evidence once; `cy-workflow-memory` owns those files. Mark task checkboxes/status complete only after the requested outcome is verified. `_tasks.md` owns graph topology and is not rewritten during normal completion.
- 27 
- 28 Use `references/tracking-checklist.md` for tracking ambiguity or drift. Commit/push follow the caller's requested delivery scope: with auto-commit disabled, leave the owned diff for the controller; with authorized commit/push delivery, continue through its required checks. This skill does not grant new publishing authority. Preserve unrelated work and stage only owned paths.
- 29 
- 30 On failure, keep task status truthful, repair the relevant cause, and recheck affected evidence. Report a concrete external/missing-contract blocker when progress depends on it; routine uncertainty is resolved from the available contract rather than converted into a permission question.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Not checked yet

7ccc00670d1e → 14f57173e5ca

SKILL.md was removed.

- 1 ---
- 2 name: cy-final-verify
- 3 description: "Assess a spec task or delivery claim against its contract and available verification evidence."
- 4 ---
- 5 
- 6 # Verify the Requested Result
- 7 
- 8 Identify the requested outcome, verification boundary, and remaining obligations.
- 9 Use this inside the caller's existing validation step; it does not start another
- 10 implementation, review, test, or QA cycle or authorize publishing.
- 11 
- 12 Compare the result with the accepted contract and user goal, using already-grounded
- 13 canonical examples and acceptance criteria. Pick the cheapest owning suite, probe,
- 14 or artifact check that can expose a missing or failed behavior. Inspect the actual
- 15 result and exit status. Reuse evidence while its source, dependencies, build/config,
- 16 and environment remain applicable; a new message, handoff, or commit alone does
- 17 not invalidate it. An unchanged HEAD does not prove a dirty tree was checked.
- 18 
- 19 Repository delivery policy owns commit/push gates and required CI at the current
- 20 head. Reuse the project's valid cached checks; do not invent an additional full
- 21 local run. A focused result supports its focused claim. A loop checkpoint names
- 22 pending integration/visual checks and their owner without claiming they ran; the
- 23 workflow resolves them before final delivery.
- 24 
- 25 Read only the applicable reference when its details are needed:
- 26 
- 27 - [Conditional contracts](references/conditional-contracts.md): the matching bug,
- 28   spec, user-visible QA, named visual reference, or created-lab section.
- 29 - [PR delivery](references/pr-delivery.md): when commit/push/PR delivery is requested
- 30   and the caller does not already own that procedure.
- 31 
- 32 Finish when the requested result and applicable checks are satisfied. Repair
- 33 failures at their source and repeat only invalidated checks; preserve valid tests
- 34 and warning/error policy. Continue authorized repairs without a review pause after
- 35 the first implementation. Report a concrete blocker when a missing external input
- 36 prevents completion.
- 37 
- 38 Summarize the outcome, evidence, and material limits in the caller's existing
- 39 report. Link larger artifacts when needed; do not create another checklist/report
- 40 or broaden validation solely because a companion skill is installed.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Not checked yet

7ccc00670d1e → 14f57173e5ca

SKILL.md was removed.

- 1 ---
- 2 name: cy-fix-reviews
- 3 description: Executes agent-authored review remediation using existing round files under .compozy/tasks/<name>/reviews-NNN/. Use when resolving batched review issues, updating issue markdown files, implementing fixes, and verifying the result. Do not use for task execution, review generation, or generic coding tasks without review issue files.
- 4 ---
- 5 
- 6 # Fix Reviews
- 7 
- 8 Execute the review remediation workflow in a strict sequence. The review files already exist and define the full scope for the run.
- 9 
- 10 ## Required Inputs
- 11 
- 12 - The scoped issue files listed in `<batch_issue_files>`.
- 13 - The task review round directory and issue-file frontmatter.
- 14 - The repository verification workflow required by `cy-final-verify`.
- 15 
- 16 ## Workflow
- 17 
- 18 1. Gather round context.
- 19    - Read the scoped issue file frontmatter to understand the round number and issue status/severity. If multiple issue files are in scope, verify their `round` and `round_created_at` values agree.
- 20    - Read `<batch_scope>` to identify the task name, review round, code files in scope, and conditional flags such as auto-commit.
- 21 
- 22 2. Read and triage the scoped issue files.
- 23    - Read every listed issue file completely before editing code.
- 24    - Update each issue file frontmatter `status` from `pending` to `valid`, `invalid`, `unresolved`, or `blocked`.
- 25    - Record concrete technical reasoning in `## Triage`: state why the issue is valid or invalid, identify the root cause if valid, outline the intended fix approach, or explain why it is unresolved/blocked.
- 26 
- 27 3. Fix valid issues completely.
- 28    - Fix issues in severity order: critical first, then high, medium, low. This ensures the most impactful fixes land even if the batch is interrupted.
- 29    - Implement production-quality fixes for every `valid` issue in scope.
- 30    - Name the changed invariant and its owning suite. Reuse existing coverage; add or update a test only for a coverage gap. Test edits needed to validate the fix are in scope.
- 31    - Keep code changes constrained to the files listed in `<batch_scope>` code files. If a fix absolutely requires touching a file not listed there, limit the change to the minimum needed and document why in the issue file's `## Triage` section.
- 32    - Do not refactor, clean up, or improve code that is unrelated to the issues being fixed.
- 33 
- 34 4. Close out issue files correctly.
- 35    - Leave a `valid` issue at frontmatter `status: valid` after the code and focused verification are done.
- 36    - Leave an `invalid` issue at frontmatter `status: invalid` after documenting why it is invalid.
- 37    - For a valid finding that cannot be resolved in this cycle because it requires an external change or an out-of-scope dependency, set frontmatter `status: unresolved` (or `blocked`), document the blocker in `## Triage` with `- Decision: UNRESOLVED` (or `BLOCKED`), and return `resolution: unresolved` (or `blocked`).
- 38    - Never set `status: resolved`; the Loop's Go finalizer owns that transition after the batch completes.
- 39 
- 40 5. Verify before completion.
- 41    - Use `cy-final-verify` before any completion claim or automatic commit.
- 42    - Run the real checks required for the scoped fix; reuse current evidence for unchanged inputs. The workflow owner handles remaining delivery gates.
- 43    - If verification fails, fix the failing checks in the code you changed. Do not revert your fixes to pass verification -- find the root cause of the failure and address it. If the failure is in pre-existing code unrelated to your changes, document it in the relevant issue file’s `## Triage` section and proceed. If two fixes conflict with each other and verification cannot pass after two attempts, document the conflict in both issue files and report the situation rather than looping indefinitely.
- 44    - If all issues in the batch are invalid and no code was changed, skip the commit step entirely -- do not create an empty commit. Cite the triage evidence; do not run product tests solely for issue-status prose.
- 45    - Leave the diff ready for manual review unless `<batch_scope>` shows "Automatic commits: enabled".
- 46 
- 47 ## Critical Rules
- 48 
- 49 - Do not generate another review inside this workflow. The reviewer agent already produced the round files.
- 50 - Do not publish or push changes. This workflow is local-only.
- 51 - Do not modify issue files outside the scoped batch.
- 52 - Do not create, rename, timestamp, or mark an issue `resolved`; the Go writer and finalizer own those bytes.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Not checked yet

7ccc00670d1e → 14f57173e5ca

SKILL.md was removed.

- 1 ---
- 2 name: cy-orchestrate-tasks
- 3 description: Conducts one spec's tasks by delegation — spawns a dedicated bounded worker session per task, dispatches the briefing, and uses the task file on disk for completion state and checks its verification evidence. Use when a prompt names a spec slug under .compozy/tasks/ and asks for its tasks to be orchestrated across worker sessions. Do not use for implementing a task directly, for review remediation, or for QA and pull-request work.
- 4 ---
- 5 
- 6 # Orchestrate Spec Tasks
- 7 
- 8 This session is the **conductor** of the spec: it conducts, it does not play. Every task under
- 9 `.compozy/tasks/<slug>/` is implemented by a dedicated CompozyOS worker session.
- 10 
- 11 ## Required Inputs
- 12 
- 13 - `slug` — the directory name under `.compozy/tasks/<slug>/`, holding `_tasks.md` (the task graph)
- 14   and `task_NN.md` files whose frontmatter carries `status`, `title`, and `type`.
- 15 - `implementer` — the exact validated Agent identifier supplied in the Goal objective. The Loop
- 16   defaults it to `code_implementer`; the conductor never substitutes that default.
- 17 - `backend_runtime`, `frontend_runtime`, and `default_runtime` — optional runtime objects supplied
- 18   in the Goal objective. Each can carry `provider`, `model`, `reasoning`, and `speed`.
- 19 
- 20 ## Workflow
- 21 
- 22 ### 1. Load the task graph
- 23 
- 24 Read `.compozy/tasks/<slug>/_tasks.md` and derive the execution order from `graph.edges`. Read the
- 25 frontmatter of every `task_NN.md`. Queue only tasks whose `status` is `pending` or `in_progress`,
- 26 in graph order. Treat `completed`, `complete`, `done`, and `finished` as already completed, ignoring
- 27 case and surrounding whitespace. Stop on unknown or missing statuses before spawning workers;
- 28 report the task file and invalid value instead of guessing.
- 29 
- 30 _Done when:_ the queue lists the id, `title`, and `status` of every queued task, in execution order.
- 31 
- 32 ### 2. Spawn the worker session
- 33 
- 34 Choose the worker runtime by exact frontmatter type: `backend` uses `backend_runtime`, `frontend`
- 35 uses `frontend_runtime`, and every other value uses `default_runtime`. Merge the task's own
- 36 frontmatter `runtime` over that category object field by field before building spawn flags. Create
- 37 one bounded `spawned` session bound to this conductor. Bind the exact `implementer` value from the
- 38 Goal once, then pass it as one quoted argument. TTL and parent-stop are the containment contract;
- 39 `--ttl-seconds` is mandatory.
- 40 
- 41 The child starts with no delegated tools when permission atoms are omitted. Before spawning,
- 42 inspect this conductor's session lineage permission policy and the worker's required operations.
- 43 Pass an explicit subset of the parent's concrete tool IDs: the bootstrap set below supports
- 44 native discovery, descriptor reads, skill lookup, and retained-reference reads. Add only task-required
- 45 tools the parent can delegate. If a required tool is absent from the parent budget, block with that
- 46 missing ID; do not retry without permissions, grant wildcards, or bypass a denial through files/CLI.
- 47 Other permission categories remain empty unless the task needs an explicit parent-authorized subset.
- 48 
- 49 For native `compozy__session_spawn`, put these same IDs in `tools`; use the live descriptor for
- 50 any additional fields. The equivalent CLI recipe is:
- 51 
- 52 ```bash
- 53 IMPLEMENTER="<exact implementer identifier from the Goal>"
- 54 compozy spawn --agent "$IMPLEMENTER" \
- 55   --name "orchestrate-<slug>-<task_id>" \
- 56   --role worker \
- 57   --tool compozy__tool_search \
- 58   --tool compozy__tool_info \
- 59   --tool compozy__tool_artifact_read \
- 60   --tool compozy__skill_search \
- 61   --tool compozy__skill_view \
- 62   --ttl-seconds 3600 \
- 63   --auto-stop-on-parent=true \
- 64   --idempotency-key "orchestrate-<slug>-<task_id>" \
- 65   -o json
- 66 ```
- 67 
- 68 Append `--provider`, `--model`, `--reasoning-effort`, and `--speed` only for non-empty fields in the
- 69 selected runtime object; `reasoning` maps to `--reasoning-effort`. When every field is empty, omit
- 70 provider, model, and reasoning flags so the child resolves them through the selected Agent and
- 71 workspace. Under current spawn behavior, omitted speed inherits the parent session. Capture
- 72 `.session.id`.
- 73 
- 74 When the spawn response is lost or ambiguous, reconcile before acting — a blind respawn creates a
- 75 second worker for one task:
- 76 
- 77 ```bash
- 78 compozy session list \
- 79   --parent "$COMPOZY_SESSION_ID" \
- 80   --type spawned \
- 81   --state active \
- 82   --query "orchestrate-<slug>-<task_id>" \
- 83   -o json
- 84 ```
- 85 
- 86 Reuse the id only when exactly one returned session has `name` equal to
- 87 `orchestrate-<slug>-<task_id>` and `agent_name` equal to `$IMPLEMENTER`. Zero results after a
- 88 confirmed spawn failure blocks the task. A mismatched `agent_name` is never adopted or followed by
- 89 a blind respawn: stop the session only when its parent and exact name prove conductor ownership,
- 90 then block the task. More than one exact match: stop every conductor-owned match and block the task.
- 91 
- 92 _Done when:_ exactly one worker session id is held for this task, or the task is marked blocked.
- 93 
- 94 ### 3. Dispatch the briefing and wait
- 95 
- 96 Send the briefing and wait in the same command. `compozy session prompt` blocks until the worker's
- 97 turn ends in every output mode; `-o jsonl` is the form that also leaves a durable per-task event log
- 98 as evidence:
- 99 
- 100 ```bash
- 101 mkdir -p .compozy/tasks/<slug>/logs
- 102 compozy session prompt <session_id> "<briefing>" \
- 103   -o jsonl > .compozy/tasks/<slug>/logs/<task_id>.jsonl 2>&1
- 104 ```
- 105 
- 106 `--queue`, `--interrupt`, and `--steer` return at admission instead of at turn end, so they cannot
- 107 carry a briefing this workflow waits on.
- 108 
- 109 _Done when:_ the command has returned and its outcome is recorded, including a failed prompt.
- 110 
- 111 ### 4. Check the proof
- 112 
- 113 Re-read the task file frontmatter. Workers write `status: completed`; the importer also accepts
- 114 `complete`, `done`, and `finished` (ignoring case and surrounding whitespace). The
- 115 worker's closing message alone never completes a task. Check the referenced verification evidence
- 116 against the task contract and current inputs; a status label is not proof that checks passed.
- 117 Reuse valid worker evidence instead of rerunning the same suite.
- 118 
- 119 If the status is not a recognized completion state, send one corrective prompt in the **same** session, using the same
- 120 blocking form, naming exactly what is missing. A second failure produces a `blocked` result citing

This preview is limited. See the complete change on GitHub.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Not checked yet

7ccc00670d1e → 14f57173e5ca

SKILL.md was removed.

- 1 ---
- 2 name: cy-review-round
- 3 description: Performs a comprehensive code review of a spec implementation and generates a review round directory with issue files compatible with cy-fix-reviews. Use when reviewing implemented spec tasks, creating a manual review round without an external provider, or performing a quality audit of code changes. Do not use for fetching reviews from external providers, fixing existing review issues, executing spec tasks, or editing source code.
- 4 ---
- 5 
- 6 # Review Round
- 7 
- 8 Perform a structured code review of a spec implementation and produce a review round directory that the `cy-fix-reviews` workflow can process.
- 9 
- 10 ## Required Inputs
- 11 
- 12 - Feature name identifying the `.compozy/tasks/<name>/` directory.
- 13 - Optional: specific files or directories to scope the review.
- 14 
- 15 ## Workflow
- 16 
- 17 1. Determine the review round directory.
- 18    - Derive the spec directory from the feature name: `.compozy/tasks/<name>/`.
- 19    - Verify the spec directory exists. If it does not, stop and report the missing directory.
- 20    - List existing `reviews-NNN/` subdirectories to determine the next round number. If none exist, use round 1.
- 21    - If prior review rounds exist, read their issue files to build a list of already-known issues. The current round must only contain NEW issues not already tracked in prior rounds. Do not re-flag issues that are pending, valid, or resolved in earlier rounds.
- 22    - Determine the review round directory path: `.compozy/tasks/<name>/reviews-NNN/` with the round number zero-padded to 3 digits. Do NOT create it yet — wait until step 4 confirms there are issues to write. This avoids leaving empty directories when the review finds no issues.
- 23 
- 24 2. Identify the review scope.
- 25    - Read `_spec.md` and `_tasks.md` from the spec directory to understand what was implemented and why, plus the contract catalogs `_user_stories.md` and `_tests.md` when present.
- 26    - Read ADRs from `.compozy/tasks/<name>/adrs/` for architectural decision context.
- 27    - If `_spec.md` is missing, warn that the review will lack requirements context but proceed with a code-quality-only review.
- 28    - If the user provided specific files or directories, scope the review to those paths.
- 29    - If no explicit scope was provided, resolve the actual PR or repository base and inspect its merge-base-to-head diff, including owned working-tree changes when requested. Reuse an established scope; ask only if the intended range remains ambiguous.
- 30    - Map the relevant changed paths and consumers locally; use bounded read-only agents only for substantial independent review slices. Reuse current implementation research.
- 31 
- 32 3. Perform the code review.
- 33    - Read `references/review-criteria.md` for severity definitions and evaluation areas.
- 34    - **Prioritize the review scope.** For a large scope, review slice by slice instead of silently sampling: partition the diff by the task boundaries that produced it (task checkpoint commits, `_tasks.md` slices) and review each partition against its task's contract, core implementation files first. When the scope cannot be partitioned and still exceeds what a complete read can honestly cover, say so in the summary and recommend splitting the delivery — a review that silently degrades to sampling at scale certifies nothing.
- 35    - Inspect every changed behavior in the prioritized scope, including enclosing contracts and affected consumers. Read full files when needed to understand their invariants; unchanged boilerplate does not require repeated reading.
- 36    - **Requirements validation**: If `_spec.md` was available in step 2, cross-check the implementation against every stated requirement, acceptance criterion, and architectural decision — including every acceptance criterion and edge case in `_user_stories.md` when it exists. Flag any requirement that is missing, partially implemented, or implemented differently than specified. These are correctness issues — assign severity based on the gap's impact (critical if a core feature is missing, high if behavior deviates from spec, medium if an edge case from the spec is unhandled).
- 37    - **Mission fit**: when `_spec.md` states a Motivating Problem, verify the delivered work solves it and name the slice that does — checking the implementation against the spec alone cannot catch a spec that drifted from its own mission. An ADR that narrowed or deferred the Motivating Problem without the user's recorded sign-off is itself a finding, at the severity of the gap it created.
- 38    - **Test-contract parity**: If `_tests.md` exists, verify that every test ID assigned in completed tasks' `## Tests` sections is implemented in the suite and asserts the behavior the contract specifies. A missing case, or a hollow one that exists without asserting the contracted behavior, is an issue — assign severity based on the impact of the behavior left unverified.
- 39    - Use the relevant evaluation areas for the changed behavior: Security, Correctness, Concurrency, Performance and Scalability, Error Handling, Code Quality and Maintainability, Testing, Architecture, and Operations.
- 40    - Identify issues in severity order: critical first, then high, medium, and low.
- 41    - For each issue record: the file path relative to the repository root, the approximate line number, the severity level, a concise title (max 72 characters), and a detailed review comment describing the problem and a suggested fix.
- 42    - **Deduplicate before writing.** If the same pattern (e.g., missing nil check, missing error wrap) appears in multiple files, create one issue for the most representative instance and list the other affected files in its Review Comment. Do not create N identical issues for N files exhibiting the same root cause. One issue per distinct problem, not per occurrence.
- 43    - **Verify before flagging.** Before creating an issue, check whether the pattern is intentional: look for adjacent comments explaining the choice, ADR references, or test coverage that validates the behavior. If code looks suspicious but has a clear justification (e.g., `// nolint: intentionally ignoring close error on read-only file`), do not create an issue. Only flag patterns that are genuinely problematic, not merely unconventional.
- 44    - Skip issues already owned by linters or formatters. Reuse current scoped gate evidence; run the owning lane only when its result is needed, not an unconditional full lint pass.
- 45    - **Focus on signal, not volume.** Aim for fewer, higher-quality issues rather than an exhaustive list. Deduplicate by root cause and retain actionable findings supported by evidence. Issue counts are not quality targets or caps.
- 46    - Also note well-implemented aspects of the code. These observations inform the summary but do not produce issue files.
- 47    - If no issues are found after a thorough review, report that the implementation looks clean and skip steps 4 through 6. Do not create the review round directory.
- 48 
- 49 4. Generate issue files.
- 50    - Create the review round directory determined in step 1.
- 51    - Read `references/issue-template.md` for the canonical format.
- 52    - For each issue identified in step 3, create an `issue_NNN.md` file in the review round directory.
- 53    - Issue numbering starts at `001` and increments sequentially.
- 54    - Each file must use this exact structure:
- 55 
- 56      ```
- 57      ---
- 58      provider: manual
- 59      pr:
- 60      round: <N>
- 61      round_created_at: <UTC timestamp in RFC3339 format>
- 62      status: pending
- 63      file: path/to/file.go
- 64      line: 42
- 65      severity: high
- 66      author: claude-code
- 67      provider_ref:
- 68      ---
- 69 
- 70      # Issue NNN: <title>
- 71 
- 72      ## Review Comment
- 73 
- 74      <detailed review body>
- 75 
- 76      ## Triage
- 77 
- 78      - Decision: `UNREVIEWED`
- 79      - Notes:
- 80      ```
- 81 
- 82    - The `<author>` field must be `claude-code`.
- 83    - The `provider_ref` field must be empty.
- 84    - The `provider` field must be `manual`.
- 85    - The `pr` field is empty for manual reviews. If the user provides a PR number, include it.
- 86    - The `round` field must match the directory number as an integer (not zero-padded).
- 87    - The `round_created_at` field must use the same current UTC RFC3339 timestamp in every issue in this round.
- 88    - The `severity` field must be exactly one of: `critical`, `high`, `medium`, `low`.
- 89 
- 90 5. Summarize and present the review.
- 91    - Print a summary listing:
- 92      - **Merge recommendation**: If any critical or high issues exist, state "Needs fixes before merge" with the blocking issues. If only medium/low issues exist, state "Safe to merge with follow-ups." If no issues, state "Clean — ready to merge."
- 93      - Total issues found, broken down by severity (critical, high, medium, low).
- 94      - The review round directory path.
- 95      - The full list of generated issue file names.
- 96      - Well-implemented aspects observed during the review.
- 97    - Suggest running `compozy loop run --workspace <ref> --name review-and-fix --input task_name=<name>` to process the review round.
- 98 
- 99 6. Verify before completion.
- 100    - Use installed `cy-final-verify` before claiming the review round is complete.
- 101    - Read back each generated issue file and verify the frontmatter parses correctly.
- 102    - Verify every issue file in the round has matching `provider`, `pr`, `round`, and `round_created_at` values.
- 103    - Confirm the review round directory follows the `reviews-NNN` naming convention.
- 104 
- 105 ## Critical Rules
- 106 
- 107 - Do not fix the issues found. This skill only identifies and documents issues. The `cy-fix-reviews` workflow handles remediation.
- 108 - Do not create issue files for problems that linters or formatters already catch.
- 109 - Every issue file must have valid YAML frontmatter parseable by `prompt.ParseReviewContext()`.
- 110 - Do not create or maintain review `_meta.md`; round metadata lives in each issue file frontmatter.
- 111 - Do not create empty review rounds. If no issues are found, report a clean review and do not create the round directory.
- 112 - Do not modify any source code files. This is a review-only skill.
- 113 - Do not call provider-specific scripts or `gh` mutations.
- 114 
- 115 ## Error Handling
- 116 
- 117 - If the spec directory does not exist, stop and report the missing directory.
- 118 - If no files can be identified for review and the user did not provide explicit paths, ask the user to specify files.
- 119 - If `_spec.md` is missing, warn about the lack of requirements context but proceed with code-quality-only review.
- 120 - If the review round directory cannot be created, stop and report the filesystem error.

This preview is limited. See the complete change on GitHub.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Not checked yet

7ccc00670d1e → 14f57173e5ca

SKILL.md was removed.

- 1 ---
- 2 name: cy-workflow-memory
- 3 description: Maintains workflow-scoped task memory for CompozyOS runs using .compozy/tasks/<name>/memory/ files. Use when a task prompt provides workflow memory paths and requires the agent to read, update, compact, and promote durable context across spec task executions. Do not use for PR review remediation, global user preferences, or programmatic event-log summarization.
- 4 ---
- 5 
- 6 # Workflow Memory
- 7 
- 8 Use the caller-provided shared/current-task memory paths for a continuing workflow. Read them on entry or after lost context; reuse them while current and do not scan unrelated task memories.
- 9 
- 10 Update only when the goal, meaningful decision, blocker, or handoff evidence changes. A new message, status report, or commit alone does not require a rewrite. Keep task-local details in the task file and promote only durable facts another task needs that are not already clear from the spec or repository.
- 11 
- 12 For compaction, preserve current state, decisions, risks, and handoff pointers; remove stale/repeated notes and transcripts. Read `references/memory-guidelines.md` only when its format or promotion rules are needed. Existing schema headings remain when the caller depends on them.
- 13 
- 14 If a supplied path is missing, inspect the caller's documented initialization contract before reporting a concrete blocker; never guess another workflow's path. Repository contracts and current user decisions override stale notes. A short task without a supplied continuity requirement does not need a new memory subsystem.

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Network or broad shell → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Network or broad shell

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Network or broad shell → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Network or broad shell

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Network or broad shell → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Network or broad shell

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Network or broad shell → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Network or broad shell

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Local scripts

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Local scripts → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

Compare on GitHub

Before Not checked yet → After Local scripts

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub

Before Network or broad shell → After Network or broad shell

7ccc00670d1e → 14f57173e5ca

+ 56 For explicit stays-on memory reads or writes, also read `references/agent-memory.md`.
+ 57 
+ 58 - references/agent-memory.md - explicit stays-on agent notes, identity boundaries, budgets, revisions, and memory tools.

Compare on GitHub

Before Not checked yet → After Network or broad shell

First observation → 7ccc00670d1e

No earlier version was observed for comparison.

Compare on GitHub