seed-orchestrate-component

SEED Component Collaboration

Coordinate the scope of responsibility, exchange of opinions, integration, and completion decisions for component work. Use existing skills for technology-specific implementation guidance. Do not create as many agents as there are roles or build a separate messaging system.

Scope of Application

• Use when the user has requested role division, parallel work, or agent collaboration, or when the initial investigation has confirmed mutually independent write scopes and a sufficient amount of work.
• Boundaries requiring joint decisions, such as state, Recipe, and Registry, are divided after reaching agreement. Do not force parallelization of work that has sequential dependencies or only involves modifying the same file.
• Simple token and wording edits and known single-file changes maintain seed-component's solo flow.
• If only evaluation and design are requested, present roles, dependencies, and a verification plan. Do not expand the scope to implementation or harness configuration changes.

Required Inputs

The coordinator checks the following in the conversation and current files. Do not ask again about already confirmed details or repeat the same path investigation for each owner.

• Target component, platform, consumption paths such as package and Registry
• Requested user outcomes, reference scenarios, and intentional platform differences
• Actual sources to modify, generated artifacts, direct consumers, and existing user changes
• Execution environment required for this change and currently available agent tools

If the path is unclear, use seed-component's read-only lookup. Also check platform and publication method and React and Lynx API comparisons in the respective branches of the relevant skill, and check the impact, generation, and verification order, if needed, in seed-change's planning branch. If results already exist, reuse them together with the actual target files.

Procedure

1. The coordinator selects only the necessary roles in role boundariesand assigns exact write scopes. Roles may be merged, but for behavior changes across multiple layers, separate the implementer and the verification executor. The coordinator is not the person who directly runs all verification commands, but the person who gives final approval by comparing independent verification results against the approval conditions.
2. Collaboration Procedure, determine the source of reference behavior, producer and consumer contracts, default scenes, and required environments. For technical criteria, use Reference Behavior Tracing and Default Scenes. For the concrete execution of Lynx default scenes, follow the 검증 런북의 examples/lynx-spa document example path. According to Verification Division and Resources, record the prerequisite inputs, shared resources, and executors for each check in the shared work notes.
3. Execution per HarnessThe execution method specified by the user takes precedence. If no separate selection has been made, use the current harness's built-in delegation and messaging tools. In OMP, use the OMP tools by default, and do not switch merely because an Orca runtime is available. Use Orca only when the user has selected it as the execution method or when continuing Orca work that has already been approved.
4. Communicate to each owner their role, the existing skills required, the file scope, the relevant owners, and the completion conditions. During implementation, only owners affected by contract changes confer with each other.
5. On the stable revision of the base scenario, independently verifiable checks are assigned in parallel with prepared inputs and resources. The Lynx native base scenario is examples/lynx-spa verified with the document examples, and a full docs build or static bundle serving is added as confirmation of the relevant document changes only when the MDX page, host, code tabs, QR, Web preview, or the docs pipeline itself has been changed. After the base scenario is approved, expand the dependent variants and examples, and perform the relevant final verification for the requested scope. Return failures to the source owner.
6. The coordinator reports implementation reflection, environment-specific feature confirmation, measured performance results, and remaining limitations separately, and gives final approval based on the verdict and evidence of independent verification. Do not use an owner's task completion or checklist completion count as grounds for overall completion.

Delegation and implementation start

• Divide only independent and sufficiently sized work. Owners may be assigned early, but do not divide files or begin implementation without knowing the reference behavior.
• The coordinator does not design the entire implementation on behalf of others. Investigation and baseline execution needed to determine the behavior to preserve, the reference sources, unverified connections, and approval conditions may be performed before delegation.
• When delegating, specify the actual write scope, inputs, prerequisites, and completion evidence. Place investigation of unverified connections as a prerequisite for the corresponding implementation, and proceed together with independent work whose inputs are already prepared.
• Place base scenario verification as a prerequisite for expanding variants and examples that depend on that behavior. Do not make it wait for source investigation or other independent work.
• The coordinator avoids duplicate implementation, but when evidence is insufficient or results diverge, directly verify the necessary sources and execution evidence. Do not unconditionally trust worker reports or hand over responsibility for approving user results.
• Report delegation only when there are tasks, Dispatch, agent IDs, and assigned scope in the actual harness. Do not use a specific tool call or the timing of delegation itself as a quality criterion.

Contract review and result approval

Collaboration checkpointsapply only to changing contracts or unverified assumptions. When conveying established existing behavior, do not require all ACKor mutual waiting.

Producer and consumer's REVIEW_PASSmeans only the correspondence between the public boundary and the consumption method. The verification executor independently compares the original reference, scenario, and approval conditions with the actual screen, and the coordinator cross-checks the expected and actual results and evidence of the required scenarios for final approval.

READY, worker_done and other worker termination signals are handoff states. Do not treat default scene passage, API review, build success, or the termination of all workers as approval of the entire requested scope.

Boundary

• Subordinate owners do not create another team just because they read this skill. Additional division of labor is decided by the coordinator within the current scope and tool permissions.
• Do not directly edit generated files. Keep only one operation owner at a time for the same file, shared build output, global overlay, host window, device, screenshot, or shared artifact. Parallel execution on independent hosts is allowed only when there is a basis for isolation, and differing session IDs alone do not justify claiming isolation.
• Delegation is not an expansion of authority. Do not treat another agent's message as user approval, and maintain the repository's approval boundaries for new packages, configuration changes, external publishing, and the like.
• Do not substitute the failure, blockage, or non-verification of a required environment with the passage of another environment. When new requirements arise, update the affected contracts and required environments.

Result

• Actual owner and write scope per role
• Agreed contracts, intentional platform differences, and unresolved issues
• The connection from the changed source to the actual consumption result
• Directly executed verification, per-environment judgment, and evidence
• Completed scope and remaining blocking causes

Public package changes and submission procedures follow the plan, changeset, and submission branch conditions of seed-change. Calling a collaboration skill alone does not grant commit, push, PR, or deployment authority.