القائمة
Run tests and/or analysis across Dart/Flutter workspace packages and fix failures
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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