opencode-onboard 0.4.3 → 0.4.4

package/content/.agents/skills/ob-pullrequest-gh/SKILL.md

@@ -1,136 +1,140 @@
----
-name: ob-pullrequest-gh
-description: Create GitHub PRs with screenshots, or read and triage PR review feedback. Use when shipping a feature branch or when user says "I've added comments to the PR".
-license: MIT
-compatibility: Requires gh CLI, openspec CLI, and opencode-browser for screenshots.
-metadata:
-  author: copilots
-  version: "1.0"
----
-
-**ALL GitHub data MUST come from `gh` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitHub operations, even if gh CLI fails. If `gh` is unavailable, report as a blocker.**
-Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
-
----
-
-## Mode A: Create PR (ship mode)
-
-Triggered when devops-manager is in ship mode after implementation is complete.
-
-### Step 1: Verify feature branch
-
-```bash
-git branch --show-current
-```
-
-Branch must be `feature/{id}-{slug}`. NEVER push to `main`.
-
-### Step 2: Capture screenshots (if UI changes exist)
-
-```bash
-browser_navigate url="http://localhost:{port}/{route}"
-browser_wait ms=2000
-browser_screenshot
-```
-
-Save to: `openspec/changes/{change-name}/images/{feature}.png`
-
-### Step 3: Commit and push
-
-```bash
-git add .
-git commit -m "feat(#{id}): {description}"
-git push origin feature/{slug}
-```
-
-### Step 4: Create PR
-
-```bash
-gh pr create \
-  --base main \
-  --head feature/{slug} \
-  --title "feat: {title}" \
-  --body "{description}"
-```
-
-### Step 5: Post screenshot comment
-
-Resolve commit SHA (the commit that includes screenshots):
-```bash
-git rev-parse HEAD
-```
-
-Build blob URL for each image (preferred, stable in PR discussion):
-```
-https://github.com/{owner}/{repo}/blob/{sha}/openspec/changes/{change}/images/{file}.png
-```
-
-Post comment:
-```bash
-gh pr comment {pr-number} --repo {owner}/{repo} --body $'## Screenshots\n\n![{feature}]({blob-url})'
-```
-
----
-
-## Mode B: Read PR Feedback (feedback mode)
-
-Triggered when user says "I've added comments to the PR" or "check PR feedback".
-
-### Step 1: Find PRs
-
-If PR link provided, extract number from URL. Otherwise:
-```bash
-gh pr list --repo {owner}/{repo} --state open --limit 1
-```
-
-### Step 2: Read comment threads
-
-```bash
-gh pr view {pr-number} --repo {owner}/{repo} --comments
-# Or structured output:
-gh api repos/{owner}/{repo}/pulls/{pr-number}/comments
-gh api repos/{owner}/{repo}/pulls/{pr-number}/reviews
-```
-
-### Step 3: Categorize feedback
-
-| Category | Description | Action |
-|----------|-------------|--------|
-| `code-change` | Reviewer requests code modification | Return to lead to spawn specialists |
-| `spec-update` | Affects proposal, design, or tasks | Update openspec artifacts |
-| `question` | Reviewer asks a question | Reply with answer |
-| `resolved` | Thread already resolved | Skip |
-
-### Step 4: Update openspec (if spec-update)
-
-```bash
-git branch --show-current
-# feature/add-user-auth → change: add-user-auth
-```
-
-Update: `openspec/changes/{change}/proposal.md`, `design.md`, or `tasks.md` as appropriate.
-
-### Step 5: Reply to each comment thread
-
-```bash
-# Reply to a review comment
-gh api repos/{owner}/{repo}/pulls/{pr-number}/comments/{comment-id}/replies \
-  --method POST \
-  --field body="Acknowledged, applying this change now."
-
-# Or post a general PR comment
-gh pr comment {pr-number} --body "Updated design.md to reflect feedback."
-```
-
----
-
-## Guardrails
-
-- ✅ Commit and push to feature branches only
-- ✅ Create and comment on PRs via gh CLI with explicit `--repo {owner}/{repo}`
-- ✅ Screenshots of localhost only via browser_screenshot
-- ❌ Commit or push to `main`, FORBIDDEN
-- ❌ Force push, FORBIDDEN
-- ❌ Merge or approve PRs, human-only
-- ❌ Navigate browser to github.com, FORBIDDEN
-- ❌ webfetch or HTTP requests to GitHub URLs, FORBIDDEN
+---
+name: ob-pullrequest-gh
+description: Create GitHub PRs with screenshots, or read and triage PR review feedback. Use when shipping a feature branch or when user says "I've added comments to the PR".
+license: MIT
+compatibility: Requires gh CLI, openspec CLI, and opencode-browser for screenshots.
+metadata:
+  author: copilots
+  version: "1.0"
+---
+
+**ALL GitHub data MUST come from `gh` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitHub operations, even if gh CLI fails. If `gh` is unavailable, report as a blocker.**
+Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
+
+---
+
+## Mode A: Create PR (ship mode)
+
+Triggered when devops-manager is in ship mode after implementation is complete.
+
+### Step 1: Verify feature branch
+
+```bash
+git branch --show-current
+```
+
+Branch must be `feature/{id}-{slug}`. NEVER push to `main`.
+
+### Step 2: Capture screenshots (if UI changes exist)
+
+```bash
+browser_navigate url="http://localhost:{port}/{route}"
+browser_wait ms=2000
+browser_screenshot
+```
+
+Save to: `openspec/changes/{change-name}/images/{feature}.png`
+
+### Step 3: Commit and push
+
+```bash
+git add .
+git commit -m "feat(#{id}): {description}"
+git push origin feature/{id}-{slug}
+```
+
+### Step 4: Create PR
+
+```bash
+gh pr create \
+  --base main \
+  --head feature/{id}-{slug} \
+  --title "feat(#{id}): {title}" \
+  --body "{description}"
+```
+
+### Step 5: Post screenshot comment
+
+Resolve commit SHA (the commit that includes screenshots):
+
+```bash
+git rev-parse HEAD
+```
+
+Build blob URL for each image (preferred, stable in PR discussion):
+
+```
+https://github.com/{owner}/{repo}/blob/{sha}/openspec/changes/{change}/images/{file}.png
+```
+
+Post comment:
+
+```bash
+gh pr comment {pr-number} --repo {owner}/{repo} --body $'## Screenshots\n\n![{feature}]({blob-url})'
+```
+
+---
+
+## Mode B: Read PR Feedback (feedback mode)
+
+Triggered when user says "I've added comments to the PR" or "check PR feedback".
+
+### Step 1: Find PRs
+
+If PR link provided, extract number from URL. Otherwise:
+
+```bash
+gh pr list --repo {owner}/{repo} --state open --limit 1
+```
+
+### Step 2: Read comment threads
+
+```bash
+gh pr view {pr-number} --repo {owner}/{repo} --comments
+# Or structured output:
+gh api repos/{owner}/{repo}/pulls/{pr-number}/comments
+gh api repos/{owner}/{repo}/pulls/{pr-number}/reviews
+```
+
+### Step 3: Categorize feedback
+
+| Category      | Description                         | Action                              |
+| ------------- | ----------------------------------- | ----------------------------------- |
+| `code-change` | Reviewer requests code modification | Return to lead to spawn specialists |
+| `spec-update` | Affects proposal, design, or tasks  | Update openspec artifacts           |
+| `question`    | Reviewer asks a question            | Reply with answer                   |
+| `resolved`    | Thread already resolved             | Skip                                |
+
+### Step 4: Update openspec (if spec-update)
+
+```bash
+git branch --show-current
+# feature/add-user-auth → change: add-user-auth
+```
+
+Update: `openspec/changes/{change}/proposal.md`, `design.md`, or `tasks.md` as appropriate.
+
+### Step 5: Reply to each comment thread
+
+```bash
+# Reply to a review comment
+gh api repos/{owner}/{repo}/pulls/{pr-number}/comments/{comment-id}/replies \
+  --method POST \
+  --field body="Acknowledged, applying this change now."
+
+# Or post a general PR comment
+gh pr comment {pr-number} --body "Updated design.md to reflect feedback."
+```
+
+---
+
+## Guardrails
+
+- ✅ Commit and push to feature branches only
+- ✅ Create and comment on PRs via gh CLI with explicit `--repo {owner}/{repo}`
+- ✅ Screenshots of localhost only via browser_screenshot
+- ❌ Commit or push to `main`, FORBIDDEN
+- ❌ Force push, FORBIDDEN
+- ❌ Merge or approve PRs, human-only
+- ❌ Navigate browser to github.com, FORBIDDEN
+- ❌ webfetch or HTTP requests to GitHub URLs, FORBIDDEN

package/content/.opencode/commands/create-engineer.md

@@ -0,0 +1,109 @@
+---
+description: Create a custom engineer agent from a description, with skills from skills.sh
+---
+
+Create a new custom engineer agent based on the `basic-engineer.md` template.
+
+**Usage**: `/create-engineer <name> "<description>"`
+
+Example: `/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`.
+   - 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.
+
+2. **Search for relevant skills from skills.sh**
+
+   Based on the description and the project context (read ARCHITECTURE.md, DESIGN.md), search for relevant skills:
+
+   ```bash
+   npx skills search "<relevant keywords from description>"
+   ```
+
+   If the search doesn't work or returns nothing, browse https://www.skills.sh/ for relevant skills based on the agent's specialty.
+
+   Select 2-5 skills that are most relevant to the agent's role. Prefer official/popular skills.
+
+3. **Install selected skills**
+
+   For each selected skill:
+   ```bash
+   npx skills add <owner/repo>
+   ```
+
+   This installs the skill files into the project.
+
+4. **Create the agent file**
+
+   Create `.agents/agents/<name>.md` with this structure:
+
+   ```markdown
+   ---
+   description: <description>
+   mode: subagent
+   color: <pick a unique hex color>
+   temperature: 0.2
+   permission:
+     edit: allow
+     bash: allow
+     read: allow
+     glob: allow
+     grep: allow
+   ---
+
+   ## Abilities
+   - Guardrails: @ob-generic-guardrails
+   - Development: <@installed-skill-1>, <@installed-skill-2>, ...
+   - Testing: <@installed-skill-for-testing>, ...
+   - Infrastructure: <@installed-skill-for-devops-cicd>, ...
+
+   ## 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`.
+   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.
+   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.
+   ```
+
+   Place the installed skills under the most relevant ability category:
+   - **Development** — language frameworks, UI libraries, application code skills
+   - **Testing** — test frameworks, linting, type checking, validation skills
+   - **Infrastructure** — DevOps, CI/CD, cloud, deployment, containerization skills
+
+   Distribute skills across ALL categories that apply. Only include categories that have at least one real skill assigned (besides Guardrails which is always present).
+
+5. **Update AGENTS.md**
+
+   Add the new agent to the agents table in AGENTS.md:
+   ```
+   | `<name>` | .agents/agents/<name>.md | <short role description> |
+   ```
+
+6. **Show summary**
+
+   Report:
+   - Agent file created at `.agents/agents/custom-engineer-<name>.md`
+   - Skills installed (list each with source)
+   - How to use: "This agent will be spawned by the lead during `/opsx-apply` for tasks matching its specialty."
+
+**Guidelines**
+- Always keep `@ob-generic-guardrails` in the Guardrails ability
+- NEVER use `@ob-default` in any ability category - all abilities must reference real installed skills
+- **Development** = language/framework/UI skills. **Testing** = test/lint/typecheck skills. **Infrastructure** = DevOps, CI/CD, cloud, deployment skills. Never put UI/CSS skills under Infrastructure.
+- Distribute installed skills across the appropriate categories — not just Development
+- Only include ability categories that have at least one real skill assigned
+- 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