filing-issueslisted

# Filing issues The mechanics of getting planned work into GitHub. `pr-writing` owns how an issue is worded — title shape, the Why/What structure, `<details>` folding, and style. This skill owns everything before and around that. ## Which repo Every issue is filed on `skyf0xx/hedgehog`, never on a core's own repo (e.g. the one shipping `full-stack-app` or `pwa-app`) — one issue queue to track and review, regardless of which repo's code changes. When the fix actually lands in a core repo, open the issue body with a line naming that repo and linking it, so a contributor knows where the PR belongs even though the issue itself doesn't live there. ## One issue or several Split when the parts have different reviewers, different repos, different risk, or can be worked in parallel. Keep one issue when the work is a single reviewable change, even a large one. A split gets a tracking issue plus sub-issues: - The tracking issue carries the Why, the scope boundary, and a numbered list of sub-issues with a one-line description of each. - Each sub-issue is self-contained — someone picking it up should not have to read the tracker to know what to do. - State the dependency edges explicitly, including their absence: which can be picked up now, which blocks which, and which merely prefer an order without blocking. - File the tracker first so sub-issues can reference its number, then patch the tracker with the real numbers once they exist. - Comment `Part of #<tracker>` on ea