Skip to content
cccskills
FreePublished on GitHub

typescript-compile-check-resilient-fallback

Run TypeScript checks without generating output files, with a fallback when the usual commands fail. The workflow records existing errors, filters diagnostics to changed files, and repeats checks after fixes to assess the modified code.

OriginalShow the original description

A resilient workflow for running TypeScript compile checks (tsc --noEmit) that falls back gracefully when npx or direct binary invocations fail, and distinguishes pre-existing errors from newly introduced ones.

See how to install

Good for

  • Check TypeScript files after editing
  • Retry checks when npx or the local binary fails
  • Separate existing errors from changed-file diagnostics
  • Recheck modified files after fixing type errors

Files included (2)

  • SKILL.md4.2 KB
  • .skill_id57 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

TypeScript Compile-Check Resilient Fallback

Use this workflow whenever you need to verify that TypeScript files compile cleanly after creating or modifying them, especially in environments where npx or direct ./node_modules/.bin/tsc invocations may return unexpected errors.


Step 1 — Attempt Primary Invocation

Run the compile check with run_shell using the standard approach:

npx tsc --noEmit

or, if you already know the project root:

./node_modules/.bin/tsc --noEmit

Evaluate the result:

  • If it exits cleanly (exit code 0, no unexpected output) → done.
  • If it exits with TypeScript diagnostic errors → proceed to Step 3.
  • If it exits with an unknown / tool-level error (e.g., npx not found, permission denied, spawn error, unclear non-zero exit unrelated to TS diagnostics) → proceed to Step 2.

Step 2 — Fallback via shell_agent

When the primary invocation fails with an unknown error, delegate to shell_agent so it can resolve environment issues automatically:

Task: "From the project directory <PROJECT_DIR>, run node node_modules/typescript/bin/tsc --noEmit and report all TypeScript diagnostic errors."

Example shell_agent task string:

From /path/to/project, run:
  node node_modules/typescript/bin/tsc --noEmit
Capture the full stdout/stderr output and return it.

shell_agent will handle PATH issues, working-directory changes, and retry on transient failures automatically.


Step 3 — Filter Pre-Existing Errors

TypeScript projects frequently have pre-existing errors in files you did not touch. To avoid false regressions:

  1. Identify the baseline error count for the project (e.g., determined at task start or documented in task context). A common baseline is 11 pre-existing errors in unrelated files.
  2. Collect the full diagnostic list from tsc output.
  3. Filter to keep only errors whose file path matches a file you created or modified in this task.
  4. Evaluate:
    • Zero errors in your new/modified files → ✅ no regression introduced.
    • One or more errors in your new/modified files → ❌ fix them before proceeding.

Filtering heuristic (pseudocode)

all_errors   = parse_tsc_output(tsc_stdout)
my_files     = [list of files created/modified in this task]
new_errors   = [e for e in all_errors if e.file in my_files]

if len(new_errors) == 0:
    print("✅ No new TypeScript errors introduced.")
else:
    for err in new_errors:
        print(f"❌ {err.file}:{err.line} — {err.message}")
    raise Exception("Fix TypeScript errors before continuing.")

Step 4 — Fix and Re-Run

If new errors are found:

  1. Fix the errors in your file(s).
  2. Repeat from Step 1.

Decision Tree Summary

run_shell: npx tsc --noEmit
        │
        ├─ clean exit ──────────────────────────────► ✅ Done
        │
        ├─ TS diagnostic errors ────────────────────► Step 3 (filter)
        │
        └─ unknown/tool error
                │
                └─ shell_agent: node .../tsc --noEmit
                        │
                        ├─ TS diagnostic errors ────► Step 3 (filter)
                        └─ clean exit ──────────────► ✅ Done

Notes

  • Always run tsc from the project root (where tsconfig.json lives).
  • The node node_modules/typescript/bin/tsc invocation is the most portable fallback because it bypasses npx, shell PATH lookups, and binary permission issues entirely.
  • When the baseline error count is unknown, run tsc before making any changes and record the count; that becomes your baseline.
  • Only report/act on errors in files you own; never attempt to fix pre-existing errors in third-party or unrelated project files unless explicitly asked.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Prepare audio stems, the separate parts of a track, for mixing by matching their durations with silence, loops, or crossfades. Verify each generated and processed file before moving to the next production step.

  • Match audio parts with different durations
  • Extend drums and melodic parts using suitable methods
  • Check audio specifications before mixing
HKUDS/OpenSpace7.8KUpdated Aug 13, 2026

Produce audio in separate stems, meaning individual instrument tracks, and verify each output as you go. Align track lengths with silence, loops, or crossfades, then apply effects, mix a master, and package the files.

  • Align instrument tracks to a reference audio file
  • Choose how to extend tracks that are too short
  • Verify audio properties after generation and effects
HKUDS/OpenSpace7.8KUpdated Aug 13, 2026

Build serverless endpoints that relay external API requests for a dashboard while keeping API keys on the server. Includes Vercel examples for input checks, caching, cross-origin access, and consistent JSON responses.

  • Connect a dashboard to external APIs without exposing API keys
  • Create endpoints for stock quotes and news
  • Standardize API responses and error handling
HKUDS/OpenSpace7.8KUpdated Aug 13, 2026

Produce a master track and separate audio parts through a structured Python workflow. Apply filters and reverb, export WAV files with consistent settings, package them in a ZIP archive, and check that the deliverables meet the requested specifications.

  • Export a master track with separate audio parts
  • Apply filters and reverb to audio
  • Check duration and format across deliverables
HKUDS/OpenSpace7.8KUpdated Aug 13, 2026

Keep document creation moving when web searches and page retrieval repeatedly fail. The skill preserves the original task, uses the model’s existing knowledge, and clearly identifies information that could not be checked against external sources.

  • Continue drafting after repeated web retrieval failures
  • Preserve task requirements during network errors
  • Mark information that could not be externally verified
HKUDS/OpenSpace7.8KUpdated Aug 13, 2026

When Python execution repeatedly fails in execute_code_sandbox, use a file-based alternative: save the script, run it through the shell, and capture results or errors. The guidance covers paths, imports, timeouts, structured output, and optional cleanup.

  • Retry Python work through the shell after repeated sandbox failures
  • Run longer tasks with an adjusted timeout
  • Execute Python work that needs multiple files or system utilities
HKUDS/OpenSpace7.8KUpdated Aug 13, 2026

See all skills by HKUDS

Report a problem with this skill