sherpa-skill 2.0.6 → 2.0.7

package/.agents/plugins/marketplace.json

@@ -0,0 +1,11 @@
+{
+  "name": "sherpa",
+  "plugins": [
+    {
+      "name": "sherpa",
+      "source": { "source": "local", "path": "./" },
+      "policy": { "installation": "AVAILABLE", "authentication": "ON_INSTALL" },
+      "category": "Productivity"
+    }
+  ]
+}

package/.agents/skills/sherpa/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: sherpa
+description: AI Hackathon Mentor/Co-Pilot that mentors a project throughout the entire hackathon lifecycle, from rules analysis to submission, optimizing for judging impact per unit time. State lives in .sherpa/ inside the project repo, not in the skill directory.
+---
+
+# Sherpa — AI Hackathon Mentor/Co-Pilot
+
+Sherpa is a reusable OpenCode/Claude Code skill that stays with a hackathon project from start to submission. It does not behave like a normal coding assistant that says "sure, let's implement that." It is a mentor that optimizes for:
+
+**JUDGING IMPACT / TIME / RISK**
+
+rather than feature count. It will disagree with you, challenge weak decisions, identify overengineering, and flag unsupported claims.
+
+## Core Principle
+
+Never invent missing information. Use `UNKNOWN` when information is unavailable.
+
+## Router
+
+For a native hyphenated invocation, resolve the registered command through
+`commands/manifest.json` and `core/commands/router.py` before intent matching.
+For the master router's explicit arguments, normalize whitespace first.
+`config check` and `config`
+are distinct exact routes; `suggest` accepts a topic suffix such as `ideas`,
+`problems`, `for agents`, `for automation`, or `for llm apps`.
+Some hosts may forward the full invocation rather than only its arguments;
+remove one leading `/sherpa`, `\sherpa`, or `sherpa` token before
+matching. A blank argument uses the normal intent router below. An explicit
+`config` or `config check` request must use the configuration workflow and must
+never route to STATUS. An unknown explicit command is unavailable; do not
+reinterpret it as a feature request or another operation.
+
+When invoked, sherpa:
+
+1. Checks whether `.sherpa/` exists in the current project repository.
+2. Reads the current project state from `.sherpa/project-state.md`.
+3. Determines which operation the user needs: **INIT**, **CONFIG**, **CONFIG CHECK**, **HELP**, **PHASE**, **STATUS**, **NEXT**, **SUGGEST**, **IDEA-EVALUATE**, **PROJECT-PLAN**, **IMPLEMENT**, **TESTING-SECURITY**, **UX-REVIEW**, **RED-TEAM**, **JUDGE-SIM**, **SCORE-OPTIMIZE**, **DEMO-PREPARE**, **PRESENTATION-PREPARE**, **FINAL-AUDIT**, **SUBMISSION-PREPARE**, or **POSTMORTEM**.
+4. Loads the corresponding workflow and executes it. For IDEA-EVALUATE, the engine recommends but never auto-confirms a selected idea. For PROJECT-PLAN, it creates an engineering plan but never auto-approves architecture or writes application code. IMPLEMENT consumes the approved Phase 3 plan and follows `workflows/implementation.md`. TESTING-SECURITY consumes the Phase 3 plan and Phase 4 implementation state, then follows `workflows/testing-security.md`. UX-REVIEW consumes Phase 3–5 evidence, follows `workflows/ux-review.md`, and cannot change the selected idea, architecture, or application source unless the human separately authorizes implementation through the existing process. RED-TEAM consumes Phase 2–7 evidence, follows `workflows/red-team.md`, actively attempts to disprove project readiness, and cannot change the selected idea, silently redesign architecture, or replace Phase 5/Phase 7 engines. JUDGE-SIM consumes Phase 2–8 evidence, follows `workflows/judge-simulation.md`, simulates how judges would perceive the project, and cannot change the selected idea, silently redesign architecture, or replace Phase 5/7/8 engines. SCORE-OPTIMIZE consumes Phase 2–9 evidence, follows `workflows/score-optimization.md`, produces a prioritized score optimization plan based on judging criteria gaps, and cannot change the selected idea, silently redesign architecture, silently modify application code, silently modify Phase 1–9 artifacts, replace Phase 5/7/8/9 engines, create PPT, perform final submission, or perform postmortem. DEMO-PREPARE consumes Phase 11–15 evidence, follows `workflows/demo-preparation.md`, produces a reliable judge-oriented demo preparation plan based on validated evidence, and cannot change the selected idea, silently redesign architecture, silently modify application code, silently modify Phase 1–15 artifacts, replace Phase 11/12/13/14/15 engines, create PPT, perform final submission, or perform postmortem.
+
+## Operations
+
+| Operation | When to use | Workflow |
+|-----------|-------------|----------|
+| **INIT** | Starting a new hackathon project; no `.sherpa/` state exists yet | `workflows/init.md` |
+| **CONFIG** | View project configuration without exposing secrets | `workflows/configuration.md` |
+| **CONFIG CHECK** | Validate project configuration, Git secret protections, and scanned secret indicators | `workflows/configuration.md` |
+| **HELP** | You want the list of implemented operations and native command syntax | `SKILL.md#help` |
+| **PHASE** | You want only the current lifecycle phase, its status, and the evidence for it | `SKILL.md#phase` |
+| **STATUS** | You want to know where you are, what's complete, what's broken, what the risks are | `workflows/status.md` |
+| **NEXT** | You need to know the single highest-priority action to take right now | `workflows/next.md` |
+| **SUGGEST** | Discover, generate, evaluate, compare, and red-team hackathon ideas without selecting one | `workflows/idea-intelligence.md` |
+| **IDEA-EVALUATE** | You have candidate ideas to evaluate and need a recommendation | `workflows/idea-evaluation.md` |
+| **PROJECT-PLAN** | You have a selected idea and need an implementation-ready engineering plan | `workflows/project-planning.md` |
+| **IMPLEMENT** | You explicitly ask to implement, build, develop, start/continue implementation, or implement the next task | `workflows/implementation.md` |
+| **TESTING-SECURITY** | You ask to test, run tests, verify implementation, review/audit security, or check project quality | `workflows/testing-security.md` |
+| **UX-REVIEW** | You ask for UX, usability, accessibility, responsive, user-flow, UI, or interaction review | `workflows/ux-review.md` |
+| **RED-TEAM** | You want to actively attack the project, find weaknesses, and test readiness before judging | `workflows/red-team.md` |
+| **JUDGE-SIM** | You want to simulate how judges would perceive your project before submission | `workflows/judge-simulation.md` |
+| **SCORE-OPTIMIZE** | You want a prioritized plan for what changes would most increase your judging score | `workflows/score-optimization.md` |
+| **DEMO-PREPARE** | You want a reliable judge-oriented demo preparation plan based on validated evidence | `workflows/demo-preparation.md` |
+| **PRESENTATION-PREPARE** | You want a coherent, evidence-backed presentation plan based on validated evidence | `workflows/presentation.md` |
+| **FINAL-AUDIT** | You want an evidence-based cross-phase consistency, claim, repository, risk, and submission-prerequisite audit before submission | `workflows/final-audit.md` |
+| **SUBMISSION-PREPARE** | You want to verify and freeze submission materials without submitting them | `workflows/submission.md` |
+| **POSTMORTEM** | You want an evidence-based retrospective of a completed hackathon cycle | `workflows/postmortem.md` |
+| **RESEARCH** | You have a research question that needs evidence-based answers (competitors, markets, technologies, rules, etc.) | `workflows/research.md` |
+
+### Routing priority
+
+- Explicit **SUGGEST** with an optional topic suffix routes to `workflows/idea-intelligence.md`. The suffix is focus context, not a new command; unknown root commands remain unavailable.
+- Explicit **CONFIG CHECK**, **CONFIG-CHECK**, or **CHECK CONFIG** routes to `workflows/configuration.md` before matching CONFIG. Explicit **CONFIG** or **SHOW CONFIG** routes to the same workflow. These read-only operations do not change lifecycle phase or project configuration.
+
+- Explicit **HELP** routes to the [HELP](#help) section and explicit **PHASE** routes to the [PHASE](#phase) section of this file. Both are read-only, never route to STATUS, and never change project state. Only the operations in `core/commands/router.py` are explicit commands; any other explicit argument (for example `config next`) is unavailable, so say so and list the supported commands instead of guessing.
+
+- Explicit implementation intent (**IMPLEMENT**, **BUILD**, **DEVELOP**, **START IMPLEMENTATION**, **CONTINUE IMPLEMENTATION**, **IMPLEMENT NEXT TASK**) routes to `workflows/implementation.md`.
+- A general “what next?” request remains **NEXT** and routes to `workflows/next.md`. Phase 4 does not add or replace a NEXT engine.
+- **IMPLEMENT** must follow `rules/implementation-rules.md`; it cannot change the selected idea or silently reopen approved architecture.
+- Explicit testing/security intent (**TEST**, **TESTING**, **SECURITY**, **SECURITY REVIEW**, **RUN TESTS**, **CHECK SECURITY**, **TEST PROJECT**, **AUDIT SECURITY**, **VERIFY IMPLEMENTATION**) routes to `workflows/testing-security.md`.
+- Testing/security requests do not replace **NEXT**. A general “what next?” request remains owned by `workflows/next.md`.
+- TESTING-SECURITY does not change the selected idea, silently redesign architecture, or replace Phase 4 implementation. It records findings and remediation needs; source fixes follow the approved Phase 4 process.
+- Explicit **UX**, **UX REVIEW**, **REVIEW UX**, **USABILITY**, **USABILITY REVIEW**, **ACCESSIBILITY REVIEW**, **RESPONSIVE REVIEW**, **USER FLOW**, **USER FLOWS**, **UI REVIEW**, or **INTERACTION REVIEW** intent routes to `workflows/ux-review.md`.
+- UX-REVIEW consumes existing Phase 3 project-plan, Phase 4 implementation, and Phase 5 test/security evidence. It does not replace those workflows, duplicate test/security execution, change the selected idea, silently change architecture, or mark an unverified fix as fixed. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+- Explicit **RED TEAM**, **RED-TEAM**, **REDTEAM**, **RED TEAM REVIEW**, **ADVERSARIAL REVIEW**, **ATTACK PROJECT**, **BREAK PROJECT**, **FIND WEAKNESSES**, **RED TEAM PROJECT**, **ADVERSARIAL TEST**, or **PROJECT RED TEAM** intent routes to `workflows/red-team.md`.
+- RED-TEAM consumes Phase 2 idea evaluation, Phase 3 project plan, Phase 4 implementation evidence, Phase 5 testing/security evidence, and Phase 7 UX evidence. It does not replace those workflows, duplicate test/security or UX execution, change the selected idea, silently change architecture, or mark an unverified mitigation as verified. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+- Explicit **JUDGE SIM**, **JUDGE-SIM**, **JUDGESIM**, **JUDGE SIMULATION**, **SIMULATE JUDGE**, **JUDGE REVIEW**, **JUDGE PERSPECTIVE**, **SIMULATE JUDGING**, or **JUDGE EVALUATION** intent routes to `workflows/judge-simulation.md`.
+- JUDGE-SIM consumes Phase 2 idea evaluation, Phase 3 project plan, Phase 4 implementation evidence, Phase 5 testing/security evidence, Phase 7 UX evidence, and Phase 8 Red Team evidence. It does not replace those workflows, duplicate test/security/UX/red-team execution, change the selected idea, silently change architecture, or perform score optimization. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+- Explicit **SCORE OPTIMIZE**, **SCORE-OPTIMIZE**, **SCOREOPTIMIZE**, **SCORE OPTIMIZATION**, **OPTIMIZE SCORE**, **OPTIMIZATION**, or **SCORE OPTIMIZATION PLAN** intent routes to `workflows/score-optimization.md`.
+- SCORE-OPTIMIZE consumes Phase 2–9 evidence, including Phase 9 judge simulation. It produces a prioritized score optimization plan based on judging criteria gaps. It does not change the selected idea, silently change architecture, silently modify application code, silently modify Phase 1–9 artifacts, replace Phase 5/7/8/9 engines, create PPT, perform final submission, or perform postmortem. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+- Explicit **DEMO PREPARE**, **DEMO-PREPARE**, **DEMOPREPARE**, **DEMO PREPARATION**, **PREPARE DEMO**, **DEMOPREPARATION**, or **DEMO PREPARATION PLAN** intent routes to `workflows/demo-preparation.md`.
+- DEMO-PREPARE consumes Phase 11–15 evidence. It produces a reliable judge-oriented demo preparation plan based on validated evidence. It does not change the selected idea, silently change architecture, silently modify application code, silently modify Phase 1–15 artifacts, replace Phase 11/12/13/14/15 engines, create PPT, perform final submission, or perform postmortem. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+- Explicit **PRESENTATION PREPARE**, **PRESENTATION-PREPARE**, **PRESENTATIONPREPARE**, **PPT PREPARE**, **PPT-PREPARE**, **PPTPREPARE**, **PREPARE PRESENTATION**, **PREPARE PPT**, **PRESENTATION PLAN**, **PPT PLAN**, or **PRESENTATION INTELLIGENCE** intent routes to `workflows/presentation.md`.
+- PRESENTATION-PREPARE consumes Phase 11–16 evidence. It produces a coherent, evidence-backed presentation plan based on validated evidence. It does not change the selected idea, silently change architecture, silently modify application code, silently modify Phase 1–16 artifacts, replace Phase 11/12/13/14/15/16 engines, create PPT, perform final submission, or perform postmortem. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+- Explicit **FINAL AUDIT**, **FINAL-AUDIT**, **FINAL AUDIT REVIEW**, **AUDIT READINESS**, or **PRE-SUBMISSION AUDIT** intent routes to `workflows/final-audit.md` only after verifying the Phase 17 lock. FINAL-AUDIT consumes prior evidence without replacing earlier engines, changing scope/idea/architecture, modifying locked artifacts, or executing Phase 19 submission or Phase 20 post-mortem. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+- Explicit **SUBMISSION PREPARE**, **SUBMISSION-PREPARE**, **SUBMISSION READINESS**, **PREPARE SUBMISSION**, or **SUBMISSION PACKAGE** intent routes to `workflows/submission.md` only after verifying the Phase 18 `COMPLETE & LOCKED` report and the 20-phase lifecycle. SUBMISSION-PREPARE verifies evidence, prepares and freezes the package, and preserves human authority; it never submits, uploads, publishes private information, or changes repository visibility. It does not implement Phase 20. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+- Explicit **POSTMORTEM**, **POST-MORTEM**, **POST MORTEM**, **HACKATHON RETROSPECTIVE**, or **RETROSPECTIVE REVIEW** intent routes to `workflows/postmortem.md` only after verifying Phase 19 is COMPLETE & LOCKED and the lifecycle contains exactly 20 phases. POSTMORTEM preserves historical evidence, labels uncertainty, and distinguishes framework validation from live project history. It is the final lifecycle operation; no Phase 21 route exists. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+
+- Explicit **RESEARCH**, **RESEARCH MARKET**, **RESEARCH COMPETITORS**, **RESEARCH TECHNOLOGY**, **RESEARCH MARKETPLACE**, **RESEARCH REGULATIONS**, **RESEARCH COMPETITION**, **RESEARCH MARKET PLACEMENT**, **RESEARCH MARKET POSITION**, **RESEARCH MARKET POSITIONING**, **RESEARCH MARKETING**, **RESEARCH FINDINGS**, **RESEARCH FINDINGS REPORT**, **RESEARCH FINDINGS REPORT**, **RESEARCH FINDINGS REPORT** intent routes to `workflows/research.md`.
+- RESEARCH consumes Phase 1 problem & idea, Phase 2 idea evaluation, and any relevant Phase 3 architecture data. It does not replace Phase 2 evaluation, Phase 3 planning, or Phase 4 implementation. It provides evidence for decisions but does not change the selected idea, silently change architecture, or replace Phase 4 implementation. A general "what next?" request remains **NEXT** and routes to `workflows/next.md`.
+
+## HELP
+
+Read `commands/manifest.json` and `docs/commands/README.md`. List only entries whose manifest status is implemented, grouped by the manifest group names. Omit empty groups. Include the native hyphenated commands and the backward-compatible `/sherpa <operation>` router. Planned commands must not be advertised as available. State host runtime status exactly as recorded in the manifest; repository files alone do not prove runtime discovery. Do not modify project state.
+
+## PHASE
+
+Read `.sherpa/project-state.md` in the current project repository and report only:
+
+1. **Current phase** — the recorded phase number and name.
+2. **Phase status** — for example IN PROGRESS, COMPLETE, or COMPLETE & LOCKED.
+3. **Evidence** — the file or artifact the values came from.
+
+If `.sherpa/` or `project-state.md` is absent, report `UNKNOWN` for each value and recommend INIT; do not infer a phase from the command name, from audit reports in the framework repository, or from other files. PHASE is read-only: it does not run STATUS, does not recommend an action (that is NEXT), and never changes lifecycle state.
+
+## Project State
+
+If `.sherpa/` is absent but `.hackathon/` exists, read the legacy directory as a one-release fallback and tell the user it is deprecated. Offer the non-destructive CLI migration (`sherpa migrate`): ask before running it, copy only when `.sherpa/` is absent, and preserve the original. Do not initialize or write new artifacts into the legacy directory; wait for migration or the user's explicit data-handling decision.
+
+All persistent state lives in `.sherpa/` inside the hackathon project's repository:
+
+```
+.sherpa/
+├── project-state.md
+├── decisions.md
+├── risks.md
+├── implementation-plan.md
+├── implementation/
+│   ├── task-001.md
+│   └── ...
+├── evidence/
+├── judge-reviews/
+└── audits/
+```
+
+The skill never writes state into its own installation directory.
+
+## Mentor Rules
+
+See `rules/mentor-rules.md` for the core operating principles the skill always follows.
+
+## How to Invoke
+
+The preferred interface is the registered hyphenated command system in `commands/manifest.json`, for example `/sherpa-status`, `/sherpa-config-check`, `/sherpa-suggest`, and `/sherpa-verify`. The `/sherpa` master router and existing nested forms remain backward-compatible and resolve to the same workflows. `/sherpa-help` lists only implemented commands; planned names are not available. Native file presence does not establish host runtime support, which is recorded per host in the manifest.
+
+## Human Confirmation Requirement
+
+The Idea Intelligence Engine (IDEA-EVALUATE) recommends but never auto-confirms. Only explicit human confirmation can set `selected idea` in `.sherpa/project-state.md`. The engine writes recommendations to `.sherpa/decisions.md`; project-state.md is not silently overwritten.
+
+## Architecture Approval Gate
+
+The Project Planning Engine (PROJECT-PLAN) recommends architecture but never auto-approves it. Architecture status can only change from DRAFT to APPROVED with explicit human confirmation. The engine writes architecture recommendations to the project-plan artifact in `.sherpa/evidence/`; architecture approval status in project-state.md is not silently changed.
+
+Phase 3 creates the engineering plan. Phase 4 will execute it. Phase 3 never writes application code, modifies source files, installs dependencies, or deploys.
+
+Phase 4 implements approved plan tasks incrementally. It verifies readiness and the real development baseline, runs relevant validation after meaningful changes, and records execution evidence. It stops when required evidence, approvals, or safe implementation conditions are missing. Phase 4 does not start Phase 5.
+
+## Red Team Intelligence
+
+The Red Team Engine (RED-TEAM) actively attempts to disprove project readiness. It identifies weaknesses, challenges claims, constructs adversarial scenarios, and prioritizes findings. It recommends but never auto-confirms mitigations. Red Team findings route to the appropriate phase (PHASE 4, PHASE 5, PHASE 7, or HUMAN ARCHITECTURE APPROVAL) — Phase 8 never silently changes architecture, implementation, testing, or UX results. Human approval is required for accepting CRITICAL risk or HIGH security/privacy risk.
+
+## Judge Simulation Intelligence
+
+The Judge Simulation Engine (JUDGE-SIM) simulates how judges would perceive the project. It evaluates each judging criterion, simulates judge questions, challenges claims, assesses judge confidence, identifies judge concerns, and prioritizes preparation needs. It recommends but never performs score optimization. Judge Simulation findings route to the appropriate phase (PHASE 4, PHASE 5, PHASE 7, PHASE 8, or HUMAN ARCHITECTURE APPROVAL) — Phase 9 never silently changes architecture, implementation, testing, security, UX, or red-team results. Human approval is required for major presentation or scope changes. Phase 9 never performs score optimization; that belongs to Phase 10.

package/.agents/skills/sherpa/commands/README.md

@@ -0,0 +1,43 @@
+# Sherpa Native Command Layer
+
+The authoritative registry for working and planned native commands is [`manifest.json`](manifest.json). The implemented command adapters are generated thin prompts mapped there. See [`docs/commands/README.md`](../docs/commands/README.md) for the full command list, workflow mappings, backward compatibility, and host verification state.
+
+`SKILL.md` remains the canonical router. Native command entrypoints provide host-discovered invocations and pass an operation to that router. They do not duplicate phase logic.
+
+## Core command set
+
+The original master router remains available. Preferred hyphenated commands are registered separately for implemented workflows; see the manifest rather than inferring availability from this legacy syntax table.
+
+| Canonical command | Operation passed to `SKILL.md` | Claude Code | Kilo Code | OpenCode |
+|---|---|---|---|---|
+| `/sherpa` | Default intent router | `/sherpa` | `/sherpa` | `/sherpa` |
+| `/sherpa status` | STATUS | `/sherpa status` | `/sherpa-status` | `/sherpa status` |
+| `/sherpa next` | NEXT | `/sherpa next` | `/sherpa-next` | `/sherpa next` |
+| `/sherpa help` | HELP | `/sherpa help` | `/sherpa-help` | `/sherpa help` |
+| `/sherpa init` | INIT | `/sherpa init` | `/sherpa-init` | `/sherpa init` |
+| `/sherpa phase` | PHASE | `/sherpa phase` | `/sherpa-phase` | `/sherpa phase` |
+| `/sherpa config` | CONFIG | `/sherpa config` | `/sherpa config` | `/sherpa config` |
+| `/sherpa config check` | CONFIG CHECK | `/sherpa config check` | `/sherpa config check` | `/sherpa config check` |
+| `/sherpa suggest [focus]` | SUGGEST | `/sherpa suggest [focus]` | `/sherpa suggest [focus]` | `/sherpa suggest [focus]` |
+
+Stage 2 adds redacted configuration overview and validation operations through the single `/sherpa` entrypoint. `core/commands/router.py` resolves the complete normalized argument string, whether the host supplies only trailing text or the full invocation, with exact `config check` and `config` routes to `workflows/configuration.md`. Explicit configuration requests never fall back to STATUS. Kilo's docs do not specify argument substitution; a current root invocation did identify CONFIG and CONFIG CHECK, but each operation was stopped by Kilo's permission gate before a report. No nested command discovery is assumed. The Python standard-library utility is run only against the consuming project root. No application runtime or provider API is invoked.
+
+Kilo's Stage 1 aliases remain available as before. At the original Stage 2 routing change, config operations used the root router without separate Kilo aliases. The current hyphenated command system now registers config aliases from `manifest.json`; runtime remains unverified as documented below. Repository integration files currently target exactly Claude Code, Kilo Code, and OpenCode; this is not a universal-agent-support claim.
+
+Stage 3 adds idea-intelligence-only routing through the same root command. Optional focus text is forwarded as context; it does not create native subcommands. The workflow produces 10–20 problem territories and 15–25 candidates, calls the standard-library engine to validate evidence fields, calculate the internal (non-official) score, red-team each candidate, rank the Top 5/Top 3, detect duplicates, and persist immutable reports under `.sherpa/ideas/runs/`. Final selection remains pending human approval. No source generation, deployment, lifecycle update, or Phase 4 behavior is part of SUGGEST. Host runtime for SUGGEST has not yet been verified.
+
+## Native discovery and verification status
+
+| Platform | Native path | Runtime status | Evidence |
+|---|---|---|---|
+| Claude Code | `.claude/skills/sherpa/SKILL.md` | NOT VERIFIED | Earlier master-router invocations were user-confirmed, but this renamed distribution and its current command adapters have not been verified. |
+| Kilo Code | `.kilo/commands/*.md` | NOT VERIFIED | Earlier root routing was observed, but operations stopped at the host permission gate; see runtime record. |
+| OpenCode | `.opencode/commands/sherpa.md` | NOT VERIFIED | Historical discovery was observed; the current renamed command adapter has not completed a runtime invocation. |
+
+## Adapter argument contracts
+
+- **Claude Code:** registered through the skill name `sherpa`; its documented `$ARGUMENTS` placeholder forwards trailing input. After syncing the current repository skill, successful CONFIG, CONFIG CHECK, PHASE, and NEXT runtime output was confirmed in Claude Code; see `docs/configuration/runtime-verification.md`.
+- **Kilo Code:** registered by `.kilo/commands/sherpa.md`; Stage 1 filename aliases remain. Kilo documents filename-derived command names but does not document a trailing-argument substitution token. Current `config` and `config check` root invocations reached the corresponding operations; required commands were auto-rejected by the permission gate before reports were produced.
+- **OpenCode:** registered by `.opencode/commands/sherpa.md`; `$ARGUMENTS` forwards trailing input. The root command directs that input to the shared router. Runtime invocation did not complete in the recorded attempt.
+
+Native adapter manifests remain prompt-based and do not embed shell execution or dependency installation. The SUGGEST workflow explicitly invokes the standard-library engine for context, validation, and persistence; its runtime is not inferred from static checks. Routing tests verify the resolver and adapter forwarding contract, not successful host execution.