Earlier quoted context omitted.
Neither, you should have a third conceptual tool to encapsulate the overall product, then once you have a feature spec, you cut tickets for the subcomponents. Depending on the API complexity, I personally would either define the spec as a PR to our API doc repo, or define it as part of the backend task.
If I have a third tool, I might as well use that tool for all my issues anyways then? Especially when a tool like Linear can integrate with GH anyways.
Concrete development work gets put into GitHub Issues. Most people on the business side don't have access to GitHub and wouldn't be comfortable with it. Smaller stuff may not get a GitHub Issue. It may just live in Basecamp. Technical stuff that the business will never care to see may only live in GitHub.
It's a new process I'm experimenting with. We'll see if it ends up being too disjointed.