Menu
Structured plan template for the Architect agent. Use when creating infrastructure or code change plans.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | darwin-plan-template |
| description | Structured plan template for the Architect agent. Use when creating infrastructure or code change plans. |
| roles | ["architect"] |
| modes | ["plan"] |
Use this structure for all plans:
---
plan: [Action] [Target]
service: [name]
repository: [repo URL]
path: [helm path or source path]
domain: [CLEAR|COMPLICATED|COMPLEX]
risk: [low|medium|high]
steps:
- id: 1
agent: [agent]
mode: [mode]
summary: [short description]
status: pending
- id: 2
agent: [agent]
mode: [mode]
summary: [short description]
status: pending
---
# Plan: [Action] [Target]
## Reason
[Why this change is needed, based on evidence]
## Steps
1. Specific action with implementation details
2. Specific action with implementation details
## UX Considerations (include when plan touches frontend/UI)
- User goal: [what the user is trying to accomplish]
- Current friction: [what's wrong with the current experience]
- Interaction pattern: [expand/collapse, modal, inline edit, etc.]
- States: [loading, empty, error -- how each is handled]
## Risk Assessment
- Risk level: [low/medium/high]
- Rollback: [how to undo]
## Verification
- [How will we know the change worked?]
- [What metric or signal confirms success?]
The frontmatter YAML header is machine-readable by FRIDAY and executing agents (Developer, QE).
The status field starts as pending and the executing team updates it to in_progress, completed, or failed as they work through the steps.
The Markdown body below the frontmatter contains the full human-readable details for each step.
Assign each step in the frontmatter steps: array to an agent and mode:
sysAdmin -- Kubernetes and GitOps operations
investigate -- Read-only cluster and service inspection, remote cluster accessexecute -- GitOps mutations (Helm value changes, commit, push)rollback -- Revert last GitOps change, verify CD syncdeveloper -- Code implementation agent
investigate -- Read-only: check MR/PR status, code inspectionexecute -- Single write actions: post comment, merge MR, tag releaseimplement -- Code changes. FRIDAY dispatches Developer first, then QE for verification.qe -- Quality verification agent
test -- Run tests, verify deployments via browser (Playwright MCP or repo Playwright tests)investigate -- Read-only test status checksarchitect -- Planning and review (use sparingly, avoid self-referential loops)
review -- Code/MR/PR review with severity findingsanalyze -- Information gathering and status reportHow to write steps for developer and QE:
developer with mode: implement,
and verification steps to qe with mode: test. FRIDAY dispatches them sequentially.developer with mode: investigate.developer with mode: execute.For COMPLICATED plans with multiple options, present options WITHOUT step assignments in the frontmatter.
Only the selected option's execution steps get agent and mode fields.
Safety rules for modifying Dockerfiles and Containerfiles. Use when editing container build files.
MR/PR context gathering and diagnostic reporting guidelines. Activates when working on events that reference MRs/PRs or when reporting investigation findings.
Team coordination for implement and test modes. Developer and QE use team_send_results for final reports, team_huddle for mid-task questions to FRIDAY.
GitOps workflow rules for modifying infrastructure via git. Use when cloning repos, modifying Helm values, committing, pushing, or verifying deployments.
MR/PR lifecycle operations -- pipeline check, retest, merge, conflict reporting. Extends darwin-gitlab-ops.
Report findings and status updates to the Darwin FRIDAY. Use team_send_results for final reports (task modes). In message mode, use team_send_message instead.