dotnet
Attempts ONE alternative fix for a bug, tests it empirically, and reports results. ALWAYS explores a DIFFERENT approach from existing PR fixes. Use when CI or an agent needs to try independent fix alternatives. Invoke with problem description, test command, target files, and optional hints.
bunx add-skill dotnet/maui -s try-fixLoadingβ¦
Attempts ONE fix for a given problem. Receives all context upfront, tries a single approach, tests it, and reports what happened.
Every invocation: Review existing fixes β Think of DIFFERENT approach β Implement and test β Report results
π¨ Try-fix runs MUST be executed ONE AT A TIME - NEVER in parallel.
Why: Each try-fix run:
If run in parallel:
Correct pattern: Run attempt-1, wait for completion, then run attempt-2, etc.
All inputs are provided by the invoker (CI, agent, or user).
| Input |
|---|
| Required |
|---|
| Description |
|---|
| Problem | Yes | Description of the bug/issue to fix |
| Test command | Yes | Repository-specific script to build, deploy, and test (e.g., pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform android -TestFilter "Issue12345"). ALWAYS use this script - NEVER manually build/compile. |
| Target files | Yes | Files to investigate for the fix |
| Platform | Yes | Target platform (android, ios, windows, maccatalyst) |
| Hints | Optional | Suggested approaches, prior attempts, or areas to focus on |
| Baseline | Optional | Git ref or instructions for establishing broken state (default: current state) |
| state_file | Optional | Path to PR agent state file (e.g., CustomAgentLogsTmp/PRState/pr-12345.md). If provided, try-fix will append its results to the Fix Candidates table. |
Results reported back to the invoker:
| Field | Description |
|---|---|
approach | What fix was attempted (brief description) |
files_changed | Which files were modified |
result | Pass, Fail, or Blocked |
analysis | Why it worked, or why it failed and what was learned |
diff | The actual code changes made (for review) |
FIRST STEP: Create output directory before doing anything else.
# Set issue/PR number explicitly (from branch name, PR context, or manual input)
$IssueNumber = "<ISSUE_OR_PR_NUMBER>" # Replace with actual number
# Find next attempt number
$tryFixDir = "CustomAgentLogsTmp/PRState/$IssueNumber/try-fix"
$existingAttempts = (Get-ChildItem "$tryFixDir/attempt-*" -Directory -ErrorAction SilentlyContinue).Count
$attemptNum = $existingAttempts + 1
# Create output directory
$OUTPUT_DIR = "$tryFixDir/attempt-$attemptNum"
New-Item -ItemType Directory -Path $OUTPUT_DIR -Force | Out-Null
Write-Host "Output directory: $OUTPUT_DIR"
Required files to create in $OUTPUT_DIR:
| File | When to Create | Content |
|---|---|---|
baseline.log | After Step 2 (Baseline) | Output from EstablishBrokenBaseline.ps1 proving baseline was established |
approach.md | After Step 4 (Design) | What fix you're attempting and why it's different from existing fixes |
result.txt | After Step 6 (Test) | Single word: Pass, Fail, or Blocked |
fix.diff | After Step 6 (Test) | Output of git diff showing your changes |
test-output.log | After Step 6 (Test) | Full output from test command |
analysis.md | After Step 6 (Test) | Why it worked/failed, insights learned |
Example approach.md:
## Approach: Geometric Off-Screen Check
Skip RequestApplyInsets for views completely off-screen using simple bounds check:
`viewLeft >= screenWidth || viewRight <= 0 || viewTop >= screenHeight || viewBottom <= 0`
**Different from existing fix:** Current fix uses HashSet tracking. This approach uses pure geometry with no state.
Example result.txt:
Pass
The skill is complete when:
π¨ CRITICAL: What counts as "Pass" vs "Fail"
| Scenario | Result | Explanation |
|---|---|---|
| Test command runs, tests pass | β Pass | Actual validation |
| Test command runs, tests fail | β Fail | Fix didn't work |
| Code compiles but no device available | β οΈ Blocked | Device/emulator unavailable - report with explanation |
| Code compiles but test command errors | β Fail | Infrastructure issue is still a failure |
| Code doesn't compile | β Fail | Fix is broken |
NEVER claim "Pass" based on:
Pass REQUIRES: The test command executed AND reported test success.
If device/emulator is unavailable: Report result.txt = Blocked with explanation. Do NOT manufacture a Pass.
Exhaustion criteria: Stop after 3 iterations if:
Never stop due to: Compile errors (fix them), infrastructure blame (debug your code), giving up too early.
MANDATORY: Review what has already been tried:
Check for existing PR changes:
git diff origin/main HEAD --name-only
If state_file provided, review prior attempts:
Identify what makes your approach DIFFERENT:
Examples of alternatives:
Review the provided context:
Do NOT search for additional context. Work with what's provided.
π¨ ALWAYS use EstablishBrokenBaseline.ps1 - NEVER manually revert files.
# Capture baseline output as proof it was run
pwsh .github/scripts/EstablishBrokenBaseline.ps1 *>&1 | Tee-Object -FilePath "$OUTPUT_DIR/baseline.log"
The script auto-detects and reverts fix files to merge-base state while preserving test files. Will fail fast if no fix files detected - you must be on the actual PR branch. Optional flags: -BaseBranch main, -DryRun.
Verify baseline was established:
# baseline.log should contain "Baseline established" and list of reverted files
Select-String -Path "$OUTPUT_DIR/baseline.log" -Pattern "Baseline established"
If the script fails with "No fix files detected": You're likely on the wrong branch. Checkout the actual PR branch with gh pr checkout <PR#> and try again.
If something fails mid-attempt: pwsh .github/scripts/EstablishBrokenBaseline.ps1 -Restore
Read the target files to understand the code.
Key questions:
Based on your analysis and any provided hints, design a single fix approach:
If hints suggest specific approaches, prioritize those.
IMMEDIATELY create approach.md in your output directory:
@"
## Approach: [Brief Name]
[Description of what you're changing and why]
**Different from existing fix:** [How this differs from PR's current approach]
"@ | Set-Content "$OUTPUT_DIR/approach.md"
Implement your fix. Use git status --short and git diff to track changes.
π¨ CRITICAL: ALWAYS use the provided test command script - NEVER manually build/compile.
For .NET MAUI repository: Use BuildAndRunHostApp.ps1 which handles:
# Capture output to test-output.log while also displaying it
pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform <platform> -TestFilter "<filter>" *>&1 | Tee-Object -FilePath "$OUTPUT_DIR/test-output.log"
Testing Loop (Iterate until SUCCESS or exhausted):
Behavioral constraints:
See references/compile-errors.md for error patterns and iteration examples.
Before reverting, save ALL required files to $OUTPUT_DIR:
# 1. Save result (MUST be exactly "Pass", "Fail", or "Blocked")
"Pass" | Set-Content "$OUTPUT_DIR/result.txt" # or "Fail"
# 2. Save the diff
git diff | Set-Content "$OUTPUT_DIR/fix.diff"
# 3. Save test output (should already exist from Step 6)
# Copy-Item "path/to/test-output.log" "$OUTPUT_DIR/test-output.log"
# 4. Save analysis
@"
## Analysis
**Result:** Pass/Fail/Blocked
**What happened:** [Description of test results]
**Why it worked/failed:** [Root cause analysis]
**Insights:** [What was learned that could help future attempts]
"@ | Set-Content "$OUTPUT_DIR/analysis.md"
Verify all required files exist:
@("baseline.log", "approach.md", "result.txt", "fix.diff", "analysis.md", "test-output.log") | ForEach-Object {
if (Test-Path "$OUTPUT_DIR/$_") { Write-Host "β
$_" }
else { Write-Host "β MISSING: $_" }
}
Analysis quality matters. Bad: "Didn't work". Good: "Fix attempted to reset state in OnPageSelected, but this fires after layout measurement. The cached value was already used."
ALWAYS restore, even if fix failed.
pwsh .github/scripts/EstablishBrokenBaseline.ps1 -Restore
git checkout -- .
Provide structured output to the invoker:
## Try-Fix Result
**Approach:** [Brief description of what was tried]
**Files Changed:**
- `path/to/file.cs` (+X/-Y lines)
**Result:** β
PASS / β FAIL
**Analysis:**
[Why it worked, or why it failed and what was learned]
**Diff:**
```diff
[The actual changes made]
Exhausted: Yes/No Reasoning: [Why you believe there are/aren't more viable approaches]
**Determining Exhaustion:** Set `exhausted=true` when you've tried the same fundamental approach multiple times, all hints have been explored, failure analysis reveals the problem is outside target files, or no new ideas remain. Set `exhausted=false` when this is the first attempt, failure analysis suggests a different approach, hints remain unexplored, or the approach was close but needs refinement.
### Step 10: Update State File (if provided)
If `state_file` input was provided and file exists:
1. **Read current Fix Candidates table** from state file
2. **Determine next attempt number** (count existing try-fix rows + 1)
3. **Append new row** with this attempt's results:
| # | Source | Approach | Test Result | Files Changed | Notes |
|---|--------|----------|-------------|---------------|-------|
| N | try-fix #N | [approach] | β
PASS / β FAIL | [files] | [analysis] |
4. **Set exhausted status** based on your determination above
5. **Commit state file:**
```bash
git add "$STATE_FILE" && git commit -m "try-fix: attempt #N (exhausted=$EXHAUSTED)"
If no state file provided: Skip this step (results returned to invoker only).
Ownership rule: try-fix updates its own row AND the exhausted field. Never modify:
| Situation | Action |
|---|---|
| Problem unclear | Report "insufficient context" - specify what's missing |
| Test command fails to run | Report build/setup error with details |
| Test times out | Report timeout, include partial output |
| Can't determine fix approach | Report "no viable approach identified" with reasoning |
| Git state unrecoverable | Run git checkout -- . and git clean -fd if needed |
β Null/state checks - Guard against unexpected null or state β Lifecycle timing - Move code to correct lifecycle event β Cache invalidation - Reset stale cached values
β Massive refactors - Keep changes minimal β Suppressing symptoms - Fix root cause, not symptoms β Multiple unrelated changes - ONE focused fix per invocation
See references/example-invocation.md for a complete example with sample inputs.
Use when you have lint errors, formatting issues, or before committing code to ensure it passes CI.
Use when you need to run Flow type checking, or when seeing Flow type errors in React code.
Use when you want to validate changes before committing, or when you need to check all React contribution requirements.
Use when feature flag tests fail, flags need updating, understanding @gate pragmas, debugging channel-specific test failures, or adding new flags to React.