@alis-build/opencode-plugin 0.1.0 → 0.2.0

package/README.md

@@ -12,8 +12,8 @@ builds, deploys, and related workspace context — the opencode counterpart of t
 - OAuth sign-in through Alis Build identity (handled by opencode)
 - Alis Build tools available inside opencode after sign-in
 - A standing Define → Build → Deploy primer loaded into every session via opencode
-  `instructions`, so the agent knows the workflow, how to route requests, and to run
-  the `alis` CLI — no trigger word required
+  `instructions`, so the agent always knows the workflow, how to route requests (it wakes
+  skill discovery when you address **alis**), and how to run the `alis` CLI
 - `/build-it` and `/fix-it` workflow commands
 - The `alis` CLI auto-approved via opencode `permission.bash`, so command-line calls
   run without a permission prompt each time
@@ -97,11 +97,11 @@ opencode mcp auth api
 After sign-in, ask opencode to use Alis Build:
 
 ```text
-build it
+alis, build it
 ```
 
 ```text
-fix it
+alis, fix it
 ```
 
 ```text

package/instructions/dbd-primer.md

@@ -7,7 +7,7 @@ Alis Build task, and walk the user through DBD rather than handing over a discon
 This primer is the standing how-to guide for Alis Build work. It carries three things:
 
 1. The **mental model** — what DBD is and where things live on disk.
-2. The **routing contract** — when to discover a skill, when to run a command directly.
+2. The **routing contract** — saying "alis" wakes skill discovery; when to run a command directly.
 3. The **execution contract** — how to actually run Define / Build / Deploy.
 
 > The Alis Build MCP provides the *tools*; this primer provides *how to operate*. When a
@@ -41,47 +41,42 @@ This primer is the standing how-to guide for Alis Build work. It carries three t
 - Deploy makes the service reachable infrastructure (commonly Cloud Run plus supporting resources).
 - Validate end-to-end via the generated playground, usually `<neuron>/.playground/main_test.go`.
 
-## Routing — discover a skill vs run a command directly
-
-Not every Alis Build request is the same kind of work. Classify first, then act.
-
-- **Routers — discover a skill before acting.** For an ambiguous *functional* request — the
-  user wants to build, fix, add, or change something and the agent needs to know *how* — treat
-  it as a router, not a direct task. Triggers: "build it", "fix it", "add X", "change Y", and
-  capability questions ("can you help with tracing?", "are you able to add X?").
-  - Work out the intended outcome (ask ONE concise question only if it is genuinely ambiguous),
-    then call the Alis Build MCP `SearchSkills` tool FIRST with that outcome as the query (fall
-    back to `ListSkills` if it returns nothing).
-  - Present the matching skills (id, what each does, when to choose it), ask which to use, and
-    only then call `LoadSkill` and follow that skill's workflow — the loaded skill owns
-    execution.
-  - **Do NOT inspect, write, or edit code, run Define / Build / Deploy, or make commits before
-    a skill is loaded.** If no skill fits, say so and offer `RequestSkill`.
-  - For a capability question, briefly confirm it is Alis Build work, then ask the user to name
-    the specific change so you can route it through `SearchSkills`. Do not dive into the
-    codebase or give a generic how-to before they name the concrete change.
-
-- **Direct DBD commands — run the CLI, no skill needed.** When the user asks to run a *DBD
-  step* on an already-known target service, just run it (see **Executing DBD**). Triggers:
-  "define it", "deploy it", "ship it", "run define/build/deploy", "define and install". These
-  are deterministic; they do not need skill reasoning.
-
-- **Spec it — call `SpecIt` directly.** "spec it" / "spec it up", or a request to turn the
+## Routing — say "alis" to wake the skill router
+
+Skill discovery is **opt-in, gated on the wake word.** What wakes the routing flow is the
+developer *speaking to alis* — not the shape of the request. Do **NOT** run `SearchSkills` on
+ordinary build/fix/add-sounding prompts; firing it on every functional-looking message floods
+the session. Wait to be addressed.
+
+- **Addressed to alis → wake up and route.** When the developer speaks to alis — "alis, …",
+  "hey alis", "ask alis to …", "get alis to …", or otherwise invokes alis by name — wake up
+  and find a skill: work out the intended outcome (ask ONE concise question only if it is
+  genuinely ambiguous), call the Alis Build MCP `SearchSkills` tool FIRST with that outcome as
+  the query (fall back to `ListSkills` if it returns nothing), present the matches (id, what
+  each does, when to choose it), then `LoadSkill` and follow that skill — the loaded skill owns
+  execution. **Do NOT inspect, write, or edit code, run Define / Build / Deploy, or make
+  commits before a skill is loaded.** If nothing fits, say so and offer `RequestSkill`. Explicitly
+  running the `build it` / `fix it` command is itself a way to address alis and invoke this flow.
+
+- **Not addressed to alis → just respond.** Handle the request directly, or ask what they
+  need — do not auto-route it through `SearchSkills`. If a skill would clearly help, you may
+  suggest the developer "ask alis" to wake the router, but don't force it.
+
+- **Direct DBD commands → run the CLI, no skill needed.** "define it", "deploy it", "ship it",
+  "run define/build/deploy", "define and install" on an already-known target are deterministic
+  — run `alis …` (see **Executing DBD**). These are explicit instructions, not skill
+  discovery; they don't need the wake word.
+
+- **Spec it → call `SpecIt` directly.** "spec it" / "spec it up", or a request to turn the
   current session into a build specification → call the `SpecIt` tool DIRECTLY (do not route
   through `SearchSkills`). It needs no arguments (session context is resolved server-side);
   pass `build_spec` only when the user names an existing one to append to. Report the returned
   BuildSpec back to the user.
 
-- **"alis" (vocative) / "dbd"** engage Alis Build context generally — then disambiguate with
-  the cases above.
-
-- **"build it" is overloaded.** It can mean "construct this feature" (a router) or "run the
-  Build step" (the `alis build` command). If a build target/context is already established and
-  the user means the DBD step, run `alis build`; if it is a functional request, route via
-  `SearchSkills`; when genuinely unclear, ask one concise question.
-
-Whenever a later request in the session would benefit from an Alis Build skill, use
-`SearchSkills` to discover one before doing the work yourself.
+- **"build it" without "alis" does not wake discovery.** A bare "build it" on an
+  already-established target means the DBD Build step → run `alis build`. To discover a build
+  skill instead, the developer addresses alis ("alis, build …") or runs the `build it`
+  command. When genuinely unclear, ask one concise question.
 
 ## Executing DBD — prefer the `alis` CLI
 
@@ -119,5 +114,5 @@ needs an explicit commit (never `HEAD`).
 ## Getting deeper
 
 For onboarding or the full step-by-step Simple API quickstart, load the `getting-started` skill
-via `LoadSkill`. For an ambiguous "build it" / "fix it" request, route through skill discovery
-(`SearchSkills`) before executing any DBD step.
+via `LoadSkill`. When the developer addresses alis ("alis, …"), wake the skill router
+(`SearchSkills`) before doing the work; otherwise respond directly.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@alis-build/opencode-plugin",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Connect opencode to Alis Build through MCP, workflow commands, and the Define-Build-Deploy primer.",
   "type": "module",
   "main": "src/index.ts",