feat(skill): add /create-merged-typings for combined beta typings packages (EXSC-237) - #2147
feat(skill): add /create-merged-typings for combined beta typings packages (EXSC-237)#21470xDEnYO wants to merge 3 commits into
Conversation
…kages Combines several in-flight PRs into one beta typings package so backend/QA can test a flow that spans more than one unmerged feature branch. Builds a throwaway "DO NOT MERGE" branch that merges the selected PRs on top of main, opens a requires-types-labelled PR to fire the Types Bindings workflow, captures the exact published beta tag from the run log, returns the backend pin, then auto-deletes the branch (the tag persists in lifi-contract-types). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 12 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
WalkthroughAdds the ChangesMerged Typings Command
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
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. Comment |
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai full review |
✅ Action performedFull review finished. Your included review limit is currently reached under our Fair Usage Limits Policy. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 40 minutes. |
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
.agents/commands/create-merged-typings.md (1)
146-148: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winRequire a backend dependency-spec check before returning the pin.
Phase 5 prints an inferred
package.jsonentry, but the only instruction is a reminder. Make matching this spec against an existing backendpackage.jsonan explicit verification step so backend pins remain usable and follow the package manager/workspace conventions.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.agents/commands/create-merged-typings.md around lines 146 - 148, Update the Phase 5 instructions in the merged-typings workflow to require checking the inferred lifi-contract-types dependency specification against an existing backend package.json before returning the pin. Instruct the agent to confirm the package manager and workspace conventions and revise the spec to match them, rather than treating backend verification as an optional reminder.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.agents/commands/create-merged-typings.md:
- Line 3: Standardize the prose spelling from “labelled” to “labeled” in both
`.agents/commands/create-merged-typings.md` line 3 and `.agents/README.md` line
71, while preserving any technical GitHub event names unchanged.
- Around line 120-129: Update the version/tag verification steps in the
create-merged-typings workflow to fail immediately when the log produces an
empty VERSION or when TAG is not found, checking each command’s exit status
before proceeding to Phase 5 or cleanup. Use paginated GitHub API requests when
inspecting repository tags so verification covers all pages, and only return the
tag or delete the temporary branch/PR after both validations succeed.
- Around line 33-38: Update the PR listing command and subsequent merge flow to
include each PR’s head repository owner/name metadata, then fetch the selected
PR head from its source repository or via refs/pull/<number>/head rather than
assuming origin/<headRefName>. Ensure forked PRs resolve to the actual selected
head before the merge steps at lines 67-68.
- Around line 105-115: The Types Bindings workflow in the documented command
sequence must not call gh run watch with an empty RUN_ID. Update this sequence
to retry gh run list with bounded waiting when no run is found, report the
failure, and exit unsuccessfully after the retry limit; invoke gh run watch only
after obtaining a non-empty run ID, while preserving the existing branch and
workflow filters.
- Around line 110-111: The workflow around gh run watch must gate Phase 5,
version parsing/tag checks, and cleanup on a successful --exit-status result.
Update the command flow so failures stop subsequent phases, report the run URL
and failing step, and preserve the branch and PR; keep the existing successful
path unchanged.
---
Nitpick comments:
In @.agents/commands/create-merged-typings.md:
- Around line 146-148: Update the Phase 5 instructions in the merged-typings
workflow to require checking the inferred lifi-contract-types dependency
specification against an existing backend package.json before returning the pin.
Instruct the agent to confirm the package manager and workspace conventions and
revise the spec to match them, rather than treating backend verification as an
optional reminder.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 2aff9971-35bd-4112-97bf-d79bc1acd6ae
📒 Files selected for processing (4)
.agents/README.md.agents/commands/create-merged-typings.md.claude/skills/create-merged-typings/SKILL.md.cursor/commands/create-merged-typings.md
…fs, run/tag guards - Phase 2: fetch refs/pull/<N>/head instead of origin/<headRefName> (fork PR heads don't exist on origin; same-name branches could merge the wrong ref) - Phase 4: bounded retry for the Types Bindings run id (jq yields literal "null" on an empty list); fail hard on a missing "New version:" log line; verify the published tag via exact-ref lookup instead of the paginated /tags list - Phase 5: make backend package.json spec verification an explicit step; split cleanup so gh pr close no longer tries to delete a branch still checked out in the worktree - Standardize prose to "labeled" (README table + description) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Which Linear task belongs to this PR?
Fixes EXSC-237
https://linear.app/lifi-linear/issue/EXSC-237/add-create-merged-typings-skill-for-combined-beta-typings-packages
Came out of the API Expansion Retro — backend blocked when a flow spans two unmerged SC feature PRs because each branch's
-betatypings package doesn't compose with the other.Why did I implement it this way?
Problem. Each feature branch publishes a
-betatypings tag generated from that branch alone (types.yaml→lifinance/lifi-contract-types), and the-betaversion is a single global counter. So no published beta ever contains two in-flight branches together. When backend/QA needs to test a flow that spans two unmerged branches, they currently hand-cut a throwaway merge branch to get one combined package. This skill automates exactly that.Approach.
types.yamland the auto-label workflow both skip draft PRs, so the throwaway PR must be non-draft + carryrequires-types. The full contracts CI suite will run and mostly fail on a merge branch — that is expected and explicitly called out as ignorable; only theTypes Bindingscheck matters.-betacounter is global, "latest tag" is unreliable — the skill readsNew version:from this run's log and verifies the tag exists inlifi-contract-typesbefore returning it.lifi-contract-types, so once captured the throwaway branch/PR is deleted; the tag keeps working for backend. On a Types Bindings failure the branch is kept for debugging.Follows the repo's agent-asset convention: source of truth
.agents/commands/create-merged-typings.md, symlinked to.cursor/commands/and.claude/skills/<name>/SKILL.md, with the.agents/README.mdcommand table updated.Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)