@dreb/coding-agent 1.16.0

package/skills/mach6-publish/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: mach6-publish
+description: "Pre-merge checks, version bump, merge PR, git tag, GitHub release. Version bump happens BEFORE merge (on the feature branch) because master requires PRs. Usage: mach6-publish 42"
+argument-hint: "<pr-number>"
+---
+
+# mach6-publish — Version Bump, Merge, Tag, and Release
+
+**User input:** $ARGUMENTS
+
+## Global Rules
+
+1. **GitHub as shared memory** — All context lives on the PR.
+2. **No `#N` in comment bodies** — Use "finding 3", "item 3" etc. instead.
+3. **Safe git** — Never use `git add -A` or `git add .`. Stage files by name. Never stage secrets.
+4. **Task tracking** — Use the `tasks_update` tool to show progress.
+
+## Step 1: Set up task tracking
+
+```
+tasks_update([
+  { id: "checks", title: "Pre-merge checks", status: "in_progress" },
+  { id: "version", title: "Version bump (on feature branch)", status: "pending" },
+  { id: "docs", title: "Update documentation", status: "pending" },
+  { id: "merge", title: "Merge PR", status: "pending" },
+  { id: "release", title: "Tag and release", status: "pending" }
+])
+```
+
+## Step 2: Pre-merge checks
+
+```bash
+gh pr checkout <pr-number>
+git pull
+gh pr view <pr-number> --json mergeable,mergeStateStatus,statusCheckRollup,reviewDecision,comments,body
+gh pr checks <pr-number>
+```
+
+Read ALL PR comments to understand the full history — plans, reviews, assessments, progress updates, and discussion.
+
+Verify:
+- [ ] CI is passing
+- [ ] No merge conflicts
+- [ ] All review findings addressed (check for genuine items in latest assessment)
+
+If there are blocking issues, report them and suggest fixes:
+- **Failed CI**: `/skill:mach6-implement <pr-number> ci`
+- **Merge conflicts**: Suggest resolving manually or rebasing
+- **Unaddressed findings**: `/skill:mach6-implement <pr-number>`
+
+### Pre-merge checklist
+
+Check for contributing guidelines first:
+```bash
+# Read first found: CONTRIBUTING.md, DEVELOPMENT.md, .github/CONTRIBUTING.md, AGENTS.md
+```
+
+Then check if these need attention:
+- [ ] Documentation updated (if behavior changed) — check README, docs/, docstrings, help text
+- [ ] Changelog updated (if project maintains one — check CHANGELOG.md, CHANGES.md)
+- [ ] Tests passing locally
+
+Present the checklist to the user. If items need attention, address them before proceeding.
+
+Update task: checks → completed, version → in_progress.
+
+## Step 3: Version bump (on the feature branch — BEFORE merge)
+
+**This step is mandatory for projects with versioning.** The version bump MUST happen on the feature branch and be pushed as part of the PR, because the default branch requires PRs for all changes — you cannot push commits directly to it.
+
+1. Detect versioning:
+   ```bash
+   # Check for version files: package.json, Cargo.toml, pyproject.toml, version.txt, etc.
+   ```
+
+2. Determine the current version and what the new version should be. If the bump level isn't obvious from the PR context, **ask the user**:
+   - **Patch**: Bug fixes, minor improvements
+   - **Minor**: New features, non-breaking changes
+   - **Major**: Breaking changes
+
+3. Apply the version bump. Check AGENTS.md / CONTRIBUTING.md for project-specific version bump procedures (e.g., sync scripts, build steps that embed the version).
+
+4. Commit and push on the feature branch:
+   ```bash
+   git add <version-files>
+   git commit -m "chore: bump version to <new-version>"
+   git push
+   ```
+
+5. Wait for CI to pass on the version bump commit before proceeding to merge.
+
+If the project doesn't use versioning, skip this step.
+
+Update task: version → completed, docs → in_progress.
+
+## Step 4: Update documentation
+
+Proactively review and update ALL documentation affected by the PR's changes. This is not limited to mach6 docs — check everything in the repo.
+
+1. Identify changed features by reading the PR diff:
+   ```bash
+   gh pr diff <pr-number>
+   ```
+
+2. Scan all documentation for references to changed features:
+   - README.md files across all packages
+   - docs/ directory (all .md files)
+   - AGENTS.md, CLAUDE.md, CONTRIBUTING.md, .dreb/CONTEXT.md
+   - Example files and their READMEs
+   - Help text and CLI flag documentation
+   - CHANGELOG.md or CHANGES.md
+
+3. For each doc, verify:
+   - CLI flags, settings, and commands match current code
+   - Code snippets and examples are accurate
+   - Cross-references point to real files and valid anchors
+   - No stale descriptions of removed or changed features
+   - Environment variables listed match current code
+
+4. Fix all inaccuracies found. Commit and push:
+   ```bash
+   git add <doc-files>
+   git commit -m "docs: update documentation for <version>"
+   git push
+   ```
+
+5. Wait for CI to pass on the docs commit.
+
+If no documentation changes are needed (rare), skip this step.
+
+Update task: docs → completed, merge → in_progress.
+
+## Step 5: Merge
+
+```bash
+gh pr merge <pr-number> --squash --delete-branch
+```
+
+Use `--squash` by default. If the user prefers a different merge strategy, they can specify.
+
+Then update local:
+```bash
+git checkout $(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
+git pull
+```
+
+Clean up local feature branch if it still exists:
+```bash
+git branch -d <branch-name> 2>/dev/null
+```
+
+Update task: merge → completed, release → in_progress.
+
+## Step 6: Tag and release
+
+Ask the user if they want to create a GitHub release:
+- **Yes**: Proceed with tagging and release
+- **No**: Skip — just create the tag
+
+### Always create the git tag
+
+The tag is created on the default branch after merge, using the version from Step 3:
+
+```bash
+git tag v<version>
+git push --tags
+```
+
+### If releasing
+
+1. Check existing releases for style:
+   ```bash
+   gh release list --limit 5
+   gh release view <latest-tag>  # if releases exist
+   ```
+
+2. Draft release notes from the PR description and comment thread. Match existing release note style.
+
+3. Present draft to user for approval, then create:
+   ```bash
+   gh release create v<version> --title "v<version>" --notes "<release-notes>"
+   ```
+
+Update task: release → completed.
+
+## Step 7: Report
+
+Report: what was merged, tagged, released. Link to the PR and release.

package/skills/mach6-push/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: mach6-push
+description: "Commit changes, push to remote, and post a progress comment on the associated PR or issue. Stages files by name (never git add -A), matches existing commit style, auto-detects PR from branch. Usage: mach6-push [optional commit message]"
+argument-hint: "[commit message]"
+---
+
+# mach6-push — Commit, Push, Progress Comment
+
+**User input:** $ARGUMENTS
+
+## Global Rules
+
+1. **GitHub as shared memory** — Progress is posted as PR/issue comments so any future session can pick up context.
+2. **HTML markers** — Use `<!-- mach6-progress -->` as the first line of progress comment bodies.
+3. **No `#N` in comment bodies** — Use "finding 3", "item 3", "stage 2" etc. instead.
+4. **Safe git** — Never use `git add -A` or `git add .`. Stage files by name. Never stage secrets (.env, credentials, tokens, keys).
+5. **Task tracking** — Use the `tasks_update` tool to show progress.
+
+## Step 1: Set up task tracking
+
+```
+tasks_update([
+  { id: "stage", title: "Stage changes", status: "in_progress" },
+  { id: "commit", title: "Commit", status: "pending" },
+  { id: "push", title: "Push to remote", status: "pending" },
+  { id: "comment", title: "Post progress comment", status: "pending" }
+])
+```
+
+## Step 2: Stage changes
+
+Run `git status` and `git diff` to understand the current state.
+
+- If you have context from this session about which files were modified, stage those by name.
+- If files are already staged and look correct, proceed.
+- If unclear (fresh session, no context), review all changes and ask the user what to stage.
+- **Never** use `git add -A` or `git add .`
+- **Never** stage secrets (.env, credentials, tokens, keys)
+
+Update task: stage → completed, commit → in_progress.
+
+## Step 3: Commit
+
+Check recent commit style:
+```bash
+git log --oneline -10
+```
+
+Generate a commit message that:
+- Follows the repository's existing style
+- Summarizes the nature of the changes
+- Uses the user's override message if provided
+
+```bash
+git commit -m "<message>"
+```
+
+Update task: commit → completed, push → in_progress.
+
+## Step 4: Push
+
+```bash
+git push
+```
+
+If no upstream is set, use `git push -u origin <branch>`.
+
+Update task: push → completed, comment → in_progress.
+
+## Step 5: Post progress comment
+
+Detect the associated PR or issue:
+
+1. **Session context first**: If an earlier mach6 command in this session targeted a specific PR or issue, use that.
+2. **PR detection**: Try `gh pr view --json number,url` on current branch. If a PR exists, comment on it.
+3. **Branch name fallback**: Check branch name for issue number pattern (e.g., `feature/issue-55-*`). If found, comment on that issue.
+4. **Skip gracefully**: If neither works, skip commenting and inform the user.
+
+If session context points to an issue but a PR also exists on the current branch, prefer the PR.
+
+Post a progress comment:
+```bash
+gh pr comment <number> --body "<!-- mach6-progress -->
+## Progress Update
+
+<summary of changes in this batch>
+
+**Commit:** \`<hash>\`
+
+---
+*Progress tracked by mach6*"
+```
+
+Update task: comment → completed.
+
+Report: what was committed, where pushed, where the comment was posted (with link).
+
+Suggest next step based on context:
+- If on a feature branch with a PR: `/skill:mach6-review <pr-number>`
+- If on a feature branch without a PR: `/skill:mach6-plan <issue-number>` to create one
+- If on the default branch: issue-oriented next steps

package/skills/mach6-review/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: mach6-review
+description: "Run specialized review agents in parallel on a PR (code-reviewer, error-auditor, test-reviewer, completeness-checker, simplifier), post findings, then independently assess each finding to separate genuine issues from nitpicks and false positives. Usage: mach6-review 42 [aspects]"
+argument-hint: "<pr-number> [code|errors|tests|completeness|simplify]"
+---
+
+# mach6-review — Multi-Agent PR Review
+
+**User input:** $ARGUMENTS
+
+## Global Rules
+
+1. **GitHub as shared memory** — Reviews and assessments are posted as PR comments so any future session can pick up context.
+2. **HTML markers** — Use `<!-- mach6-review -->` and `<!-- mach6-assessment -->` as the first line of comment bodies.
+3. **No `#N` in comment bodies** — Use "finding 3", "item 3", "stage 2" etc. instead.
+4. **Task tracking** — Use the `tasks_update` tool to show progress.
+
+**Important: Do NOT fix any issues in this session. Fixes happen via `/skill:mach6-implement`.**
+
+## Step 1: Set up task tracking
+
+```
+tasks_update([
+  { id: "prepare", title: "Prepare — checkout and gather context", status: "in_progress" },
+  { id: "review", title: "Run review agents", status: "pending" },
+  { id: "post-review", title: "Post review findings", status: "pending" },
+  { id: "assess", title: "Independent assessment", status: "pending" },
+  { id: "post-assess", title: "Post assessment", status: "pending" },
+  { id: "summary", title: "Present CLI summary", status: "pending" }
+])
+```
+
+## Step 2: Parse input
+
+Extract:
+- **PR number** (required)
+- **Review aspects** (optional) — if specified, only run matching agents
+
+## Step 3: Prepare
+
+```bash
+gh pr checkout <pr-number>
+git pull
+```
+
+Mark the PR as ready for review (it was opened as a draft by mach6-plan):
+```bash
+gh pr ready <pr-number>
+```
+
+Gather PR context — read ALL comments, not just specific markers:
+```bash
+gh pr view <pr-number> --json title,body,comments,files
+gh pr diff <pr-number>
+```
+
+Read the PR description, ALL comments (plans, progress updates, prior reviews, discussion), and the linked issue. This full context must be provided to review agents so they understand what was intended and what has already been discussed.
+
+Update task: prepare → completed, review → in_progress.
+
+## Step 4: Select and run review agents
+
+**Available review agents:**
+
+These agents are **pre-existing agent definitions** shipped with dreb — do not redefine them inline. Reference them by name via the `agent` parameter in `subagent`. Each agent definition already specifies a model with a provider fallback list — the defaults work across providers and are fine for most reviews. Override the model only when there's a good reason (e.g. a particularly complex or security-sensitive review warrants a stronger tier); note that a single-string override discards the fallback list, so prefer provider-prefixed IDs (e.g. `anthropic/claude-opus-4-6`) when overriding.
+
+| Agent | Question | When to run |
+|---|---|---|
+| `code-reviewer` | "Does this code do what it should, correctly and idiomatically?" | Always |
+| `error-auditor` | "What can go wrong silently at runtime?" | If error handling / try-catch / fallback logic touched |
+| `test-reviewer` | "What behaviors are untested or poorly tested?" | If test files changed or testable code added |
+| `completeness-checker` | "Does this PR deliver everything the linked issue requires?" | If PR links to an issue |
+| `simplifier` | "Can this be expressed more clearly without changing behavior?" | Always (runs last, after others) |
+
+**Targeted review:** If the user specified aspects, only run matching agents:
+- `code` → code-reviewer
+- `errors` → error-auditor
+- `tests` → test-reviewer
+- `completeness` → completeness-checker
+- `simplify` → simplifier
+
+**For each agent**, launch via the `subagent` tool. Run `code-reviewer`, `error-auditor`, `test-reviewer`, and `completeness-checker` in parallel. Run `simplifier` after the others complete.
+
+Provide each agent with:
+- The list of changed files with paths
+- The PR description and linked issue context
+- Instructions to read the actual changed files for full context
+
+All agents use confidence scoring (0-100, only report findings ≥ 80).
+
+Update task: review → completed, post-review → in_progress.
+
+## Step 5: Post review findings
+
+Compile all findings from all agents into a single structured comment:
+
+```bash
+gh pr comment <pr-number> --body "<!-- mach6-review -->
+## Code Review
+
+### Critical
+<findings with severity: critical, if any>
+
+### Important
+<findings with severity: high, if any>
+
+### Suggestions
+<findings with severity: medium or low, if any>
+
+### Strengths
+<notable positive observations>
+
+**Agents run:** <list of agents>
+
+---
+*Reviewed by mach6*"
+```
+
+Save the review comment URL:
+```bash
+gh pr view <pr-number> --json comments --jq '.comments[-1].url'
+```
+Extract the numeric comment ID from the URL (the number after `issuecomment-`).
+
+Update task: post-review → completed, assess → in_progress.
+
+## Step 6: Independent assessment
+
+Launch a subagent with `agent: "independent-assessor"`. This is a **pre-existing agent definition** shipped with dreb — it has full codebase read access and uses the strongest available model via its own fallback list. The default is fine for most cases.
+
+**Do NOT use the Sandbox agent for this step** — the Sandbox agent has no codebase access and cannot verify findings against actual code.
+
+Provide the assessor with:
+- The full review text
+- The PR context (title, body, comments)
+- Instructions to **read the actual code** for each finding and verify independently
+
+The assessor classifies each finding as:
+- **Genuine issue** — Real problem, should fix before merge. Explain why.
+- **Nitpick** — Stylistic, doesn't affect correctness. Explain why it doesn't matter.
+- **False positive** — Not actually an issue. Explain why the code is correct.
+- **Deferred** — Real issue but out of scope. Should track separately.
+
+If a finding was already addressed in prior commits or PR discussion, classify as false positive with a note.
+
+After classifying all findings, produce an **action plan** listing what to fix, in what order.
+
+**Important guidance on "deferred" classifications:** Test coverage gaps should NOT be automatically deferred. If a PR adds new testable code, tests should ship with it — even if that means adding test infrastructure to a package that lacks it. Only defer tests when the gap is truly unrelated to the PR's changes (e.g., pre-existing untested code that the PR happens to touch). When tests are deferred, the assessor must note whether a tracking issue exists or needs to be created.
+
+Update task: assess → completed, post-assess → in_progress.
+
+## Step 7: Post assessment
+
+```bash
+gh pr comment <pr-number> --body "<!-- mach6-assessment -->
+## Review Assessment
+
+<link to review comment>
+
+### Classifications
+
+| Finding | Classification | Reasoning |
+|---|---|---|
+| <summary> | genuine/nitpick/false-positive/deferred | <1-2 sentences> |
+
+### Action Plan
+
+<numbered list of what to fix, ordered by priority>
+
+---
+*Assessment by mach6*"
+```
+
+Update task: post-assess → completed, summary → in_progress.
+
+## Step 8: CLI summary
+
+Present to the user:
+- Per-finding breakdown: summary, classification, reasoning
+- Counts: genuine, nitpicks, false positives, deferred
+- Action plan
+
+If any findings were classified as **deferred**, ask the user if they want to create issues for them:
+```bash
+gh issue create --title "<title>" --body "<body referencing PR and finding>"
+```
+
+Update task: summary → completed.
+
+Suggest next step:
+- If genuine issues: `/skill:mach6-implement <pr-number> <finding-numbers>`
+- If all clear: `/skill:mach6-publish <pr-number>`

package/skills/telegram-send/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: telegram-send
+description: Send files to the user via Telegram. Use when the user asks you to send, share, or deliver a file to them.
+ui: telegram
+---
+
+# Telegram File Send
+
+When you need to send a file to the user, include this marker in your response:
+
+```
+[[telegram:send:/absolute/path/to/file]]
+```
+
+The Telegram frontend detects this pattern, strips it from the displayed message, and sends the file as a Telegram document attachment.
+
+## When to use
+
+- User asks "send me that file"
+- User asks "share the script you created"
+- User asks to "deliver" or "export" something as a file
+- After creating a file the user explicitly wants sent to them
+
+## Examples
+
+**User:** "Create a Python script and send it to me"
+```
+Here's the script I created.
+
+[[telegram:send:/tmp/hello.py]]
+```
+
+**User:** "Send me my bashrc"
+```
+Here's your bashrc file:
+
+[[telegram:send:/home/drew/.bashrc]]
+```
+
+## Rules
+
+- Use **absolute paths** only
+- The file must exist and be readable
+- Multiple files: include multiple `[[telegram:send:...]]` markers
+- The marker is stripped from the message before display — don't reference it in your text
+- Non-existent paths are silently ignored