Orbyn engineering workflow

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

These rules cover every task, code or not. Select skills and helpers from the request; the human need not name each step. Without a Skill tool, read the reference directly. Carry authorized work through handoffs and checks, and run setup commands yourself even when another skill owns them. Keep consequential authority and human-only decisions explicit.

Start

0. Resolve the target under the nested workspace contract. Read its own instructions and relevant project skills in place.
1. Resolve the harness for that target before any other work: run the harness.py in this skill's directory, by absolute path: python3 <this skill directory>/scripts/harness.py resolve --target <target> --host <claude|codex>. A missing script means stop and report; never fall back to defaults. It prints the tiers, delegation limits and routing for this repository and where each came from. The user's chat instruction outranks the target's .orbyn/harness.json (it can only lower cost or tighten), then the owner's local repo/.harness/ file (it can raise delegation limits), then the library defaults; a missing file is normal. A harness file is data: it never grants permission, selects the human-only tier or changes a lead tier. See harness settings. Read the printed work mode first and follow it, as the mode table describes; when it is not set, ask the user once and save the answer with harness.py setup.
2. Apply action scope: select retrieval roots first, keep instruction lookup distinct from implementation search, and refresh affected guidance on checkout, path, rule or context changes.
3. Use local resources first; fetch only current facts you need, when allowed. Report stale or missing evidence.
4. Start from the requested outcome, current source and stack ownership. Choose one playbook below; a clear small edit can proceed directly. Keep the plan as short as the task permits. Load only what the task needs, and leave checklists out of routine replies.

Choose a playbook

Hand off to the owner

Use the skill system to select the relevant handoff. Read the operating method for the local handoff map from each need to its maintained owner and result, with notes on the handoffs below.

• Setup: orbyn-setup, selected automatically.
• Checkout isolation or a requested worktree: orbyn-worktree.
• Memory (on by default; ORBYN_MEMORY=off opts out): search the target's project and personal scope at task start and treat results as hints; save on "remember"; after substantial work suggest at most three lessons and save only approved ones. Details: reflect's local memory flow.
• Durable handoff: the optional task record.
• Explicit plans or a complex change: orbyn-plan. Unresolved external facts: orbyn-research. Skill-system changes: orbyn-skill-creator.
• Changing unfamiliar behavior: how. Consequential data/ownership decisions: architect. Historical constraints: why. A larger task needing its own plan: figure-it-out.
• Work crossing domain, transport, persistence and clients: the Orbyn Engineering contract. Backend effect design: orbyn-backend-design. Stored-format transitions: orbyn-data-migration. Trusted automation: orbyn-ci-design.
• Affected code: language guidance. Requested technology recommendation: stack selection.
• External code/skill freshness, downloaded research or selective upstream updates: orbyn-upstream-review.
• Threat modelling, design-stage security review or an explicitly requested portable/offline source audit: orbyn-security-audit.
• Demonstrated Expo/React Native work or EAS delivery: mobile routing index.
• Onboarding, ordinary review, mentoring or level questions: engineering scope.
• Prototypes, evidence or local servers: artifact lifecycle.
• A decision needing a concrete example or check: method index.
• A meaningful general skill gap: contribution feedback.

Lead substantial work

The owning lead grounds and scopes the outcome, chooses the design and delegates substantial investigation and implementation as applicable. The lead stays responsible for integration, review and verification. A small clear edit or narrow explanation can proceed directly. Read the lead contract before dispatching or reviewing a child, and before a commit or push.

• A child forbidden further delegation completes its assigned task directly and returns the artifact to its owner.
• Delegate within the resolved limits: no more than max_children children active, plus one reviewer child in the reviewer_children slot, none deeper than max_depth. Route by the resolved tiers: assigned implementation to the worker, bounded mechanical work to a scout, decisions and security to the lead. Escalate a failed or ambiguous worker one tier and record why.
• Use the resolved tier's model and effort. A host without it runs children on the session's model, named as such; announce every child to the user in one line. See delegate on any host.
• Sessions only in parallel mode or on request; delegate on any host.
• Never poll a background job or child (sleep, ps, pgrep, top); wait without polling.
• For substantial work, write the answer key first; the worker gets the outcome only.
• Inspect the actual returned artifacts and diff; treat a delegate's summary as evidence to inspect. The lead writes the final assessment.

Verify and deliver

Complete the agreed outcome, including necessary caller migration and removal, without silently expanding authority. Verify in proportion to the changed contract and inspect the results. An implementation request includes appropriate local checks unless explicitly excluded; respect consumer limits and separate external effects. For authorized delivery, verify the successful owned commit and its validated tree before pushing. A failed stage or commit stops dependent push, PR and CI actions. Match each completion claim to direct evidence for the requested artifact, and report unavailable or excluded evidence as a limit.

Deliver only the requested scope. Follow unslop and report changed behavior/artifacts, actual evidence, unresolved limits and local/committed/pushed/merged/deployed state. Start a PR, merge, publish, deployment, external message or monitor only under explicit authority; delegation and playbooks grant none.