work-feedback

name	work-feedback
description	Periodic status-table check-ins while background sub-agents work, gated by credentials.json.

Work Feedback

When an orchestrating agent spawns sub-agents that run in the background (e.g. Agent with run_in_background: true, or a Workflow run), the user loses visibility into progress until the final summary. This skill defines a periodic, table-only check-in that closes that gap.

---

Configuration Gate

Read .dev-team-agents/user-data/credentials.local.json before doing anything in this skill:

{
  "work_feedback_active": true,
  "work_feedback_interval_minutes": 5
}

• work_feedback_active: false → do not run any part of this skill. No table, no scheduling. Proceed with the task silently as if this skill did not exist.
• work_feedback_interval_minutes → the polling interval in minutes. Convert to seconds and clamp to [60, 3600] (the ScheduleWakeup runtime limit) before use. A value outside that range after conversion is clamped, never rejected.
• If the file or either key is missing, treat it as active: true, interval_minutes: 5 — scripts/install.sh and /devteam:health-check Category 10 guarantee the keys exist, so an absence here means a stale read, not an opt-out.

These two keys are the only source of truth for whether and how often this skill runs. Do not infer a different cadence from context, and do not skip the gate check because "it's probably fine."

---

When To Apply

Applies only when sub-agents are running in the background and the task has a known, ordered set of steps (from an approved plan, a /devteam:* command's roster, or an explicit step list stated to the user). Does not apply to:

• Foreground/synchronous agent calls (the user already sees them run one at a time)
• Single-agent tasks with no parallel work to report on
• Tasks with no step list to render (nothing to put in the table)

---

Loop Mechanics

1. Before the first background spawn, resolve the step list (ordered, from the plan/roster), note the version string (installed_version from .dev-team-agents/user-data/state.json), and record the start timestamp — it is fixed for the whole run and never recomputed on later ticks.
2. After spawning, call ScheduleWakeup with delaySeconds = the clamped interval from the gate above, and a reason naming what is being polled.
3. On each wake-up, check the real status of in-flight sub-agents (TaskList/TaskOutput, or the workflow's own progress state) and update each step's status:
   • ✅ done
   • ⏳ in progress right now
   • 🕐 waiting (not started)
4. Emit only the table (see Format below) — no narration, no preamble, no trailing text in that turn.
5. If any step is still not ✅, call ScheduleWakeup again with the same interval. If all steps are ✅, emit the final all-✅ table and stop scheduling (stop: true) — do not keep polling a finished task.

Never fire more than one wake-up cycle per interval, and never shorten the interval to "check sooner" — the interval is a user-controlled setting, not a suggestion.

---

Table Format

### 📋 DEVTEAM AGENTS v<installed_version> • WORK FEEDBACK
Started at <yyyy-mm-dd hh:mm> (duration: <Xh Ym Zs>)

| # | Step               | Status |
|---|--------------------|--------|
| 1 | <step 1 title>     | ✅     |
| 2 | <step 2 title>     | ⏳     |
| 3 | <step 3 title>     | 🕐     |

• Line 1 is a markdown heading (###) starting with the 📋 marker, then product name and installed version in upper case, •, WORK FEEDBACK in upper case — no extra separators or emphasis.
• Line 2: Started at followed by the fixed start timestamp recorded in Loop Mechanics step 1, then the elapsed duration since that timestamp in parentheses, formatted <h>h <m>m <s>s (omit a leading unit that is zero, e.g. 23m 4s when under an hour).
• Steps appear in planned order, unchanged across ticks (only the Status column changes).
• No text before or after the table in that message.