[yichengq]

Pairs with getdoable/trd#615, which adds target_app to the Round and names the app in the copy prompt.

Problem

The copy prompt named only the Doable organization, which is the account, not the product. One organization can test several apps (org "sockswow" tests teamspire.vercel.app), so an agent whose workspace has a repository named like the organization and another that serves the tested app routed to the wrong one.

What changes (0.2.13)

• record-round reads the Round's optional target_app ({name, entry_url} or null; targetApp also accepted), validates it, keeps it as targetApp in the round file, and prints App under test: <name> (<entry URL>) (only the URL without a name). A Round without it, or with null, records as before.
• doable-answer-questions SKILL.md
  • Step 1: the prompt may name the app before the organization; the organization name and slug identify only the Doable account for the connection check, never which product or repository to investigate.
  • Step 6: the product under test is the Round's target_app (or else the app the prompt names); route to the repositories that serve it, and never route by the organization name.
  • The wrong-workspace stop is unchanged. A missing name or host match does not stop the agent: environment names are often generic and deploy hosts are often not in the repository.
• Version 0.2.13 in package.json, the three plugin manifests, CLIENT, verify-release.mjs, README, CHANGELOG; TESTING.md scenario 28.

Compatibility: older backends send no target_app, and the helper records those Rounds as before. Plugins before 0.2.13 ignore the field but still read the app from the prompt text.

Tests

• New helper test: snake_case and camelCase target_app, missing and null values, and five invalid shapes.
• npm test: 5 passed (release verification reports doable-code-context@0.2.13: 3 Skill(s)).
• claude plugin validate ./plugins/doable-code-context: passed. Cursor manifest schema check: passed.

🤖 Generated with Claude Code