Menú
Run tests and/or analysis across Dart/Flutter workspace packages and fix failures
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Dart/Flutter workspace orchestrator (multi-package, git submodules). Use proactively when working in any multi-package workspace — run tests/analysis across packages (parallel, cached), commit submodule work (auto-push + parent ref sync), check workspace-wide git state (status/diff/push/pull/check). Not for single-file tests, git branch surgery, or single-package repos.
Official Dart/Flutter MCP server (tools appear as mcp__dart__*). Use for the live-app runtime loop (launch, hot reload, runtime errors, screenshots, widget tree + driver interaction), pub.dev search, and grepping/reading dependency source. NOT for workspace-wide test/analyze/git — glittering stays the default there. If a project lacks .mcp.json, symlink the canonical one (~/nixfiles/dotfiles/ai/mcp.json) — never write a copy.
Comprehensively review an implementation plan or design doc — grounds every claim against the real codebase, critiques across correctness/architecture/risk/completeness lenses, adversarially verifies flaws, and returns a prioritized verdict with concrete fixes. Use when the user asks to review, critique, sanity-check, or find flaws in a plan file (e.g. "review this plan", "critique my plan at <path>", "is this plan sound?"). After reporting, it asks which items to apply, revises the plan, and emits a cold-start handoff brief to implement the revised plan in a fresh session. SKIP for authoring a new plan (that's plan mode) or reviewing code/PRs (use code-review).
Bring a multi-package workspace fully in sync when moving between machines — commit (with approval), push, pull, verify clean. State-driven; dirty repos trigger the commit ritual first. Command syntax lives in the glittering skill.
Multi-package project orchestrator — git (status, diff, commit, push, pull, check), Dart/Flutter test, analyze, stats, pub get/upgrade
| name | glitterfix |
| description | Run tests and/or analysis across Dart/Flutter workspace packages and fix failures |
| disable-model-invocation | true |
Run tests and/or analysis across all Dart/Flutter packages in the workspace and fix issues.
/glitterfix [$ARGUMENTS]
Arguments:
tests — run tests and fix failuresanalyze — run analysis and fix issuesfix — auto-fix without promptingblink_highlight,blink_core to target specific packagesCombine freely: /glitterfix fix tests blink_highlight, /glitterfix analyze, /glitterfix fix.
tests, analyze, or both), fix flag, and package filterglittering get --path <workspace_root> [--filter <filter>] to ensure dependencies are resolvedglittering analyze --path <workspace_root> [--filter <filter>]details_file in the JSON) and list: severity, file:line:col, message, codefix was NOT passed: ask the user whether to auto-fixfix was passed: proceed to Phase 2For each package with errors or warnings, spawn a parallel Agent (one per package) with this prompt:
Fix analysis issues in
<package_path>.Workspace root:
<workspace_root>This package is part of a multi-package workspace. Runglittering status --path <workspace_root>if you need to understand the package layout.Issues:
<severity><file>:<line>:<col>—<message>(<code>) (list all issues for this package)Steps:
- Read the files with issues and understand the context
- Read README.md and CLAUDE.md in the package if they exist
- Fix each issue. Prefer fixes that address root causes over suppressing warnings
- If a fix requires cross-package changes: STOP and describe what you found
- Verify:
cd <workspace_root>/<package_path> && dart analyze- Report what you fixed and any remaining issues
glittering analyze --path <workspace_root> [--filter <filter>] to verifyglittering test --path <workspace_root> [--filter <filter>]error status: check the error message. If it's a compilation error, run glittering analyze on that package to get details. If it's a missing dependency, re-run glittering get. Resolve before proceedingfail status, read the session detail file (from details_file in the JSON) and list: test name, file:line, truncated error (first 2 lines)glittering analyze --path <workspace_root> [--filter <filter>] on failing packages — analysis errors are often the root cause of test failures. If found, fix analysis errors first and re-run tests before proceeding to Phase 2fix was NOT passed: ask the user whether to auto-fixfix was passed: proceed to Phase 2For each package with failures, spawn a parallel Agent (one per package) with this prompt:
Fix failing tests in
<package_path>.Runner:
<dart|flutter> testWorkspace root:<workspace_root>This package is part of a multi-package workspace. Runglittering status --path <workspace_root>if you need to understand the package layout.Failures:
<test_name>in<test_file>:<line>—<error_summary>(list all failures for this package)Steps:
- Read the failing test file(s) and the source code they test
- Read README.md and CLAUDE.md in the package if they exist
- Determine: is the test stale (source changed) or is the source buggy?
- If the fix is clear and contained: make the fix
- If ambiguous or requires cross-package changes: STOP and describe what you found
- Verify:
cd <workspace_root>/<package_path> && timeout 90 <runner> test- Verify:
cd <workspace_root>/<package_path> && dart analyze- Report what you fixed and any remaining issues
glittering test --path <workspace_root> [--filter <filter>] to verify the full suiteglittering git commit