OrcAI.Tool 0.10.3

There is a newer version of this package available.
See the version list below for details.
dotnet tool install --global OrcAI.Tool --version 0.10.3
                    
This package contains a .NET tool you can call from the shell/command line.
dotnet new tool-manifest
                    
if you are setting up this repo
dotnet tool install --local OrcAI.Tool --version 0.10.3
                    
This package contains a .NET tool you can call from the shell/command line.
#tool dotnet:?package=OrcAI.Tool&version=0.10.3
                    
nuke :add-package OrcAI.Tool --version 0.10.3
                    

OrcAI CLI

A CLI tool for orchestrating bulk GitHub work across many repositories. From a single YAML config, OrcAI creates a GitHub Project, opens templated issues in every target repo, and hands them off to whoever (or whatever) does the work — a human teammate, a bot, or an AI agent like GitHub Copilot or OpenCode.

Full docs, features, and examples: github.com/dburriss/orca

Prerequisites

Quick start

# 1. Scaffold a job config + issue template
orcai generate --name "Add AGENTS.md" --org my-github-org --repo repo-one --repo repo-two

# 2. Edit add-agents-md.yml (repos, labels, action) and add-agents-md.md (the task)

# 3. Run it
orcai run add-agents-md.yml

run finds or creates a GitHub Project, creates issues from your template, adds them to the project, and executes the configured action — assign @copilot/anyone, post a comment, or run a command per repo and open a PR with the result (cmd-to-github). A <basename>.lock.json file is written alongside the YAML so re-runs are fast and idempotent.

Commands

Command Description
orcai generate Scaffold a YAML job config and stub issue template
orcai run Execute a bulk job (globs, concurrency control, JSON output)
orcai nudge Re-trigger stale issues with no linked PR
orcai notify Post a templated comment to issues and/or PRs
orcai validate Validate YAML config(s) and repo access
orcai info Display the current state of a job
orcai cleanup Tear down everything created by run
orcai graph Render the dependsOn dependency graph
orcai migrate Upgrade a job YAML/lock file to the current schema
orcai auth pat/app/create-app/switch Manage credentials and profiles

For full flag details, the YAML schema, config file options, and runnable examples, see the CLI reference, config reference, and examples.

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

This package has no dependencies.

Version Downloads Last Updated
0.10.5 104 9/7/2026
0.10.4 119 9/3/2026
0.10.3 100 9/2/2026
0.10.2 87 9/2/2026
0.10.1 98 9/1/2026
0.10.0 105 8/30/2026
0.9.0 103 8/30/2026
0.8.1 297 6/16/2026
0.8.0 171 6/9/2026
0.7.5-beta6 121 6/9/2026
0.7.4-beta5 117 5/21/2026
0.7.3-beta4 126 5/19/2026
0.7.2-beta3 127 5/18/2026
0.7.1-beta2 136 5/18/2026
0.7.0-beta1 128 5/13/2026
0.6.0 168 5/7/2026
0.5.1 304 3/17/2026
0.5.0 176 3/16/2026
0.4.4 178 3/16/2026
0.4.3 167 3/16/2026
Loading failed

Repos were misreported as "not found or inaccessible" in large, chunk-boundary-aligned blocks during bulk repo-state fetch (`FetchReposState`), even though they exist and are accessible. Root cause: GitHub's edge/gateway can return a valid-JSON but non-GraphQL-shaped error envelope (e.g. `{"message": "We couldn't respond to your request in time..."}`, typically a 502/504 gateway timeout) for an expensive query — previously this was treated as a successful response with no data, so every repo in the chunk fell into the "not found" branch. It's now detected and treated as a retryable transient error like any other backoff-eligible failure.
Reduced how often that gateway timeout is hit in the first place: `FetchReposState` now issues `isArchived` lookups (cheap) in batches of 100 as before, but the two `search` lookups per repo (open/closed issue, one of GitHub's most expensive GraphQL root fields) in much smaller batches of 15 — down from a combined batch of 50 that could put up to 100 `search` invocations in a single GraphQL call.