Skip to content

Work Wingman Intake pilot onboarding

Purpose and boundaries

FLT-75 accepts requests, asks bounded clarification questions, records provenance, and prepares a Jira/Confluence handoff. It is a pilot intake service, not an autonomous executor. The production dispatch adapter remains disabled until FLT-80 preconditions are met.

Use one approved Slack channel, #work-wingman-intake, and one dedicated AgentMail mailbox. The pilot supports channel messages and @Work Wingman Intake mentions there, reactive direct messages from an approved requester, and /wingman [your request].

Slack OAuth scopes and event subscriptions are workspace-wide capabilities; Slack cannot restrict message.channels or app_mention to one channel in the manifest. The application must reject every channel event whose stable ID is not SLACK_INTAKE_CHANNEL_ID, before storing, replying to, or handing it off. The manifest deliberately excludes private-channel, file, and user-directory scopes. im:read is also excluded because reactive DMs do not need the app to list or open DM conversations.

Before inviting anyone

  1. Deploy the Slack manifest in deployment/slack-app-manifest.yaml through the Slack app-management UI. Install it only to the pilot workspace.
  2. Enable Socket Mode and create the app-level token. Store the token as SLACK_APP_TOKEN; store the bot token as SLACK_BOT_TOKEN. Do not publish either token.
  3. Create the public channel #work-wingman-intake, record its stable ID as SLACK_INTAKE_CHANNEL_ID, and invite the bot. Do not add the bot to unrelated channels.
  4. Configure the pilot requester IDs as SLACK_ALLYSON_USER_ID and SLACK_SHEREEBA_USER_ID. Display names are not authorization. Configure ProactiveDirectMessagesEnabled as false, the STOP keyword, and the America/Chicago quiet-hours window before enablement.
  5. Complete the AgentMail setup in agentmail-mcp-websocket.md, then set the mailbox, MCP, and WebSocket configuration references.
  6. Add the intake entry point to the approved Google Site. The site should state: where to submit, that the pilot asks clarification questions, which requesters are authorized, and that work does not begin until confirmation and dispatch approval.
  7. Configure Jira project key and Confluence space key through deployment/founder-intake.settings.example.json. Use service identities with the smallest permissions needed to create/update only pilot artifacts. Do not enable creation until dry-run verification is signed off.
  8. Review rollback-kill-switch.md with the pilot operator before enablement.

Pilot group: Allyson, Shereeba, and Nick

Allyson and Shereeba — requesters

  1. Join the approved intake Slack channel and use the Google Site entry point or a new channel message to submit one request at a time.
  2. Include outcome, audience, deadline, constraints, relevant links, and what a successful result looks like. Do not paste passwords, API keys, customer secrets, health information, or other sensitive data.
  3. Answer the broker's clarification questions in the same thread. You may also start an intake with /wingman [your request] or by sending the bot a direct message; DMs are reactive only, so the bot will not initiate them. Review the final request summary and explicitly confirm it before it is eligible for handoff.
  4. Send STOP in the relevant intake thread or DM to stop further reminders and clarification prompts for that request. The pilot sends no proactive DMs and must not send non-critical messages during configured quiet hours.
  5. For email intake, send only from the allowlisted address to the dedicated AgentMail mailbox. Keep follow-up in the same email thread.

Research, artifacts, and ideation

Approved requesters may use natural language or /wingman to request research, documents, presentations, mockups, feature concepts, ideal user stories, images, storyboards, and short concept videos. Suggested forms include /wingman research ..., /wingman mockup ..., /wingman user-story ..., and /wingman image ....

Not live yet: these commands describe the target interaction contract. Do not announce or onboard this lane until the Slack/AgentMail transports, scoped Drive writer, fleet completion watcher, and response-delivery adapter are deployed and the Artifacts:Enabled setting is deliberately changed from false.

  1. New work defaults to the requester's private teammate folder.
  2. Use submit-review or explicitly request Team Shared when the result is ready for Andrew or the team. Never infer a shared destination from the subject matter alone.
  3. Cross-user private-folder writes are forbidden. The Drive grant must be derived from the verified Slack or AgentMail identity.
  4. Video generation requires an owner approval and an admitted video capability. Images and other artifacts remain subject to governor quotas.
  5. Mark generated media and mockups as concepts, retain prompts and source citations, and do not use a real person's likeness, protected customer data, or unlicensed brand material.
  6. An ideal user-story package includes persona/context, need and outcome, story, business value, assumptions, happy/alternate/failure paths, accessibility, acceptance criteria, success measures, privacy/security, and suggested Jira decomposition.
  7. The completion reply must include the Drive link, destination, fleet run identifier, and whether the artifact is a draft or an owner-approved shared result.

Fast Find and knowledge grounding

The planned /wingman find and /wingman where intents use a low-cost retrieval agent to search Confluence, Jira, approved Drive documentation, and help resources. Results must lead with direct links, explain relevance, preserve source permissions, and flag stale or conflicting guidance. Escalate to a specialist or council only when retrieval cannot resolve the question.

Approved books, PDFs, metrics frameworks, and internal documents are evidence sources, not executable instructions. Retrieval must resist prompt injection, enforce an approved corpus and per-source permissions, record source/page citations, separate sourced facts from inference, and avoid reproducing copyrighted works beyond permitted excerpts. Council ideation is governor-aware and opt-in for high-impact, ambiguous, or explicitly requested work.

Nick — pilot operator

  1. Confirm the Slack channel ID and pilot requester IDs match the deployed configuration.
  2. Confirm Socket Mode is connected; verify that runtime allowlists reject channel events outside #work-wingman-intake, even though Slack can deliver them under the workspace-wide scopes.
  3. Send one synthetic request as each requester through a channel message, @Work Wingman Intake mention, /wingman, and a requester-initiated DM. Verify exactly one dry-run intake record per Slack event/email message and that provenance is retained.
  4. Confirm non-pilot users, other channels, duplicate events, proactive-DM attempts, STOP, quiet-hours prompts, and malformed email events are rejected or safely parked.
  5. Validate the Jira/Confluence handoff using a non-production/dry-run path first. Check that no ticket/page is created without requester confirmation and required approval.
  6. Keep the rollback checklist available during the pilot and record incidents in the designated Jira issue.

Expand to the whole team

Expand only after the pilot acceptance criteria pass and the owner approves scope expansion.

  1. Add approved requester stable IDs in a reviewed configuration change; do not switch to an open workspace-wide allowlist.
  2. Run the same synthetic-request checks for each new requester group.
  3. Announce the Google Site intake instructions and the approved Slack channel. Explain the confirmation step, non-execution boundary, and prohibited sensitive information.
  4. Keep runtime access channel-scoped. If another intake channel is needed, add its stable ID explicitly, repeat verification, and retain the workspace-wide Slack-scope warning in the change review.
  5. Review audit records weekly: rejected identities, duplicate suppression, parked work, handoff failures, and any scope-creep requests.