check-changed-folders

Check Changed Folders

Identify what changed on the branch, verify provider parity, the centralized agent-instruction layout, and agent attribution, run the package checks, and report pass/fail status with actionable failure output. The root npm scripts validate the core package and the Rudder plugin workspace. Checks are therefore repo-wide rather than per-package.

Workflow

1. Identify changed files against main, including local staged/unstaged changes:

git fetch origin main
git diff --name-only origin/main...HEAD
git diff --name-only
git diff --name-only --cached

If anything under src/, bin/, test/, ui/, .claude-plugin/, .codex-plugin/, hooks/, skills/, or a build/config file (package.json, tsconfig*.json, .mcp.json, .github/) changed, the package checks below apply.

1. Verify the centralized agent-instruction layout before running checks:

• AGENTS.md is the canonical repository guidance.
• .agents/skills/ is the only reusable-workflow source. Do not add command aliases or edit tool-specific symlinks.
• Ensure that every skill has a corresponding skills/<skill-name>/agents/openai.yaml detailing its Codex display name, short description, and default prompt.
• Confirm the compatibility links resolve correctly:
  • .claude/skills -> ../.agents/skills
  • .codex/skills -> ../.agents/skills
• If any link is missing or resolves outside .agents/, mark the check as failed and report the broken path.

1. Verify provider parity.

• Treat Claude and Codex as supported providers for the same Rudder plugin package.
• When a change adds, removes, or modifies a provider-facing component—manifest metadata, skills, hooks, MCP servers, apps, UI, or packaged artifacts—inspect both provider manifests and runtime paths.
• Require equivalent discovery, launch behavior, packaged resources, and user-facing capability across providers. Provider-specific schema or environment-variable differences are allowed, but they must remain explicit implementation details rather than functional gaps.
• Add or update a regression assertion in test/plugin-package.test.ts or the relevant runtime test that exercises both provider paths. If provider-facing behavior changes without parity coverage, fail this check.
• Permit a provider-specific exception only when the user explicitly requests it or the provider cannot support the capability. Report the reason, the affected provider, and the test that protects the supported behavior.