@desplega.ai/agent-swarm 1.56.3 → 1.56.5

package/openapi.json

@@ -2,7 +2,7 @@
   "openapi": "3.1.0",
   "info": {
     "title": "Agent Swarm API",
-    "version": "1.56.3",
+    "version": "1.56.4",
     "description": "Multi-agent orchestration API for Claude Code, Codex, and Gemini CLI. Enables task distribution, agent communication, and service discovery.\n\nMCP tools are documented separately in [MCP.md](./MCP.md)."
   },
   "servers": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@desplega.ai/agent-swarm",
-  "version": "1.56.3",
+  "version": "1.56.5",
   "description": "Multi-agent orchestration for Claude Code, Codex, Gemini CLI, and other AI coding assistants",
   "license": "MIT",
   "author": "desplega.sh <contact@desplega.sh>",

package/plugin/commands/close-issue.md

@@ -13,78 +13,26 @@ Close a GitHub or GitLab issue with an appropriate closing comment summarizing t
 
 ## Arguments
 
-- `issue-number-or-url`: Either an issue number (e.g., `123`) or a full issue URL (e.g., `https://github.com/owner/repo/issues/123` or `https://gitlab.com/group/project/-/issues/123`)
+- `issue-number-or-url`: Either an issue number (e.g., `123`) or a full issue URL
 
 ## Workflow
 
-### 1. Parse the Input
-
-If given a URL, extract the owner, repo, and issue number. If given just a number, use the current repository context.
-
-### 2. Ensure Repository is Cloned Locally
-
-Make sure the repository is available in your personal workspace:
-
-```bash
-REPO_PATH=/workspace/personal/<repo-name>
-
-if [ ! -d "$REPO_PATH" ]; then
-  gh repo clone <owner>/<repo> "$REPO_PATH"
-fi
-
-cd "$REPO_PATH"
-```
-
-### 3. Get Issue Details
-
-```bash
-gh issue view <issue-number> --json title,body,author,labels,comments
-```
-
-### 4. Understand the Context
-
-Review:
-- What was the original issue about?
-- What work was done to resolve it?
-- Were there any related PRs or commits?
-
-Check for related PRs:
-
-```bash
-gh pr list --search "fixes #<issue-number>" --json number,title,state
-```
-
-### 5. Generate Closing Comment
-
-Write a closing comment that includes:
-- Brief summary of what was done
-- Reference to any PRs that addressed the issue
-- Any follow-up items or notes
-
-### 6. Post Comment and Close
-
-```bash
-# Add the closing comment
-gh issue comment <issue-number> --body "Your closing comment"
-
-# Close the issue
-gh issue close <issue-number>
-```
-
-Or combine with a reason:
-
-```bash
-gh issue close <issue-number> --comment "Your closing comment" --reason completed
-```
+1. **Parse the input** — if given a URL, extract owner, repo, and issue number. If just a number, use the current repo context.
+2. **Ensure repo is cloned** to `/workspace/personal/<repo-name>` (clone with `gh repo clone` if needed).
+3. **Get issue details** — read the issue title, body, comments, and check for related PRs.
+4. **Generate closing comment** — summarize what was done, reference related PRs/commits, note any follow-ups.
+5. **Post comment and close:**
+   ```bash
+   gh issue close <issue-number> --comment "Your closing comment" --reason completed
+   ```
 
 ## Closing Reasons
 
-- `completed` - The issue was resolved
-- `not_planned` - Won't fix / out of scope / duplicate
+- `completed` — The issue was resolved
+- `not_planned` — Won't fix / out of scope / duplicate
 
 ## Tips
 
 - Always explain why the issue is being closed
 - Reference specific PRs or commits when applicable
 - If closing as "not planned", explain the reasoning
-- Be respectful - someone took time to report the issue

package/plugin/commands/create-pr.md

@@ -5,15 +5,15 @@ argument-hint: [base-branch]
 
 # Create Pull Request / Merge Request
 
-Create a pull request (GitHub) or merge request (GitLab) from the current branch with an auto-generated title and description.
+Create a PR (GitHub) or MR (GitLab) from the current branch with an auto-generated title and description.
 
-**Provider detection:** Check the remote URL to determine the VCS provider:
-- If the remote contains `github.com` → use `gh` CLI
-- If the remote contains `gitlab.com` or `gitlab.` → use `glab` CLI
+**Provider detection:** Check the remote URL:
+- If `github.com` → use `gh` CLI
+- If `gitlab.com` or `gitlab.` → use `glab` CLI
 
 ## Arguments
 
-- `base-branch` (optional): The branch to merge into (defaults to `main` or the repo's default branch)
+- `base-branch` (optional): Branch to merge into (defaults to `main` or repo default)
 
 ## Prerequisites
 
@@ -21,79 +21,17 @@ You should be working in a repository cloned to `/workspace/personal/<repo-name>
 
 ## Workflow
 
-### 1. Verify Working Directory
-
-Ensure you're in a git repository:
-
-```bash
-git rev-parse --is-inside-work-tree
-```
-
-### 2. Check Branch Status
-
-```bash
-# Get current branch
-git branch --show-current
-
-# Ensure we're not on main/master
-# Ensure there are commits to push
-git log origin/main..HEAD --oneline
-```
-
-### 3. Push the Branch
-
-```bash
-git push -u origin HEAD
-```
-
-### 4. Gather Context for PR Description
-
-```bash
-# Get commit messages since diverging from base
-git log origin/main..HEAD --pretty=format:"%s%n%b"
-
-# Get changed files
-git diff --stat origin/main..HEAD
-```
-
-### 5. Generate PR Title and Description
-
-Based on the commits and changes:
-- **Title**: Concise summary of the changes (use conventional commit style if the repo uses it)
-- **Description**:
-  - Summary of what changed and why
-  - List of notable changes
-  - Any testing done
-  - Related issues (if applicable)
-
-### 6. Create the PR/MR
-
-**For GitHub:**
-```bash
-gh pr create \
-  --title "Your generated title" \
-  --body "Your generated description" \
-  --base main
-```
-
-**For GitLab:**
-```bash
-glab mr create \
-  --title "Your generated title" \
-  --description "Your generated description" \
-  --target-branch main
-```
-
-### 7. Report the PR/MR URL
-
-After creation, provide the URL to the user:
-
-**GitHub:** `gh pr view --json url --jq '.url'`
-**GitLab:** `glab mr view --web`
+1. **Verify state** — confirm you're in a git repo, not on main/master, and have commits to push.
+2. **Push the branch** — `git push -u origin HEAD`
+3. **Gather context** — review commit messages and changed files since diverging from base.
+4. **Generate title and description:**
+   - **Title**: Concise summary (conventional commit style if the repo uses it)
+   - **Description**: Summary of changes, notable items, testing done, related issues
+5. **Create the PR/MR** using `gh pr create` or `glab mr create`.
+6. **Report** the PR/MR URL.
 
 ## Tips
 
 - Link related issues using `Fixes #123` or `Closes #123` in the description
-- Include a test plan if the changes are significant
-- Keep PRs focused - one logical change per PR
-- If the branch has many commits, consider summarizing the overall change rather than listing each commit
+- Keep PRs focused — one logical change per PR
+- If the branch has many commits, summarize the overall change rather than listing each commit

package/plugin/commands/implement-issue.md

@@ -5,131 +5,55 @@ argument-hint: <issue-number-or-url>
 
 # Implement Issue
 
-Read a GitHub or GitLab issue, implement the requested changes, and create a pull request / merge request.
+Read a GitHub or GitLab issue, implement the requested changes, and create a PR/MR.
 
-**Provider detection:** Check the URL or remote to determine the VCS provider:
+**Provider detection:** Check the URL or remote:
 - If GitHub → use `gh issue view` / `gh pr create`
 - If GitLab → use `glab issue view` / `glab mr create`
 
 ## Arguments
 
-- `issue-number-or-url`: Either an issue number (e.g., `123`) or a full URL (e.g., `https://github.com/owner/repo/issues/123` or `https://gitlab.com/group/project/-/issues/123`)
+- `issue-number-or-url`: Either an issue number (e.g., `123`) or a full URL
 
 ## Workflow
 
-### 1. Parse the Input
+### 1. Parse and Fetch
 
-If given a URL, extract the owner, repo, and issue number. If given just a number, use the current repository context.
+If given a URL, extract owner, repo, and issue number. Fetch issue details (title, body, labels, comments). Understand what's being requested, acceptance criteria, and any technical constraints.
 
-### 2. Fetch Issue Details
+### 2. Setup
 
-```bash
-gh issue view <issue-number> --json number,title,body,labels,comments
-```
+- Ensure repo is cloned to `/workspace/personal/<repo-name>` (clone with `gh repo clone` if needed)
+- Fetch origin, checkout main, pull latest
+- Create a feature branch: `fix/issue-<number>-<short-description>`
 
-Read and understand:
-- What is being requested?
-- Are there acceptance criteria?
-- Any technical details or constraints mentioned?
-- Check comments for additional context or clarifications
+### 3. Implement
 
-### 3. Ensure Repository is Cloned
-
-Clone the repository to your personal workspace if not already present:
-
-```bash
-REPO_PATH=/workspace/personal/<repo-name>
-
-if [ ! -d "$REPO_PATH" ]; then
-  gh repo clone <owner>/<repo> "$REPO_PATH"
-fi
-
-cd "$REPO_PATH"
-git fetch origin
-git checkout main
-git pull origin main
-```
-
-### 4. Create a Feature Branch
-
-```bash
-# Use a descriptive branch name based on the issue
-git checkout -b fix/issue-<number>-<short-description>
-
-# Examples:
-# git checkout -b fix/issue-123-add-dark-mode
-# git checkout -b fix/issue-456-fix-login-redirect
-```
-
-### 5. Implement the Changes
-
-This is the core work. Based on the issue:
-
-1. **Understand the codebase** - Explore relevant files, understand existing patterns
-2. **Plan your approach** - Consider using `/desplega:create-plan` for complex changes
-3. **Write the code** - Implement the requested functionality
-4. **Test your changes** - Run existing tests, add new tests if appropriate
-5. **Verify it works** - Manual verification where possible
+1. **Understand the codebase** — explore relevant files and existing patterns
+2. **Plan your approach** — consider using `/desplega:create-plan` for complex changes
+3. **Write the code** — implement the requested functionality
+4. **Test your changes** — run existing tests, add new tests if appropriate
+5. **Verify it works** — manual verification where possible
 
 Keep changes focused on what the issue requests. Avoid scope creep.
 
-### 6. Commit Your Changes
-
-```bash
-# Stage your changes
-git add -A
-
-# Commit with a message referencing the issue
-git commit -m "Fix #<issue-number>: <short description>
-
-<longer description if needed>"
-```
-
-Use conventional commit style if the repo uses it (e.g., `feat:`, `fix:`, `docs:`).
-
-### 7. Push the Branch
-
-```bash
-git push -u origin HEAD
-```
-
-### 8. Create the Pull Request
-
-```bash
-gh pr create \
-  --title "<descriptive title>" \
-  --body "## Summary
-<Brief description of what this PR does>
-
-## Changes
-- <List key changes>
-
-## Testing
-- <How you tested the changes>
-
-Fixes #<issue-number>"
-```
+### 4. Commit and Push
 
-The `Fixes #<number>` syntax will auto-close the issue when the PR is merged.
+Commit with a message referencing the issue (e.g., `Fix #123: <description>`). Use conventional commit style if the repo uses it. Push with `git push -u origin HEAD`.
 
-### 9. Report Back
+### 5. Create the PR
 
-Provide the user with:
-- PR URL
-- Summary of changes made
-- Any notes or caveats
+Create the PR with a descriptive title and body including: summary of changes, key changes list, testing done, and `Fixes #<issue-number>` to auto-close the issue on merge.
 
-Optionally, comment on the original issue:
+### 6. Report Back
 
-```bash
-gh issue comment <issue-number> --body "I've created a PR to address this: <PR-URL>"
-```
+Provide the PR URL, summary of changes, and any caveats. Optionally comment on the original issue linking the PR.
 
 ## Tips
 
-- Read the issue thoroughly before starting - misunderstanding wastes time
-- Check if there are related issues or existing PRs
-- Keep PRs focused - one issue = one PR
-- If the issue is too large, consider breaking it into smaller PRs
-- If you get stuck or the issue is unclear, use `/respond-github` to ask for clarification
+- Read the issue thoroughly before starting — misunderstanding wastes time
+- Check for related issues or existing PRs
+- One issue = one PR
+- If the issue is too large, break it into smaller PRs
+- If unclear, use `/respond-github` to ask for clarification
 - Run linters and tests before creating the PR

package/plugin/commands/investigate-sentry-issue.md

@@ -9,130 +9,67 @@ Investigate a Sentry issue to understand the error, gather context, and prepare
 
 ## Prerequisites
 
-Environment variables `SENTRY_AUTH_TOKEN` and `SENTRY_ORG` must be set (they are pre-configured in the worker environment).
-
-Verify authentication:
-```bash
-sentry-cli info
-```
+`SENTRY_AUTH_TOKEN` and `SENTRY_ORG` must be set. Verify with `sentry-cli info`.
 
 ## Arguments
 
-- `sentry-issue-url-or-id`: Either a Sentry issue URL (e.g., `https://sentry.io/organizations/myorg/issues/123456/`) or just the issue ID (e.g., `123456`)
+- `sentry-issue-url-or-id`: A Sentry issue URL or just the issue ID (e.g., `123456`)
 
 ## Workflow
 
-### 1. Parse the Sentry URL
+### 1. Parse the Input
 
-If given a URL, extract the issue ID:
-```bash
-# URL format: https://sentry.io/organizations/{org}/issues/{issue_id}/
-# Extract issue_id from the URL path
-```
+If given a URL (`https://sentry.io/organizations/{org}/issues/{issue_id}/`), extract the issue ID.
 
 ### 2. Get Issue Overview
 
-Use `sentry-cli` to list the issue:
 ```bash
 sentry-cli issues list --id <issue-id>
 ```
 
-### 3. Get Detailed Issue Information
-
-For more context, use the REST API:
-```bash
-curl -s "https://sentry.io/api/0/organizations/${SENTRY_ORG}/issues/<issue-id>/" \
-  -H "Authorization: Bearer ${SENTRY_AUTH_TOKEN}" | jq
-```
+### 3. Get Detailed Info via REST API
 
-This returns:
-- Error title and metadata
-- First/last seen timestamps
-- Event count and user impact
-- Assigned user and status
+Use `https://sentry.io/api/0/organizations/${SENTRY_ORG}/issues/<issue-id>/` for metadata (first/last seen, event count, user impact, status).
 
 ### 4. Get Full Stacktrace
 
-The recommended event provides the best debugging context:
-```bash
-curl -s "https://sentry.io/api/0/organizations/${SENTRY_ORG}/issues/<issue-id>/events/recommended/" \
-  -H "Authorization: Bearer ${SENTRY_AUTH_TOKEN}" | jq
-```
-
-Key fields in the response:
-- `.entries[] | select(.type == "exception")` - The exception with stacktrace
-- `.entries[] | select(.type == "breadcrumbs")` - Actions leading to the error
-- `.tags` - Environment, browser, OS info
-- `.context` - Custom context data
+Use the recommended event endpoint: `.../issues/<issue-id>/events/recommended/`
 
-### 5. Extract Stacktrace Frames
-
-To see the actual stack:
-```bash
-curl -s "https://sentry.io/api/0/organizations/${SENTRY_ORG}/issues/<issue-id>/events/recommended/" \
-  -H "Authorization: Bearer ${SENTRY_AUTH_TOKEN}" | \
-  jq '.entries[] | select(.type == "exception") | .data.values[].stacktrace.frames'
-```
+Key jq paths for the response:
+- `.entries[] | select(.type == "exception")` — exception with stacktrace
+- `.entries[] | select(.type == "exception") | .data.values[].stacktrace.frames` — stack frames
+- `.entries[] | select(.type == "breadcrumbs")` — actions leading to the error
+- `.tags` — environment, browser, OS info
+- `.context` — custom context data
 
-### 6. Analyze and Report
+### 5. Analyze and Report
 
-Based on the stacktrace and context:
 1. Identify the failing file and line number
 2. Understand the error type and message
 3. Review breadcrumbs for the sequence of events
 4. Check tags for environment-specific issues
 
-### 7. Take Action (if appropriate)
+### 6. Take Action (if appropriate)
 
-**Resolve an issue:**
 ```bash
-sentry-cli issues resolve <issue-id>
-```
-
-**Mute an issue:**
-```bash
-sentry-cli issues mute <issue-id>
-```
-
-**Unresolve an issue:**
-```bash
-sentry-cli issues unresolve <issue-id>
-```
-
-## Common CLI Commands
-
-```bash
-# Verify authentication
-sentry-cli info
-
-# List unresolved issues
-sentry-cli issues list --query "is:unresolved"
-
-# List recent issues (last 2 days)
-sentry-cli issues list --query "lastSeen:-2d"
-
-# List issues matching a message
-sentry-cli issues list --query "message:undefined"
-
-# Bulk resolve issues
-sentry-cli issues resolve <id1> <id2> <id3>
+sentry-cli issues resolve <issue-id>    # Resolve
+sentry-cli issues mute <issue-id>       # Mute
+sentry-cli issues unresolve <issue-id>  # Unresolve
 ```
 
 ## Search Query Syntax
 
-Use these filters with `--query`:
+Use these filters with `sentry-cli issues list --query`:
 
 | Filter | Example | Description |
 |--------|---------|-------------|
-| `is:` | `is:unresolved`, `is:resolved` | Issue status |
+| `is:` | `is:unresolved` | Issue status |
 | `lastSeen:` | `lastSeen:-2d` | Seen within time range |
 | `message:` | `message:undefined` | Match error message |
 | `issue.category:` | `issue.category:error` | Error category |
 
 ## Tips
 
-- Always get the recommended event first - it's curated for debugging
-- Use `jq` to filter large JSON responses
+- Always get the recommended event first — it's curated for debugging
 - Check breadcrumbs to understand user actions before the error
-- Look at tags for environment info (browser, OS, etc.)
 - If investigating from a Slack alert, the issue URL is in the alert message

package/plugin/commands/respond-github.md

@@ -7,92 +7,31 @@ argument-hint: <issue-or-pr-number-or-url>
 
 Post a response to a GitHub issue/PR or GitLab issue/MR.
 
-**Provider detection:** Check the URL or remote to determine the VCS provider:
+**Provider detection:** Check the URL or remote:
 - If GitHub → use `gh issue comment` / `gh pr comment`
 - If GitLab → use `glab issue note` / `glab mr note`
 
 ## Arguments
 
-- `issue-or-pr-number-or-url`: Either a number (e.g., `123`) or a full URL (e.g., `https://github.com/owner/repo/issues/123` or `https://gitlab.com/group/project/-/issues/123`)
+- `issue-or-pr-number-or-url`: Either a number (e.g., `123`) or a full URL
 
 ## Workflow
 
-### 1. Parse the Input
+1. **Parse the input** — if given a URL, extract owner, repo, type (issue/PR), and number. If just a number, determine type from current repo context.
+2. **Ensure repo is cloned** to `/workspace/personal/<repo-name>` (clone with `gh repo clone` if needed).
+3. **Get full context** — read the original description and all comments in the thread.
+4. **Understand what's being asked** — if this is from `@agent-swarm`, focus on what was asked in that mention.
+5. **Formulate and post your response** using `gh issue comment` / `gh pr comment` (or `glab` equivalents).
 
-If given a URL, extract:
-- Owner and repo
-- Whether it's an issue or PR (from the URL path)
-- The number
+## Decision Framework
 
-If given just a number, use the current repository context and check if it's an issue or PR.
-
-### 2. Ensure Repository is Cloned Locally
-
-Make sure the repository is available in your personal workspace:
-
-```bash
-REPO_PATH=/workspace/personal/<repo-name>
-
-if [ ! -d "$REPO_PATH" ]; then
-  gh repo clone <owner>/<repo> "$REPO_PATH"
-fi
-
-cd "$REPO_PATH"
-```
-
-### 3. Get Full Context
-
-For issues:
-```bash
-gh issue view <number> --json title,body,author,labels,comments,state
-```
-
-For PRs:
-```bash
-gh pr view <number> --json title,body,author,comments,state,reviews
-```
-
-### 4. Understand What's Being Asked
-
-Read through:
-- The original issue/PR description
-- All comments in the thread
-- Any specific questions or requests
-
-If this is a task from agent-swarm with `@agent-swarm` mention, focus on what was asked in that mention.
-
-### 5. Formulate Your Response
-
-Consider:
 - What specific question or request needs addressing?
 - Do you need to provide code examples?
 - Should you ask clarifying questions?
 - Is this something you can resolve, or do you need human input?
 
-### 6. Post the Response
-
-For issues:
-```bash
-gh issue comment <number> --body "Your response"
-```
-
-For PRs:
-```bash
-gh pr comment <number> --body "Your response"
-```
-
-## Response Guidelines
-
-- Be helpful and constructive
-- If you don't know something, say so
-- Provide code examples when relevant
-- Use markdown formatting for readability
-- Keep responses focused and concise
-- If you've completed work, link to the relevant PR or commit
-
 ## Tips
 
 - Check if there's already a PR addressing an issue before responding
-- If asked to implement something, consider whether to respond first or just do it
 - For complex requests, acknowledge receipt and outline your plan
-- Tag relevant people with `@username` if needed
+- If you've completed work, link to the relevant PR or commit