dd-shared-ci

Validates macOS code changes through GitHub Actions CI runs across baseline, regression, push, and merge scenarios.

Updated Jun 11, 2026
One-click install
npx skills add https://github.com/marcocpt/trae_skills --skill dd-shared-ci-marcocpt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dd-shared-ci
Source: https://github.com/marcocpt/trae_skills/tree/main/dd-shared-ci
Command: npx skills add https://github.com/marcocpt/trae_skills --skill dd-shared-ci-marcocpt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams working on macOS Xcode projects often skip CI verification or fall back to local tests that mask environment-specific failures (signing, SDK, runner configuration). This Skill enforces a CI-first verification policy shared by the dd bug-fix and feature-development workflows, ensuring every commit is validated by GitHub Actions before proceeding. ## Core Features & Use Cases - Four CI verification scenarios: baseline CI reuse (checking BASE_BRANCH results by matching headSha), regression CI after commits (push-first then trigger), post-push CI waiting, and post-merge CI validation. - GitHub CLI command patterns: ready-to-use gh run list, gh run watch --exit-status, and gh workflow run invocations with SHA-matching logic to find the correct run. - Strict anti-degradation rules: a red-line policy and rationalization table that block common excuses for downgrading to local tests, with AskUserQuestion fallback flows for push failures, trigger failures, and CI failures. - Use Case: After committing a bug fix on a new branch, the Skill pushes the branch, triggers macos-ci.yml, watches the run to completion, and routes failures back to the TDD step with log analysis via gh run view --log-failed. ## Quick Start Ask the AI to verify the current branch against CI following the dd-shared-ci rules, reusing any successful baseline run or triggering macos-ci.yml and watching it to completion.

Frequently Asked Questions about dd-shared-ci

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I wait for a GitHub Actions run after pushing a branch?

Use gh run list with the workflow name, branch, and a headSha filter to find the run ID for your current commit, then run gh run watch <run-id> --exit-status. Add a short sleep after pushing so GitHub registers the new run first.

How do I trigger a GitHub Actions workflow manually with gh CLI?

Run gh workflow run macos-ci.yml --ref <branch> to dispatch the workflow, then locate the run with gh run list filtered by headSha and watch it with gh run watch --exit-status. If triggering fails, retry or investigate configuration rather than falling back to local tests.

Can I reuse an existing CI result instead of triggering a new run?

Yes, for baseline verification. If gh run list returns a run with conclusion=success whose headSha equals your current working-tree HEAD, you can reuse that result and skip re-running, including results from the base branch when your branch is not yet pushed.

Why should XCUITest not run locally instead of on CI?

XCUITest is highly sensitive to GUI sessions, Accessibility permissions, window focus, and TCC prompts, so local passes do not prove CI success. Local runs are only allowed to diagnose a CI failure, and fixes must be re-verified through CI.

What should I do when the branch is not pushed and CI cannot be triggered?

Push the branch first with git push -u origin <branch>, then trigger and watch CI. Being unpushed is not a valid reason to run tests locally; if push fails, ask the user whether to retry or stop the workflow.

When is running the local test-macos.sh script acceptable?

Only in a closed set of cases: the project has no .github/workflows configuration, the gh CLI is unavailable and the user declines to fix it, or no CI result exists and triggering failed with the user explicitly choosing local. It never substitutes for regression CI verification.