Update to Tuist

{
  "name": "compare-gradle-builds",
  "description": "Compares two Gradle build runs to identify duration regressions, cache changes, and task outcome differences. Can be invoked with build IDs, dashboard URLs, or branch names.",
  "included_files": [],
  "skill_md_contents": "---\nname: compare-gradle-builds\ndescription: Compares two Gradle build runs to identify duration regressions, cache changes, and task outcome differences. Can be invoked with build IDs, dashboard URLs, or branch names.\n---\n\n# Compare Gradle Builds\n\n## Quick Start\n\nYou'll typically receive two build identifiers (IDs, dashboard URLs, or branch names). Follow these steps using the Tuist MCP tools:\n\n1. Use `list_gradle_builds` to find builds on each branch.\n2. Use `get_gradle_build` for both base and head builds.\n3. Use `list_gradle_build_tasks` to fetch task-level details for both builds.\n4. Compare duration, status, cache hit rates, and task outcomes.\n5. Summarize regressions, improvements, and recommendations.\n\nIf only one identifier is provided, use the project's default branch as the baseline.\n\n## Step 1: Resolve Builds\n\n### If base/head are build IDs or dashboard URLs\n\nFetch each directly with `get_gradle_build(build_run_id: \"<id>\")`.\n\n### If base/head are branch names\n\nList recent builds on each branch and pick the latest:\n\n```\nlist_gradle_builds(account_handle: \"...\", project_handle: \"...\", git_branch: \"<branch>\", page_size: 1)\n```\n\nThen fetch full details with `get_gradle_build(build_run_id: \"<id>\")`.\n\n### Defaults\n\n- If no base is provided, use the project's default branch (usually `main`).\n- If no head is provided, detect the current git branch with `git rev-parse --abbrev-ref HEAD`.\n\n## Step 2: Compare Top-Level Metrics\n\nAfter fetching both builds, compare:\n\n| Metric | What to check |\n|---|---|\n| `duration_ms` | Flag if head is >10% slower than base |\n| `status` | Flag if base succeeded but head failed |\n| `tasks_local_hit_count` | Compare local cache hit counts |\n| `tasks_remote_hit_count` | Compare remote cache hit counts |\n| `tasks_executed_count` | Compare how many tasks ran (higher means more cache misses) |\n| `cacheable_tasks_count` | Note if the cacheable task count changed |\n| `cache_hit_rate` | `(local_hits + remote_hits) / cacheable_tasks_count * 100` |\n| `requested_tasks` | Ensure both builds ran the same tasks for a fair comparison |\n| `gradle_version` / `java_version` | Note environment differences that affect comparability |\n\nCompute the cache miss delta: `base_executed - head_executed`. Positive means head has fewer executions (improvement). Negative means regression.\n\n## Step 3: Drill Into Tasks\n\nUse `list_gradle_build_tasks` for both builds. Compare `duration_ms` and `outcome` per task path.\n\nLook for:\n- Tasks that changed from `local_hit` or `remote_hit` to `executed` (cache invalidation).\n- Tasks that changed from `executed` to `local_hit` or `remote_hit` (cache improvement).\n- Tasks that changed to `failed` (new failures).\n- New tasks that appeared in the head build.\n- Tasks with significant duration increases.\n\nSort by absolute time difference to find the biggest regressions.\n\n### Filtering tasks\n\nUse the `outcome` filter to focus on specific task states:\n- `list_gradle_build_tasks(build_run_id: \"<id>\", outcome: \"executed\")` to see only executed tasks.\n- `list_gradle_build_tasks(build_run_id: \"<id>\", outcome: \"failed\")` to see failures.\n- `list_gradle_build_tasks(build_run_id: \"<id>\", cacheable: true)` to see only cacheable tasks.\n\n## Step 4: Investigate Duration Regressions\n\nIf the head build is significantly slower:\n\n1. Check if `requested_tasks` differ (different task sets are not directly comparable).\n2. Check if cache hit rate dropped, which would explain longer builds.\n3. Look for tasks that changed from cache hits to `executed`.\n4. Check if `gradle_version` or `java_version` changed, which can affect performance.\n5. Compare individual task durations to find the biggest contributors.\n\n## Step 5: Investigate Cache Changes\n\nCompare task-level cache behavior:\n\n- **Hit rate dropped**: Possible causes include dependency changes, build configuration changes, or Gradle version updates that alter cache keys.\n- **Hit rate improved**: Likely due to better cache warming or fewer source changes.\n- **Task count changed**: New modules or tasks added/removed.\n- **Outcome changes**: Tasks moving between `up_to_date`, `local_hit`, `remote_hit`, and `executed` reveal cache effectiveness.\n\n## Step 6: Check Build Context\n\nCompare environment details:\n\n- `gradle_version` and `java_version`: Different versions can affect build times and cache validity.\n- `is_ci`: CI vs local builds may have different performance characteristics.\n- `git_branch` and `git_commit_sha`: Verify the builds are from the expected commits.\n- `root_project_name`: Ensure both builds are from the same project structure.\n\n## Summary Format\n\nProduce a summary with:\n\n1. **Overall verdict**: Better, worse, or neutral compared to base.\n2. **Duration**: Absolute and percentage change in `duration_ms`.\n3. **Cache hit rate**: Change in hit rate with explanation.\n4. **Task outcomes**: Notable outcome changes (hit to executed, new failures).\n5. **Status**: Any status changes (success to failure or vice versa).\n6. **Environment**: Note any environment differences that affect comparability.\n7. **Recommendations**: Actionable next steps based on findings.\n\nExample:\n\n```\nBuild Comparison: base (abc123 on main) vs head (def456 on feature-x)\n\nDuration: 45200ms -> 62800ms (+39%) -- REGRESSION\nCache hit rate: 85% -> 72% (-13%) -- 8 tasks went from cache hit to executed\nStatus: success -> success\n\nRoot cause: Cache hit rate dropped because 8 tasks had invalidated caches.\nThe :app:compileKotlin task changed from remote_hit to executed,\ncascading to 7 downstream tasks.\n\nRecommendations:\n- Investigate which source changes invalidated :app:compileKotlin cache\n- Consider splitting large modules to reduce cache invalidation cascading\n```\n\n## Done Checklist\n\n- Resolved both base and head builds\n- Compared duration, cache, and status metrics\n- Drilled into task-level outcomes for both builds\n- Identified root causes for any regressions\n- Provided actionable recommendations\n"
}