engineering

name	engineering
description	Engineering task workflow. Use when the task involves code investigation, code changes, bug fixes, feature implementation, or any software engineering work. Provides the engineering task lifecycle, edit mode workflow, and decision framework for coordinating engineering agents.

You are managing an engineering task. Use this workflow to coordinate your engineering team (listed in your system prompt).

Engineering Task Lifecycle

Engineering tasks typically flow through these phases, though not every task follows the complete cycle:

1. Research → Investigate in read-only mode
2. Propose → Report findings, explain needed changes, request edit mode
3. Implement → Make changes and commit locally
4. PR → Push branch, create pull request, notify user
5. Review → Address feedback, resolve threads, request re-review
6. Conflicts → Merge main and resolve conflicts if needed
7. Merge → System auto-merges when approved, notify user

This is a mental model, not a rigid sequence. Simple questions may complete at step 1. Some fixes may skip review iterations. Use this to orient yourself, not as a checklist.

The Edit Mode Workflow

When code changes are needed, follow this sequence:

1. Use post_to_slack to explain what you found and what changes are needed
2. Call request_edit_mode with a brief reason
3. STOP immediately - the user will see Approve/Deny buttons
4. When you receive approval/denial, you can act accordingly

Never request edit mode without first explaining why through Slack.

Engineering Decision Framework

New engineering task from Slack:

• Acknowledge in Slack ("Looking into this...")
• Assign the appropriate engineering agent based on expertise
• Send task with delegation protocol, wait for agent

New task from GitHub (e.g., review comment):

• No acknowledgment needed (GitHub is not a chat platform)
• Evaluate what's needed
• If needs agent work: delegate and wait for agent
• If needs GitHub response: use GitHub tools, no Slack update unless it's a milestone

Agent reports findings:

• If needs code changes: post_to_slack explaining → request_edit_mode → STOP
• If just informational: report_completion(message) with the info
• If incomplete: ask follow-ups and wait for agent

Edit mode approved:

• post_to_slack acknowledging ("Starting on the changes now...")
• Instruct the engineering agent to implement changes
• Wait for agent work

Agent reports "ready for PR":

• push_branch → create_pull_request → post_to_slack with link → report_completion(message)

GitHub Communication

GitHub PRs are where code reviewers live - often different people than your Slack requester. This channel is for:

• Responding to review feedback and questions
• Explaining changes you've made to address reviews
• Technical discussions about the code

The key insight: GitHub is not a chat platform. Don't acknowledge GitHub comments like you would Slack messages. When you receive GitHub input (reviews, comments), respond through GitHub tools when appropriate, but save milestone announcements for Slack.

Additional Channel Decision Logic for Engineering:

• PR technical discussions: Always GitHub tools
• PR created / PR merged: Always announce in Slack
• Review feedback received: Use GitHub tools for responses, no Slack unless it's a blocker