القائمة
MR/PR lifecycle operations -- pipeline check, retest, merge, conflict reporting. Extends darwin-gitlab-ops.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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.
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.
Kubernetes investigation workflow with time-boxed evidence gathering. Activates for Mode:investigate tasks or when investigating pod failures, service anomalies, or cluster issues.
استنادا إلى تصنيف SOC المهني
| name | darwin-mr-lifecycle |
| description | MR/PR lifecycle operations -- pipeline check, retest, merge, conflict reporting. Extends darwin-gitlab-ops. |
| requires | ["darwin-gitlab-ops","darwin-pipelines-as-code"] |
| roles | ["developer","sysadmin"] |
Handles the full MR/PR lifecycle: check pipeline, retest, merge, and conflict reporting.
CRITICAL: For the project path and MR/PR URL, always use the values from the event document's GitLab Context section.
Use the service tools only for aligner events or when a user asked
Before modifying an MR's source branch, read the MR description for Bot Instructions
(### Bot Instructions section). If instructions restrict modifications, report the
constraint to FRIDAY instead of pushing. Even when no Bot Instructions are present,
the source mutation approval gate still applies — report the proposed fix to FRIDAY
and let FRIDAY authorize the push.
When the pipeline failure requires a code/config fix (e.g., Dockerfile update, dependency bump):
To trigger a pipeline retest, post the appropriate PaC GitOps command as an MR/PR comment. See the darwin-pipelines-as-code skill for command selection (e.g., /retest for transient failures, /test for full re-trigger).
After posting, check pipeline status to confirm the retest was accepted.
After retesting:
running or pending:
darwin-k8s-mcp) and include it in the report.success: proceed to merge.failed: read the failed job log and report the error.Do NOT poll in a loop -- report the current state and let FRIDAY handle the timing.
Before merging, perform these pre-merge checks IN ORDER:
@darwin-project.io),
do NOT merge. Report to FRIDAY that the MR/PR contains agent-authored code
requiring human review.success. If the pipeline is from an older commit, or status is pending/running/failed, do NOT merge. Report the state to FRIDAY.CAUTION, error, Pending approval, or waiting for /ok-to-test, do NOT merge. Report the CI warning to FRIDAY.merge_status is can_be_merged.Only merge when ALL checks pass.
waiting for /ok-to-test) or has bot CAUTION warningscannot_be_merged, report conflicts to maintainer@darwin-project.io)If merge_status is cannot_be_merged:
For automated submodule MRs (branch starts with submodule-, author is a bot):
For all other MRs:
Do NOT tag individual users (@username) in MR/PR comments or anywhere else. Do NOT query project/group members to find usernames to tag. MR/PR comments must only describe what happened -- FRIDAY handles all human notifications via Slack.
Always end your response with a clear recommendation for FRIDAY. Do NOT include GitLab usernames or @mentions -- FRIDAY has its own maintainer list.