- Add design-conformance-reviewer agent for reviewing code against design docs - Add weekly-shipped skill for stakeholder summaries from Jira/GitHub - Fix component counts across marketplace.json, plugin.json, and README - Add worktree constraints to ce-review and resolve_todo_parallel skills - Fix typo in resolve_todo_parallel SKILL.md Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
190 lines
9.3 KiB
Markdown
190 lines
9.3 KiB
Markdown
---
|
|
name: weekly-shipped
|
|
description: Generate a weekly summary of all work shipped by the Talent team. Queries Jira ZAS board and GitHub PRs across talent-engine, talent-ats-platform, and agentic-ai-platform. Cross-references tickets and PRs, groups by theme, and writes a Slack-ready stakeholder summary to ~/projects/talent-engine/docs/. Run every Friday afternoon. Triggers on "weekly shipped", "weekly update", "friday update", "what shipped this week".
|
|
disable-model-invocation: true
|
|
allowed-tools: Bash(gh *), Bash(date *), Bash(jq *), Read, Write, mcp__atlassian__searchJiraIssuesUsingJql, mcp__atlassian__getJiraIssue
|
|
---
|
|
|
|
# Weekly Shipped Summary
|
|
|
|
Generate a stakeholder-ready summary of work shipped this week by the Talent team.
|
|
|
|
**Voice**: Before drafting the summary, load `/john-voice` — read [core-voice.md](../john-voice/references/core-voice.md) and [casual-messages.md](../john-voice/references/casual-messages.md). The tone is a 1:1 with your GM — you have real rapport, you're direct and honest, you say why things matter, but you're not slouching. Not a coffee chat, not a board deck.
|
|
|
|
## Constants
|
|
|
|
- **Jira cloudId**: `9cbcbbfd-6b43-42ab-a91c-aaaafa8b7f32`
|
|
- **Jira project**: `ZAS`
|
|
- **Jira board**: `https://discoverorg.atlassian.net/jira/software/c/projects/ZAS/boards/5615`
|
|
- **GitHub host**: `git.zoominfo.com`
|
|
- **Repos**:
|
|
- `dozi/talent-engine`
|
|
- `dozi/talent-ats-platform`
|
|
- `dozi/agentic-ai-platform` (talent PRs only)
|
|
- **Output dir**: `~/projects/talent-engine/docs/`
|
|
- **Ticket URL pattern**: `https://discoverorg.atlassian.net/browse/{KEY}`
|
|
- **PR URL pattern**: `https://git.zoominfo.com/{org}/{repo}/pull/{number}`
|
|
|
|
## Coverage Window
|
|
|
|
**Last Friday 1:00 PM CT → This Friday 12:59 PM CT**
|
|
|
|
The window is approximate at the day level for queries. The skill runs Friday afternoon, so "this week" means the 7-day period ending now.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Calculate Dates
|
|
|
|
Determine the date range for queries:
|
|
|
|
```bash
|
|
# Last Friday (YYYY-MM-DD) — macOS BSD date
|
|
LAST_FRIDAY=$(date -v-fri -v-1w "+%Y-%m-%d")
|
|
|
|
# This Friday (YYYY-MM-DD)
|
|
THIS_FRIDAY=$(date -v-fri "+%Y-%m-%d")
|
|
|
|
echo "Window: $LAST_FRIDAY to $THIS_FRIDAY"
|
|
```
|
|
|
|
Store `LAST_FRIDAY` and `THIS_FRIDAY` for use in all subsequent queries.
|
|
|
|
### Step 2: Gather Data
|
|
|
|
Run Jira and GitHub queries in parallel.
|
|
|
|
#### 2a. Jira — Tickets Completed This Week
|
|
|
|
Search for tickets resolved in the window:
|
|
|
|
```
|
|
mcp__atlassian__searchJiraIssuesUsingJql
|
|
cloudId: 9cbcbbfd-6b43-42ab-a91c-aaaafa8b7f32
|
|
jql: project = ZAS AND status = Done AND resolved >= "{LAST_FRIDAY}" AND resolved <= "{THIS_FRIDAY}" ORDER BY resolved DESC
|
|
limit: 50
|
|
```
|
|
|
|
For each ticket, capture: key, summary, assignee, status.
|
|
|
|
If the initial query returns few results, also try:
|
|
```
|
|
jql: project = ZAS AND status changed to "Done" after "{LAST_FRIDAY}" before "{THIS_FRIDAY}" ORDER BY updated DESC
|
|
```
|
|
|
|
#### 2b. GitHub — Merged PRs
|
|
|
|
Query all three repos for merged PRs. Run these three commands in parallel:
|
|
|
|
```bash
|
|
# talent-engine
|
|
GH_HOST=git.zoominfo.com gh pr list --repo dozi/talent-engine \
|
|
--state merged --search "merged:>={LAST_FRIDAY}" \
|
|
--json number,title,url,mergedAt,author,headRefName --limit 100
|
|
|
|
# talent-ats-platform
|
|
GH_HOST=git.zoominfo.com gh pr list --repo dozi/talent-ats-platform \
|
|
--state merged --search "merged:>={LAST_FRIDAY}" \
|
|
--json number,title,url,mergedAt,author,headRefName --limit 100
|
|
|
|
# agentic-ai-platform (fetch all, filter for talent next)
|
|
GH_HOST=git.zoominfo.com gh pr list --repo dozi/agentic-ai-platform \
|
|
--state merged --search "merged:>={LAST_FRIDAY}" \
|
|
--json number,title,url,mergedAt,author,headRefName --limit 100
|
|
```
|
|
|
|
**Filter agentic-ai-platform results**: Only keep PRs where:
|
|
- `title` contains "talent" or "[Talent]" (case-insensitive), OR
|
|
- `headRefName` starts with "talent-" or "talent/"
|
|
|
|
Discard the rest — they belong to other teams.
|
|
|
|
### Step 3: Cross-Reference
|
|
|
|
Build a unified picture of what shipped:
|
|
|
|
1. **Match PRs to Jira tickets** — Scan PR titles and branch names for ticket keys (ZAS-NNN pattern). Link matched pairs.
|
|
2. **Identify orphan PRs** — PRs with no Jira ticket. These represent real work that slipped through ticketing. Include them.
|
|
3. **Filter out empty tickets** — Jira tickets moved to Done with no corresponding PR and no evidence of work (no comments, no linked PRs). Exclude silently — these were likely backlog grooming moves, not shipped work.
|
|
4. **Verify merge times** — Confirm merged PRs fall within the actual window. GitHub search by date can be slightly off.
|
|
|
|
### Step 4: Group by Theme
|
|
|
|
Review all shipped items and cluster into 3-6 logical groups based on feature area. Examples of past groupings:
|
|
|
|
- **Outreach System** — email, templates, response tracking
|
|
- **Candidate Experience** — UI, cards, review flow
|
|
- **Search & Pipeline** — agentic search, batch generation, ranking
|
|
- **Dev Ops** — infrastructure, staging, deployments, CI
|
|
- **ATS Platform** — data model, architecture, platform decisions
|
|
- **Developer Tooling** — internal tools, automation
|
|
|
|
Adapt groups to whatever was actually shipped. Do not force-fit. If something doesn't fit a group, let it stand alone.
|
|
|
|
**Skip these unless the week is light on real content:**
|
|
- Dependency updates, version bumps
|
|
- Code cleanup, refactoring with no user-facing impact
|
|
- Test additions
|
|
- Linter/formatter config changes
|
|
- Minor bug fixes
|
|
|
|
### Step 5: Draft the Summary
|
|
|
|
**Title**: `Agentic Sourcing App Weekly Highlights {Mon} {Day}{ordinal}`
|
|
|
|
**Critical rules — read these before writing:**
|
|
|
|
1. **UNDERSTATE, never overstate.** Senior leaders read this. Getting caught overstating kills credibility. If the work is foundational, say "foundations." If it's on mock data, say "mock data." If it's not wired end-to-end, say so.
|
|
2. **Non-technical language.** The reader is a VP, not an engineer. "Database schema added" → "Tracking infrastructure set up." "Refactored query layer" → skip it or say "Search speed improvements."
|
|
3. **Qualify incomplete work honestly.** Qualifications aren't caveats — they're what makes the update credible. "Hasn't been tested end-to-end yet, but the pieces are connected" is stronger than pretending it's done. Always note gaps, blockers, and what's next.
|
|
4. **Say why, not just what.** Every bullet should connect what shipped to why it matters. Not "Nightly batch generation running in staging" — instead "Nightly batch generation is running in staging. The goal is recruiters waking up to fresh candidates every morning without doing anything." If you can't explain why a reader should care, reconsider including it.
|
|
5. **No laundry lists.** Each bullet should read like a short explanation, not a changelog entry. If a section has more than 3-4 bullets, you're listing features, not telling someone what happened. Merge related items. Bad: `"Contact actions MVP: compose email and copy phone directly from cards. Project metadata row in header. Outreach template MVP with search state polish."` Good: `"Cards are starting to feel like a real tool. Recruiters can send an email or grab a phone number without leaving the card, see previous roles, career trajectory, and AI scores inline."`
|
|
6. **Give credit.** Call out individuals with @first.last when they knocked something out of the park. Don't spray kudos everywhere — be selective and genuine.
|
|
7. **Be skimmable.** Each group gets a bold header + 2-4 bullet points max. Each bullet is 1-3 lines. The whole message should take 60 seconds to read.
|
|
8. **No corporate speak.** No "leveraging", "enhancing", "streamlining", "driving", "aligning", "meaningfully", "building block." Write like you're explaining what happened to someone you respect.
|
|
9. **Link tickets and PRs where they add value.** Inline link tickets where a reader might want to click through for detail: `[ZAS-123](https://discoverorg.atlassian.net/browse/ZAS-123)`. Link PRs when they represent significant standalone work. Don't link every single one — just where it helps.
|
|
10. **This is a first draft, not the final product.** Optimize for editability. Get the structure, facts, and links right. Keep the voice close. The human will sharpen it before sharing.
|
|
|
|
**Format:**
|
|
|
|
```
|
|
Agentic Sourcing App Weekly Highlights {date}
|
|
|
|
**{Group Name}** {optional — short color commentary or kudos}
|
|
|
|
- {Item} — {what shipped, why it matters, any qualifications}
|
|
- {Item} — {context}
|
|
|
|
**{Group Name}**
|
|
|
|
- {Item}
|
|
- {Item}
|
|
|
|
{Optional closing note — kudos, callout, or one-liner}
|
|
```
|
|
|
|
### Step 6: Write to File
|
|
|
|
Save the summary:
|
|
|
|
```
|
|
~/projects/talent-engine/docs/weekly-shipped-{YYYY-MM-DD}.md
|
|
```
|
|
|
|
Where the date is this Friday's date. The file is plain markdown optimized for copy-pasting into Slack.
|
|
|
|
### Step 7: Present and Confirm
|
|
|
|
Display the full summary to the user. Ask:
|
|
|
|
> Here's the weekly shipped summary. Anything to adjust, add, or cut before you share it?
|
|
|
|
Wait for confirmation before considering the skill complete.
|
|
|
|
## Troubleshooting
|
|
|
|
**gh auth issues**: If `GH_HOST=git.zoominfo.com gh` fails, check that `gh auth status --hostname git.zoominfo.com` shows an authenticated session.
|
|
|
|
**Jira returns no results**: Try broadening the JQL — drop the `resolved` filter and use `status = Done AND updated >= "{LAST_FRIDAY}"` instead. Some tickets may not have the resolution date set.
|
|
|
|
**Few PRs found**: Some repos may use squash merges or have PRs merged to non-default branches. Check if `--search "merged:>={LAST_FRIDAY}"` needs adjustment.
|