메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Set up, list, or manage triggers — persistent "do Y when X happens" rules. Use when someone asks Archie to do something on a schedule ("every weekday at 9am…", "every morning post…", "remind the channel weekly…"), to react to new messages in a channel ("whenever someone posts X in
Boot a live Archie instance from the current branch, drive E2E scenarios headlessly through the archie-debug MCP (nonce → create_task → wait_for_task → approve), capture per-scenario evidence files, and tear down cleanly. Use for Forge Stage 4 QA, verifying a branch against a live instance, running the basic or edit-mode E2E scenario, or when asked to "run the e2e harness", "boot archie for testing", or "verify this AC live".
How to work with a channel's standing project context — the "Archie" canvas a team pins in a channel. Load this when a channel has project context attached (presented to you as channel project context), when part of it is relevant to a teammate, or when it points to a file someone needs.
Read this before authoring or substantially changing a plugin, agent, or skill for Archie. It's the conceptual playbook for building plugins that fit Archie's multi-agent, single-orchestrator model — what a plugin must respect, why every plugin usually needs an orchestrator-facing skill, and how to think about agents vs skills vs PM skills. Triggers on "write a plugin", "add an agent", "add a skill", "create a new domain", "make a new teammate". This is the "how to think about it" layer; the README's Plugins section and docs/architecture/plugin-system.md are the "how to wire it up" layer.
Summarize or draft workflow. Use when someone asks to summarize a piece of text, condense a document, draft a short reply, or "TL;DR this". This is the example skill that ships with Archie.
Use when the user asks about Archie itself — what Archie is, how it works, what it can or cannot do, what agents or domains exist, how plugins work, how requests get handled, why something behaves a certain way, what integrations are available, or whether Archie can change itself. Triggers on phrases like "what can you do", "how do you work", "what are you", "who are you", "are you able to…", "do you have access to…", "can you change yourself", "can you add a plugin", "what's your architecture", "how do you handle…", "what happens when…". Provides the ground truth needed to answer accurately without inventing capabilities.
| 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 tasks typically flow through these phases, though not every task follows the complete cycle:
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.
When code changes are needed, follow this sequence:
post_to_slack to explain what you found and what changes are neededrequest_edit_mode with a brief reasonNever request edit mode without first explaining why through Slack.
New engineering task from Slack:
New task from GitHub (e.g., review comment):
Agent reports findings:
post_to_slack explaining → request_edit_mode → STOPreport_completion(message) with the infoEdit mode approved:
post_to_slack acknowledging ("Starting on the changes now...")Agent reports "ready for PR":
push_branch → create_pull_request → post_to_slack with link → report_completion(message)GitHub PRs are where code reviewers live - often different people than your Slack requester. This channel is for:
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: