opencastle 0.32.5 → 0.32.6

package/src/orchestrator/plugins/slack/SKILL.md

@@ -15,95 +15,55 @@ Agent communication patterns via the Slack MCP server. Enables agents to post pr
 |-------|-------|
 | **Package** | [`@kazuph/mcp-slack`](https://www.npmjs.com/package/@kazuph/mcp-slack) |
 | **Type** | stdio (spawned via `npx -y @kazuph/mcp-slack`) |
-| **Auth** | Bot token (`xoxb-…`) via `SLACK_MCP_XOXB_TOKEN` env var (loaded from `.env` or `envFile`) |
-| **Extra env** | `SLACK_MCP_ADD_MESSAGE_TOOL=true` — enables the `conversations_add_message` tool |
-| **Supported clients** | VS Code, Claude Code, Cursor, any MCP-compatible client with stdio support |
+| **Auth** | Bot token (`xoxb-…`) via `SLACK_MCP_XOXB_TOKEN` env var |
+| **Extra env** | `SLACK_MCP_ADD_MESSAGE_TOOL=true` — enables `conversations_add_message` |
 
 ### Authentication
 
-The `@kazuph/mcp-slack` server supports multiple token types (only one is needed):
+Use a **bot token** (`SLACK_MCP_XOXB_TOKEN`). For message search, a user token (`xoxp-…`) via `SLACK_MCP_XOXP_TOKEN` is required instead.
 
-| Env Variable | Token Type | Notes |
-|-------------|------------|-------|
-| `SLACK_MCP_XOXB_TOKEN` | Bot token (`xoxb-…`) | Limited to invited channels only, no search |
-| `SLACK_MCP_XOXP_TOKEN` | User OAuth token (`xoxp-…`) | Full access, requires OAuth app setup |
-| `SLACK_MCP_XOXC_TOKEN` + `SLACK_MCP_XOXD_TOKEN` | Browser tokens | "Stealth mode" — no app install needed |
-
-This project uses a **bot token** (`SLACK_MCP_XOXB_TOKEN`). Add these under **Bot Token Scopes** in the Slack app configuration:
+**Bot Token Scopes:**
 
 | Scope | Purpose |
 |-------|---------|
 | `chat:write` | Post messages and replies |
-| `channels:read` | List public channels and their metadata |
-| `channels:history` | Read messages in public channels |
-| `channels:manage` | Create/rename channels, set topics (optional) |
-| `groups:read` | List private channels |
-| `groups:history` | Read messages in private channels |
-| `im:read` | List direct message conversations |
-| `im:history` | Read direct messages |
-| `mpim:read` | List group DM conversations |
-| `mpim:history` | Read group DMs |
-| `users:read` | Look up user profiles |
-| `users:read.email` | Look up user emails |
-
-> **Note:** `channels:manage` is optional — only needed if agents should create channels or rename them. Without it, `conversations_create` and `conversations_rename` will return `missing_scope`.
-> 
-> **Note:** Bot tokens cannot search messages. If search is needed, use a user token (`xoxp-…`) instead.
-
-Admin approval is required. Work with the workspace admin to install the app.
+| `channels:read`, `channels:history` | List and read public channels |
+| `groups:read`, `groups:history` | List and read private channels |
+| `im:read`, `im:history`, `mpim:read`, `mpim:history` | DMs and group DMs |
+| `users:read`, `users:read.email` | Look up user profiles and emails |
+| `channels:manage` | Create/rename channels (optional) |
 
 ## Available MCP Tools
 
-The Slack MCP server exposes the following tools (prefixed with `mcp_slack_` in VS Code / Copilot):
-
 ### Channel Management
 
-| Tool | Description | Key Parameters |
-|------|-------------|----------------|
-| `channels_list` | List workspace channels | `channel_types` (public/private), `limit`, `cursor` |
-| `conversations_create` | Create a new channel | `name` (required). Needs `channels:manage` scope |
-| `conversations_rename` | Rename a channel | `channel_id`, `name`. Needs `channels:manage` scope |
-| `conversations_set_topic` | Set a channel's topic | `channel_id`, `topic` |
-| `conversations_invite` | Invite user(s) to a channel | `channel_id`, `users` (comma-separated user IDs) |
+`channels_list`, `conversations_create`, `conversations_rename`, `conversations_set_topic`, `conversations_invite`
 
 ### Messaging
 
 | Tool | Description | Key Parameters |
 |------|-------------|----------------|
-| `conversations_add_message` | Post a message to a channel or thread | `channel_id` (ID or name), `payload` (message text), `content_type` (`text/markdown` or `text/plain`, default: `text/markdown`), `thread_ts` (optional, for threading) |
-| `conversations_history` | Read recent messages from a channel | `channel_id`, `limit` (time range like `1d`/`7d`/`30d` or message count like `50`), `cursor` |
-| `conversations_replies` | Get replies in a thread | `channel_id`, `thread_ts`, `limit`, `cursor` |
-| `conversations_search_messages` | Search messages across channels | `search_query`, `filter_in_channel`, `filter_users_from`, `filter_date_before`/`after`/`on`/`during`, `limit` (1-100) |
+| `conversations_add_message` | Post a message to a channel or thread | `channel_id`, `payload`, `content_type` (`text/markdown`), `thread_ts` |
+| `conversations_history` | Read recent messages from a channel | `channel_id`, `limit` (e.g. `1d`, `50`) |
+| `conversations_replies` | Get replies in a thread | `channel_id`, `thread_ts`, `limit` |
+| `conversations_search_messages` | Search messages across channels | `search_query`, `filter_in_channel`, `filter_date_*` |
 
 ### Users
 
-| Tool | Description | Key Parameters |
-|------|-------------|----------------|
-| `users_resolve` | Look up a user by name or email | Returns user ID for mentions |
-
-### Channel ID Resolution
-
-The `channel_id` parameter in messaging tools accepts:
-- **Channel ID** — e.g., `C0AHAQFJ7C1` (most reliable)
-- **Channel name** — e.g., `new-channel` (without `#` prefix)
-
-When a channel name is ambiguous or not found, use `channels_list` first to get the correct ID.
+`users_resolve` — look up a user by name or email; returns user ID for mentions.
 
-### Key Differences from Documented Slack Web API
+### Key Differences from Slack Web API
 
 - Tool names use `conversations_*` pattern, not `chat.postMessage` etc.
 - Message body is sent via `payload` parameter, not `text`
 - Message posting is **disabled by default** — requires `SLACK_MCP_ADD_MESSAGE_TOOL=true` env var
 - `limit` on history/replies accepts time ranges (`1d`, `7d`, `30d`) or message counts (`50`)
-- No reaction tools — reactions are not available via this MCP server
-- No canvas tools — canvases are not exposed
+- No reaction tools or canvas tools available via this MCP server
 
 ## Agent Notification Patterns
 
 ### Progress Updates
 
-Post structured progress updates to a designated channel:
-
 ```
 Channel: #agent-updates (or project-specific channel)
 Format:
@@ -113,29 +73,11 @@ Format:
   **ETA:** ~5 minutes
 ```
 
-### Completion Notifications
-
-```
-✅ **Task:** TAS-42 — Add price filter component
-**Status:** Complete — PR opened
-**PR:** https://github.com/org/repo/pull/123
-**Summary:** Added PriceRangeFilter with 4 range options, 12 unit tests passing
-```
-
-### Error / Blocking Notifications
-
-```
-🚨 **Task:** TAS-42 — Add price filter component
-**Status:** Blocked — needs human input
-**Issue:** Cannot determine correct price ranges for the market
-**Action needed:** Reply in this thread with the desired price range values
-```
-
 ## Bi-Directional Communication
 
 ### Dual-Channel Approval Pattern
 
-Approval requests are always **dual-channel** — posted to Slack AND asked in the chat window. The first response (from either channel) wins.
+Approval requests are always **dual-channel** — posted to Slack AND asked in the chat window. The first response wins.
 
 ```
 Agent needs approval
@@ -150,8 +92,6 @@ Agent needs approval
        (immediate, no polling needed)
 ```
 
-**Why dual-channel:** The chat path is instant (user's next message is the answer). The Slack path covers the case where the user is away from VS Code (mobile, another machine) and wants to unblock the agent remotely.
-
 ### Approval Flow
 
 1. **Post to Slack** with a structured approval request:
@@ -166,40 +106,13 @@ Agent needs approval
    💬 Or reply with questions
    ```
 
-2. **Ask in chat** — Yield to the user with the same question so they can respond directly in the chat window.
-
-3. **If the user responds in chat** — The agent receives the answer immediately. Post confirmation to the Slack thread:
-   ```
-   ✅ Approved via VS Code chat. Proceeding.
-   ```
-
-4. **If waiting for Slack reply** — While the agent has non-blocked work, poll every 30 seconds:
-   - Use `conversations_replies` with the message's `thread_ts`
-   - Continue with independent subtasks between polls
-   - When a reply arrives, parse it and proceed
-
-5. **If session ends before reply** — Save to checkpoint (see session-checkpoints skill):
-   ```markdown
-   ## Pending Approvals
-   | Provider | Channel | Thread ID | Question | Posted At |
-   |----------|---------|-----------|----------|-----------|
-   | slack | C0AHAQFJ7C1 | 1772393542.345149 | Run migration on production? | 2026-03-01 14:30 |
-   ```
-   The next session's `on-session-start` hook checks for replies.
-
-### Reading User Responses
-
-To check for approvals or instructions:
+2. **Ask in chat** — Yield to the user with the same question so they can respond directly.
 
-1. Use `conversations_replies` with the `thread_ts` of the approval message to read replies
-2. Use `conversations_history` with `oldest`/`latest` time range to find recent directives
-3. Thread replies are the primary mechanism — reactions are not available via MCP
+3. **If the user responds in chat** — Post confirmation to the Slack thread: `✅ Approved via VS Code chat. Proceeding.`
 
-### Resolution Rule
+4. **If waiting for Slack reply** — Poll every 30 seconds using `conversations_replies` with the message's `thread_ts`. Continue independent subtasks between polls.
 
-- **First response wins** — whether from chat or Slack
-- **Cross-post confirmation** — when answered in one channel, post confirmation to the other
-- **Conflicting responses** — if both arrive simultaneously, prefer the chat response (it's more intentional)
+5. **If session ends before reply** — Save to checkpoint with channel, thread ID, question, and timestamp. The next session's `on-session-start` hook checks for replies.
 
 ### Parsing Conventions
 
@@ -211,22 +124,11 @@ To check for approvals or instructions:
 | Thread reply with detailed text | Instructions or questions |
 | `@agent` mention | Direct command or question for the agent |
 
-> **Note:** Reactions (emoji responses) are not available via the Slack MCP server. Use thread replies for all approval workflows.
+> **Note:** Reactions are not available via the Slack MCP server. Use thread replies for all approval workflows.
 
 ## Channel & Thread Conventions
 
-### Channel Configuration
-
-Project-specific channel mappings are defined in `.opencastle/stack/notifications-config.md`. Agents read that file to determine which channel to post to for each event type. Always prefer channel IDs from the config over hardcoded names.
-
-### Default Channel Structure
-
-| Channel | Purpose |
-|---------|---------|
-| `#agent-updates` | General agent activity feed |
-| `#agent-approvals` | Approval requests requiring human action |
-| `#agent-errors` | Error reports and blocked tasks |
-| Project-specific channel | All activity for a specific project |
+Project-specific channel mappings are defined in `.opencastle/stack/notifications-config.md`. Always prefer channel IDs from the config over hardcoded names.
 
 ### Threading Rules
 
@@ -235,79 +137,15 @@ Project-specific channel mappings are defined in `.opencastle/stack/notification
 - **Include task ID** — every message references the tracker issue ID
 - **Pin important threads** — pin approval requests and blocking issues
 
-## Message Formatting
-
-Slack uses a markdown-like syntax with some differences:
-
-| Format | Syntax |
-|--------|--------|
-| Bold | `*bold*` |
-| Italic | `_italic_` |
-| Strikethrough | `~strikethrough~` |
-| Code | `` `inline code` `` |
-| Code block | ` ```code block``` ` |
-| Link | `<https://example.com|Display Text>` |
-| User mention | `<@U12345>` |
-| Channel mention | `<#C12345>` |
-| Emoji | `:emoji_name:` |
-| Blockquote | `> quoted text` |
-| List | `• item` or `1. item` |
-
 ## Rate Limits
 
-| Tier | Limit | Applies to |
-|------|-------|------------|
-| Tier 1 | 1 per minute | Rare admin actions |
-| Tier 2 | 20 per minute | Most write operations (`chat:write`) |
-| Tier 3 | 50 per minute | Most read operations |
-| Tier 4 | 100+ per minute | Search, history reads |
-
-**Best practices:**
+Write ops are Tier 2 (20/min); read ops Tier 3 (50/min). Best practices:
 - Batch updates into single messages rather than posting many small messages
 - Use threads to consolidate related updates
-- Add 1-second delays between consecutive write operations
 - Cache channel/user IDs — don't look them up repeatedly
 
 ## Security Considerations
 
-- **Bot tokens** are passed via `SLACK_MCP_XOXB_TOKEN` env var (in `.env` file) — never hardcode in config files or commit to git
-- **Scope minimization** — request only the scopes agents actually need (omit `channels:manage` if agents shouldn't create channels)
-- **Channel restrictions** — limit the bot to specific channels rather than granting workspace-wide access
-- **Audit logging** — Slack Enterprise Grid provides audit logs for all API activity
-- **No secrets in messages** — never post tokens, passwords, or credentials in Slack messages (per Constitution #1)
-
-## Integration with Agent Workflows
-
-### Session Start
-
-At the beginning of a work session, post a brief status message:
-```
-🏁 **Session started**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Mode: Autonomous (will request approval for destructive actions)
-```
-
-### Session End
-
-At the end of a work session, post a summary:
-```
-🏁 **Session complete**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Result: ✅ PR opened (#123)
-Duration: 12 minutes
-Files changed: 5
-Tests: 12 passing, 0 failing
-```
-
-### Error Recovery
-
-If an agent encounters an unrecoverable error, notify before stopping:
-```
-💥 **Session failed**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Error: TypeScript compilation failed — 3 type errors in PriceFilter.tsx
-Action: Posted details in thread. Needs manual fix or re-delegation.
-```
+- **Bot tokens** are passed via `SLACK_MCP_XOXB_TOKEN` env var — never hardcode in config files or commit to git
+- **Scope minimization** — request only the scopes agents actually need
+- **No secrets in messages** — never post tokens, passwords, or credentials in Slack messages

package/src/orchestrator/plugins/teams/SKILL.md

@@ -26,26 +26,14 @@ Agent communication patterns via the Microsoft Teams MCP server (Microsoft Agent
 3. **Graph API permissions:** `McpServers.Teams.All` (delegated or application)
 4. **Admin consent** for the registered app
 
-> **Note:** The Teams MCP server is in preview and not yet generally available as a standalone endpoint. Features and availability may change.
-
 ## Available MCP Tools
 
-The Teams MCP server exposes tools for:
-
-- **Chats** — Create, list, read, update, delete chats
-- **Messages** — Send, read, edit, delete messages in chats and channels
-- **Channels** — List, create, manage channel settings
-- **Members** — List, add, remove members from chats and channels
-- **Teams** — List teams, get team details, manage team settings
-
-Tool names follow the pattern `teams_<resource>_<action>`. Use tool discovery to list available tools at runtime.
+Tool names follow `teams_<resource>_<action>`. Covers: chats, messages, channels, members, and team settings. Use tool discovery to list available tools at runtime.
 
 ## Agent Notification Patterns
 
 ### Progress Updates
 
-Post structured progress updates to a designated channel:
-
 ```
 Channel: Agent Updates (or project-specific channel)
 Format:
@@ -55,52 +43,21 @@ Format:
   **ETA:** ~5 minutes
 ```
 
-### Completion Notifications
-
-```
-✅ **Task:** TAS-42 — Add price filter component
-**Status:** Complete — PR opened
-**PR:** https://github.com/org/repo/pull/123
-**Summary:** Added PriceRangeFilter with 4 range options, 12 unit tests passing
-```
-
-### Error / Blocking Notifications
-
-```
-🚨 **Task:** TAS-42 — Add price filter component
-**Status:** Blocked — needs human input
-**Issue:** Cannot determine correct price ranges for the market
-**Action needed:** Reply in this thread with the desired price range values
-```
+## Human-in-the-Loop Approval
 
-## Bi-Directional Communication
-
-### Human-in-the-Loop Approval
-
-When an agent needs approval before proceeding:
-
-1. **Post approval request** to the channel with clear instructions:
+1. **Post approval request** to the channel:
    ```
    ⏳ **Approval Required**
    Task: TAS-42 — Database migration adds `price_range` column
    Action: Run migration on production database
-   
+
    Reply with:
    ✅ Approve — to proceed
    ❌ Reject — to stop
    Or reply with questions/comments
    ```
-
-2. **Poll for response** — Read replies to determine the decision
-3. **Acknowledge** — Post confirmation of the action taken
-
-### Reading User Responses
-
-To check for approvals or instructions:
-
-1. Read message replies in the channel or chat thread
-2. Parse reply content for approval keywords (`approve`, `approved`, `yes`, `proceed`, `reject`, `no`, `stop`)
-3. Check for reactions on messages (Teams supports reactions via Graph API)
+2. **Poll for response** — Read replies to determine the decision.
+3. **Acknowledge** — Post confirmation of the action taken.
 
 ### Parsing Conventions
 
@@ -114,15 +71,6 @@ To check for approvals or instructions:
 
 ## Channel & Chat Conventions
 
-### Channel Structure
-
-| Channel | Purpose |
-|---------|---------|
-| Agent Updates | General agent activity feed |
-| Agent Approvals | Approval requests requiring human action |
-| Agent Errors | Error reports and blocked tasks |
-| Project-specific channel | All activity for a specific project |
-
 ### Threading Rules
 
 - **Always reply in threads** — use message replies, not top-level posts for follow-ups
@@ -130,33 +78,11 @@ To check for approvals or instructions:
 - **Include task ID** — every message references the tracker issue ID
 - **Mark important messages** — use importance flags for approval requests
 
-### Chat vs Channel
-
-| Use Case | Preferred |
-|----------|-----------|
-| Team-wide updates | Channel |
-| Approval requests | Channel (for visibility) |
-| Direct questions | 1:1 or group chat |
-| Sensitive discussions | 1:1 chat |
-
 ## Message Formatting
 
-Teams messages support HTML and a subset of Markdown:
-
-| Format | Syntax |
-|--------|--------|
-| Bold | `**bold**` or `<strong>bold</strong>` |
-| Italic | `*italic*` or `<em>italic</em>` |
-| Code | `` `inline code` `` |
-| Code block | ` ```code block``` ` |
-| Link | `[Display Text](https://example.com)` |
-| User mention | `<at>User Name</at>` (requires user ID in adaptive card) |
-| List | `- item` or `1. item` |
-| Heading | `### Heading` |
-
 ### Adaptive Cards
 
-For richer formatting, Teams supports Adaptive Cards (JSON-based card format):
+For richer formatting, use Adaptive Cards (JSON-based):
 
 ```json
 {
@@ -178,74 +104,18 @@ Use Adaptive Cards for approval workflows when available — they provide struct
 
 ## Rate Limits
 
-Microsoft Graph API rate limits for Teams:
-
-| Resource | Limit |
-|----------|-------|
-| Messages (per app per tenant) | 50 per second |
-| Channel messages | 50 per second |
-| Chat creation | 50 per second |
-| Individual API calls | 10,000 per 10 minutes |
+Microsoft Graph API: 50 messages/second per app per tenant; 10,000 individual API calls per 10 minutes.
 
 **Best practices:**
 - Batch updates into single messages rather than posting many small messages
-- Use threads to consolidate related updates
 - Cache team/channel/user IDs — don't look them up repeatedly
-- Respect 429 (Too Many Requests) responses with retry-after headers
 
 ## Security Considerations
 
 - **OAuth tokens** are managed by the MCP server — agents never see raw tokens
 - **Scope minimization** — request only the Graph API permissions agents actually need
-- **Tenant restrictions** — configure the app for single-tenant or specific tenant access
-- **Conditional Access** — Microsoft Entra Conditional Access policies apply to API calls
-- **Audit logging** — Microsoft 365 audit logs capture all Graph API activity
-- **No secrets in messages** — never post tokens, passwords, or credentials in Teams messages (per Constitution #1)
-- **Data residency** — Teams data is stored in the tenant's Microsoft 365 region
-
-## Integration with Agent Workflows
-
-### Session Start
-
-At the beginning of a work session, post a brief status message:
-```
-🏁 **Session started**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Mode: Autonomous (will request approval for destructive actions)
-```
-
-### Session End
-
-At the end of a work session, post a summary:
-```
-🏁 **Session complete**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Result: ✅ PR opened (#123)
-Duration: 12 minutes
-Files changed: 5
-Tests: 12 passing, 0 failing
-```
-
-### Error Recovery
-
-If an agent encounters an unrecoverable error, notify before stopping:
-```
-💥 **Session failed**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Error: TypeScript compilation failed — 3 type errors in PriceFilter.tsx
-Action: Posted details in thread. Needs manual fix or re-delegation.
-```
+- **No secrets in messages** — never post tokens, passwords, or credentials in Teams messages
 
 ## Preview Limitations
 
-Since the Teams MCP server is in Frontier preview:
-
-- **Availability** may change without notice
-- **Tool surface** may be incomplete compared to the full Graph API
-- **Performance** may vary during preview
-- **Breaking changes** are possible between preview versions
-
-Check [Microsoft Agent 365 documentation](https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/) for the latest status.
+The Teams MCP server is in Frontier preview — availability and tool surface may change without notice. Check [Microsoft Agent 365 documentation](https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/) for the latest status.

package/src/orchestrator/plugins/vitest/SKILL.md

@@ -158,9 +158,9 @@ export default defineConfig({
 - Use `describe` blocks to group related tests
 - Each test should be independent — no shared mutable state between tests
 - Clean up mocks with `vi.restoreAllMocks()` in `afterEach`
-- Use `vi.mock()` at the top level — Vitest hoists mock calls automatically
+- Mock dependencies before imports — `vi.mock()` calls are hoisted automatically but declare them at the top for clarity
 - Prefer `toEqual` for objects, `toBe` for primitives
 - Use `test.each` for parameterized tests
 - Set coverage thresholds to prevent regression
 - Use `vi.useFakeTimers()` for time-dependent code — never `setTimeout` in tests
-- Use `--reporter=json` in CI for machine-readable output
+- Aim for 3-5 focused tests per file for maintainability — split large test suites