@staff0rd/assist 0.606.1 → 0.608.0

package/README.md

@@ -65,6 +65,7 @@ After installation, the `assist` command will be available globally. You can als
 - `/github [action] [ref] [args]` - GitHub issue actions: `view`, `edit`, `associate`, `update`, `started`, `done`, `help`. `[ref]` is optional — it resolves from the session's backlog item. A bare `/github <ref>` runs `edit`, which opens the issue in the web preview pane; outside a web session the command prints the issue to chat instead
 - `/journal` - Append a journal entry summarising recent work
 - `/next [id]` - Signal completion and chain into the next backlog item
+- `/slack-post <channel> <what to say>` - Compose a markdown message, preview it in the web pane via `assist slack post`, then post the approved body to that Slack channel with the Slack MCP connector and report the permalink
 - `/standup` - Summarise recent journal entries as a standup update
 - `/subtask <text>` - Add a sub-task to the session's current backlog item
 - `/strip-code-comments` - Strip redundant comments from tracked source files
@@ -137,7 +138,7 @@ Every command supports `--help` for full detail on its flags and behaviour.
   - `--announce` - Announce the PR in Slack (`/prs-slack <n> --no-confirm`) at the tail of the chain: the Address Comments session announces once every thread is processed when one was started, otherwise a `/prs-slack` session is started directly. Announces exactly once, and only inside an assist session
   - `--verbose` - Per-line log output instead of the stacked-spinner UI (automatic in CI)
 - `assist github commits <org> [--since <date>] [--top <n>] [--json]` - Report commit activity across a GitHub organisation: repos ranked by commits, top committers, and a per-repo author breakdown
-- `assist github issue create --title <title> --body <body> [-R <owner>/<repo>] [--type <name>] [--project <number>] [--status <name>] [--label <name>]` - Create a GitHub issue on the current repo (or `-R`'s). There is no What/Why/How template — an issue reports a problem, and the target repo's own issue template is unknowable from here. The title and body are rejected if they reference Claude or an assist backlog item, and in a web session they are previewed for approve/reject first (with inline comments); nothing is created until it is approved. `--type` sets the native issue type after creation, `--project` adds the issue to the repo owner's project of that number, `--status` sets that project item's Status, and `--label` applies repo labels (repeat the flag or pass a comma-separated list). All four are resolved before the preview — including the token's `project` OAuth scope, whose remediation is `gh auth refresh -h github.com -s project` — so an unknown name, a missing scope, or `--status` without `--project` creates nothing. The preview pane names the repo, type, project, status and labels above the body without adding them to the posted body. Raw `gh issue create` is denied in favour of this command
+- `assist github issue create --title <title> --body <body> [-R <owner>/<repo>] [--type <name>] [--parent <issue>] [--project <number>] [--status <name>] [--label <name>]` - Create a GitHub issue on the current repo (or `-R`'s). There is no What/Why/How template — an issue reports a problem, and the target repo's own issue template is unknowable from here. The title and body are rejected if they reference Claude or an assist backlog item, and in a web session they are previewed for approve/reject first (with inline comments); nothing is created until it is approved. `--type` sets the native issue type after creation, `--parent` files the new issue as a sub-issue of the referenced issue (`owner/repo#number`, a github.com issue URL, or a bare number read against `--repo` or the current repo; a parent in another repository is allowed), `--project` adds the issue to the repo owner's project of that number, `--status` sets that project item's Status, and `--label` applies repo labels (repeat the flag or pass a comma-separated list). All five are resolved before the preview — including the token's `project` OAuth scope, whose remediation is `gh auth refresh -h github.com -s project` — so an unknown name, an unreadable parent, a missing scope, or `--status` without `--project` creates nothing. The preview pane names the repo, type, parent, project, status and labels above the body without adding them to the posted body. Raw `gh issue create` is denied in favour of this command
 - `assist github issue edit <number> [-R <owner>/<repo>] [--fresh]` - Rework an existing GitHub issue's body in the web preview pane. Fetches the issue's current `title`, `body` and `updatedAt` with `gh issue view`, writes the body to a working file under `~/.assist/github-issues/`, and previews it for approve/reject. Approving pushes the pane's markdown back with `gh issue edit --body-file`; nothing is pushed if the issue was updated on GitHub after it was fetched (the working file is named instead, so nobody else's edit is clobbered) or if the preview is rejected. Rejecting writes the pane's markdown — collapses included — to the working file and names it in the output, so the revision is made in that file rather than composed from scratch; a re-run resumes from the working file while the issue has not moved on GitHub, and `--fresh` discards it and re-fetches. Outside a web session there is no pane to edit in, so the command just prints the issue — callers never need to detect the session themselves. Only the body is touched — the title, labels, assignees and state are left alone
 - `assist github issue comment <number> --body <body> [-R <owner>/<repo>]` - Comment on a GitHub issue on the current repo (or `-R`'s); a body of `-` reads it from stdin. The body is rejected if it references Claude or an assist backlog item, and in a web session it is previewed for approve/reject first (with inline comments); nothing is posted until it is approved. Raw `gh issue comment` is denied in favour of this command
 - `assist github issue fix-structure <target> [-R <owner>/<repo>] [--level <level>] [--type-chain <names>] [--strip-label <label>...] [--apply]` - Normalise the issue types across one issue subtree, reading and writing nothing outside it. `<target>` is `owner/repo#number`, a github.com issue URL, or a bare number with `-R`; a bare number with no repo is refused rather than guessed. Walks the subtree via sub-issues level by level (a single deep query blows the GraphQL node limit) and reports the type each issue should carry: every level below the target is typed to the next level down the chain, matching type names loosely so `Subtask` and `Sub-task` both bind to the leaf. The chain defaults to `Epic` > `Story` > `Subtask`; `--type-chain Initiative,Feature,Task` replaces it, parent level first, and every level named must already exist as an issue type on the organisation or the run fails listing the ones that do. Untyped issues are typed rather than skipped, and cross-repo children are handled in the one run. The target's own level is inferred from its issue type, so aiming at a story types its children as subtasks; when its type is not in the chain the level cannot be inferred and the command exits non-zero naming the type it has. `--level` asserts the position instead, which also types the target itself. No label is touched unless `--strip-label` names it; it is repeatable, matched case-insensitively, and each label is removed by the id found on that issue, since label ids differ per repository. Anything nested below the leaf level fails the run before a single write, naming the offender and its parent; nothing is ever re-parented. Without `--apply` nothing is written. `--apply` announces each write before it is issued and flushes it, so a long run shows progress, then re-walks the subtree and fails with a non-zero exit if any drift remains
@@ -296,6 +297,7 @@ The Config tab of the sessions web dashboard never receives secret values: `GET
 - `assist seq auth remove <name>` - Remove a configured connection
 - `assist seq set-connection <name>` - Set the default Seq connection
 - `assist seq query <filter>` - Query Seq events (`-c <connection>`, `--json`, `-n <count>`, `--from <date>`, `--to <date>`)
+- `assist slack post <channel> --body <body|->` - Preview a markdown message bound for a Slack channel; `--body -` reads it from stdin. Posting is MCP-only, so the command never posts: in an assist web session it renders the markdown in the preview pane for approve/reject (with inline comments), and on approval writes the approved body — including any edit made in the pane — to a working file under `~/.assist/slack/`, printing its path on the last line for `/slack-post` to send. On rejection it exits non-zero with the reason and any inline comments, leaving the previewed markdown in that working file to revise in place and re-preview. Outside a web session there is no preview and the body passes straight through
 - `assist sql auth add` - Add a new MSSQL connection
 - `assist sql auth list` - List configured SQL connections
 - `assist sql auth remove <name>` - Remove a configured connection

package/claude/commands/slack-post.md

@@ -0,0 +1,37 @@
+---
+description: Preview a markdown message, then post it to a Slack channel
+allowed_args: "<channel> <what to say>"
+---
+
+Post a message to Slack on the user's behalf. `assist slack post` owns the preview and the approval; you own composing the markdown and sending it.
+
+`$ARGUMENTS` is the target channel — `#name`, a bare name, or a channel id — followed by what the message should say. If the channel is missing, ask for it before composing anything.
+
+## Step 1: compose the message
+
+Write the message as standard markdown. `slack_send_message` renders bold, italic, code, strikethrough, blockquotes, lists, links, code blocks (with a language specifier), tables and headers as they are, capped at 5000 characters — so no conversion to Slack's `*bold*` dialect, and no `<url|text>` links.
+
+State only the confirmed conclusion and the facts behind it. No hedging, no speculative next steps, no pleasantries. Match the scope of what was asked.
+
+Write it to a scratch file with the Write tool rather than inlining it in a shell command — the markdown will contain quotes, backticks and newlines.
+
+## Step 2: preview it
+
+```
+assist slack post '<channel>' --body - < <scratch file>
+```
+
+In an assist web session this renders the markdown in the preview pane for approve/reject. The command posts nothing either way.
+
+- **Approved** — the last line of stdout is the path to the approved body under `~/.assist/slack/`. That file, not your scratch file, is what gets posted: it carries any edit made in the pane.
+- **Rejected** — the command exits non-zero with the reason and any inline comments, and names the same working file. Address every comment, rewrite that file in place, and re-run the preview against it (`assist slack post '<channel>' --body - < <working file>`). Do not post, and do not recompose the message from scratch.
+
+Outside a web session there is no pane: the body passes straight through and the working file is written immediately.
+
+## Step 3: post it
+
+Read the approved body from the path the command printed, then:
+
+1. Resolve the channel to its id with `mcp__claude_ai_Slack__slack_search_channels`, passing `channel_types: "public_channel,private_channel"` so private channels resolve too. If the query returns no match, or more than one plausible match, stop and ask the user which channel to use — do not guess.
+2. Post the file's contents verbatim with `mcp__claude_ai_Slack__slack_send_message` (`channel_id`, `message`). Use `slack_send_message`, not `slack_send_message_draft`: the preview pane is the user's review.
+3. Report the permalink it returns.

package/claude/settings.json

@@ -98,6 +98,8 @@
 			"SlashCommand(/subtask)",
 			"Skill(miro)",
 			"SlashCommand(/miro)",
+			"Skill(slack-post)",
+			"SlashCommand(/slack-post)",
 			"Bash(git ls-files:*)",
 			"Bash(gh pr checks:*)",
 			"Bash(ls ~/.assist/pr-comments:*)",