Feat: create orchestration skill#121
Open
YevheniiaLementova wants to merge 7 commits into
Open
Conversation
…tions and extract operation-manager commands to dedicated asset
Contributor
Rosetta Triage ReviewSummary: This PR adds a new
Instruction-Quality Findings
Suggestions
Verdict: Request changes — two HIGH findings (F1, F2) must be resolved before merge. Three MEDIUM findings are strongly recommended for this PR. Automated triage by Rosetta agent |
… orchestration skill; make orchestartion skill user invocable
isolomatov-gd
requested changes
Jun 27, 2026
isolomatov-gd
left a comment
isolomatov-gd
left a comment
Contributor
There was a problem hiding this comment.
Heavy changes required. Skill is not good, became worse.
|
|
||
| Think about how big the request is and adopt your own strategy. | ||
|
|
||
| Examples — how to think about request size and orchestrator strategy: |
Contributor
There was a problem hiding this comment.
TOO BIG and wrong direction alltogether. Keep our original sizing with description on what happens when. The thinking how provided here is useless noise. When I say "Teach how to think" does not mean you just say "Think about".
You convert the entire meaning and sentence to thinking which RESULTS in request sizing. Example: instead of fishing tell how to fish.
Example: https://github.com/griddynamics/cto-claude-marketplace/blob/main/skills/gd-work-on/SKILL.md
|
|
||
| </documentation_sync_rules> | ||
|
|
||
| <decomposition_strategies> |
Contributor
There was a problem hiding this comment.
Look https://github.com/griddynamics/cto-claude-marketplace/blob/main/skills/gd-work-on/SKILL.md
This section is not good
|
|
||
| </request_sizing> | ||
|
|
||
| <documentation_sync_rules> |
Contributor
There was a problem hiding this comment.
Orchestration skill?
|
|
||
| </decomposition_strategies> | ||
|
|
||
| <subagent_dispatch_rules> |
Contributor
There was a problem hiding this comment.
| <delegated_task_sizing> | ||
|
|
||
| 1. Request size ≠ delegated task size. | ||
| 2. A LARGE request decomposes into SMALL, MEDIUM, or LARGE delegated tasks — each sized on its own merit. |
Contributor
There was a problem hiding this comment.
TOO VERBOSE, current version makes no sense.
|
|
||
| 1. Request size ≠ delegated task size. | ||
| 2. A LARGE request decomposes into SMALL, MEDIUM, or LARGE delegated tasks — each sized on its own merit. | ||
| 3. A MEDIUM request decomposes into SMALL or MEDIUM tasks only. |
Contributor
There was a problem hiding this comment.
This should be clear by any model.
How I wrote to model:
We need to get AI to understand, if fresh eye reads and tells it wrong => we need to fix. if it says this missing/that missing/how to improve => it understood and started acting on it. Our task is done. We don't need to put OBVIOUS things.
| 2. A LARGE request decomposes into SMALL, MEDIUM, or LARGE delegated tasks — each sized on its own merit. | ||
| 3. A MEDIUM request decomposes into SMALL or MEDIUM tasks only. | ||
|
|
||
| Think: what does this specific task need from the subagent to succeed? |
Contributor
There was a problem hiding this comment.
Not good. We are not teaching how to think. We are not giving direct instructions either.
You kind of simply restated original "Identify request size" to "Think about request size". Which is NOT what was required.
Contributor
📋 Prompt Quality Validation Report❌ Validation FailedThe full markdown report and raw JSON output are available in the workflow artifacts for 5 days. Files With Issues
📄
|
| Severity | Gate | Details |
|---|---|---|
| Critical | Reference Integrity | Problem: This SKILL.md declares frontmatter name: orchestration, and a second file orchestration_v1/SKILL.md declares the exact same name: orchestration. The bootstrap always-on rule (bootstrap-alwayson.md line 65) injects USE SKILL orchestration for every orchestrator/top-agent turn, so this collision fires on the hot path, not a rare branch. Which skill body actually loads is not deterministic across the agent-agnostic IDE surface Rosetta targets.Reason: An ambiguous, always-on skill name makes core orchestration behavior non-deterministic on essentially every task, which is a reliability failure, not a cosmetic one. Solution: Keep exactly one skill named orchestration. Remove the duplicate orchestration_v1/ skill so a single file owns the orchestration name. Do not ship two folders with the same frontmatter name. |
| Very High | Rosetta | Problem: The file violates pa-hardening's MUST-level ban on non-operational provenance/change annotations (the RAW SOURCE/framing comments) and participates in a duplicate-skill-name collision. It is the skill actually registered in docs/definitions/skills.md, yet it ships as work-in-progress (scaffolding + TODO).Reason: Rosetta prompts must be source-agnostic, state-only, and action-only; the registered skill currently fails these contract rules. Solution: Strip all provenance/annotation comments, remove the [TODO], and resolve the name collision by keeping a single orchestration skill, so the registered skill meets Rosetta authoring standards. |
| Very High | Bloat Control | Problem: About half the file (~175 of 366 lines) is dead <!-- ... --> scaffolding: multiple <!-- RAW SOURCE: ... --> provenance tags and <!-- META-PROCESS FRAMING --> blocks that restate content already present live (e.g. the operating beliefs at lines 44-55 are re-stated as prose in the comment at lines 57-71).Reason: pa-hardening bans non-operational provenance/origin/change annotations in target prompts; HTML comments are not stripped before reaching the agent, so this doubles context cost on every load and duplicates the live content. Solution: Delete all RAW SOURCE, META-PROCESS FRAMING, and commented-out duplicate blocks. Keep only the operative instruction text. |
| High | Precision & Explicitness | Problem: Line ~100 ships a literal author note [TODO: don't like it] inside the live <adoption_strategy> section, and the surrounding guidance uses vague phrasing (e.g. assemble the right combination of instruments).Reason: An unresolved author-doubt marker in operative instructions can seed agent hesitation or an unprompted deviation, and vague qualifiers reduce reliable execution. Solution: Remove the [TODO: don't like it] note and resolve the adoption-strategy wording before shipping; replace the vague phrasing with concrete selection criteria already present in the toolkit section. |
| High | Safety Boundaries | Problem: The strongest verify-before-integrate guardrail — MUST spawn reviewer subagent to verify delegated work ... never integrate unverified output — sits only inside a dead comment block (lines 260-266). The operative live text carries a softer aphorism (unverified output never integrates — delegation without verification is outsourcing without accountability, line ~191), which is a philosophy rather than an actionable MUST.Reason: The mandatory review gate is a core safety mechanism; leaving it commented weakens the enforced guardrail an orchestrator actually acts on. Solution: Move the explicit MUST spawn reviewer subagent ... never integrate unverified output directive into live (non-commented) instruction text. |
| High | Structural Coherence | Problem: Active instruction sections are shadowed by adjacent commented-out near-duplicates (e.g. the <role> active text plus a commented alternate role, and live QUALITY/ESCALATION guidance mirrored inside comment blocks). This breaks MECE and contradicts the file's own stated principle (line ~54: information that exists once is referenced, not replicated).Reason: Duplicated content in two forms forces the agent to reconcile which version is authoritative, degrading follow-through. Solution: Remove the duplicated commented variants so each requirement lives in exactly one place. |
| High | Cognitive Budget | Problem: The file is 19301 characters (10K-20K band), and roughly half of that is dead comment mass served verbatim to the agent each time the skill loads. Reason: The PR's stated goal is reducing running context, yet this file inflates every orchestrator turn with non-functional tokens, directly working against that goal. Solution: After removing the scaffolding (see Bloat Control), the active content is well under budget; target the schema guidance of <300 ideal / 300-500 acceptable lines of operative text. |
| High | Reference Integrity | Problem: A live-looking directive inside a comment (line ~205: READ SKILL orchestration FILE assets/o-subagent-delegation.md) points to assets/o-subagent-delegation.md, but that asset was not added to orchestration/assets/ (only o-operation-manager-commands.md exists there).Reason: Comment content is served to the agent verbatim; a comment that reads like an instruction can trigger a failed ACQUIRE with no defined fallback. Solution: Either add o-subagent-delegation.md to orchestration/assets/ (extract the inlined template there) or remove the dangling pointer. Do not leave directive-shaped text referencing a missing asset. |
📄 instructions/r3/core/skills/orchestration_v1/SKILL.md
⚠️ Issues Found
| Severity | Gate | Details |
|---|---|---|
| Critical | Reference Integrity | Problem: Frontmatter declares name: orchestration while the folder is orchestration_v1. The skill schema (docs/schemas/skill.md) requires name to equal the parent folder name, and the sibling orchestration/SKILL.md already uses name: orchestration — so this is both a schema breach and a duplicate-name collision on the always-on USE SKILL orchestration path.Reason: A skill whose name does not match its folder and collides with another skill is unresolvable and unregistered; it makes orchestrator loading ambiguous and violates the schema contract. Solution: Remove this orchestration_v1/ skill. If any of its (cleaner) content is preferred, fold it into the single orchestration/ skill rather than shipping a second folder with a colliding name. |
| Very High | Rosetta | Problem: This is an unregistered, dangling skill (only orchestration is listed in docs/definitions/skills.md) that duplicates the orchestration skill under a schema-violating folder name. pa-rosetta registry policy forbids out-of-list items.Reason: A stray twin skill on the always-on load path is a structural defect that undermines deterministic, governed skill resolution. Solution: Delete orchestration_v1/; merge any preferred content into the registered orchestration skill. |
| High | Safety Boundaries | Problem: The explicit MUST spawn a fresh-eyes reviewer (different model) before integrating; never integrate unverified output gate lives only in assets/o-subagent-delegation.md, reached via the broken ACQUIRE above, so it may never load. The SKILL body itself carries only lighter communication/validation guidance.Reason: If the mandatory review gate never reaches the agent, delegated work can be integrated unverified. Solution: Ensure the verify-before-integrate MUST directive is reachable — surface it in the SKILL body or fix the asset path so the guardrail always loads. |
| High | Reference Integrity | Problem: It does ACQUIRE orchestration/assets/o-subagent-delegation.md FROM KB (line ~91), but that file exists only at orchestration_v1/assets/o-subagent-delegation.md. Every asset reference points into the sibling orchestration/ folder, not this skill's own assets.Reason: A failed ACQUIRE for the delegation template leaves the orchestrator without dispatch-assembly guidance, with no defined fallback. Solution: Point ACQUIRE at the asset's real resource path, or (preferred) consolidate into one orchestration skill so asset paths and folder align. |
📄 instructions/r3/core/skills/orchestration_v1/assets/o-operation-manager-commands.md
⚠️ Issues Found
| Severity | Gate | Details |
|---|---|---|
| Medium | Rosetta | Problem: This asset is byte-identical to orchestration/assets/o-operation-manager-commands.md, and it is orphaned: its own skill (orchestration_v1/SKILL.md) references the orchestration/ copy, never this one.Reason: Duplicated, unreferenced assets create DRY drift risk and dead files in the published knowledge base. Solution: Remove this duplicate when the orchestration_v1/ skill is deleted; keep a single copy under the one surviving orchestration skill. |
📄 instructions/r3/core/skills/orchestration_v1/assets/o-subagent-delegation.md
⚠️ Issues Found
| Severity | Gate | Details |
|---|---|---|
| High | Rosetta | Problem: This is the only correctly-extracted copy of the composable subagent-delegation template (matching the PR story's intent), yet it lives under the unregistered, to-be-removed orchestration_v1/ skill. The registered orchestration/ skill instead inlines the template and lacks this asset. Deleting the stray twin (the correct fix for the name collision) would erase the only good copy.Reason: The properly-structured delegation asset must live under the surviving, registered skill so the extraction-contract holds and the orchestrator can actually load it. Solution: Move this asset to orchestration/assets/o-subagent-delegation.md and reference it from the registered orchestration skill, then delete the orchestration_v1/ folder. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements the orchestration skill as specified in the reduce-bootstrap story — one of the core skills needed to shrink the always-on bootstrap and make rigor user-invoked rather than always-injected.
What was built:
instructions/r3/core/skills/orchestration/SKILL.md — the orchestration skill covering role definition, request sizing (with examples), decomposition strategies (map-reduce / split-by-roles / delegate-to-plan), subagent dispatch rules, delegated task sizing, communication rules, validation, memory, and pitfalls.
assets/o-subagent-delegation.md — a single composable subagent-delegation prompt template (banded [SMALL+]/[MEDIUM+]/[LARGE]) with assembly guidance and a dispatch self-test.
assets/o-operation-manager-commands.md — OPERATION_MANAGER command reference extracted as a standalone asset so the SKILL.md stays focused and the reference can be loaded on demand.
Story progress update: