| name | weekly-status |
| description | Write a weekly status report on a GitLab issue or epic using a fixed template. Use when the user asks for a "weekly status", "weekly update", "status review", or "status update" on a specific work item. |
| license | MIT |
| compatibility | opencode |
| metadata | {"audience":"developers","author":"pedropombeiro","workflow":"gitlab"} |
Weekly status
Write a weekly status comment on a GitLab issue or epic using the template below.
When to use
The user mentions any of:
- "weekly status", "weekly update", "weekly review"
- "status update for #N" or "status update on &N"
- "status review for [work item]"
When NOT to use
- The target is a merge request. MRs have their own review-state machinery; do
not post a weekly status comment on an MR.
- The target is a closed issue or epic without a clear wrap-up intent. Ask the
user whether they want a final closing comment instead.
Template
Read assets/template.md and use it verbatim,
including the comments. Fill in the bullets and check exactly one
confidence box.
Drafting rules
- Audience is a manager. Keep each bullet terse and high-signal.
- Skip process noise: review-suggestion cycles, lint runs, rebase mechanics,
draft iteration count, mode switches, tool-call details.
- Each
Progress this week bullet describes an outcome, not a step. Prefer
"MR !X opened with Y" over "Iterated on the description for MR !X".
What's next lists concrete, named items (MR IIDs, issue numbers).- Wrap GitLab usernames in backticks (
`username`) so they are not
pinged.
- Link issues and merge requests by IID. Inside
gitlab-org/gitlab, !IID
and #IID short references render as links. For epics or cross-project
references, use the full URL.
- Pick exactly one confidence checkbox. Leave the other two unchecked but
visible. Do not remove any line from the Confidence section.
- The
/health_status argument must match the chosen confidence checkbox.
Confidence ↔ /health_status mapping
| Checkbox | /health_status value |
|---|
| 🔴 At risk - may not make it | at_risk |
| 🟡 Some concerns - watching closely | needs_attention |
| 🟢 On track - confident we'll deliver | on_track |
Posting workflow
- Draft the comment in chat. Do not call
gitlab_create_note yet.
- Wait for the user's explicit "post it" or "go ahead" before posting. Mode
approvals (plan mode → build mode, answering questions) do not count
as posting approval.
- Post via
gitlab_create_note:
- For an issue:
resource_type=issue, project_id=<group/project>,
iid=<issue-iid>, body=<final-text>.
- For an epic:
resource_type=epic, group_id=<group>,
iid=<epic-iid>, body=<final-text>.
- Verify the response includes
commands_changes.health_status so the
/health_status quick action took effect.
Examples
Good
Tight, manager-readable, one outcome per bullet:
## Status Update
**Progress this week:**
- Filed issue and opened MR !235898 adding two new pages under
`doc/development/agent_principles/` and a cross-link from
`feature_development.md`.
- MR is mergeable, pipeline green, all discussions resolved.
**What's next:**
- Land MR !235898 after `dgruzd` review.
- Follow-up: back-link from `.ai/principles/README.md` and
`.ai/principles/manifest.yml` to the new docs page, landing on
!235272.
**Blockers:**
- None
**Confidence for current milestone:**
- [ ] 🔴 At risk - may not make it
- [ ] 🟡 Some concerns - watching closely
- [x] 🟢 On track - confident we'll deliver
/health_status on_track
/cc @cheryl.li
Bad
Process-heavy, low-signal, would not help a manager:
**Progress this week:**
- Filed the issue on 2026-05-13 and opened the MR.
- Applied three Duo Code Review suggestions on opening paragraphs and
validation wording; modified two to preserve the planning-time framing
and accepted one verbatim. All three suggestion threads resolved.
- Restructured the rule-authoring guidance into two audiences after
feedback that imperative phrasing applies only to baseline files.
- Triggered the `review-docs-deploy` Review App. Preview URLs: ...
- Vale and `markdownlint-cli2` both pass.
Why it fails: review-iteration mechanics, lint pass/fail, and Review App
trigger details are process noise, not outcomes a manager needs to track.
Asking the user
If any of these are unknown, ask before drafting:
- The work item to report on (issue IID or epic IID + group).
- Which milestone the work belongs to, if it isn't obvious from the work
item's metadata.
- Confidence level for the current milestone (🔴 / 🟡 / 🟢).
- Override for the default
/cc handle (@cheryl.li).
