opencode-onboard 0.3.3 → 0.4.1

package/content/.opencode/skills/openspec-apply-change/SKILL.md

@@ -19,14 +19,14 @@ Implement tasks from an OpenSpec change using the ensemble agent team.
    If a name is provided, use it. Otherwise:
    - Infer from conversation context if the user mentioned a change
    - Auto-select if only one active change exists
-   - If ambiguous, run `rtk openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
 
    Always announce: "Using change: <name>" and how to override (e.g., `/opsx-apply <other>`).
 
 2. **Check status to understand the schema**
 
    ```bash
-   rtk openspec status --change "<name>" --json
+   openspec status --change "<name>" --json
    ```
 
    Parse the JSON to understand:
@@ -36,7 +36,7 @@ Implement tasks from an OpenSpec change using the ensemble agent team.
 3. **Get apply instructions**
 
    ```bash
-   rtk openspec instructions apply --change "<name>" --json
+   openspec instructions apply --change "<name>" --json
    ```
 
    This returns:
@@ -64,7 +64,7 @@ Implement tasks from an OpenSpec change using the ensemble agent team.
 
 6. **Implement via ensemble team**
 
-   NEVER implement tasks directly. Always delegate to specialists via ensemble.
+   NEVER implement tasks directly. Always delegate to engineer workers via ensemble.
    Do NOT touch any source files before the team is running, not even a single edit.
 
    Steps MUST be followed in order. Do not skip any step.
@@ -92,20 +92,40 @@ Implement tasks from an OpenSpec change using the ensemble agent team.
       DO NOT call team_claim yourself, only agents claim tasks.
       DO NOT proceed to 6d until team_tasks_add succeeds.
 
-   **Step 6d.** Discover relevant skills, then spawn specialists.
-
-      Before spawning, scan `.agents/skills/` and read each `SKILL.md` description line.
-      Match skills to agents by domain:
-      - front-engineer: UI, components, framework skills (e.g. next-best-practices, browser-automation)
-      - back-engineer: API, data, service skills
-      - infra-engineer: cloud, pipeline, deployment skills
-      - quality-engineer: testing, coverage skills
+   **Step 6d.** Discover available agents, assign tasks by best fit, then spawn workers.
+
+      Agent discovery and assignment rule:
+      - Read `.agents/agents/*.md` and use each agent's `description` and `## Abilities` to understand specialization.
+      - For each task ID, choose the best-fit agent based on task domain (backend, frontend, infra, testing, etc.).
+      - Prefer specialized agents when available; use `basic-engineer` as fallback only.
+      - Only spawn agents that have assigned task IDs.
+
+      REQUIRED assignment algorithm (do not skip):
+      1. Build candidate list from `.agents/agents/*.md` excluding `devops-manager`.
+      2. Classify each task by domain using task text (api/backend, ui/frontend, infra/devops, testing/qa).
+      3. For each task, score every candidate agent:
+         - +3 if agent description explicitly matches domain
+         - +2 if agent `## Abilities` include domain-relevant skills
+         - +1 if prior tasks of same domain already assigned to that agent (cohesion)
+      4. Assign task to highest-score agent.
+      5. Use `basic-engineer` ONLY when no specialized agent has positive score.
+      6. If all tasks go to `basic-engineer`, you MUST explain why no specialist matched.
+
+      HARD RULES:
+      - NEVER assign a task to `basic-engineer` if a specialized agent has higher score.
+      - NEVER skip agent discovery from `.agents/agents/*.md`.
+      - ALWAYS include assignment rationale in spawn prompt: "Selected because <domain match>".
+
+      Skill loading is worker-driven:
+      - The spawned agent MUST load `@ob-global` first.
+      - Then it MUST load skills from its own `## Abilities` for the claimed task domain.
 
       Each team_spawn MUST include the agent field (required, causes NOT NULL error if omitted).
 
       The spawn prompt must contain exactly:
       1. Their name and role on this team
       2. Which tasks are theirs, list the task IDs and content from the board
+      2.1 Why they were selected for those tasks (domain/abilities match)
       3. Key context they need (summarized from context files, do NOT tell them to read files themselves)
       4. The 6 OpenCode tools they have available (these are OpenCode tools, NOT shell commands, call them directly as tools, never via bash):
          team_claim, team_tasks_complete, team_tasks_list, team_tasks_add, team_message, team_broadcast
@@ -115,21 +135,18 @@ Implement tasks from an OpenSpec change using the ensemble agent team.
       Keep spawn prompts under 600 tokens. Do not describe team internals or how ensemble works.
       Only spawn agents whose tasks are actually needed by this change. Skip agents with no tasks.
 
-      First spawn all agents (wait for each team_spawn to confirm before the next):
+      Spawn one or more best-fit workers (parallel when dependencies allow):
       ```
-      team_spawn name:"back" agent:"back-engineer" prompt:"..."
-      (wait for result)
-      team_spawn name:"front" agent:"front-engineer" prompt:"..."
-      (wait for result)
-      team_spawn name:"infra" agent:"infra-engineer" prompt:"..."
-      (wait for result)
+      team_spawn name:"eng-1" agent:"backend-engineer" prompt:"..."
+      team_spawn name:"eng-2" agent:"frontend-engineer" prompt:"..."
+      team_spawn name:"eng-3" agent:"basic-engineer" prompt:"..."
       ```
 
-      Then immediately send each spawned agent a start message to kick them off:
+      Then immediately send each spawned worker a start message with exact task IDs:
       ```
-      team_message to:"back" text:"Start now. Read all skills listed in your prompt first, confirm loaded skills, then claim your first task with team_claim."
-      team_message to:"front" text:"Start now. Read all skills listed in your prompt first, confirm loaded skills, then claim your first task with team_claim."
-      team_message to:"infra" text:"Start now. Read all skills listed in your prompt first, confirm loaded skills, then claim your first task with team_claim."
+      team_message to:"eng-1" text:"Start now. Load @ob-global first, then use your agent `## Abilities` for these tasks: [task-<id1>] ... Claim each task ID before starting."
+      team_message to:"eng-2" text:"Start now. Load @ob-global first, then use your agent `## Abilities` for these tasks: [task-<id2>] ... Claim each task ID before starting."
+      team_message to:"eng-3" text:"Start now. Load @ob-global first, then use your agent `## Abilities` for these tasks: [task-<id3>] ... Claim each task ID before starting."
       ```
 
    **Step 6e.** After sending start messages, tell the user what is running, then STOP and wait.
@@ -141,18 +158,18 @@ Implement tasks from an OpenSpec change using the ensemble agent team.
       If team_merge blocks ("overlapping local changes"), commit or stash your local changes first, then retry.
       Fix any other blockers reported.
 
-7. **Quality check**
+7. **Verification check**
 
-   Spawn quality engineer with worktree:false (read-only, no file edits):
-   ```
-   team_spawn name:"quality" agent:"quality-engineer" worktree:false prompt:"<verification scope, context summary, run tests + build + lint + verify acceptance criteria, no task claiming required in this phase, send results to lead when done>"
-   ```
-   Wait for message → team_results → fix blockers → team_shutdown (no team_merge needed, worktree:false)
+   Run verification tasks (tests/build/lint) using a worker suited for verification scope:
+   - either same engineer workers
+   - or a dedicated verifier worker if your project defines one
+
+   Wait for results → fix blockers.
 
 8. **Mark tasks complete in openspec**
 
    Update tasks.md: `- [ ]` → `- [x]` for each completed task.
-   Run `rtk openspec status --change "<name>" --json` to confirm.
+   Run `openspec status --change "<name>" --json` to confirm.
 
 9. **Show status, then cleanup**
 
@@ -175,10 +192,10 @@ Implement tasks from an OpenSpec change using the ensemble agent team.
 - ALWAYS pass the task IDs returned by team_tasks_add to each agent's spawn prompt
 - NEVER edit files between team_spawn and team_merge, team_merge blocks on overlapping local changes
 - ALWAYS add every task to the board with team_tasks_add before spawning
-- ALWAYS spawn agents sequentially (wait for each team_spawn result before the next), then send start messages to all of them together
+- ALWAYS spawn workers based on dependencies: parallel when safe, sequential when required
 - ALWAYS instruct agents to call team_claim before each task and team_tasks_complete after
 - If teammates are stuck, use team_message to resend tasks, then wait, never implement directly
-- Mark tasks complete in openspec AFTER specialists finish, not before
+- Mark tasks complete in openspec AFTER worker implementation and verification finish, not before
 - Pause on errors, blockers, or unclear requirements. Do not guess
 - Use contextFiles from CLI output, do not assume specific file paths
-- Use `rtk` wrapper for ALL CLI commands. Never run openspec, git, gh, or az directly
+- Follow CLI rules from `@ob-global` when present

package/content/AGENTS.md

@@ -97,7 +97,7 @@ After restarting you are ready to work.
 - Do NOT implement any features
 - Do NOT create branches or PRs
 - Do NOT modify any project source files
-- Do NOT create RTK files, scripts, or wrappers, RTK is already defined in AGENTS.md and agent files
+- Do NOT create CLI wrapper files or scripts
 - Only read source files for analysis, write only to ARCHITECTURE.md, DESIGN.md, AGENTS.md, and openspec/
 
 <!-- AGENTS-TEMPLATE-START -->
@@ -112,17 +112,20 @@ This file provides guidance to AI agents when working in this repository.
 This is the agent orchestration layer for your project. It provides:
 - Universal agent team for development workflow
 - OpenSpec change management
-- Skills for platform-specific knowledge
+- Mandatory global baseline skill (`ob-global`) for all agents
+- Additional skills for platform/task-specific knowledge
 
 ## Source Scope
 
-- Read source scope from `.agents/source-roots.json`.
-- Use those roots for codebase analysis tasks (design, architecture, project-history, exploration).
-- If missing, default to current folder.
+Source scope is defined by mandatory `ob-global` skill.
+
+- Load `ob-global` first.
+- Follow the generated `## Source Roots` section from that skill.
+- Do not duplicate source-scope rules here.
 
 ## I Am the Lead, Full Workflow Ownership
 
-When the user provides a work item URL or says "implement the plan" or "I've added comments to the PR", **I own the full lifecycle**. I load the appropriate skill and use ensemble tools to coordinate the agent team.
+When the user provides a work item URL or says "implement the plan" or "I've added comments to the PR", **I own the full lifecycle**. I load `ob-global` skill first, then the appropriate userstory skill, and use ensemble tools to coordinate the agent team.
 
 Trigger patterns, I recognize ALL of these, exact wording does not matter:
 - User pastes or mentions a GitHub Issue URL → load `ob-userstory-gh` skill → parse issue → run `/opsx-propose` → confirm with user → run `/opsx-apply` → ship
@@ -135,26 +138,15 @@ Trigger patterns, I recognize ALL of these, exact wording does not matter:
 
 **Never delegate without a plan. Never write implementation code directly, always spawn specialists, no exceptions. "Small feature", "faster to do it directly", or "environment issues" are not valid reasons to skip ensemble.**
 
-## Multi-Agent Execution, opencode-ensemble
-
-Parallel execution uses the `opencode-ensemble` plugin (`team_create`, `team_spawn`, etc.).
-Works on **all platforms** (Windows, macOS, Linux) via OpenCode's built-in worktree support.
-
-| Tool | What it does |
-|------|-------------|
-| `team_create` | Create a team (caller becomes lead) |
-| `team_spawn` | Start a teammate asynchronously |
-| `team_shutdown` | Stop a teammate, preserve their branch |
-| `team_merge` | Merge a teammate's branch into working dir |
-| `team_cleanup` | Tear down the team |
-| `team_results` | Retrieve full message content (delivery is a ping only) |
-| `team_message` | Send a direct message to a teammate or lead |
-| `team_broadcast` | Message all teammates |
-| `team_status` | View all members and task summary |
-| `team_tasks_list` | View the shared task board |
-| `team_tasks_add` | Add tasks to shared board |
-| `team_tasks_complete` | Mark task done, auto-unblocks dependents |
-| `team_claim` | Atomically claim a pending task (teammates use this) |
+## Multi-Agent Execution, opencode-ensemble
+
+Parallel execution uses the `opencode-ensemble` plugin (`team_create`, `team_spawn`, etc.).
+Works on **all platforms** (Windows, macOS, Linux) via OpenCode's built-in worktree support.
+
+Core tools used in this workflow:
+- `team_create`, `team_spawn`, `team_shutdown`, `team_merge`, `team_cleanup`
+- `team_tasks_add`, `team_tasks_list`, `team_claim`, `team_tasks_complete`
+- `team_message`, `team_results`, `team_status`
 
 **Dashboard**: Monitor running agents at **http://localhost:4747/**
 
@@ -171,30 +163,25 @@ If a teammate stalls due to model quota/rate-limit exhaustion:
 
 ---
 
-## Pipeline
+## Pipeline
 
 ```
-devops-manager (read mode)
-  → parse work item via skill → structured summary
+devops-manager (lead mode)
+  → load ob-global + parse work item via skill
         ↓
   openspec-propose
   → proposal.md + specs + tasks
         ↓
   [confirm with user]
         ↓
-back-engineer → front-engineer → infra-engineer  ← sequential, one at a time, only spawn what the task needs
-        ↓
-quality-engineer (worktree:false)
-  → tests, build, lint, acceptance criteria
-        ↓
-security-auditor (worktree:false)
-  → vulnerability audit, secrets, auth gaps
+basic-engineer + custom-engineer-* (parallel as needed)
+  → claim tasks + load abilities + implement
         ↓
 devops-manager (ship mode)
-  → screenshots → commit → push → PR → post comment
+  → verify completion → commit → push → PR → post comment
 ```
 
-### Phase 1, Parse & Propose
+### Phase 1, Parse & Propose
 
 ```
 1. Detect URL type → load matching skill (ob-userstory-gh or ob-userstory-az)
@@ -204,60 +191,44 @@ devops-manager (ship mode)
 5. STOP. Ask user: "Ready to implement? (yes/no)", DO NOT proceed until confirmed.
 ```
 
-### Phase 2, Implement
-
-```
-1. Run /opsx-apply, handles context reading, ensemble orchestration, and task marking.
-   - Lead adds all tasks to board, then spawns specialists ONE AT A TIME (not parallel)
-   - Each specialist claims tasks, implements, completes tasks, messages lead when done
-   - Lead merges each branch after shutdown, then marks tasks done in tasks.md
-2. After /opsx-apply completes, proceed to quality check.
-```
-
-### Phase 3, Quality
-
-```
-3. team_spawn name:quality agent:quality-engineer worktree:false → tests, build, lint
-4. Wait → team_results → fix any blockers → team_shutdown (no merge, worktree:false)
-```
+### Phase 2, Implement
+
+```
+1. Run /opsx-apply.
+   - Lead adds all tasks to board.
+   - Lead spawns one or more engineers (`basic-engineer` and/or custom engineers) in parallel where safe.
+   - Each engineer must claim task IDs, load relevant abilities, implement, and complete tasks.
+   - Lead merges each engineer branch after shutdown, then marks tasks done in tasks.md.
+2. Verify with tests/build/lint according to task scope.
+```
 
-### Phase 4, Security
+### Phase 3, Ship
 
 ```
-5. team_spawn name:security agent:security-auditor worktree:false → audit full change
-6. Wait → team_results → fix Critical findings → team_shutdown (no merge, worktree:false)
+3. team_spawn name:devops agent:devops-manager (ship mode)
+   → commit & push → create PR → post comment
+4. Wait → team_results → report PR URL to user
+5. team_cleanup
 ```
 
-### Phase 5, Ship
-
-```
-11. team_spawn name:devops agent:devops-manager (ship mode)
-    → screenshots → commit & push → create PR → post comment
-12. Wait → team_results → report PR URL to user
-13. team_cleanup
-```
-
-### Phase 6, PR Feedback Loop
+### Phase 4, PR Feedback Loop
 
 ```
 When user says "I've added comments to the PR" or asks to fix PR comments from PR URLs:
 1. team_create "pr-feedback-<id>-<random>"
 2. team_tasks_add with at least these lead-managed tasks:
    - Parse and classify PR feedback (devops-manager)
-   - Implement Api feedback items (back-engineer, if needed)
-   - Implement App feedback items (front-engineer, if needed)
-   - Infra feedback items (infra-engineer, if needed)
-   - Verify with tests/build (quality-engineer)
+   - Implement feedback items (basic-engineer and/or custom engineers)
+   - Verify with tests/build/lint (implementation worker or dedicated verifier if available)
    - Push updates and post PR replies (devops-manager)
 3. team_spawn devops-manager (feedback mode) with explicit task IDs, then team_message "Start now"
 4. Wait for message → team_results
-5. Add/update implementation tasks on board from parsed checklist (Api/App/Infra), then spawn needed specialists in parallel with explicit task IDs + team_message "Start now"
-6. Wait for specialist results → team_shutdown + team_merge per specialist
-7. team_spawn quality-engineer worktree:false with verification task ID + team_message "Start now"
-8. Wait → team_results → fix blockers if any
-9. team_spawn devops-manager (ship mode) with "push + update PR threads" task ID + team_message "Start now"
-10. Wait → team_results → report what was updated
-11. team_cleanup
+5. Add/update implementation tasks on board, then spawn needed engineers in parallel with explicit task IDs + team_message "Start now"
+6. Wait for engineer results → team_shutdown + team_merge per engineer
+7. Run verification tasks (tests/build/lint) and fix blockers if any
+8. team_spawn devops-manager (ship mode) with "push + update PR threads" task ID + team_message "Start now"
+9. Wait → team_results → report what was updated
+10. team_cleanup
 ```
 
 ---
@@ -269,28 +240,43 @@ All agents are universal, no project-specific knowledge. Platform and tech knowl
 | Agent | File | Role |
 |-------|------|------|
 | `devops-manager` | .agents/agents/devops-manager.md | Reads work items, creates PRs, handles review feedback |
-| `front-engineer` | .agents/agents/front-engineer.md | Web, mobile, UI implementation |
-| `back-engineer` | .agents/agents/back-engineer.md | APIs, services, data, AI implementation |
-| `infra-engineer` | .agents/agents/infra-engineer.md | Terraform, pipelines, cloud infrastructure |
-| `quality-engineer` | .agents/agents/quality-engineer.md | Unit, integration, e2e tests across all layers |
-| `security-auditor` | .agents/agents/security-auditor.md | Vulnerability audit, secrets, auth gaps |
+| `basic-engineer` | .agents/agents/basic-engineer.md | Generic implementation worker using ability-loaded skills |
+
+User can add more custom engineer agents and run them in parallel. Keep behavior ability-driven via skill mappings.
+
+Default `basic-engineer` abilities:
+
+```
+## Abilities
+- Guardrails: @ob-generic-guardrails, @ob-default
+- Development: @ob-default
+- Testing: @ob-default
+- Infrastructure: @ob-default
+```
 
-## Skills
+## Skills
 
-Skills provide platform and tech-specific knowledge. Agents detect and load them automatically, the user never specifies which skill to use.
+Skills provide platform and tech-specific knowledge. Agents detect and load them automatically, **you never tell an agent which skill to use**.
+
+`ob-global` is always loaded first, it provides baseline rules for all agents.
 
 Skills are located in `.agents/skills/`. Each skill has a `SKILL.md` with a description the agent reads to determine relevance.
 
 | Skill | Purpose |
 |-------|---------|
+| `ob-global` | Generic skill, baseline rules loaded by all agents. Context, source roots, git/secrets guardrails, token opt rules |
+| `ob-default` | Fallback skill, when no other skill matches |
+| `ob-generic-guardrails` | Minimal foundation for user guardrails skills |
 | `ob-userstory-az` | Parse Azure DevOps work item URL |
 | `ob-userstory-gh` | Parse GitHub Issue URL |
 | `ob-pullrequest-az` | Create PR on Azure DevOps |
 | `ob-pullrequest-gh` | Create PR on GitHub |
 | `openspec-propose` | Propose change artifacts (proposal, specs, tasks) |
 | `openspec-apply-change` | Implement change with agent team |
-| `openspec-archive-change` | Archive completed change |
-| `browser-automation` | Browser automation for localhost UI, screenshots, clicks, queries |
+| `openspec-archive-change` | Archive completed change |
+| `browser-automation` | Browser automation for localhost UI, screenshots, clicks, queries |
+
+Execution rules live in skills. Keep AGENTS.md focused on orchestration and routing.
 
 ---
 
@@ -299,7 +285,7 @@ Skills are located in `.agents/skills/`. Each skill has a `SKILL.md` with a desc
 Format: `feature/{issue-id}-{slug}`
 Example: `feature/42-add-user-auth`
 
-When `## Source Roots` lists multiple roots, each root is an independent git repository. The same branch name must be created in every repo that will have changes. Git operations (`branch`, `commit`, `push`) run once per repository — there is no shared git history.
+When `## Source Roots` lists multiple roots, each root is an independent git repository. The same branch name must be created in every repo that will have changes. Git operations (`branch`, `commit`, `push`) run once per repository, there is no shared git history.
 
 ---
 
@@ -309,7 +295,16 @@ When `## Source Roots` lists multiple roots, each root is an independent git rep
 [project-root]/
 ├── .agents/
 │   ├── agents/        # Agent definitions (universal, no project knowledge)
-│   └── skills/        # Skills (platform/tech specific knowledge)
+│   │   ├── devops-manager.md
+│   │   ├── basic-engineer.md
+│   │   └── custom-engineer-*.md   # optional, user-defined workers
+│   └── skills/      # Skills (platform/tech specific knowledge)
+│       ├── ob-global/              ← baseline skill, load first
+│       ├── ob-default/            ← fallback skill
+│       ├── ob-generic-guardrails/ ← foundation for user guardrails
+│       ├── ob-userstory-gh/
+│       ├── ob-userstory-az/
+│       └── browser-automation/
 ├── openspec/
 │   ├── specs/
 │   └── changes/
@@ -322,61 +317,16 @@ When `## Source Roots` lists multiple roots, each root is an independent git rep
 
 ---
 
-## RTK
-
-Use `rtk` wrapper for ALL CLI commands. Never run git, az, gh, or openspec commands directly.
-
-- `rtk git add` NOT `git add`
-- `rtk git commit` NOT `git commit`
-- `rtk git push` NOT `git push`
-- `rtk az boards work-item show` NOT `az boards work-item show`
-- `rtk az repos pr create` NOT `az repos pr create`
-- `rtk gh issue view` NOT `gh issue view`
-- `rtk gh pr create` NOT `gh pr create`
-- `rtk openspec new change` NOT `openspec new change`
-
----
-
-## Guardrails
-
-### Git Operations
-
-Agents CAN:
-- ✅ Commit to feature branches
-- ✅ Push to feature branches
-
-Agents CANNOT:
-- ❌ Commit or push to `main`, FORBIDDEN
-- ❌ Force push, FORBIDDEN
-- ❌ Merge PRs, human-only
-- ❌ Create or delete branches other than `feature/*`
-
-**Multi-repo**: When `## Source Roots` lists multiple roots, each is an independent git repository with its own history. All `rtk git` commands must be issued per repository. Never assume one `git` context covers all repos. Create the feature branch in each repo, commit per repo, push per repo, open one PR per repo.
-
-### Platform CLI
-
-ALL platform interactions via CLI only. Browser MCP and webfetch FORBIDDEN for any DevOps or GitHub operation, use `gh` or `az` CLI exclusively, never fall back to HTTP requests.
-
-| Operation | Azure DevOps | GitHub |
-|-----------|-------------|--------|
-| Read issue | `az boards work-item show --id <id>` | `gh issue view <number>` |
-| Read PR threads | `az devops invoke ...` | `gh pr view <number> --comments` |
-| Create PR | `az repos pr create ...` | `gh pr create ...` |
-
-Browser MCP tools permitted only for screenshots of **local running app** on `localhost` URLs.
-
-### Security
-
-Agents CANNOT:
-- ❌ Access `.env` or config files with secrets
-- ❌ Log or output credentials, API keys, or tokens
-- ❌ Commit secrets to git
-
-### Scope
-
-- Max 10 files per change
-- No architecture changes without human approval
-- No pipeline modifications without human approval
+## Guardrails
+
+Guardrails are mandatory via `ob-global` and ability-loaded skills.
+
+Minimal non-negotiables:
+- Never commit or push to `main`.
+- Never force push.
+- Never expose or commit secrets.
+- Use `gh`/`az` CLI for platform operations.
+- In multi-repo source scope, run git operations per repository.
 
 ---
 

package/content/skills-lock.json

@@ -0,0 +1,4 @@
+{
+  "version": 1,
+  "skills": {}
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-onboard",
-  "version": "0.3.3",
+  "version": "0.4.1",
   "description": "Prepare any brownfield codebase for AI agent workflows using OpenCode, OpenSpec, and ensemble orchestration.",
   "keywords": [
     "opencode",
@@ -33,12 +33,17 @@
     "ora": "^8.0.0"
   },
   "devDependencies": {
+    "@eslint/js": "^9.0.0",
+    "eslint": "^9.0.0",
+    "globals": "^15.0.0",
     "vitest": "^4.1.5"
   },
   "vitest": {
     "environment": "node"
   },
   "scripts": {
+    "lint": "eslint .",
+    "lint:fix": "eslint . --fix",
     "test": "vitest run",
     "test:watch": "vitest"
   }