opencode-onboard 0.4.4 → 0.4.7

package/README.md

@@ -6,7 +6,7 @@
 
 **One command to prepare any codebase for AI agent workflows in OpenCode.**
 
-Works with [OpenCode](https://opencode.ai), [OpenCode Ensemble](https://github.com/hueyexe/opencode-ensemble), [OpenSpec](https://github.com/fission-ai/openspec), GitHub and Azure DevOps.
+Works with [OpenCode](https://opencode.ai), [OpenCode Ensemble](https://github.com/hueyexe/opencode-ensemble), [OpenSpec](https://github.com/fission-ai/openspec), GitHub, Azure DevOps, or no tracker/PR platform at all.
 
 [![npm version](https://img.shields.io/npm/v/opencode-onboard?style=flat-square&color=black)](https://www.npmjs.com/package/opencode-onboard)
 [![npm downloads](https://img.shields.io/npm/dm/opencode-onboard?style=flat-square&color=black)](https://www.npmjs.com/package/opencode-onboard)
@@ -74,8 +74,8 @@ The CLI runs a 10-step onboarding wizard. It keeps the current step visible, plu
 | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **1. Source scope**               | Choose current repo or sibling source roots for code analysis                                                                                                        |
 | **2. Clean AI files**             | Detects existing `AGENTS.md`, `.cursorrules`, `CLAUDE.md`, `.agents/` etc. and removes them, preserves your `.agents/skills/`                                        |
-| **3. Choose platform**            | GitHub or Azure DevOps                                                                                                                                               |
-| **4. Check platform CLI**         | Verifies `gh` (GitHub) or `az` + `azure-devops` (Azure DevOps)                                                                                                       |
+| **3. Choose platform**            | GitHub, Azure DevOps, or None                                                                                                                                       |
+| **4. Check platform CLI**         | Verifies `gh` (GitHub) or `az` + `azure-devops` (Azure DevOps), or skips checks when platform is None                                                              |
 | **5. Copy scaffolding**           | Copies agents + built-in skills + bootstrap docs, writes source-roots metadata, applies AGENTS bootstrap patching, copies `skills-lock.json`, then runs `npx skills` |
 | **6. Init OpenSpec**              | Runs `npx @fission-ai/openspec init` silently for structured change management                                                                                       |
 | **7. Choose models**              | Fetches live model list from [models.dev](https://models.dev), lets you pick plan / build / fast models with cost indicators and canonical pricing                   |
@@ -86,10 +86,10 @@ The CLI runs a 10-step onboarding wizard. It keeps the current step visible, plu
 When it finishes, open OpenCode in your project and type:
 
 ```
-init
+/ob-init
 ```
 
-OpenCode generates `ARCHITECTURE.md` and `DESIGN.md` from your actual codebase, then activates the full agent team.
+OpenCode asks if this is a greenfield or brownfield project. For brownfield projects it generates `ARCHITECTURE.md` and `DESIGN.md` from your actual codebase, archives project history, then activates the full agent team. For greenfield projects it skips doc generation and leaves placeholder files you can populate later with `/ob-create-architecture` and `/ob-create-design`.
 
 ---
 
@@ -99,10 +99,12 @@ Custom slash commands are installed into `.opencode/commands/` and are available
 
 | Command        | Description                                                                                           |
 | -------------- | ----------------------------------------------------------------------------------------------------- |
-| `/init`        | Initialize the project: generate `ARCHITECTURE.md`, `DESIGN.md`, archive history, activate agent team |
-| `/plan <url>`  | Parse a user story URL and produce a plan, proposal, specs, and tasks. Stops before implementation.   |
-| `/main <task>` | Quick direct implementation, no OpenSpec, no ensemble, no PRs. Just do it.                            |
-| `/create-engineer <name> "<description>"` | Create a custom engineer agent from a description, with skills auto-installed from [skills.sh](https://www.skills.sh/) |
+| `/ob-init`        | Initialize the project. Asks greenfield vs brownfield, then activates the agent team. Supports skipping doc generation for new projects. |
+| `/ob-plan <url>`  | Parse a user story URL and produce a plan, proposal, specs, and tasks. Stops before implementation. Use platform mode, not `None`.   |
+| `/ob-main <task>` | Quick direct implementation, no OpenSpec, no ensemble, no PRs. Just do it.                            |
+| `/ob-create-engineer <name> "<description>"` | Create a custom engineer agent from a description, with skills auto-installed from [skills.sh](https://www.skills.sh/) |
+| `/ob-create-architecture` | Generate or regenerate `ARCHITECTURE.md` from the codebase. Safe to rerun any time the architecture changes. |
+| `/ob-create-design` | Generate or regenerate `DESIGN.md` from the codebase design system. Safe to rerun any time the design system changes. |
 
 ---
 
@@ -121,11 +123,14 @@ devops-manager     lead/orchestrator, planning, PR lifecycle
 basic-engineer     implementation worker, ability-driven
 ```
 
-`basic-engineer` behavior is composed by abilities, not hardcoded role silos.
+`basic-engineer` behavior is composed by abilities, not hardcoded role silos.
+Project-specific specialization comes from user-created custom engineers via `/ob-create-engineer`. During `/opsx-apply`, the lead should inspect the engineers that actually exist in `.agents/agents/`, prefer matching custom engineers, and fall back to `basic-engineer` only when no specialist is a clear fit.
 
-### Skills, platform knowledge
-
-Skills define _what to know_. They provide project rules, platform behavior, and task-specific execution guidance. Agents auto-detect/load relevant skills; **you do not manually choose skills per prompt**.
+### Skills, platform knowledge
+
+Skills define _what to know_. They provide project rules, platform behavior, and task-specific execution guidance. Agents auto-detect/load relevant skills; **you do not manually choose skills per prompt**.
+
+If you choose platform `None` during onboarding, no userstory or pull-request platform skills are injected into the workflow. The project works from direct conversation, local repo context, and optional OpenSpec artifacts only.
 
 Current loading model:
 
@@ -174,7 +179,7 @@ Models are fetched live from [models.dev](https://models.dev) (3000+ models, cac
 
 ## The pipeline
 
-When you give the lead agent a work item URL, execution follows this pipeline:
+When you give the lead agent a work item URL, execution follows this pipeline. If onboarding platform is `None`, skip the work item / PR stages and work directly from conversation plus optional OpenSpec artifacts:
 
 ```
 devops-manager (load ob-global first)
@@ -239,15 +244,49 @@ your-project/
 
 ## The bootstrap sequence
 
-The first time you type `init` in OpenCode after onboarding:
+The first time you type `init` in OpenCode after onboarding, the agent asks whether this is a **greenfield** or **brownfield** project:
+
+### Brownfield (existing codebase)
 
 1. Bootstrap-mode `AGENTS.md` triggers the initialization workflow
 2. OpenCode archives existing project context into OpenSpec (`project-history`)
-3. OpenCode generates real `DESIGN.md` and `ARCHITECTURE.md` from your codebase
-4. Bootstrap `AGENTS.md` is replaced with production guidance
-5. Team workflows become fully active for normal implementation tasks
+3. OpenCode runs `/ob-create-architecture` → generates real `ARCHITECTURE.md` from your codebase
+4. OpenCode runs `/ob-create-design` → generates real `DESIGN.md` from your design system
+5. OpenSpec `config.yaml` is populated with discovered tech stack and domain context
+6. Bootstrap `AGENTS.md` is replaced with production guidance
+7. Team workflows become fully active for normal implementation tasks
+
+### Greenfield (new project, little or no existing code)
+
+1. Bootstrap-mode `AGENTS.md` triggers the initialization workflow
+2. OpenSpec `config.yaml` is populated with what is known (intended stack, domain)
+3. Bootstrap `AGENTS.md` is replaced with production guidance
+4. `ARCHITECTURE.md` and `DESIGN.md` are left as placeholder files
+
+Once your codebase has meaningful content, run:
+- `/ob-create-architecture` to generate architecture docs
+- `/ob-create-design` to generate design system docs
+
+Both commands are safe to rerun at any time as the project evolves.
+
+---
+
+## Token Budget Controls
+
+Long unattended agent sessions can consume significant tokens. Set these controls up **before** first use:
+
+1. **Set provider-side limits first** — monthly soft-limit + hard usage cap in your provider dashboard:
+   - OpenAI: [platform.openai.com/account/limits](https://platform.openai.com/account/limits)
+   - Anthropic: [console.anthropic.com](https://console.anthropic.com)
+   - Google AI Studio: [aistudio.google.com/app/usage](https://aistudio.google.com/app/usage)
+
+2. **Route models by task type** — use a fast/cheap model (e.g. `haiku`, `gpt-4o-mini`) for orchestration and status loops; reserve expensive models (e.g. `sonnet`, `opus`, `gpt-4o`) for implementation tasks only.
+
+3. **Install the quota plugin** — the [`opencode-quota`](https://github.com/opencode-ai/opencode-quota) plugin adds `/quota` and `/quota_status` commands that surface real-time token usage inside OpenCode sessions.
+
+4. **Use `/quota` checkpoints** — run `/quota` before starting any `/opsx-apply` session and after each agent wave. Pause at 75% consumed; stop at 90%.
 
-After this, every agent has accurate, persistent context about your project, no manual documentation required.
+5. **Confirm before large runs** — the onboarded `/opsx-apply` workflow will ask for your confirmation before spawning agents for Medium (4–7 tasks) or High (8+ tasks) scope sessions.
 
 ---
 

package/content/.agents/agents/basic-engineer.md

@@ -20,13 +20,13 @@ permission:
 ## Workflow
 
 When spawned by the lead:
-1. Call `team_tasks_list` and verify your assigned task IDs and status before starting.
-2. For each assigned task: before calling `team_claim task_id:<id>`, check `team_tasks_list` to confirm every dependency of that task has status `done`. If any dependency is not done, skip to the next assigned task that IS unblocked. Only claim tasks whose dependencies are fully complete.
-3. Load `@ob-global` first, then load mandatory ability `Guardrails`.
+1. Call `team_tasks_list` immediately and identify your assigned task IDs.
+2. Claim the first assigned task that is unblocked with `team_claim task_id:<id>`. If the first assigned task is blocked, claim the next assigned task whose dependencies are already `done`. Do not wait once you have an unblocked assigned task.
+3. After claiming, load `@ob-global` first, then load mandatory ability `Guardrails`.
 4. Load additional abilities from the `## Abilities` section as needed for the claimed task domain (for example: development, testing, infrastructure). Each ability can include one or more skills; load all relevant skills listed under each selected ability.
-5. Send a short `team_message` to lead confirming claimed task ID and loaded skills.
+5. Send a short `team_message` to lead confirming the claimed task ID and loaded skills.
 6. Implement the task following all loaded skill rules.
 7. Call `team_tasks_complete task_id:<id>` after finishing that task.
 8. Repeat until all currently assigned tasks are completed or blocked.
 9. Message lead with results via `team_message`. Lead may assign more tasks, do NOT stop working or shut down until lead confirms no more tasks for you.
-10. If lead sends new task IDs via `team_message`, treat them as new assignments and go back to step 2.
+10. If lead sends new task IDs via `team_message`, treat them as new assignments and go back to step 1.

package/content/.agents/agents/devops-manager.md

@@ -25,10 +25,10 @@ Skills are located in `.agents/skills/`. Load required skills explicitly from co
 
 Always load `@ob-global` FIRST before any other skill.
 
-Platform skill selection must follow onboarding platform choice from CLI step:
-<!-- OB-PLATFORM-SKILLS-START -->
-- Platform-specific skill instructions are injected during onboarding copy step.
-<!-- OB-PLATFORM-SKILLS-END -->
+Platform skill selection must follow onboarding platform choice from CLI step:
+<!-- OB-PLATFORM-SKILLS-START -->
+- Platform-specific skill instructions are injected during onboarding copy step.
+<!-- OB-PLATFORM-SKILLS-END -->
 
 1. If the spawn prompt lists specific skills to load, read those `SKILL.md` files FIRST before any implementation
 2. Additionally, identify the platform from URLs or context
@@ -39,12 +39,16 @@ Examples of intent → skill mapping:
 - "PR has comments" or "review feedback" → load platform pullrequest observer skill
 - URL-based platform inference is fallback-only when onboarding metadata is unavailable
 
-Rules:
-- Platform selected in onboarding metadata takes precedence over URL inference when both exist
-- Never interact with a platform without loading the matching skill first
-- Follow skill instructions exactly, do not partially apply them
-- If no skill exists for the platform, report it as a blocker rather than improvising
-- Skills listed in the spawn prompt are MANDATORY, not optional
+Rules:
+- Platform selected in onboarding metadata takes precedence over URL inference when both exist
+- Never interact with a platform without loading the matching skill first
+- Follow skill instructions exactly, do not partially apply them
+- If no skill exists for the platform, report it as a blocker rather than improvising
+- Skills listed in the spawn prompt are MANDATORY, not optional
+
+<!-- OB-PLATFORM-MODE-START -->
+This project uses platform-integrated workflow modes described below.
+<!-- OB-PLATFORM-MODE-END -->
 
 ## Working Modes
 

package/content/.agents/skills/ob-global/SKILL.md

@@ -46,19 +46,21 @@ If multiple roots are generated, each root is an independent git repository. Bra
 
 When working as a spawned agent in an ensemble team, these rules are mandatory:
 
-**Claim-first execution:**
-- Your FIRST tool call after loading skills MUST be `team_claim task_id:<id>`. The dashboard must show your active task immediately.
-- Do NOT spend more than 2 tool calls reading/planning before writing code. Claim first, then explore only what's needed for that specific task.
+**Board-first claim flow:**
+- If you are working from assigned task IDs, your first task-board call may be `team_tasks_list` to confirm the task exists and its dependencies are done.
+- Your next task-board call for the first unblocked assigned task MUST be `team_claim task_id:<id>`. The dashboard should show your active task immediately after that.
+- Do NOT spend more than 2 total tool calls reading/planning before claiming an unblocked assigned task.
 
 **One task at a time:**
 - Claim → implement → build/verify → commit → `team_tasks_complete` → claim next.
 - NEVER hold multiple claimed tasks simultaneously.
 - NEVER batch completions. Mark done immediately after each commit.
 
-**Dependency check before claiming:**
-- Before calling `team_claim task_id:<id>`, call `team_tasks_list` and verify every dependency of that task has status `done`.
-- If any dependency is not `done`, do NOT claim that task. Scan the board for another assigned task whose dependencies ARE all done and claim that one instead.
-- If no assigned task is unblocked, report blocked to lead and STOP. Do NOT poll, sleep, or loop waiting for a dependency.
+**Dependency check before claiming:**
+- Before calling `team_claim task_id:<id>`, call `team_tasks_list` and verify every dependency of that task has status `done`.
+- If any dependency is not `done`, do NOT claim that task. Scan the board for another assigned task whose dependencies ARE all done and claim that one instead.
+- If no assigned task is unblocked, report blocked to lead and STOP. Do NOT poll, sleep, or loop waiting for a dependency.
+- If the lead provided `claim_task` or exact task IDs and the board does not match that assignment, report the mismatch to lead immediately instead of waiting idle.
 
 **Commit cadence:**
 - After each task passes build: `git add -A && git commit -m "feat: <short description>"`

package/content/.opencode/commands/ob-create-architecture.md

@@ -0,0 +1,76 @@
+---
+description: Generate or regenerate ARCHITECTURE.md by analyzing the codebase structure. Safe to run at any time.
+---
+
+Analyze the architecture of this codebase and generate a populated `ARCHITECTURE.md` in the project root.
+
+Reference material:
+  Website : https://architecture.md/
+  Repo    : https://github.com/timajwilliams/architecture
+
+**Steps**
+
+1. **Check current state**
+
+   Read `ARCHITECTURE.md`. If it already contains real content (not the placeholder), warn the user:
+   > "ARCHITECTURE.md already has content. Running this will overwrite it. Proceeding..."
+
+   Then continue regardless — this command is always safe to rerun.
+
+2. **Check for source roots**
+
+   Load `.agents/source-roots.json` when present. Only analyze those roots plus this repo's docs/config files.
+
+3. **Analyze the codebase**
+
+   Read:
+   - Folder structure, root-level config files
+   - Route/controller definitions
+   - Data models, schemas, migrations
+   - Integration points, external API calls
+   - Build config, CI/CD workflows, Dockerfiles
+   - README, changelogs, ADRs, any existing docs
+
+   Do not rely on prior knowledge — read the actual files.
+
+4. **Write ARCHITECTURE.md**
+
+   Overwrite `ARCHITECTURE.md` with a complete document following this structure:
+
+   - **Architecture Overview** — what the system is, what problem it solves, major architectural style
+   - **1. Project Structure** — annotated directory tree with purpose of each major directory
+   - **2. High-Level System Diagram** — Mermaid diagram of actors, services, data stores, external systems
+   - **3. Core Components** — each major component: name, responsibility, key files, technologies, inputs/outputs
+     - 3.1 Frontend / User Interface (if present)
+     - 3.2 Backend / Server / API (if present)
+     - 3.3 Shared Libraries / Common Code (if present)
+     - 3.4 CLI / Scripts / Automation (if present)
+   - **4. Data Flow** — request lifecycle, key user journeys, sequence diagram for main runtime flow
+   - **5. Data Stores** — all persistent storage: type, purpose, schemas, migration approach
+   - **6. External Integrations / APIs** — each integration: method, config location, auth, failure behavior
+   - **7. Key Technologies** — full stack summary with architectural relevance of each
+   - **8. Deployment & Infrastructure** — build artifacts, env config, containerization, CI/CD, hosting
+   - **9. Security Architecture** — auth, authz, secrets, input validation, trust boundaries
+   - **10. Monitoring & Observability** — logging, metrics, tracing, error reporting
+   - **11. Performance & Scalability** — caching, batching, concurrency, known bottlenecks
+   - **12. Development Workflow** — local setup, install/dev/test/build/lint commands
+   - **13. Testing Strategy** — test frameworks, locations, coverage gates, gaps
+   - **14. Architectural Decisions & Rationale** — key choices with evidence and tradeoffs
+   - **15. Constraints, Risks, and Technical Debt** — tight coupling, TODOs, operational risks
+   - **16. Future Considerations** — documented roadmap + reasonable recommendations (labeled as such)
+   - **17. Project Identification** — name, language, type, runtime, date of review, maintainer
+   - **18. Glossary / Acronyms** — project-specific terms an agent or new developer needs to know
+
+   Rules:
+   - Be specific and concrete — include actual directories, files, modules, commands
+   - Do NOT invent systems, services, or integrations not supported by repository evidence
+   - Mark anything undiscoverable as "Not evident from the repository"
+   - Use Mermaid diagrams where helpful
+   - Write as if this document will be committed and maintained over time
+
+5. **Report**
+
+   Tell the user:
+   - `ARCHITECTURE.md` generated successfully
+   - Top-level components found
+   - Tip: "Rerun `/ob-create-architecture` any time the architecture changes significantly."

package/content/.opencode/commands/ob-create-design.md

@@ -0,0 +1,53 @@
+---
+description: Generate or regenerate DESIGN.md by analyzing the codebase design system. Safe to run at any time.
+---
+
+Analyze the design system of this codebase and generate a populated `DESIGN.md` in the project root.
+
+Reference material:
+  Overview : https://stitch.withgoogle.com/docs/design-md/overview/
+  Format   : https://stitch.withgoogle.com/docs/design-md/format/
+  Spec     : https://github.com/google-labs-code/design.md
+
+Examples from the spec repo:
+  https://github.com/google-labs-code/design.md/blob/main/examples/atmospheric-glass/DESIGN.md
+  https://github.com/google-labs-code/design.md/blob/main/examples/paws-and-paths/DESIGN.md
+
+**Steps**
+
+1. **Check current state**
+
+   Read `DESIGN.md`. If it already contains real content (not the placeholder), warn the user:
+   > "DESIGN.md already has content. Running this will overwrite it. Proceeding..."
+
+   Then continue regardless — this command is always safe to rerun.
+
+2. **Check for source roots**
+
+   Load `.agents/source-roots.json` when present. Only analyze those roots.
+
+3. **Analyze the codebase**
+
+   Look for:
+   - CSS files, Tailwind config, PostCSS config
+   - Component files with inline styles or class usage
+   - Design token definitions (JS/TS/JSON/YAML)
+   - Theme files or style constants
+   - UI framework config (shadcn, MUI, Chakra, etc.)
+
+   If access to a running local server or screenshots is available, use them to validate visual identity.
+
+4. **Write DESIGN.md**
+
+   Overwrite `DESIGN.md` with the result. The output must:
+   - Begin with YAML frontmatter containing all structured design tokens (colors, typography, spacing, elevation, motion, radii, shadows, etc.)
+   - Follow with free-form Markdown describing the look & feel and capturing design intent that token values alone cannot convey
+   - Be entirely self-contained — do not reference any files, variables, or paths from the codebase
+   - Use valid YAML design token format for all token values
+
+5. **Report**
+
+   Tell the user:
+   - `DESIGN.md` generated successfully
+   - Key design tokens found (color palette, fonts, spacing scale)
+   - Tip: "Rerun `/ob-create-design` any time your design system changes."

package/content/.opencode/commands/{create-engineer.md → ob-create-engineer.md}

@@ -4,15 +4,15 @@ description: Create a custom engineer agent from a description, with skills from
 
 Create a new custom engineer agent based on the `basic-engineer.md` template.
 
-**Usage**: `/create-engineer <name> "<description>"`
+**Usage**: `/ob-create-engineer <name> "<description>"`
 
-Example: `/create-engineer frontend-engineer "A frontend engineer specialized in React, Next.js, and CSS"`
+Example: `/ob-create-engineer frontend-engineer "A frontend engineer specialized in React, Next.js, and CSS"`
 
 **Steps**
 
 1. **Parse input**
 
-   Extract `<name>` and `<description>` from the arguments after `/create-engineer`.
+   Extract `<name>` and `<description>` from the arguments after `/ob-create-engineer`.
    - Name should be kebab-case (e.g., `frontend-engineer`)
    - Description is the quoted string explaining the agent's specialty
    - If no input provided, use the AskUserQuestion tool to ask for both.
@@ -65,16 +65,16 @@ Example: `/create-engineer frontend-engineer "A frontend engineer specialized in
    ## Workflow
 
    When spawned by the lead:
-   1. Call `team_tasks_list` and verify your assigned task IDs and status before starting.
-   2. For each assigned task: before calling `team_claim task_id:<id>`, check `team_tasks_list` to confirm every dependency of that task has status `done`. If any dependency is not done, skip to the next assigned task that IS unblocked. Only claim tasks whose dependencies are fully complete.
-   3. Load `@ob-global` first, then load mandatory ability `Guardrails`.
+   1. Call `team_tasks_list` immediately and identify your assigned task IDs.
+   2. Claim the first assigned task that is unblocked with `team_claim task_id:<id>`. If the first assigned task is blocked, claim the next assigned task whose dependencies are already `done`. Do not wait once you have an unblocked assigned task.
+   3. After claiming, load `@ob-global` first, then load mandatory ability `Guardrails`.
    4. Load additional abilities from the `## Abilities` section as needed for the claimed task domain (for example: development, testing, infrastructure). Each ability can include one or more skills; load all relevant skills listed under each selected ability.
-   5. Send a short `team_message` to lead confirming claimed task ID and loaded skills.
+   5. Send a short `team_message` to lead confirming the claimed task ID and loaded skills.
    6. Implement the task following all loaded skill rules.
    7. Call `team_tasks_complete task_id:<id>` after finishing that task.
    8. Repeat until all currently assigned tasks are completed or blocked.
    9. Message lead with results via `team_message`. Lead may assign more tasks, do NOT stop working or shut down until lead confirms no more tasks for you.
-   10. If lead sends new task IDs via `team_message`, treat them as new assignments and go back to step 2.
+   10. If lead sends new task IDs via `team_message`, treat them as new assignments and go back to step 1.
    ```
 
    Place the installed skills under the most relevant ability category:
@@ -107,3 +107,4 @@ Example: `/create-engineer frontend-engineer "A frontend engineer specialized in
 - Pick a color that doesn't conflict with existing agents (basic-engineer uses #68A063)
 - Skills should match both the agent description AND the project's tech stack
 - If `npx skills` CLI is not available, manually reference skills by their `owner/repo` name in the abilities section and tell the user to install them
+- Keep the worker startup sequence short. Claim comes before skill loading so the agent is visible on the board immediately.

package/content/.opencode/commands/ob-init.md

@@ -0,0 +1,8 @@
+---
+description: Initialize the project. Runs the bootstrap sequence defined in AGENTS.md if not yet initialized. Supports both greenfield and brownfield projects.
+---
+
+Check if `AGENTS.md` is in bootstrap mode (contains `<!-- AGENTS-TEMPLATE-START -->`).
+
+- If yes: run the full initialization sequence defined in `AGENTS.md` now. The sequence will ask whether this is a greenfield or brownfield project and branch accordingly.
+- If no: tell the user the project is already initialized. Suggest running `/ob-create-architecture` or `/ob-create-design` if they want to refresh those docs.

package/content/.opencode/commands/{main.md → ob-main.md}

@@ -2,7 +2,7 @@
 description: Quick direct implementation, no OpenSpec, no ensemble, no PRs. Just do it.
 ---
 
-Implement the task described after `/main` directly and immediately.
+Implement the task described after `/ob-main` directly and immediately.
 
 **Rules:**
 - No OpenSpec artifacts (no proposal, no specs, no tasks.md)
@@ -14,4 +14,4 @@ Implement the task described after `/main` directly and immediately.
 - After editing, run `pnpm run typecheck` to catch type errors; fix any that are caused by your changes
 - Do NOT run lint or tests unless the user asks
 
-**Input**: Everything after `/main` is the task. Execute it now. 
+**Input**: Everything after `/ob-main` is the task. Execute it now. 

package/content/.opencode/commands/{plan.md → ob-plan.md}

@@ -2,9 +2,9 @@
 description: Parse a user story URL and produce a plan, proposal, specs, and tasks. Stops before implementation.
 ---
 
-Parse the work item at the URL provided after `/plan` and produce a full implementation plan.
+Parse the work item at the URL provided after `/ob-plan` and produce a full implementation plan.
 
-**Input**: A GitHub Issue URL or Azure DevOps work item URL. Example: `/plan https://github.com/org/repo/issues/42`
+**Input**: A GitHub Issue URL or Azure DevOps work item URL. Example: `/ob-plan https://github.com/org/repo/issues/42`
 
 **Steps:**