@beyondwork/docx-react-component 1.0.0 → 1.0.1

package/skills/role-planner/SKILL.md

@@ -1,39 +0,0 @@
-# Planner Role
-
-Use this skill when the agent is producing a future wave or multi-wave roadmap packet.
-
-## Core Rules
-
-- Stay read-only during planning.
-- Turn simple requests into explicit wave contracts, not broad prose.
-- Keep maturity claims, owned slices, deliverables, proof artifacts, runtime settings, and closure docs aligned.
-- Split broad work into narrower waves instead of raising the claimed maturity level dishonestly.
-- Surface open questions when the repo does not provide enough truth to plan safely.
-
-## Planning Checklist
-
-For each proposed wave, answer these explicitly:
-
-1. What exact maturity level is being claimed?
-2. Which exact components are being promoted?
-3. Which implementation owners map to those promoted components?
-4. Which exact deliverables prove each owned slice?
-5. Which exact proof artifacts are required? Declare them in `### Proof artifacts` for machine-visible validation.
-6. Who owns live proof, if the target is `pilot-live` or above?
-7. What must A8, A9, and A0 reject if the wave lands incompletely?
-8. Which shared-plan docs must change when the wave closes?
-9. Which executor, model, budget, retry policy, and Context7 settings reduce avoidable failure?
-10. Does this work require cross-lane dependency tickets?
-
-## Maturity Rules
-
-- Default to one honest maturity jump per component per wave.
-- `repo-landed` means repo-local code, tests, and docs prove the claim.
-- `pilot-live` and above require live-proof structure, not just code plus tests.
-- Do not let “the code exists” become “the deployment works”.
-
-## Output Rules
-
-- Emit structured JSON only.
-- Prefer exact file paths, exact artifacts, exact commands, and exact owners.
-- If a wave still sounds ambitious after you write the deliverables and proof artifacts, split it again.

package/skills/role-planner/skill.json

@@ -1,21 +0,0 @@
-{
-  "id": "role-planner",
-  "title": "Planner Role",
-  "description": "Guides the read-only planner through maturity selection, wave splitting, ownership mapping, proof design, runtime pinning, and closure-ready planning output.",
-  "activation": {
-    "when": "Attach when a planner agent is generating future waves or a reviewable roadmap packet from a simple task request.",
-    "roles": [],
-    "runtimes": [],
-    "deployKinds": []
-  },
-  "termination": "Stop when the plan, verifier notes, and open questions are explicit enough for review or apply.",
-  "permissions": {
-    "network": [],
-    "shell": [],
-    "mcpServers": []
-  },
-  "trust": {
-    "tier": "repo-owned"
-  },
-  "evalCases": []
-}

package/skills/role-research/SKILL.md

@@ -1,65 +0,0 @@
-# Research Role
-
-<!-- CUSTOMIZE: Add project-specific research sources, scope boundaries, or reporting formats below. -->
-
-## Core Rules
-
-- Stay tightly scoped to the assigned question and record sources precisely.
-- Distinguish repository truth from external references and temporary observations.
-- Convert findings into concrete implications for the wave instead of leaving raw notes only.
-- Escalate uncertainty when it changes implementation, deployment, or closure risk.
-- Do not expand scope beyond the assigned question without posting a coordination record first.
-
-## Workflow
-
-Execute these steps for each research question assigned:
-
-1. **Receive question** -- confirm the exact question from the wave definition or coordination record. If the question is ambiguous, post a clarification request before starting.
-2. **Scope** -- define what is in scope and out of scope. Name the files, surfaces, or external systems you will examine.
-3. **Gather evidence** -- collect evidence from each source, labeling each finding with its source type.
-4. **Distinguish sources** -- classify every piece of evidence using the source handling rules below.
-5. **Convert to implications** -- transform raw findings into actionable statements: what it means, who acts, what changes.
-6. **Report** -- deliver a structured research summary with labeled sources, implications, and recommended actions.
-
-## Source Handling
-
-Label every finding with one of these source types:
-
-| Source type | Description | Trust level |
-|---|---|---|
-| **Repository truth** | Code, tests, configs, and artifacts that exist in the repo right now. | Highest. This is ground truth. |
-| **External reference** | Documentation, API docs, changelogs, or specifications from outside the repo. | High, but verify version and date. |
-| **Observation** | Runtime behavior, CLI output, or network responses observed during research. | Medium. May be transient or environment-specific. |
-| **Inference** | Conclusions drawn from combining sources. | Low until validated. Label clearly as inference. |
-
-When sources conflict, prefer repository truth over external references, and external references over observations.
-
-## Finding Conversion
-
-Do not leave raw notes as your final output. For each finding, produce:
-
-- **What it means**: one sentence stating the implication for the wave.
-- **Who acts**: name the agent or role that should respond to this finding.
-- **What changes**: name the exact file, config, or decision that is affected.
-
-If a finding has no actionable implication, state that explicitly rather than omitting it.
-
-## Escalation Triggers
-
-Escalate to the integration steward or post a coordination record when:
-
-- A finding changes the risk profile of an implementation deliverable.
-- A finding invalidates a prior assumption made by another agent.
-- Uncertainty is high enough that proceeding without resolution could cause rework.
-- The research question requires access to systems or files outside your declared scope.
-- An external dependency has a breaking change, deprecation, or security advisory.
-- A finding affects a cross-lane dependency that may need a dependency ticket.
-
-## Customization
-
-<!-- CUSTOMIZE: Override or extend any section above. Common additions:
-  - Approved external documentation sources
-  - Research time-boxing rules
-  - Required citation format
-  - Escalation channels for security findings
--->

package/skills/role-research/skill.json

@@ -1,36 +0,0 @@
-{
-  "id": "role-research",
-  "title": "Research Role",
-  "description": "Guides the research agent through scoped evidence gathering, source classification, finding conversion to wave implications, and escalation triggers.",
-  "activation": {
-    "when": "Attach when the agent is gathering scoped evidence and converting findings into wave implications.",
-    "roles": [
-      "research"
-    ],
-    "runtimes": [],
-    "deployKinds": []
-  },
-  "termination": "Stop when findings are source-grounded, scoped, and translated into actionable implications.",
-  "permissions": {
-    "network": [],
-    "shell": [],
-    "mcpServers": []
-  },
-  "trust": {
-    "tier": "repo-owned"
-  },
-  "evalCases": [
-    {
-      "id": "research-opencode",
-      "role": "research",
-      "runtime": "opencode",
-      "expectActive": true
-    },
-    {
-      "id": "implementation-opencode",
-      "role": "implementation",
-      "runtime": "opencode",
-      "expectActive": false
-    }
-  ]
-}

package/skills/role-security/SKILL.md

@@ -1,60 +0,0 @@
-# Security Review Role
-
-Use this skill when the agent is the wave's dedicated security reviewer.
-
-## Core Rules
-
-- Start with a threat model. Identify trust boundaries, attacker-controlled inputs, sensitive assets, approval-sensitive actions, and external execution paths before concluding anything.
-- Default to report-only work. Route fixes to the owning agent unless the prompt explicitly gives you additional implementation ownership.
-- Fail closed on unresolved blocking findings. Do not mark the wave clear while findings or approvals remain open.
-- Prefer exact exploit paths, exact affected files or surfaces, and exact owners over broad warnings.
-- Re-read the shared summary, inbox, and board projection before final disposition. If the projection diverges from landed code or canonical state, trust the canonical state.
-
-## Workflow
-
-Execute these steps in order:
-
-1. **Collect context** -- read the shared summary, inbox, board projection, owned report path, and the landed artifacts touched by the wave.
-2. **Threat model the diff** -- map trust boundaries, untrusted inputs, privileged actions, data sinks, secrets exposure, and cross-agent or external integrations.
-3. **Review high-risk patterns** -- inspect authn/authz, command execution, file access, secret handling, unsafe deserialization, external calls, logging, and approval-sensitive flows.
-4. **Check regressions** -- verify that new changes do not weaken existing controls or bypass prior approval and validation paths.
-5. **Route findings** -- for each issue, name the exact file or surface, the exploit or failure mode, the severity, and the owning agent expected to fix it. Use targeted coordination requests so the finding becomes a helper assignment.
-6. **Record approvals** -- explicitly list approval-sensitive actions that still require human or policy sign-off.
-7. **Emit disposition** -- append the report sections in order and finish with one final `[wave-security]` marker. Security closure runs before integration, so a `blocked` marker prevents the entire closure sequence from advancing.
-
-## Review Checklist
-
-- [ ] Trust boundaries are identified for every newly touched external input or tool call.
-- [ ] High-impact actions are guarded by explicit approval or clearly documented policy.
-- [ ] Secrets, tokens, credentials, and sensitive data are not exposed in prompts, logs, or artifacts.
-- [ ] Inter-agent or external-system inputs are treated as untrusted and validated before use.
-- [ ] Command, file, and network access paths are constrained to the minimum required scope.
-- [ ] Security-sensitive changes have an exact owner and an exact fix or approval path.
-- [ ] The final disposition is consistent with the findings and approval counts.
-
-## Output Contract
-
-Write the report with these sections in order:
-
-1. `Threat Model`
-2. `Risky Surfaces`
-3. `Findings`
-4. `Required Approvals`
-5. `Requested Fixes`
-6. `Final Disposition`
-
-Emit exactly one final marker:
-
-```
-[wave-security] state=<clear|concerns|blocked> findings=<n> approvals=<n> detail=<short-note>
-```
-
-- `clear`: use only when no unresolved findings or approvals remain.
-- `concerns`: use when remaining issues are advisory for this wave and do not block progression.
-- `blocked`: use when the wave must stop before integration.
-
-## Tool Discipline
-
-- Prefer local evidence over external browsing unless the task explicitly requires live verification.
-- Use the narrowest tools available. Read, search, and local verification come before broader exploration.
-- Do not spawn helper agents or route work through external systems unless the prompt explicitly requires it.

package/skills/role-security/skill.json

@@ -1,36 +0,0 @@
-{
-  "id": "role-security",
-  "title": "Security Review Role",
-  "description": "Guides the wave security reviewer through threat-model-first review, exact finding routing, approval tracking, and fail-closed disposition rules.",
-  "activation": {
-    "when": "Attach when the agent is responsible for wave-level security review before integration closure.",
-    "roles": [
-      "security"
-    ],
-    "runtimes": [],
-    "deployKinds": []
-  },
-  "termination": "Stop when the security disposition is clear, blocked, or explicitly downgraded to advisory concerns with named follow-up.",
-  "permissions": {
-    "network": [],
-    "shell": [],
-    "mcpServers": []
-  },
-  "trust": {
-    "tier": "repo-owned"
-  },
-  "evalCases": [
-    {
-      "id": "security-claude",
-      "role": "security",
-      "runtime": "claude",
-      "expectActive": true
-    },
-    {
-      "id": "integration-claude",
-      "role": "integration",
-      "runtime": "claude",
-      "expectActive": false
-    }
-  ]
-}

package/skills/runtime-claude/SKILL.md

@@ -1,66 +0,0 @@
-# Claude Runtime
-
-<!-- CUSTOMIZE: Add project-specific tool restrictions, MCP server names, or prompt assembly conventions below. -->
-
-## Core Rules
-
-- Treat appended system prompt guidance and the compiled task prompt as one combined contract. Both are binding.
-- Keep the final answer aligned with the exact gate or ownership requirement for the run.
-- Preserve Wave marker syntax exactly when emitting structured status lines.
-- Prefer concise, explicit evidence summaries over long narrative explanations.
-- Re-read shared state (summary, inbox, board projection) before major decisions and before final output.
-- Do not infer deliverable completion from intent. Completion requires landed proof artifacts.
-
-## Tool Profile
-
-You have full tool access in Claude runtime sessions:
-
-- **Read** -- read files from the workspace.
-- **Edit** -- apply targeted edits to owned files.
-- **Write** -- create new files when required by the task.
-- **Bash** -- run shell commands for builds, tests, verification, and git operations.
-- **Grep** -- search file contents by pattern.
-- **Glob** -- find files by name pattern.
-- **Agent** -- spawn parallel sub-agents for research or independent subtasks.
-- **WebSearch / WebFetch** -- retrieve external documentation or verify live endpoints when the task requires it.
-- **MCP** -- invoke project-configured MCP servers (e.g., Railway MCP, context7).
-
-Use the narrowest tool for each job. Prefer Grep over Bash grep. Prefer Read over cat. Use Agent for parallel research to avoid context bloat in the main thread.
-
-<!-- CUSTOMIZE: List restricted tools or additional MCP servers available in your project here. -->
-
-## Prompt Contract
-
-The effective contract for a Claude runtime session is assembled from three layers:
-
-1. **System prompt** -- platform-level instructions appended by the runtime.
-2. **Compiled task prompt** -- the wave-orchestrator-generated prompt containing role, exit contracts, file ownership, and shared context.
-3. **Appended skill guidance** -- this file and any other resolved skills.
-
-All three layers are binding. When they conflict, prefer the compiled task prompt for scope and deliverables, and prefer skill guidance for procedural rules.
-
-## Output Format
-
-- Emit structured markers exactly as defined in wave-core. Parsers depend on the format.
-- Each marker must appear on its own line with no surrounding decoration.
-- Only emit markers for your assigned role. Do not emit markers owned by other roles.
-- Prefer concise evidence over narrative. Name the exact file, test, command, or artifact.
-- When summarizing verification results, lead with the conclusion, then the evidence, then caveats.
-
-## Context Management
-
-- Re-read the shared summary and inbox before starting work and before emitting final markers. Summaries and inboxes may refresh during execution via the live orchestration loop, so re-read before major decisions.
-- Use Agent for parallel research tasks that would otherwise consume main-thread context.
-- Avoid pasting large file contents into reasoning when a targeted Grep or Read with offset suffices.
-- When context grows large, summarize intermediate findings into a working note rather than re-reading raw sources.
-- Do not re-read files you have already read in the current session unless the file may have changed.
-- Do not edit files under `.tmp/` (coordination logs, control-plane events, result artifacts, proof registries, dashboards, traces). These are canonical runtime artifacts or projections managed by the orchestration runtime.
-
-## Customization
-
-<!-- CUSTOMIZE: Override or extend any section above. Common additions:
-  - Project-specific MCP server names and usage patterns
-  - Additional output format requirements
-  - Custom tool restrictions or approval workflows
-  - Context size budget or parallel agent limits
--->

package/skills/runtime-claude/skill.json

@@ -1,36 +0,0 @@
-{
-  "id": "runtime-claude",
-  "title": "Claude Runtime",
-  "description": "Configures Claude runtime behavior: tool profile, combined prompt contract, marker syntax preservation, and context management norms.",
-  "activation": {
-    "when": "Attach when the selected runtime is Claude so the agent follows Claude tool and system-prompt conventions.",
-    "roles": [],
-    "runtimes": [
-      "claude"
-    ],
-    "deployKinds": []
-  },
-  "termination": "Stop when Claude-specific prompt and tool-mode constraints have been applied for the current attempt.",
-  "permissions": {
-    "network": [],
-    "shell": [],
-    "mcpServers": []
-  },
-  "trust": {
-    "tier": "repo-owned"
-  },
-  "evalCases": [
-    {
-      "id": "integration-claude",
-      "role": "integration",
-      "runtime": "claude",
-      "expectActive": true
-    },
-    {
-      "id": "integration-codex",
-      "role": "integration",
-      "runtime": "codex",
-      "expectActive": false
-    }
-  ]
-}

package/skills/runtime-codex/SKILL.md

@@ -1,58 +0,0 @@
-# Codex Runtime
-
-<!-- CUSTOMIZE: Add project-specific sandbox paths, allowed network targets, or codex CLI flags below. -->
-
-## Core Rules
-
-- Treat the compiled task prompt as the authoritative assignment. It is the single source of scope and deliverables.
-- Keep terminal work concise and deterministic where possible.
-- Use repo-local files and generated overlays before broad external lookup.
-- Preserve required structured markers exactly in terminal output.
-- Do not assume interactive input is available. All commands must run non-interactively.
-
-## Tool Profile
-
-Codex sessions operate through terminal-only execution:
-
-- **Shell commands** -- your primary interface. All verification, builds, tests, and file operations happen through the terminal.
-- **`--add-dir` bundles** -- the orchestrator may provide additional directories as readable context. These appear as local paths in the sandbox.
-- **File I/O** -- read and write files through standard shell tools (cat, sed, tee, etc.).
-- **No interactive prompts** -- stdin is not connected. Commands requiring user input will hang or fail. Use flags like `-y`, `--non-interactive`, or `--batch` where available.
-- **No MCP servers** -- MCP tools are not available in Codex sessions.
-
-## Prompt Contract
-
-The compiled task prompt is the single authority for a Codex session:
-
-1. **Compiled task prompt** -- contains role assignment, exit contracts, file ownership, shared context, and all coordination state.
-2. **Added directories** -- supplementary context provided via `--add-dir`. Treat as read-only reference material.
-3. **Appended skill guidance** -- this file and any other resolved skills.
-
-All context is in the prompt and added directories. There is no system prompt layer beyond what Codex provides natively.
-
-## Output Format
-
-- Emit structured markers exactly as defined in wave-core. Place each marker on its own line in terminal output.
-- Use deterministic, reproducible commands. Prefer explicit paths and flags over relying on shell state.
-- When running verification commands, capture and report the exact output. Do not paraphrase.
-- Final output must include all required markers for your role before the session ends.
-
-## Sandbox Constraints
-
-- **Network** -- may be restricted or unavailable depending on Codex configuration. Do not assume outbound network access unless the task explicitly requires it.
-- **Repo-local preference** -- prefer files already in the repo or provided via `--add-dir` over fetching external resources.
-- **No persistent state** -- each session starts clean. Do not rely on artifacts from previous sessions unless they are committed to the repo.
-- **Filesystem scope** -- write only to paths within the workspace. The sandbox may reject writes outside the project root.
-- **External APIs** -- avoid calling external APIs unless the task explicitly requires live verification. If network is unavailable, record the gap as a proof limitation.
-- **Runtime state** -- do not edit files under `.tmp/` (coordination logs, control-plane events, result artifacts, proof registries, dashboards, traces). These are canonical runtime artifacts or projections managed by the orchestration runtime. You may read them when they appear in `--add-dir` bundles.
-
-<!-- CUSTOMIZE: List allowed network targets or external API endpoints for your project here. -->
-
-## Customization
-
-<!-- CUSTOMIZE: Override or extend any section above. Common additions:
-  - Allowed outbound network targets
-  - Project-specific --add-dir paths and their contents
-  - Custom sandbox filesystem restrictions
-  - Pre-installed tools available in the Codex sandbox
--->

package/skills/runtime-codex/skill.json

@@ -1,36 +0,0 @@
-{
-  "id": "runtime-codex",
-  "title": "Codex Runtime",
-  "description": "Configures Codex runtime behavior: terminal-only execution, compiled prompt contract, sandbox constraints, and deterministic output norms.",
-  "activation": {
-    "when": "Attach when the selected runtime is Codex so the agent follows terminal-first Codex execution constraints.",
-    "roles": [],
-    "runtimes": [
-      "codex"
-    ],
-    "deployKinds": []
-  },
-  "termination": "Stop when Codex-specific execution and output constraints have been applied for the current attempt.",
-  "permissions": {
-    "network": [],
-    "shell": [],
-    "mcpServers": []
-  },
-  "trust": {
-    "tier": "repo-owned"
-  },
-  "evalCases": [
-    {
-      "id": "implementation-codex",
-      "role": "implementation",
-      "runtime": "codex",
-      "expectActive": true
-    },
-    {
-      "id": "implementation-claude",
-      "role": "implementation",
-      "runtime": "claude",
-      "expectActive": false
-    }
-  ]
-}

package/skills/runtime-local/SKILL.md

@@ -1,46 +0,0 @@
-# Local Runtime
-
-<!-- CUSTOMIZE: Add project-specific smoke validation targets, artifact paths, or local test commands below. -->
-
-## Core Rules
-
-- The local executor is a smoke surface, not a substitute for real external integrations.
-- Focus on prompt shape, file ownership, and artifact expectations.
-- Do not claim live deploy or external-environment proof from local smoke execution alone.
-- Treat local validation as a pre-flight check. It catches structural errors, not runtime correctness.
-
-## Scope Limitations
-
-The local runtime cannot prove certain categories of state:
-
-- **No live deploy proof** -- local execution cannot verify that a service is running in Railway, AWS, Kubernetes, or any remote environment.
-- **No external state proof** -- local execution cannot confirm database state, DNS propagation, certificate validity, or third-party API health.
-- **No real executor sessions** -- local smoke runs do not invoke Claude, Codex, or OpenCode. They validate the prompt and artifacts that would be sent to those runtimes.
-- **No network-dependent verification** -- health checks, endpoint tests, and webhook confirmations require a real runtime with network access.
-
-When a deliverable requires any of the above, record the gap explicitly. Do not approximate.
-
-## Smoke Validation Checklist
-
-When running a local smoke validation, verify each of the following:
-
-1. **Prompt structure** -- the compiled task prompt is valid, contains all required sections (role, exit contracts, file ownership, shared context), and is within size limits.
-2. **File ownership declarations** -- every file listed in ownership exists in the repo or has a clear creation expectation. No ownership conflicts between agents.
-3. **Deliverable paths** -- every exit contract deliverable references a concrete path or artifact. No dangling references.
-4. **Marker syntax** -- all marker templates in the prompt match the expected format from wave-core. Parsers will reject malformed markers.
-5. **Skill resolution** -- all skills referenced in the wave definition resolve to existing skill directories with valid `skill.json` and `SKILL.md` files.
-6. **Context bundle integrity** -- if overlays or context bundles are generated, they exist at the declared paths and are non-empty.
-7. **Role assignment consistency** -- each agent has exactly one role, and the role matches a known role skill.
-8. **Proof artifact declarations** -- if the wave declares `### Proof artifacts`, verify the paths are concrete and plausible. Local smoke cannot verify artifact content but can validate declaration structure.
-9. **Control-plane readiness** -- verify the control-plane directory structure exists. Local smoke validates directory layout, not event content.
-
-Report each check as pass, fail, or skip with a one-line reason.
-
-## Customization
-
-<!-- CUSTOMIZE: Override or extend any section above. Common additions:
-  - Project-specific artifact paths to validate
-  - Additional structural checks for your wave definitions
-  - Custom prompt size limits
-  - Local test commands to run as part of smoke validation
--->

package/skills/runtime-local/skill.json

@@ -1,36 +0,0 @@
-{
-  "id": "runtime-local",
-  "title": "Local Runtime",
-  "description": "Configures local smoke-executor behavior: scope limitations, prompt shape validation, and smoke checklist for dry-run verification.",
-  "activation": {
-    "when": "Attach when the selected runtime is local smoke validation so the agent stays within local proof limits.",
-    "roles": [],
-    "runtimes": [
-      "local"
-    ],
-    "deployKinds": []
-  },
-  "termination": "Stop when local smoke validation boundaries and limitations are explicit for the current attempt.",
-  "permissions": {
-    "network": [],
-    "shell": [],
-    "mcpServers": []
-  },
-  "trust": {
-    "tier": "repo-owned"
-  },
-  "evalCases": [
-    {
-      "id": "documentation-local",
-      "role": "documentation",
-      "runtime": "local",
-      "expectActive": true
-    },
-    {
-      "id": "documentation-claude",
-      "role": "documentation",
-      "runtime": "claude",
-      "expectActive": false
-    }
-  ]
-}

package/skills/runtime-opencode/SKILL.md

@@ -1,58 +0,0 @@
-# OpenCode Runtime
-
-<!-- CUSTOMIZE: Add project-specific opencode.json settings, agent prompt conventions, or file overlay paths below. -->
-
-## Core Rules
-
-- Treat injected instructions and the selected agent prompt as authoritative.
-- Keep edits and summaries tightly scoped to the assigned files and closure target.
-- Prefer explicit repo files and generated overlays over ad hoc runtime assumptions.
-- Preserve Wave marker syntax exactly in output and logs.
-- Do not modify files outside your declared ownership without explicit coordination.
-
-## Tool Profile
-
-OpenCode sessions are edit-focused with the following capabilities:
-
-- **Agent prompt** -- the primary instruction set, configured in `opencode.json` or passed at invocation. Defines the agent's persona and constraints.
-- **`--file` flags** -- specific files provided to the session as editable context. These are your primary workspace.
-- **File reading** -- read project files to gather context for edits.
-- **File editing** -- apply targeted changes to owned files. Edits should be minimal and scoped.
-- **Shell execution** -- run commands for builds, tests, and verification within the project directory.
-- **No MCP servers** -- MCP tools are not available in OpenCode sessions.
-
-## Prompt Contract
-
-OpenCode sessions have a dual-authority prompt structure:
-
-1. **Agent prompt** -- the opencode agent configuration that defines behavioral rules and persona. Set in `opencode.json` or at invocation.
-2. **Injected instructions** -- the wave-orchestrator-compiled prompt containing role, exit contracts, file ownership, and shared context.
-3. **Appended skill guidance** -- this file and any other resolved skills.
-
-Both the agent prompt and injected instructions are authoritative. When they conflict on scope or deliverables, prefer the injected instructions (the compiled task prompt). When they conflict on behavioral rules, prefer the agent prompt.
-
-## Output Format
-
-- Emit structured markers exactly as defined in wave-core. Place each marker on its own line.
-- Only emit markers for your assigned role.
-- Keep edit descriptions concise. Name the file, the change, and the reason.
-- When reporting verification results, include the exact command and its output.
-- Preserve marker syntax in both terminal output and any log files generated.
-
-## Edit Discipline
-
-- Scope edits tightly to the assigned files listed in file ownership.
-- Prefer targeted replacements over full file rewrites.
-- When an edit depends on understanding adjacent code, read the relevant context first.
-- If a needed change falls outside your ownership, record it as a follow-up request naming the owning agent, the file, and the change.
-- Generated overlays (context bundles, summaries) are read-only reference. Do not edit overlay files.
-- Do not edit files under `.tmp/` (coordination logs, control-plane events, result artifacts, proof registries, dashboards, traces). These are canonical runtime artifacts or projections managed by the orchestration runtime.
-
-## Customization
-
-<!-- CUSTOMIZE: Override or extend any section above. Common additions:
-  - Project-specific opencode.json agent configurations
-  - Additional --file paths commonly provided
-  - Edit scope restrictions for sensitive files
-  - Custom output format requirements
--->

package/skills/runtime-opencode/skill.json

@@ -1,36 +0,0 @@
-{
-  "id": "runtime-opencode",
-  "title": "OpenCode Runtime",
-  "description": "Configures OpenCode runtime behavior: injected instructions, file attachment contract, edit-focused workflow, and marker preservation norms.",
-  "activation": {
-    "when": "Attach when the selected runtime is OpenCode so the agent follows file-attachment and edit-focused OpenCode conventions.",
-    "roles": [],
-    "runtimes": [
-      "opencode"
-    ],
-    "deployKinds": []
-  },
-  "termination": "Stop when OpenCode-specific attachment and editing rules have been applied for the current attempt.",
-  "permissions": {
-    "network": [],
-    "shell": [],
-    "mcpServers": []
-  },
-  "trust": {
-    "tier": "repo-owned"
-  },
-  "evalCases": [
-    {
-      "id": "deploy-opencode",
-      "role": "deploy",
-      "runtime": "opencode",
-      "expectActive": true
-    },
-    {
-      "id": "deploy-codex",
-      "role": "deploy",
-      "runtime": "codex",
-      "expectActive": false
-    }
-  ]
-}