feat(skills): roster-discovery hardening — use run artist context; never trust the org list alone

[sweetmantech]

Part of recoupable/chat#1837 (defense-in-depth; pairs with recoupable/api#742, the primary context-injection fix). Base: main.

Why

Two live failures (#1837 evidence): headless agents ignored the artist their run carried, roster-guessed, resolved GET /artists?org_id=$RECOUP_ORG_ID — the org's roster ("Rostrum Pacific", 1 unrelated artist) — and declared an artist missing that sat in the 59-artist personal roster (chats fd8e8b26, aa4eb91f). Implicit-artist tasks delivered 1/4 across two benchmark rounds; the id-embedding task went 2/2.

Change (recoup-platform-api-access SKILL.md, roster-discovery section)

1. Skip discovery when the run provides artist_account_id — use it directly; don't search the roster to "confirm" a given artist.
2. ⚠️ org_id-scoped lists are the org's roster, not yours — never conclude an artist doesn't exist from it alone; check the personal GET /api/artists first (with the real failure quoted as the cautionary example).

CI green: check_resolvable, run_resolver_eval (structural), validate_manifests.

With api#742 merged, headless runs will actually have the artist context this guidance points at; this skill change protects the no-context case and older sandboxes.

🤖 Generated with Claude Code

---

Summary by cubic

Hardened roster discovery guidance in recoup-platform-api-access to use run-provided artist context and avoid false “missing artist” results from org-scoped lists. Addresses recoupable/chat#1837 and protects headless runs and older sandboxes.

• Bug Fixes
  • Skip discovery when artist_account_id is present; call /api/artists/{id}/* directly.
  • Treat GET /artists?org_id=… as the org’s roster only; never conclude absence from it. Check personal GET /api/artists first.

^{Written for commit f684607. Summary will update on new commits.}

[coderabbitai]

Warning

Review limit reached

@sweetmantech, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 29 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: b6ef06ee-ca53-446a-96f0-2316c5aaec2a

📥 Commits

Reviewing files that changed from the base of the PR and between 006ff76 and f684607.

📒 Files selected for processing (1)

• skills/recoup-platform-api-access/SKILL.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/roster-discovery-hardening

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="skills/recoup-platform-api-access/SKILL.md">

<violation number="1" location="skills/recoup-platform-api-access/SKILL.md:34">
P3: Placeholder `{that id}` is conversational and doesn't match the variable name `artist_account_id` introduced in the same sentence. An agent reading `call /api/artists/{that id}/*` may not resolve what value to substitute. Use `{artist_account_id}` for consistency with the rest of the skill's named-placeholder convention.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Placeholder {that id} is conversational and doesn't match the variable name artist_account_id introduced in the same sentence. An agent reading call /api/artists/{that id}/* may not resolve what value to substitute. Use {artist_account_id} for consistency with the rest of the skill's named-placeholder convention.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At skills/recoup-platform-api-access/SKILL.md, line 34:

<comment>Placeholder `{that id}` is conversational and doesn't match the variable name `artist_account_id` introduced in the same sentence. An agent reading `call /api/artists/{that id}/*` may not resolve what value to substitute. Use `{artist_account_id}` for consistency with the rest of the skill's named-placeholder convention.</comment>

<file context>
@@ -30,8 +30,20 @@ If neither var is set, ask the user to authenticate — don't retry blindly.
-**Roster discovery:** `GET /accounts/id` → `GET /artists` (your roster; `org_id`
-optional — orgs are often empty, so don't stop when `organizations` is `[]`).
+**Skip discovery when the run gives you the artist.** If your context/system
+prompt provides an `artist_account_id` (scheduled tasks and headless runs pass
+one), **use it directly** — call `/api/artists/{that id}/*` and get to work. Do
+not search the roster to "confirm" an artist you were already given.
</file context>

[sweetmantech]

Closing per review — superseded by recoupable/api#742, and the residual guidance was built on a wrong assumption.

1. The primary fix covers it. api#742's injected context block already instructs the agent: "artist_account_id: (the active artist for this run — use for /api/artists/{id}/ and roster operations; do NOT search the roster for it)"* — preview-verified (the 0/2 implicit-artist benchmark passed first-run with 0 roster lookups). Duplicating that in the skill adds surface without adding behavior.

2. The "check the personal roster before concluding absence" guidance assumed personal is the source of truth — it isn't. Artists legitimately exist in org rosters AND personal rosters as different sets; neither list is authoritative for "does this artist exist."

3. The API layer already resolves artist ids across both scopes: checkAccountArtistAccess grants /api/artists/{id}/* access via personal account_artist_ids or shared org membership — no org_id required. With #742 handing agents the id, discovery topology no longer matters for scheduled runs.

No skill change needed. recoupable/chat#1837 updated accordingly.