github-issueslisted

# GitHub Issues and Task Documentation Use this skill when work needs a tracked GitHub issue, a durable task document, or synchronization between the two. Use the `gh` CLI for all GitHub operations against `lauriparviainen/agent_collab`. ## Core Rule Small tasks use a GitHub issue only. Bigger tasks use both a local task document and a matching issue. For small tasks (bugs, cleanups, bounded features), the issue is the source of truth: keep its description and comments current, and do not create a task document unless the work grows. Use the bigger-task path when work involves design decisions, multi-component behavior, security or auth, config or data migrations, or context future agents need before editing code. There the task document under `doc/tasks_open/` is the durable technical history and the issue is the work-tracking surface. The issue carries a distilled problem statement, acceptance criteria, and the task document's name; never paste the full document into the issue. Refer to task documents by name only, not path, because they move to `doc/tasks_closed/` when done. When an issue-only task grows, promote it: create the task document and comment its name on the issue. ## Issue Workflow Before creating an issue, search for duplicates: `gh issue list --search`, plus `rg` over `doc/tasks_open/` and `doc/tasks_closed/`. Issue bodies state the problem, the intended outcome, and acceptance criteria (a "Done when:" line works well). Include exact commands and obs