Jak centrálně spravovat a řídit skills pro agenty

> List tasks waiting for response and summarize what needs attention.

The Task API is responding, but the first request hit a rate limit. I’m checking the response shape and then retrying with a short pause so I can give you the actual waiting items instead of a guess.

5 tasks are waiting for response. The ones needing the most attention are the two high-priority items stalled on external confirmation or approval.

  ┌──────────────────────────────────────────────────────────────────┬──────────┬───────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Task                                                             │ Priority │ Assignee          │ Needs attention                                                                                                        │
  ├──────────────────────────────────────────────────────────────────┼──────────┼───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ task-1 — Waiting on customer confirmation — order #8821          │ High     │ alice@example.com │ Customer still has not confirmed after the initial outreach and a 48-hour follow-up.                                   │
  │ task-3 — Awaiting legal sign-off on NDA amendment                │ High     │ carol@example.com │ Legal review is pending after the NDA draft was forwarded.                                                             │
  │ task-2 — Pending vendor reply for Q3 renewal                     │ Medium   │ bob@example.com   │ Vendor has not replied since the renewal quote was sent.                                                               │
  │ task-5 — Infrastructure cost review — ops team response needed   │ Medium   │ eve@example.com   │ Ops response is pending, and there is no comment history, so this likely needs owner context or a first follow-up.     │
  │ task-4 — Customer reported login failure — needs repro steps     │ Low      │ dave@example.com  │ Blocked waiting for the customer to provide reproduction steps.                                                        │
  └──────────────────────────────────────────────────────────────────┴──────────┴───────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

> Open task-1 and add this comment: "Following up - please provide an update."

Added the comment to task-1. The API accepted it as comment c-c0d260d5.

> Add the same comment to every task waiting for response.

The bulk run hit rate limits mid-stream. I’m reading the exact output and then I’ll finish only the tasks that didn’t get updated.
task-5 was the only one not updated. I’m retrying that single task with a slower cadence to get it through cleanly.
Done. The comment was added to all other tasks currently in waiting-for-response, and task-1 was skipped because it already had the same comment.

Best improvement: add a first-class bulk command to the shared CLI, for example:

python task_cli.py bulk-add-comment --status waiting-for-response --text "Following up - please provide an update." --skip-existing

That would help because this workflow currently requires list -> get each task -> detect duplicates -> post comment, which is slow and exposed to 429 rate limits. A bulk command could make it both faster and more reliable by handling:

- built-in retry/backoff for rate limits
- duplicate-comment detection (--skip-existing)
- a single summary of which tasks were updated or skipped

Per the skill’s process, the right next step would be a local proof of concept that captures before/after evidence: fewer API calls, fewer retries, and cleaner operator output.

> OK, this make sense. Follow improvement guide, test this idea locally as PoC and if it is good, publish this is detailed issue into skills-demo-catalog repository.

I’m setting up a proper local PoC in the installed skill, capturing before/after evidence, and then I’ll revert the local patch before opening the upstream issue if the results hold.
I’ve got a clean baseline: 11 calls over ~30s, one 429, and only 4 of 5 tasks updated.
The first PoC run worked cleanly: all 5 tasks updated in about 6 seconds with no failures.
I’ve got enough evidence now: the PoC fixed the partial-failure case and validated duplicate skipping. I’m writing the findings down, restoring the installed skill to the published baseline, and then I’ll open the upstream issue from that evidence.

https://github.com/tkubica12/skills-demo-catalog/issues/15