AgentStack
SKILL verified MIT Self-run

Briefing Daily

skill-panqiwei-board-superpowers-briefing-daily · by PanQiWei

|

No reviews yet
0 installs
13 views
0.0% view→install

Install

$ agentstack add skill-panqiwei-board-superpowers-briefing-daily

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Briefing Daily? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

briefing-daily

This is the Producer's daily orientation skill. It reads the board, produces a one-screen summary, flags WIP issues and stale claims, and recommends ONE next action.

Required sub-skills:

  • board-superpowers:board-canon — read before any Status or WIP decision.
  • board-superpowers:operating-kanban — dispatch the read_board protocol

action; resolves the active projection from settings.

  • board-superpowers:composing-siblings — consult before any sibling-plugin

handoff (e.g., if overflow delegation to gstack:* / superpowers:* is needed in an extended orientation session).

  • board-superpowers:classifying-actions + board-superpowers:auditing-actions

— applied at every mutating action (stale-claim administrative release if any). The daily read itself is non-mutating and does NOT invoke auditing-actions.

Overview

The daily briefing answers three questions:

  1. Where is everything? — group cards by Status, count each group.
  2. Is anything wrong? — WIP cap violations, stale claims (>72h with no

commits beyond the initial claim marker).

  1. What should I do next? — ONE recommended action, from the priority list

below.

This skill does NOT merge, transition, or create cards (those are reviewing-pr-queue, triaging-board, intaking-requirement). If the briefing surfaces something that needs action, route to the appropriate routine SKILL.

Step-by-step procedure

Step 1 — Read the board

Invoke board-superpowers:board-canon to load the state machine and WIP counting formula. Then invoke board-superpowers:operating-kanban with action read_board. The projection (GitHub Project v2 / Linear / Jira) is resolved from /.board-superpowers/settings.yml § modules.m10_kanban; operating- kanban handles the backend routing transparently.

Parse the JSON output. Expect fields: number, title, status, url, item_id per card.

Step 2 — Group by Status

Produce a markdown summary in this exact format (omit groups with 0 items, unless ALL groups are 0):

## Board state — 

### In Progress ()
- #  — claimed by , 

### In Review ()
- #  — PR #,  since opened

### Blocked ()
- #  — blocker: 

### Ready ()
- #  — 

### Backlog ()
-  cards (names omitted when > 5 total)

If ALL statuses are empty, use the empty-board format in references/daily-detail.md.

Hot-card ordering: In Progress + In Review first; collapse Backlog to a count when > 5 items.

Single-Consumer projects: drop the "by " suffix when there is only one person. See references/daily-detail.md for the simplified format.

Step 3 — Flag WIP issues

Per board-superpowers:board-canon § "WIP counting formula" (In Progress + In Review count; Blocked is excluded):

  • At cap: if any Consumer is at their WIP cap, flag it: "⚠ is at

WIP cap — review queue or unblock before claiming new work."

  • Stale claims: a claim branch is stale if age > 72h AND commit count

beyond the initial claim marker = 0. Flag: "⚠ # stale claim — no commits in d h".

Stale-claim age computation:

git log origin/claim/- --not main --oneline | wc -l

If 0 (or 1 for the initial empty-marker commit), count the time since branch creation. See references/daily-detail.md for the exact git invocation.

Step 4 — Recommend ONE next action

Priority order (pick the first that applies):

  1. "Review the review queue" — if In Review count > 0. Invoke

board-superpowers:reviewing-pr-queue.

  1. "Triage Blocked cards" — if Blocked count > 0. Invoke

board-superpowers:triaging-board.

  1. "Claim a Ready card" — if Ready count > 0 and the Producer wants to

context-switch into Consumer mode. Show the top card by priority.

  1. "Run intake" — if all the above are empty. Invoke

board-superpowers:intaking-requirement.

State the recommendation as ONE sentence: "Recommend: review the PR queue — #12 and #14 are awaiting validation."

Do NOT list multiple recommendations. The value is the single opinionated recommendation, not a menu. If the Producer wants a different action, they can say so.

Step 4a — Extended orientation (sibling-plugin handoff)

After the board state is presented, the Producer may respond with a strategic question ("Is this the right work to be doing?", "Should we drop card #N and start on X instead?") that goes beyond what board data can answer. This is a sibling-plugin handoff scenario.

When the Producer's response to the briefing reads as a direction or prioritization question rather than a "what's on the board" question:

  1. Invoke board-superpowers:composing-siblings to confirm the appropriate

sibling and its invocation safety (Mode-2 compatibility check).

  1. Surface the routing decision to the Producer before routing:

"This reads as 'is this the right work' territory. Routing to gstack:/office-hours for a demand-reality check."

  1. Route to the appropriate sibling skill:
  • Direction / prioritization question ("should we build this?",

"is card #N still worth doing?") → gstack:/office-hours or gstack:/plan-ceo-review.

  • Architecture re-check ("does the current roadmap sequence make sense?",

"is the dependency graph right?") → gstack:/plan-eng-review.

  • Design exploration triggered by briefing output (e.g., a new blocker

surfaces a design question the team hasn't resolved) → route to board-superpowers:intaking-requirement which then routes to superpowers:brainstorming via composing-siblings.

This extended orientation path is the ONLY place in briefing-daily where a sibling-plugin handoff occurs. All other sibling-plugin calls are routed through the appropriate routine (intaking-requirement, reviewing-pr-queue, triaging-board) rather than initiated from within the briefing.

How mutating actions are handled

On rare occasions the briefing surfaces a clear administrative action (e.g., deleting a ghost branch for a card that is already Done). Apply the 5-step governance sequence:

  1. Resolve the action_id (from board-superpowers:classifying-actions

references/action-id-catalog.md).

  1. Invoke board-superpowers:classifying-actions with that action_id;

receive A (auto), R (requires approval), or N (forbidden).

  1. If A: act → invoke board-superpowers:auditing-actions to record one

entry.

  1. If R: invoke auditing-actions to record the proposal; surface to the

Producer; wait for reply; on approve → act + audit; on decline → audit decline and abort.

  1. If N: refuse the action, no audit entry.

Prefer to route to triaging-board rather than taking administrative action from within the briefing. The briefing's job is to orient, not to mutate.

Context-switch reload (re-entry variant)

When the Producer returns to an old card or Thread after a gap, the briefing skill runs first to re-establish context before routing to the appropriate routine. The briefing narrows its output to the card in question:

  • Show the card's current status, last-commit timestamp, and most recent

PR comment.

  • Recommend the appropriate next action for that specific card (resume →

consuming-card; review → reviewing-pr-queue; investigate block → triaging-board).

This re-entry variant fires when the user signals orientation desire — "catch me up on #N", "what's the status of #N", "orient me on #N", "where did we leave off on #N" — NOT resume desire ("claim #N", "work on #N", "pick up #N"); resume phrases route to consuming-card directly. See references/daily-detail.md § "Context-switch reload" for the truncated output format.

Today's dispatch recommendation (extended variant)

When the Producer asks "what should I work on today" with a time-window qualifier ("I have 2 hours", "I can ship one card today"), extend the recommendation to a dispatch list:

  1. Complete Step 1-3 as above.
  2. Score Ready cards by (size ≤ available time) × (blocked-on count = 0) ×

(oldest first for equal scores).

  1. Return a ranked list of up to 3 cards with one-line rationale each.

The dispatch recommendation is read-only and non-binding — the Producer decides. Do NOT pre-claim cards.

Velocity signal (optional)

When the board shows consecutive Done cards from the past 5 days, append a one-line velocity note below the recommendation:

Velocity: N cards shipped in the last 5 days. Pace: [above / at / below] target.

This is informational only. Do NOT compute a prediction or a sprint burn-down — those are human-team cadence constructs that don't translate directly to the AI-agent throughput model. Surface the raw count; let the Producer interpret it.

Failure modes

| Situation | Correct handling | |-----------|-----------------| | read_board returns empty (network / auth failure) | Surface the failure verbatim. Do NOT synthesize a board state from memory or cache. "Board read failed — operating-kanban returned: . Fix the connection before proceeding." | | read_board returns a stale dataset (e.g., GitHub Project sync lag) | Note the timestamp of the response if available. "Board data as of — if this looks stale, re-run after to pick up the latest sync." | | WIP count exceeds cap but no obvious stale claims | Flag the cap violation. Do NOT attempt to release claims or transition cards. Route to triaging-board for the investigation. | | Producer ignores the recommendation and asks for the next one | Give the next item in the priority list and explain why it ranked lower. Still surface only ONE at a time. | | All groups are empty (fresh project) | Show the empty-board format (see references/daily-detail.md). Recommend intake: "Board is clear — run board-superpowers:intaking-requirement to add the first card." |

Tone and format

The briefing is for a busy Producer. Go straight to the data — no preamble ("Here is your morning briefing:"). Skip group headers with 0 items (unless all are 0). One screen, no scroll. Sentence fragments are fine: "In Progress: 2 cards, both on track."

Single-page discipline: if the card list would require scrolling, collapse lower-priority groups. In Progress + In Review always display in full; Ready shows the top 3 cards with a "(+N more)" trailer; Backlog collapses to a count.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.