Update to DXD Skills

{
  "name": "ci-verify-setup",
  "description": "Use when a project lacks a single reliable verification command, has missing or broken CI, asks to add GitHub Actions, asks to make agents able to verify their work, or needs lint/type/test checks standardized across local and remote environments.",
  "included_files": [],
  "skill_md_contents": "---\nname: ci-verify-setup\ndescription: >-\n  Use when a project lacks a single reliable verification command, has missing or broken CI, asks to add GitHub Actions, asks to make agents able to verify their work, or needs lint/type/test checks standardized across local and remote environments.\n---\n\n# CI Verify Setup\n\n## Goal\n\nGive any coding agent one dependable command that verifies the project locally, then mirror that command in CI so local and remote feedback agree.\n\n## When to Use\n\nUse this skill when the user asks you to:\n\n- Add or repair a project-level `verify`, `check`, or equivalent command.\n- Set up GitHub Actions or another CI workflow for lint, typecheck, build, or tests.\n- Make the repo easier for Codex, Claude Code, Cursor, or other agents to validate.\n- Replace scattered manual checks with one documented verification path.\n\n## Workflow\n\n1. **Inspect before editing.**\n   - Identify the package manager, language, framework, and existing scripts.\n   - Read current CI config, contributor docs, and agent instructions if present.\n   - Note whether tests, linting, typechecking, formatting, and builds already exist.\n\n2. **Define the smallest honest local verification command.**\n   - Prefer an existing command if it already covers the important checks.\n   - If no command exists, add one named according to local convention: `verify`, `check`, or the repo's established equivalent.\n   - Compose existing scripts instead of introducing new tooling unless a required check has no existing runner.\n\n3. **Make CI run the same contract.**\n   - Add or update the CI workflow so it installs dependencies, restores cache if appropriate, and runs the local verification command.\n   - Keep local and CI commands aligned; do not let CI become a separate checklist.\n   - Use the repo's default branch, package manager lockfile, and supported runtime versions.\n\n4. **Document the verification path.**\n   - Update README, contributing docs, or agent instructions with the exact command agents should run before handing off.\n   - Mention any checks that are intentionally excluded and why.\n\n5. **Verify the setup.**\n   - Run the local verification command if the environment allows it.\n   - Validate workflow syntax when possible.\n   - If checks fail for pre-existing reasons, report the failure clearly instead of hiding it.\n\n## Guardrails\n\n- Never add a new package manager, lockfile, linter, formatter, or test framework just to make CI exist.\n- Never delete existing CI jobs without explaining what replaces their coverage.\n- Never make CI pass by weakening tests, suppressing type errors, or skipping meaningful checks.\n- Never claim verification works unless you ran it or clearly state why it could not be run.\n- Never commit secrets, tokens, or environment-specific credentials into workflow files.\n\n## Completion Checklist\n\n- [ ] Existing local scripts and CI were inspected before editing.\n- [ ] A single local verification command exists or an existing one was documented.\n- [ ] CI runs the same verification contract as local development.\n- [ ] Runtime versions, package manager, and lockfile usage match the repo.\n- [ ] Verification instructions were documented for future agents.\n- [ ] Local verification or workflow validation was run, or the blocker was reported.\n"
}