Add github/local-action to dev-tools local workflow validation path

[coisa]

Objective

Integrate github/local-action into the dev-tools repository so local workflow validation becomes deterministic and easy for maintainers.

Current Limitation

We currently validate GitHub Actions behavior mainly through remote executions and manual edits to action source refs. This creates friction for contributors and makes reproducing action-related CI behavior locally harder.

Proposed Work

• Add a documented local execution path using github/local-action for action-based checks that are currently validated only in GitHub-hosted environments.
• Define where this workflow lives (likely under resources/github-actions/ and repository docs) and how contributors can run it locally.
• Add a minimal smoke script/check to execute a representative workflow_dispatch-style path with the repository resources.
• Include a short compatibility matrix with known constraints (OS, required dependencies, action references used in tests).

Scope

• In-scope: local execution setup, contributor-facing docs, and at least one validated local smoke target.
• In-scope: update existing action-related docs so local action execution is discoverable.
• Out-of-scope: refactoring all existing production workflows in one pass.

Non-goals

• Do not change action semantics or workflow business logic beyond enabling local execution parity.
• Do not alter unrelated CI jobs not related to action runtime validation.

Acceptance Criteria

Delivery Criteria

• A contributor can run a documented local workflow validation flow for dev-tools action wiring using github/local-action.
• The process is reproducible in a clean checkout with deterministic inputs and explicit prerequisites.
• Documentation identifies required tools/versions and known limitations.

Architectural / Isolation Criteria

• MUST: The core logic MUST be isolated into dedicated classes or services instead of living inside command or controller entrypoints.
• MUST: Responsibilities MUST be separated across input resolution, domain logic, processing or transformation, and output rendering when the change is non-trivial.
• MUST: The command or controller layer MUST act only as an orchestrator.
• MUST: The implementation MUST avoid tight coupling between core behavior and CLI or framework-specific I/O.
• MUST: The design MUST allow future extraction or reuse with minimal changes.
• MUST: The solution MUST remain extensible without requiring major refactoring for adjacent use cases.

---

Additional Requirement: agent skills workflow validation update

We should also update the existing agent skill prompts that currently mention only action lint checks so they require/attempt validation with github/local-action when available.

What to change

• For each skills guide that documents workflow validation, add a validation branch:
  • Primary path: run workflow checks with github/local-action (local execution) for action changes.
  • Fallback path: if github/local-action is not available, include explicit installation instructions (Linux/macOS) and continue with action-lint-based validation.
• This should include the expectation that agents validate impacted action references before opening PRs.
• This requirement applies to action-heavy repos and should be explicit in the corresponding skills.

Installation fallback (local-action)

• Linux/macOS: install via npm or the repository's installation docs when available and run from repo root.
• Provide command examples in skill docs (minimum):

  npm i -g @github/local-action
  # or use the local-action installation method documented for your environment

• If installation is not possible in the environment, document the reason and fallback to lint-only checks rather than dropping validation.

Acceptance add-on

• Skills mentioning workflow validation now document local-action as a preferred path for action testing.
• A clear fallback to action lint remains available when local-action is not installed.
• Agents have an explicit instruction to validate actions before PR submission whenever feasible.