orchestrate

Use when driving one or more tasks end to end from the local bare repo's `main` worktree — a feature designed with the user first when its scope is open, or a ready list of tasks — ordering them, cutting a worktree per task, handing each to a subagent that runs new-feat, running prep-pr with every finding fixed rather than reported, and shepherding each pull request to a squash merge and worktree teardown. Not for a one-file change, and not outside the bare repo.

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is an exceptionally actionable, well-sequenced orchestration workflow with strong validation checkpoints and error-recovery loops, and it makes sound use of a one-level-deep reference file for the full gotchas table. Its main cost is token efficiency: the branch-attribution rationale is duplicated across two long passages and padded with repository spend statistics.

Suggestions

Explain the TASK-BRANCH attribution mechanism once — collapse the precondition warning block and the first Step 3 dispatch bullet into a single statement of the rule (every dispatch carries 'TASK-BRANCH: <branch>' or its spend is misattributed) plus one pointer to wiki/observability/session-metrics.md for the mechanism.

Move the spend-statistics justification (the 64% HEAD-pool figure, the 85.8% subagent-spend figure, and the gitBranch-capture mechanics) out of the main flow into references/gotchas.md or the observability wiki page, keeping only the operational instruction in SKILL.md.

Trim the rationale prose in Step 3/Step 4 (e.g. why an implementer reliably does 'create the file' and skips 'make something call it', why the shepherd pins the cheapest model) to one clause each; the surrounding imperative already carries the instruction.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient operational instruction, but the TASK-BRANCH attribution rationale is explained at length twice (the warning block and the first Step 3 dispatch bullet), and motivational spend statistics ("64% of this repository's recorded token spend currently sits in that anonymous HEAD pool", "It is 85.8% of subagent spend today") pad otherwise actionable sections. Fits the 3 anchor (mostly efficient, some unnecessary explanation) rather than 4, because the duplication is substantive rather than a minor trim.	3 / 5
Actionability	Fully executable throughout: concrete git commands ("git -C /Users/ac/.work/osn.git worktree add ... -b <prefix>/<dir> origin/main"), GH commands ("gh pr merge <n> --squash --delete-branch", "gh pr view <n> --json mergeStateStatus,statusCheckRollup,state"), verification commands ("git -C <dir> status --porcelain", "bun run --cwd tools/pr-metrics backfill -- --dry-run"), and a concrete dispatch contract with a verbatim "TASK-BRANCH: <branch>" marker. Matches the 5 anchor; nothing is pseudocode or hand-wavy.	5 / 5
Workflow Clarity	Steps 00 → 0 → 1–5 are clearly sequenced with explicit validation checkpoints (mechanical verification before reading a report, "Never merge red", re-verify after fixes, the post-run attribution backfill check) and dedicated feedback loops for error recovery (dead subagent recovery, DIRTY/BEHIND rebase path, NEEDS INPUT handling). Matches the 5 anchor exactly.	5 / 5
Progressive Disclosure	Good structure: the top five gotchas are inlined with the full table clearly signaled one level deep in references/gotchas.md (verified to exist and to carry that table), and sections are well-organized for navigation. Fits the 4 anchor rather than 5 because a large attribution warning block and other long rationale sections are inlined content that could itself live in a reference file.	4 / 5
	Total	17 / 20 Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is specific, complete, and highly distinctive, with an explicit "Use when" clause and concrete negative triggers that sharply bound its scope. Its only weakness is reliance on repo-internal terminology over the natural synonyms and phrasings a user might invoke it with.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions covering the entire orchestration loop — "ordering them, cutting a worktree per task, handing each to a subagent that runs new-feat, running prep-pr with every finding fixed rather than reported, and shepherding each pull request to a squash merge and worktree teardown" — with comprehensive coverage and no gaps.	5 / 5
Completeness	Explicitly answers both: what (order tasks, cut worktrees, dispatch subagents, run prep-pr, shepherd PRs to squash merge) and when ("Use when driving one or more tasks end to end ... a feature ... or a ready list of tasks", plus negative triggers "Not for a one-file change, and not outside the bare repo"). Clearly matches the 5 anchor, not 4, because the when-clause is explicit and concrete rather than merely present.	5 / 5
Trigger Term Quality	Natural phrases like "driving one or more tasks end to end", "a feature ... when its scope is open, or a ready list of tasks" are present, but the description leans on internal jargon ("bare repo", "new-feat", "prep-pr") and omits common synonyms a user might say. Fits the 4 anchor (good coverage, a few natural terms missing) rather than 5 (comprehensive synonyms), and is well above 3 since the core trigger phrasing is natural and explicit.	4 / 5
Distinctiveness Conflict Risk	A clear niche — orchestration from the local bare repo's main worktree with named sibling skills and explicit exclusions for one-file changes and non-bare-repo environments — leaves minimal overlap risk with any other skill. Not 4, because no closely related skill could plausibly capture these triggers.	5 / 5
	Total	19 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: englishstventures/osn
Path: .claude/skills/orchestrate/SKILL.md
Commit: e92e5d1

Reviewed: 5 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.