AgentSkillsCN

runtime-tooling-validation

在引入、升级或评审运行时与构建工具时，运用此技能确保各组件均采用经批准的 LTS 版本，并贯彻一致的工具使用策略。

SKILL.md
--- frontmatter
name: runtime-tooling-validation
description: >
  Use this skill when introducing, upgrading, or reviewing runtimes and build
  tooling to ensure approved LTS versions and consistent tooling policies are
  applied across components.

Runtime & Tooling Currency Validation

Intent

Maintain consistency and currency of runtimes/tooling (LTS policy) to reduce risk, avoid fragmentation, and keep builds predictable.

When to Use

  • •Upgrading .NET/Node/Python/tooling versions
  • •Introducing new components that depend on runtime versions
  • •Reviewing inconsistencies across the monorepo

Precondition Failure Signal

  • •Components use non-approved or inconsistent runtime versions
  • •Tooling is pinned inconsistently across components
  • •Builds are unreliable across environments due to version drift
  • •Upgrades are performed ad hoc without compatibility consideration
  • •Package installs emit warnings or errors that are left unresolved

Postcondition Success Signal

  • •Approved LTS versions are used consistently per policy
  • •Version policies are explicit and traceable
  • •Components remain buildable/testable under the chosen versions
  • •No unnecessary divergence is introduced
  • •Tool configuration remains consistent across tools and components (see automated-standards-enforcement)
  • •Local runtime/tooling versions are checked against repo pins, and any drift is resolved or documented
  • •Package installs complete with zero warnings or errors

Process

  1. •Source Review: Inventory all runtimes and build tools currently used in the repository and compare them against the repo pins.
  2. •Discovery: Confirm the latest LTS versions from authoritative sources and confirm the repo-specific target with the user.
  3. •Decision: Record the repo-specific LTS baseline in tooling files (e.g., .nvmrc, package.json engines).
  4. •Implementation: Upgrade or align runtimes and tools to the required versions.
  5. •Verification: Run package installs and build/test for all components to ensure the updated tooling doesn't introduce regressions or warnings.
  6. •Documentation: Document the required runtime and tool versions in the repository's root documentation or an ADR for major upgrades.
  7. •Review: Platform Engineer and Tech Lead review the tooling changes for consistency and stability.

Example Test / Validation

  • •Demonstrate a failing build/check due to unsupported version, then align to pass
  • •Verify impacted components build/test under the approved versions
  • •Confirm version policy is reflected consistently in component configuration
  • •Record the LTS source and confirmation used for the repo decision
  • •Verify package installs complete without warnings or errors

Common Red Flags / Guardrail Violations

  • •"It works on my machine" version choices
  • •Pinning bespoke versions per component without justification
  • •Upgrading runtimes as part of unrelated feature work without impact analysis
  • •Downgrading standards to accommodate drift
  • •Ignoring engine warnings or local version mismatches without a repo decision
  • •Allowing package install warnings/errors to remain unresolved

Recommended Review Personas

  • •Platform Engineer – validates standardisation and environment parity
  • •Tech Lead – validates policy alignment and scope
  • •Domain Expert – validates compatibility risks for critical components

Skill Priority

P2 – Consistency & Governance

Conflict Resolution Rules

  • •Prefer standardisation unless a justified exception exists
  • •Exceptions require explicit documentation and review
  • •Upgrades must be scoped; avoid bundling with unrelated work (YAGNI)

Conceptual Dependencies

  • •incremental-change-impact

Classification

Governance
Operational

Notes

Tooling drift is a compounding cost. Prevent it early and consistently.