Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

vanara-orchestrate

Estrelas7

Forks4

Atualizado14 de julho de 2026 às 20:43

Run a goal end-to-end as a gated pipeline of specialist agents — reproduce → test → patch → review → commit — where nothing advances past a gate until its exit condition holds and the required agent has signed off. Use when a task needs several agents in sequence with checkpoints, not a single one-shot answer.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

vanara-agents

vanara-agents/skills

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

Explorador de arquivos

4 arquivos

SKILL.md

readonly

name	vanara-orchestrate
description	Run a goal end-to-end as a gated pipeline of specialist agents — reproduce → test → patch → review → commit — where nothing advances past a gate until its exit condition holds and the required agent has signed off. Use when a task needs several agents in sequence with checkpoints, not a single one-shot answer.
type	skill
version	1.0.0
updated	"2026-07-13T00:00:00.000Z"

vanara-orchestrate — outcomes, not one-shots

A single agent answers a question. Orchestration delivers an outcome: it chains the right specialists into a pipeline with gates between stages, so the work only advances when the previous stage actually succeeded — and nothing risky ships without a sign-off. This is the difference between "here's a suggested fix" and "the bug is fixed, tested, reviewed, committed."

You run in the main Claude Code context, so you can invoke installed agents (via the Task tool, or the vanara-route skill) one after another and enforce the gates between them.

The core loop

For any goal, run plan → act → gate → advance, repeating until done:

Plan the pipeline. Pick the named workflow that fits the goal (see references/workflows.md), or compose one from installed agents. State the stages and their gates up front, in one short line each.
Run one stage. Invoke exactly one agent for the current stage and let it finish.
Check the gate. Before advancing, verify the stage's exit condition holds (tests green, a failing test now written, no blocking review findings, no new secrets — see references/gates.md). If it doesn't hold, do not advance: loop back, fix, and re-check. A gate is a hard stop, not a suggestion.

Checkpoint. Record the stage result so the run is auditable and resumable:

node .claude/skills/vanara-orchestrate/scripts/checkpoint.mjs "fix-defect" "review" "pass"

Advance to the next stage, or finish.

Named workflows

fix-defect — reproduce → write a failing regression test → patch → review → commit. Gate before commit: tests green and the reviewer returns no blocking findings.
ship-feature — plan → write tests first → implement → review → commit. Gate before implement: tests exist and fail (RED); gate before commit: GREEN + review clean.
harden — audit (security) → triage → fix highest severity → re-audit → report. Gate before "done": the re-audit shows the fixed findings gone and no new ones introduced.

Full stage/gate definitions are in references/workflows.md.

Rules that make orchestration trustworthy

One agent per stage. Don't blur stages; each has one owner and one gate.
Never skip a gate to save time. A red gate means the pipeline stops and reports exactly which condition failed and why — that failure is the useful output, not a thing to hide.
Escalate, don't loop forever. If a stage can't clear its gate after a reasonable attempt, stop and hand back to the user with the specific blocker. Cap retries (2–3), don't spin.
The reviewer is the last gate. For anything that writes to the repo, the final stage is a review, and nothing commits with blocking findings open.
Respect the operating protocol. Every stage still grounds its claims and logs its changes; orchestration adds sequencing and gates on top, it doesn't replace an agent's own discipline.

Edge cases

Missing agent for a stage → use vanara-route to find the closest fit, or tell the user which specialist to npx vanara install before the pipeline can run.
A gate that can't be evaluated (no tests exist to run) → say so; treat an unverifiable gate as not passed, don't wave it through.
Partial progress → the checkpoint log lets you resume from the last passed stage instead of restarting the whole pipeline.

Example

Goal: "the login endpoint 500s on an empty email."

Pipeline (fix-defect): debugger reproduces → test-author writes a failing test for the empty-email case (gate: test is RED) → debugger patches validation (gate: that test is now GREEN) → code-reviewer reviews (gate: no blocking findings) → commit. Each stage checkpointed; if review flags a blocking issue, the pipeline loops back to the patch stage, not forward.

Mais deste repositório

mesmo repositório

api-pagination

vanara-agents/skills

Implement correct, fast API pagination — cursor vs offset trade-offs, opaque cursor encoding, stable sort keys, page-size limits, total-count costs, and consumer-side iteration that survives inserts, deletes, and retries. With runnable cursor checks.

2026-07-147

caching-strategies

vanara-agents/skills

Deep reference for caching — what to cache, cache-aside vs read/write-through/write-behind, TTLs with jitter, eviction (LRU/LFU/FIFO), invalidation, and surviving stampedes (thundering herd / dogpile). Worked examples and a runnable jitter check.

2026-07-147

conventional-commits

vanara-agents/skills

Write Conventional Commits — the type(scope)!: subject + body + footer spec — so history is readable and changelogs and SemVer bumps can be derived automatically. Use when committing, configuring commitlint, designing release tooling, or deciding feat vs fix vs breaking change.

2026-07-147

database-migrations

vanara-agents/skills

How to write safe, reversible, zero-downtime database schema migrations — additive-first changes, the expand/migrate/contract pattern, batched backfills, concurrent index builds, safe NOT NULL, rollbacks, and the locking pitfalls that cause outages. A deep reference with runnable checks.

2026-07-147

error-handling-patterns

vanara-agents/skills

How to handle errors explicitly and consistently across an app — validate at boundaries, classify operational vs programmer errors, add context while propagating, retry transient failures with backoff, and never swallow. Covers JS/Python/Go/Rust patterns with runnable checks.

2026-07-147

git-collaboration-workflows

vanara-agents/skills

Run git collaboration that scales — trunk-based vs git-flow decided by deploy cadence, branch protection and required checks, PR sizing and review etiquette, monorepo vs polyrepo trade-offs, release branches and hotfixes, and history hygiene with disciplined merges.

2026-07-147

name	vanara-orchestrate
description	Run a goal end-to-end as a gated pipeline of specialist agents — reproduce → test → patch → review → commit — where nothing advances past a gate until its exit condition holds and the required agent has signed off. Use when a task needs several agents in sequence with checkpoints, not a single one-shot answer.
type	skill
version	1.0.0
updated	"2026-07-13T00:00:00.000Z"

vanara-orchestrate — outcomes, not one-shots

You run in the main Claude Code context, so you can invoke installed agents (via the Task tool, or the vanara-route skill) one after another and enforce the gates between them.

The core loop

For any goal, run plan → act → gate → advance, repeating until done:

Plan the pipeline. Pick the named workflow that fits the goal (see references/workflows.md), or compose one from installed agents. State the stages and their gates up front, in one short line each.
Run one stage. Invoke exactly one agent for the current stage and let it finish.
Check the gate. Before advancing, verify the stage's exit condition holds (tests green, a failing test now written, no blocking review findings, no new secrets — see references/gates.md). If it doesn't hold, do not advance: loop back, fix, and re-check. A gate is a hard stop, not a suggestion.

Checkpoint. Record the stage result so the run is auditable and resumable:

node .claude/skills/vanara-orchestrate/scripts/checkpoint.mjs "fix-defect" "review" "pass"

Advance to the next stage, or finish.

Named workflows

fix-defect — reproduce → write a failing regression test → patch → review → commit. Gate before commit: tests green and the reviewer returns no blocking findings.
ship-feature — plan → write tests first → implement → review → commit. Gate before implement: tests exist and fail (RED); gate before commit: GREEN + review clean.
harden — audit (security) → triage → fix highest severity → re-audit → report. Gate before "done": the re-audit shows the fixed findings gone and no new ones introduced.

Full stage/gate definitions are in references/workflows.md.

Rules that make orchestration trustworthy

One agent per stage. Don't blur stages; each has one owner and one gate.
Never skip a gate to save time. A red gate means the pipeline stops and reports exactly which condition failed and why — that failure is the useful output, not a thing to hide.
Escalate, don't loop forever. If a stage can't clear its gate after a reasonable attempt, stop and hand back to the user with the specific blocker. Cap retries (2–3), don't spin.
The reviewer is the last gate. For anything that writes to the repo, the final stage is a review, and nothing commits with blocking findings open.
Respect the operating protocol. Every stage still grounds its claims and logs its changes; orchestration adds sequencing and gates on top, it doesn't replace an agent's own discipline.

Edge cases

Missing agent for a stage → use vanara-route to find the closest fit, or tell the user which specialist to npx vanara install before the pipeline can run.
A gate that can't be evaluated (no tests exist to run) → say so; treat an unverifiable gate as not passed, don't wave it through.
Partial progress → the checkpoint log lets you resume from the last passed stage instead of restarting the whole pipeline.

Example

Goal: "the login endpoint 500s on an empty email."

Pipeline (fix-defect): debugger reproduces → test-author writes a failing test for the empty-email case (gate: test is RED) → debugger patches validation (gate: that test is now GREEN) → code-reviewer reviews (gate: no blocking findings) → commit. Each stage checkpointed; if review flags a blocking issue, the pipeline loops back to the patch stage, not forward.