Orchestration envelope
Skill gtrabanco/agentic-workflow/skills/orchestration-envelope
Internal machine-result contract for headless agentic-workflow drivers. The executable source is @gtrabanco/agentic-workflow-schema: strict Envelope v2 for workflow-status, compact SkillOutcome v1 for driven work, compatibility parsing, and deterministic document snapshots. Not a menu entry.From its SKILL.md
npx -y skills add gtrabanco/agentic-workflow --skill orchestration-envelopeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.8 KB, as published. Nobody here has run it
Machine result contract (internal)
Interactive skills remain text-first. A headless driver obtains a compact, validated result at the boundary; it does not add a repeated JSON section to every user-facing skill.
The canonical Turn contract remains here for the executor and review skills that load it.
The executable source of truth is
@gtrabanco/agentic-workflow-schema:
types, JSON Schemas, renderOutputInstruction(skill), parseTurn(input), and
compileWorkflowSnapshot(input). This document states the policy only; do not
copy a second schema here.
Output profiles
WORKFLOW_SKILL_PROFILES is the authoritative inventory.
workflow-statusalways returns the strict Envelope v2 sensor result. Its envelope includes the detailed project view underdetail.- The other driver-invoked skills return SkillOutcome v1 only when the
driver appends
renderOutputInstruction(skill)to that invocation. It has the small model-owned fields: outcome, next intent/targets, blockers, questions, discoveries, and evidence references. ship-roadmapis the conductor, not a worker profile: it keeps its native terminalSHIP:banner and is parsed by its own fixed turn contract.- Interactive invocations emit their normal human-readable reports; no driver result is required.
Both results are one final fenced json block. The package rejects unknown
keys at the routing boundary. Repository facts are never reconstructed from
model prose: the driver compiles WorkflowSnapshot v1 from its selected,
versioned documents and caller-supplied repository facts.
Driver protocol
- Read the profile and append
renderOutputInstruction(skill)only for a driven invocation. - Pass the final response to
parseTurn({skill, text, context}). Keep the returned source and diagnostics with the run journal. - On an absent, malformed, or invalid machine result, re-invoke the same
session once with:
Emit only the machine result for the turn above. - Parse the repair reply. A second failure is driver-level
FAILED; never retry indefinitely and never turn arbitrary prose into workflow facts.
Compatibility is deliberately narrow: it can repair documented legacy v2 shapes only when the missing value is mechanically knowable. A nonzero issue count without issue identities, an unmatched numeric unit id, or unrelated prose remains invalid and is surfaced to the driver.
Contract evolution
- Envelope v2 is strict for new drivers.
detailis required (usuallynull) and skill-specific extensions live inside it;design_candidates, for example, isdetail.design_candidates, never a root key. workflow-statusretains Envelope v2 for existing sensor consumers.parseEnvelope()remains the legacy-compatible package API; new consumers useparseEnvelopeV2Strict()orparseTurn().SkillOutcome v1andWorkflowSnapshot v1are separate, versioned JSON Schemas. A breaking change to any published contract is a package major.
Normalized Repository State
Drivers call discover-repository-state before planning and retain the frozen
docs/workflow/REPOSITORY_STATE.md reference. WorkflowSnapshot v1 preserves
unknowns, provenance, and declared contradictions; a driver routes a
contradiction to resolve-repository-state rather than silently replacing it.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most agent orchestration skills give
Counted across 848 of the 1,300 authors here whose files we hold, read 2026-09-06
- Dispatch one agent per independent problem domainin 56 of 848, across 42 files
- Run full test suite after integrationin 55 of 848, across 42 files
- Verify fixes do not conflictin 40 of 848, across 32 files
- Review each summary when agents returnin 40 of 848, across 31 files
- Write a handoff document summarising the current conversationin 30 of 848, across 25 files
- Reference existing artifacts by path or URLin 26 of 848, across 24 files
- Give each agent a specific scopein 19 of 848, across 10 files
- Give each agent a clear goalin 19 of 848, across 10 files
- Include a suggested skills section in the documentin 18 of 848, across 16 files
- Tailor the doc to the user argumentsin 18 of 848, across 15 files
- Issue all subagent dispatches in the same responsein 17 of 848, across 11 files
- Use git worktrees for isolationin 17 of 848, across 8 files
Said here and by no other author read
- Read the profile and append output instruction
- Pass final response to parseTurn
- Re-invoke session once on invalid machine result
- Call discover-repository-state before planning
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.