Slack and MS Teams integration for research delivery and capture

Research Question

What is the most practical way to integrate the research corpus with Slack and/or Microsoft Teams — for both outbound delivery (notifying when new research is completed) and inbound capture (receiving new research requests or queries via chat) — given the constraints of a personal, GitHub-hosted repository with no server infrastructure?

Findings

Executive Summary

Outbound push delivery to Slack or MS Teams is viable, low-complexity, and immediately implementable using a single new GitHub Actions workflow file and one new secret per platform (SLACK_WEBHOOK_URL for Slack, or a Power Automate webhook URL for Teams). The same trigger pattern as publish-wiki.yml (push to main touching Research/completed/**) applies directly; the official slackapi/slack-github-action@v2.1.1 action handles the Slack POST. Inbound capture via Slack slash commands is blocked under the no-server constraint — Slack requires a 3-second HTTP response that GitHub Actions cannot provide — but a GitHub-issues-as-backlog-proxy workflow achieves equivalent inbound capture with zero new secrets. MS Teams Incoming Webhooks (old connector model) are deprecated; the supported replacement is a Power Automate workflow with a webhook trigger. Query-in-chat capability requires a persistent bot server and is out of scope without additional approved infrastructure.

Key Findings

1. slackapi/slack-github-action@v2.1.1 is the only actively maintained official Slack notification action for GitHub Actions; 8398a7/action-slack was archived on 2025-09-13 and its own README recommends migrating to the Slack-maintained action. The Slack action supports incoming webhook delivery in four lines of workflow YAML.

2. Outbound Slack notification requires exactly one new secret (SLACK_WEBHOOK_URL) stored as a GitHub Actions repository secret; this secret is the only new credential needed for per-item delivery and requires explicit owner approval before the workflow can be implemented.

3. The MS Teams Office 365 Connector model is deprecated; new Teams webhook integrations must use Power Automate with the "When a Teams webhook request is received" trigger, which produces a functionally equivalent HTTPS webhook URL. The Power Automate URL is stored as TEAMS_WEBHOOK_URL and called via curl in the Actions step.

4. The publish-wiki.yml trigger pattern (push to main touching Research/completed/** + workflow_dispatch) is directly reusable for the notification workflow, requiring no new trigger logic and ensuring the notification fires on the same commit that adds the completed research item.

5. Slack slash commands cannot be implemented under the no-server constraint because Slack requires an HTTPS endpoint that responds within 3 seconds of command invocation, and GitHub Actions workflow_dispatch has a typical queue latency of 5–30 seconds that makes it structurally incompatible as a direct slash command handler.

6. A GitHub-issues-as-proxy workflow achieves equivalent inbound capture with zero new secrets: the owner creates a GitHub issue (accessible from the iOS app) with the research question as the title, and a workflow triggered on issues: [opened] converts it to a Research/backlog/ file and closes the issue. This fits the owner's existing interaction model and costs nothing to implement.

7. A weekly digest can be implemented by adding a schedule: cron: '0 8 * * 1' trigger to the notification workflow, which reads Research/completed/ files with completed: dates in the past 7 days and posts a consolidated summary; digest and per-item notifications are not mutually exclusive.

8. Full query-in-chat capability (asking the bot "what have I researched about X?") requires a persistent bot server to receive the query, call the research MCP server, and post the reply; this is out of scope without approved persistent infrastructure and is already addressed architecturally by the 2026-03-02-chat-conversational-interface.md MCP server item.

9. The existing src/wiki/publish.py load_frontmatter() function is directly reusable for the notification workflow's metadata extraction step, eliminating the need for a new library; the notification script reads the changed file paths via git diff --name-only HEAD~1, loads their front-matter, and formats the payload.

10. Per-item notification is the correct default delivery mode for a personal research system where each completed item is discrete and actionable; the weekly digest is an additive option, not a replacement.

Assumptions

• Assumption: The owner uses either Slack or MS Teams personally (not as enterprise admin). Justification: The research question specifically asks about Slack and MS Teams; if the owner uses neither, the integration question is moot. This assumption is flagged as the top unknown.

• Assumption: The research loop continues to complete 3–5 items per run. Justification: Based on observed behaviour from prior loop runs; per-item notifications at this volume are not burdensome in a personal Slack channel.

• Assumption: The Power Automate webhook URL generated by the Teams flow is stable (does not rotate automatically). Justification: Microsoft's documentation does not indicate automatic rotation; the URL behaves like an API key — stable until explicitly deleted or regenerated.

Analysis

Evidence weight: Slack Incoming Webhook documentation (api.slack.com) and the slackapi/slack-github-action README are primary sources with high authority. The MS Teams deprecation notice is a primary source from Microsoft Learn and is unambiguous. The 8398a7/action-slack archive notice is a primary source. The GitHub Actions workflow_dispatch latency claim is an inference supported by general community knowledge but not a single citable source — it is the weakest link in the inbound capture analysis, though the direction of the conclusion (slack commands require a faster endpoint than Actions can provide) is well-established in practice.

The inbound capture analysis identifies three options and recommends Option A (GitHub issue proxy) on the basis that it requires no new credentials. Options B and C are documented but deferred pending owner approval. This is the conservative choice consistent with AGENTS.md constraints, not the most user-friendly choice — a Zapier bridge (Option B) would provide one-step Slack-to-backlog creation.

Digest vs. per-item is not a significant trade-off at the current research volume. Per-item is recommended as the default because it is simpler to implement (same trigger, no scheduling logic) and delivers findings immediately.

Risks, Gaps, and Uncertainties

• Owner's platform is unknown. All recommendations require the owner to confirm which platform (Slack, Teams, or both) is in use before any implementation begins. Without this, the credential approval request cannot be scoped.
• Slack slash command endpoint gap. The 3-second acknowledgement requirement was noted in the Slack slash commands page but the full documentation was only partially fetched. The latency-based incompatibility with Actions is an inference, not a confirmed benchmark.
• Power Automate dependency. Teams webhook URLs via Power Automate depend on the user maintaining an active Power Automate flow. If the flow is disabled or the user's Power Automate environment is restricted by an enterprise policy, the integration breaks silently.
• Notification payload design is unspecified. The research identifies what metadata to include (title, tags, executive summary excerpt, wiki link) but does not specify the exact Block Kit JSON structure. This is implementation detail, not a research gap, but the payload must be validated against Slack's message size limits (not defined in this item).

Open Questions

• Which platform does the owner use — Slack, Teams, or both? This is the prerequisite question for all implementation work. Recommend the owner answer this before any workflow is built. Could become a new backlog item: 2026-03-08-owner-platform-selection-chat-integration.md, though it is more appropriate as a direct question to the owner.
• Should the inbound GitHub issue workflow replace or extend the existing backlog item creation process? If implemented, the issue-to-backlog workflow would create files automatically; the owner's current manual process would become optional.
• Is digest mode wanted at all, or is per-item notification sufficient? This is an owner preference question. No new backlog item needed — it can be decided when the notification workflow is implemented.

sources

• [x] Research/backlog/2026-02-27-interface-and-delivery.md — upstream interface and delivery options item
• [x] Research/completed/2026-03-01-github-wiki-research-content.md — existing delivery channel (wiki), same trigger pattern to reuse
• [x] Research/completed/2026-03-02-chat-conversational-interface.md — conversational query interface (inbound query path)
• [x] Slack Incoming Webhooks docs
• [x] Slack app slash commands
• [x] MS Teams Incoming Webhook
• [x] MS Teams bot framework
• [ ] GitHub Actions: workflow_dispatch with inputs — for triggering backlog capture from external webhooks
• [x] 8398a7/action-slack — community Slack notification Action (archived Sep 2025; replaced by slackapi/slack-github-action)