Update to teem

{
  "description": "Analyze what customers ask for in teem and suggest what to build next. Use when someone asks for top requests, themes in feedback, what to prioritize, or wants a request's status changed.",
  "included_files": [],
  "name": "feedback-analysis",
  "skill_md_contents": "---\nname: feedback-analysis\ndescription: Analyze what customers ask for in teem and suggest what to build next. Use when someone asks for top requests, themes in feedback, what to prioritize, or wants a request's status changed.\n---\n\n# Feedback analysis\n\n## Gather\n\n1. Call `list_posts` with `sort: \"top\"` for the open board. Add `status: \"open\"` or\n   `status: \"planned\"` when the question is about what's next. Follow `meta.next_cursor` when the\n   person wants the whole board. `meta.counts` gives totals by status.\n2. Call `get_post` for any request you recommend, so you have its body, verified authors and the\n   team's updates.\n3. For a theme (\"exports\", \"SSO\"), call `search` with `type: \"posts\"`, then `search` with\n   `type: \"conversations\"` to find support threads about the same thing. Conversations show\n   demand that never reached the board.\n\n## Report\n\n- Rank by votes, then by how many support conversations mention it. Give each one its title,\n  votes, status, a one-line why, and its `url`.\n- Say when a request's votes come mostly from unverified authors. A verified author's own server\n  signed who they are.\n- Keep bugs (`kind: \"bug\"`) apart from feature requests.\n- Recommend two or three to build next, with the reason in one line each. The team decides.\n- With no requests, or none on the topic, say so. Don't fill the gap with guesses.\n\n## Change a status\n\n- Call `update_status` only when the person asks for it, for one request at a time.\n- Moving a request to `planned`, `in_progress` or `shipped` emails everyone who voted. Before\n  you call it, say how many voters will get the email (`votes`) and ask to confirm. Pass\n  `notify: false` only when the person says not to email anyone.\n- `note` is public on the board. Show it to the person before you send it.\n- To announce something that shipped, use the release-drafting workflow instead: publishing a\n  changelog entry ships its linked requests and emails their voters in one step.\n- Don't call `create_post` for a customer unless the person asks. It puts a request on the public\n  board under that customer's name.\n"
}