agentleFS
linuxfoundationlinuxfoundation/insights/.claude/skills/preflight/SKILL.md

preflight

Skill288 starsChanged 52 days agoMITView on GitHub

Pre-PR validation — license headers, format, lint, TypeScript check, build, and protected file check. Use before submitting any PR, to check if code is ready, validate changes, or verify a branch before review.

  • Commits and pushes

47 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use ship, report and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • AWSSkill

    ship

    Finalize dev work on an issue branch — update docs, push, and open a PR.

    Also in 5 projects that use this

  • MicrosoftSkill

    report

    Turn an exploration (threads, findings, charts) into a single Markdown report — note, blog post, executive summary, KPI dashboard, slide brief, or multi-section analytical report, with embedded charts.

    Also in 3 projects that use this

  • Google CloudSkill

    triage

    Gather context on a change or bug and plan the implementation.

    Also in 4 projects that use this

  • AnthropicSkill

    status

    Case status summary by audience — client-facing (plain language), internal (for the professor), or court-ready (formal caption format per local rules). Same facts, different framing and depth. Use when a student needs to update the client, brief the professor, or prepare a court status report.

    Also in 3 projects that use this

  • GitHubSkill

    refactor

    Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.

    Also in 3 projects that use this

  • MicrosoftSkill

    caveman

    Ultra-compressed response style that reduces output token count while preserving technical accuracy, with intensity levels and auto-clarity safety rules

    Also in 3 projects that use this

  • +2 more from microsoft

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 8 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 42 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run each check in order, report results clearly, and help fix any issues found.

    line 13
  2. Very specific:

    All script commands run from the frontend/ directory unless otherwise noted.

    line 15
  3. Distinctive:

    Before running any validation, check the state of the working tree:

    line 19
  4. Very specific:

    Every source file (.ts, .vue, .js, .scss) must have the copyright header.

    line 38
  5. Very specific:

    If any files are missing headers, add them using the scripts/add-license.js script or manually.

    line 51
  6. Distinctive:

    If files were modified, stage them:

    line 62
  7. Distinctive:

    If there are lint errors, fix them.

    line 75
  8. Distinctive:

    If any fixes were applied in Checks 1–3, re-run lint to confirm fixes are clean:

    line 83
  9. Very specific:

    Check for TypeScript errors not caught by tsc-check

    line 109
  10. Distinctive:

    Verify all imports resolve correctly

    line 110
  11. Distinctive:

    Check for circular dependencies

    line 111
  12. Distinctive:

    If protected files appear in the diff, warn the contributor and ask them to revert or get code owner approval.

    line 127

“Common” is measured: kept by at least 6 in 10 of the 42 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Pre-Submission Preflight Check

You are running a comprehensive validation before submitting a pull request. Run each check in order, report results clearly, and help fix any issues found.

All script commands run from the frontend/ directory unless otherwise noted.

Check 0: Working Tree Status

Before running any validation, check the state of the working tree:

git status
git diff --stat origin/main...HEAD
git log --format="%h %s%n%b" origin/main..HEAD

Evaluate:

  • Uncommitted changes? — Ask the contributor: commit now or stash?
  • No commits ahead of main? — The branch has nothing to validate. Ask if they're on the right branch.
  • Commits missing an issue reference? — Flag commits whose body lacks Refs linuxfoundation/lfx-cdp-insights-ops#<number>.
  • Commits missing --signoff? — Flag any commits without Signed-off-by: lines.

Resolve any issues before proceeding.

Check 1: License Headers

Every source file (.ts, .vue, .js, .scss) must have the copyright header. Check for files missing it:

# From repo root
find frontend/app frontend/server -type f \( -name "*.ts" -o -name "*.vue" -o -name "*.js" -o -name "*.scss" \) | \
  xargs grep -rL "Copyright" 2>/dev/null | grep -v node_modules | grep -v ".nuxt" | head -20

The correct headers are:

  • TypeScript / JS / SCSS: // Copyright (c) 2025 The Linux Foundation and each contributor. + // SPDX-License-Identifier: MIT
  • Vue files: <!--\nCopyright (c) 2025 The Linux Foundation and each contributor.\nSPDX-License-Identifier: MIT\n-->

If any files are missing headers, add them using the scripts/add-license.js script or manually.

Check 2: Formatting

# From repo root
pnpm format

This applies oxfmt formatting. Run format before lint to eliminate whitespace noise from the lint step.

If files were modified, stage them:

git add -p

Check 3: Linting

# From repo root
pnpm lint

If there are lint errors, fix them. Common issues:

  • Unused imports or variables
  • Missing type annotations
  • Vue template rule violations

Re-validation

If any fixes were applied in Checks 1–3, re-run lint to confirm fixes are clean:

cd frontend && pnpm lint

Check 4: TypeScript Check

cd frontend && pnpm tsc-check

Fix any type errors before proceeding. Common issues:

  • Missing types on function parameters
  • Incorrect return types
  • Import path issues

Check 5: Build Verification

cd frontend && pnpm build

The build must succeed. If it fails:

  • Check for TypeScript errors not caught by tsc-check
  • Verify all imports resolve correctly
  • Check for circular dependencies

Check 6: Protected Files Check

The authoritative list of protected files is maintained in .claude/hooks/guard-protected-files.sh. Cross-reference the diff against that hook — do not rely on any hardcoded list here, which may be stale.

# Get changed files
git diff --name-only origin/main...HEAD

# Extract the protected path patterns from the hook
grep -E "^\s+(frontend/|\.husky/|\.oxlintrc|\.oxfmtrc|AGENTS|\.claude/|scripts/|COPYRIGHT|package\.json|pnpm-lock)" .claude/hooks/guard-protected-files.sh

For each changed file, check whether it matches any case pattern or glob ([[ ... == glob ]]) in the hook. If it does, flag it — those files should NOT be modified without code owner approval.

If protected files appear in the diff, warn the contributor and ask them to revert or get code owner approval.

Check 7: Commit Verification

git status
git log --format="%h %s%n%b" origin/main..HEAD
  • All changes committed? — If not, remind them to commit.
  • Commit messages follow conventions? — type: description format per commit-workflow.md. Scope is optional. Valid types include feat, fix, docs, chore, refactor, build, etc.
  • --signoff on all commits? — Every commit must have Signed-off-by:.
  • Issue referenced? — Commit bodies should include Refs linuxfoundation/lfx-cdp-insights-ops#<number> per commit-workflow.md.

Check 8: Change Summary

Generate a summary of all changes for the PR description:

git diff --stat origin/main...HEAD

List:

  1. New files created — with their purpose
  2. Modified files — with what changed
  3. Server API changes — any new or modified routes in server/api/
  4. Component changes — any new or modified components
  5. Data/query changes — any TanStack Query or Pinia store changes

Results Report

Present a clear report:

PREFLIGHT RESULTS
─────────────────────────────────
✓ Working tree        — Clean, N commits ahead of main
✓ License headers     — All files have headers
✓ Formatting          — Applied
✓ Linting             — No errors
✓ TypeScript          — No errors
✓ Build               — Succeeded
✓ Protected files     — None modified
✓ Commits             — Conventions followed, signed off
─────────────────────────────────
READY FOR PR

Or if there are issues:

PREFLIGHT RESULTS
─────────────────────────────────
✓ Working tree        — Clean, N commits ahead of main
✗ License headers     — 2 files missing headers (see above)
✓ Formatting          — Applied
✗ Linting             — 3 errors (see above)
✓ TypeScript          — No errors
✗ Build               — Failed (see above)
✓ Protected files     — None modified
✓ Commits             — Conventions followed, signed off
─────────────────────────────────
ISSUES FOUND — Fix before submitting

If All Checks Pass

Suggest creating the PR:

"All preflight checks passed! Ready to create a PR. Would you like me to create it with gh pr create?"

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.