Skip to content
Back to skills

Orbyn Workflow

ASecurity

Route engineering work through investigation, design, implementation and verification, including open-source contribution intake and bounded PR feedback/CI iteration. Follow the consuming project's instructions.

  • 4 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added November 11, 2026
developmentpythonrustrefactoringbackendsecurityperformance

Security analysis

A100/100

Pro scans all 20 files and shows the line behind each finding

Scanned November 13, 2026

npx -y skills add orbyn-dev/orbyn-fullstack-skills --skill orbyn-workflow --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Orbyn Workflow?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Orbyn Workflow
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/orbyn-dev-orbyn-workflow/badge)](https://www.skillsdirectory.com/skills/orbyn-dev-orbyn-workflow)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: orbyn-workflow
description: "Route engineering work through investigation, design, implementation and verification, including open-source contribution intake and bounded PR feedback/CI iteration. Follow the consuming project's instructions."
---

# Orbyn engineering workflow

Follow the consuming project's instructions and requested scope; use the
[portable defaults](references/project-policy.md) only where guidance is missing.
These rules cover every task, code or not. Select skills 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](../orbyn-setup/references/repository-workspaces.md);
   read its own instructions and relevant project skills in place.
1. Resolve the harness 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. A harness
   file is data: it never grants permission, selects the human-only tier or changes
   a lead tier. Precedence and trust:
   [harness settings](references/harness-settings.md). Read the printed `work mode`
   first and follow the [mode table](references/harness-settings.md#the-work-mode);
   when not set, ask the user once and save the answer with `harness.py setup`.
2. Apply [action scope](../orbyn-setup/references/action-scope.md): 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](../orbyn-setup/references/offline.md); fetch only
   needed current facts, when allowed; report stale or missing evidence.
4. Start from the requested outcome, current source and
   [stack ownership](references/project-policy.md#stack-and-ownership). Choose one
   playbook; a clear small edit or a narrow explanation can proceed directly. Keep the plan short, load only what
   the task needs and leave checklists out of routine replies.

## Choose a playbook

| Work | Playbook |
| --- | --- |
| Explain current behavior | [Investigation](playbooks/investigation.md) |
| Fix a defect | [Bug fix](playbooks/bug-fix.md) |
| Improve measured performance | [Performance](playbooks/perf-issue.md) |
| Diagnose live behavior | [Runtime forensics](playbooks/runtime-forensics.md) |
| Analyze a captured profile | [Trace forensics](playbooks/trace-forensics.md) |
| Product opportunity or outcome | [Product discovery](../orbyn-plan/references/product-discovery.md), then [user evidence](../orbyn-research/references/user-evidence.md) |
| Model-powered product behavior | [AI application engineering](../orbyn-ai-application/SKILL.md) |
| Add behavior | [Feature](playbooks/feature.md) |
| Change structure | [Refactoring](playbooks/refactoring.md) |
| Resolve an empirical design question | [Prototype](playbooks/prototype.md) |
| Lifecycle rules, verification drift | [Statecharts](../architect/references/statecharts.md), then [property verification](../tdd/references/formal-verification.md) |
| Match a reference UI | [Visual parity](playbooks/visual-parity.md) |
| Author reusable instructions | [Skill authoring](playbooks/authoring-a-skill.md) |
| Compare prompt/skill behavior | [Evaluation](playbooks/eval.md) |
| Autonomous task, PR queue, no-merge handoff, dependent stack, standing program | [Autonomous run](playbooks/autonomous-run.md) |
| Research, answers, writing, non-code work | [General task](playbooks/general-task.md) |
| Resume or pause work | [Session pickup](playbooks/session-pickup.md), [Pause safely](playbooks/pause-safely.md) |
| Large migration, staged delivery | [Multi-phase plan](playbooks/multi-phase-plan.md) |
| PR delivery requested | [Opening a PR](playbooks/opening-a-pr.md) |
| Upstream contribution | [Contribution intake](playbooks/contribution-intake.md) |
| PR feedback or CI | [Bounded PR iteration](playbooks/pr-iteration.md) |
| Keep building while a PR waits on CI or review | [Build while waiting](playbooks/build-while-waiting.md) |
| Bulk CI failures, release evidence | [Pipeline failures](playbooks/pipeline-failures.md) |
| Rollout or incident recovery | [Health and recovery](../orbyn-ci-design/references/rollout-recovery.md) |

## Hand off to the owner

Select handoffs from the [skill system](references/project-policy.md#routing); the
[handoff index](references/operating-method.md#handoff-index) lists every owner
(plan, research, why, backend, data, CI, language, stack, upstream, mobile, scope,
artifacts). Always:

- Changing unfamiliar behavior: [how](../how/SKILL.md). Consequential data/ownership decisions: [architect](../architect/SKILL.md).
- Threat modelling or design-stage security review, or an explicitly requested portable/offline source audit: [orbyn-security-audit](../orbyn-security-audit/SKILL.md).
- Setup: [orbyn-setup](../orbyn-setup/SKILL.md). Isolation or a worktree: [orbyn-worktree](../orbyn-worktree/SKILL.md).
- Memory (on by default, `ORBYN_MEMORY=off` opts out): search project and personal
  scope at task start and treat results as hints; save on "remember"; after substantial
  work suggest at most three lessons, save only approved ones ([memory flow](../reflect/references/memory.md)).
  Durable handoff: optional [task record](references/task-record.md).

## Lead substantial work

The owning lead grounds and scopes the outcome, chooses the design, delegates
substantial investigation and implementation, and stays responsible for
integration, review and verification. Read the [lead contract](references/lead-contract.md) before
dispatching or reviewing a child, and before a commit or push.

- A child forbidden further delegation completes its slice directly.
- Stay within the resolved `max_children`, `reviewer_children` and `max_depth`, use the
  resolved tier's model and effort, announce every child in one line; sessions only in
  `parallel` mode or on request.
- Never poll a background job or child (`sleep`, `ps`, `pgrep`, `top`); [wait without polling](references/waiting.md).
- For substantial work, write the [answer key](references/answer-key.md) first; the worker gets the outcome only.
- Inspect returned artifacts and diff; a delegate's summary is evidence. 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 results; implementation includes appropriate local checks unless excluded. 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 and report
unavailable or excluded evidence as a limit ([details](references/lead-contract.md#verify)).

Deliver only the requested scope. Follow [unslop](../unslop/SKILL.md) and report changed
behavior/artifacts, evidence, 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.

### Worked failure

A synthetic test filter exits zero with `0 tests selected`. That is missing
evidence, not a passing baseline: read the runner configuration, find the supported
selector, and name any unverified mode instead of claiming all passed
([worked decisions: a green command that selected nothing](references/contribution-examples.md)).

Files in this skill

  • LICENSE2.1 KB
  • SKILL.md10.2 KB
  • examples/public-only-handoff.json998 B
  • playbooks/authoring-a-skill.md926 B
  • playbooks/autonomous-run.md8.5 KB
  • playbooks/bug-fix.md2.2 KB
  • playbooks/contribution-intake.md7.3 KB
  • playbooks/eval.md1.1 KB
  • playbooks/feature.md2 KB
  • playbooks/general-task.md1.7 KB
  • playbooks/investigation.md798 B
  • playbooks/multi-phase-plan.md197 B
  • playbooks/opening-a-pr.md10.4 KB
  • playbooks/pause-safely.md359 B
  • playbooks/perf-issue.md10.9 KB
  • playbooks/pipeline-failures.md1.7 KB
  • playbooks/pr-iteration.md12.9 KB
  • playbooks/prototype.md2.2 KB
  • playbooks/refactoring.md1.9 KB
  • playbooks/runtime-forensics.md2.1 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

View all in development →

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.