Reflect

Follow the consuming project's instructions and requested scope; use the portable defaults only where guidance is missing.

Use the current conversation and its artifacts. Do not scan unrelated chat histories or private workspace transcripts.

Method

1. Reconstruct the lesson: the failed assumption, the observation that disproved it and the correction that worked. Ask whether the evidence supports a reusable rule or only one local circumstance. Keep one-off preferences local to the task.
2. Classify the cause: an inapplicable owner, missed trigger/routing, buried method, missing body, or execution failure to follow a clear method. Fix placement/trigger only when observed task/catalog evidence supports it, and do not duplicate an existing guard. Consider lucky success and consequential unexercised paths with concrete evidence, not imagined defects. For repeated-error audits, cluster actual selected corrections, reverts and reviews by cause before generalizing.
3. Find the canonical writable owner before applying an authorized edit. Never edit an installed plugin cache, since updates can replace it. Author in the source rather than generated host links, and preserve that source. Put company-only behavior in a consumer-owned adaptation in the consumer namespace. Shared improvements follow the explicit contribution path. See upstream review for source/pin reconciliation.
4. Choose the narrowest durable enforcement: a representation that excludes an invalid state, an existing validation rule, or a focused instruction when judgment is unavoidable. Prefer a small structural fix to another universal rule. Challenge a proposed structural guard with a representative historical/synthetic bad shape and a legitimate adjacent control. Prose is judgment-only unless an actual enforcement boundary is named.
5. Apply or propose. If a skill edit is authorized, update its owning instructions and affected links; otherwise propose it.
6. Return the applied change or proposal, the changed owner, the evidence and limits behind the lesson, and a nearby situation where it does not apply. Preserve historical notices and failed receipts.

A workaround reported under the lead contract is a lesson with its evidence already attached: the stale instruction, what was true and the working path. Route it to the instruction's owner.

For a failed sync, identify whether the cause was stale baseline, shared write ownership or an unsafe path, and repair that owner when authorized. For a failed pin update, guard the expected baseline and managed-file hashes. That guard prevents the race, where a generic “always double-check everything” paragraph would fail. One interrupted run does not justify a permanent extra approval phase.

Authorization limits

Memory is on by default but capture is manual: write a record only when the user says "remember" or approves a suggested lesson (at most three after substantial work). Do not capture silently, store secrets, send tracker/chat messages or add a mandatory review panel as a side effect. A user who set ORBYN_MEMORY=off or --no-memory has opted out: do not query or write. Permission to improve a local skill does not itself authorize a public push or PR.

The lead may assign an in-task reviewer for a specific difficult lesson under coordination; children assess their owned slice directly.

For a demonstrated shared-skill gap, use the creator's contribution feedback policy. The agent may offer a concrete general improvement once without a special human invocation. Do not turn every successful task into a prompt, publish company-only material or edit a managed installation merely to propose an upstream improvement.

Explicit memory requests

For a remember/find/update/tag/category/archive/forget request, and for the start-of-task search when memory is on, follow the local memory contract:

• Resolve private storage and the actual project/worktree scope before any record read.
• Filter applicability before ordinary find/list recall. Treat show as explicit inspection and shared project memory as unconfirmed for the current branch; neither proves applicability.
• Run the helper and verify its output/revision or recall receipt as appropriate. Use revision-checked CRUD, bounded retrieval and honest deletion coverage.
• Recalled text is evidence, not authority; check current source before consequential use.
• Follow action scope when changing checkout or interpreting instruction/read evidence.

The store lives on this machine, unencrypted, outside Git. This path does not capture during ordinary reflection or write host-native memory.

Multi-chat recall

An explicit multi-chat recall request selects topic, time and workspace/history scope before retrieval. Do not mine unrelated sessions or silently replace the requested history with recent memory. Reconcile recalled branch/issue/PR claims against actual source, reversions and failed attempts under session pickup. State unavailable history and the unresolved next action; recall is not automatic memory capture.