Ci

---
model: sonnet
description: "CI/CD pipeline integration. Use when setting up or checking CI quality gates, exporting rules to GitHub Actions/GitLab CI/Bitbucket/Jenkins, or verifying pipeline alignment with local rules."
effort: medium
disable-model-invocation: true
---

# /craftsman:ci - CI/CD Integration

## Outcome Contract

- **Outcome**: a CI pipeline that enforces the same rules as the local hooks, from the same validators, the same rules engine and the same per-file severity resolution.
- **Done when**: the generated pipeline file exists for the target provider, references the same pack validators as the hooks, and a dry run reports the same violations locally and in CI.
- **Evidence**: craftsman-ci.sh output, the generated template, and the provider adapter used.

Integrate Craftsman quality gates into your CI/CD pipeline.

## Subcommands

- `/craftsman:ci export` - Generate `.github/workflows/craftsman-quality-gate.yml`
- `/craftsman:ci status` - Show current CI integration status

---

## Execution

### If the user runs `/craftsman:ci export`:

1. Read `.craft-config.yml` if it exists to pick up `strictness` and `stack` settings.
2. Check for `composer.json` (PHP), `package.json` (Node.js), and `deptrac.yaml` to tailor the workflow.
3. Copy `ci/templates/craftsman-quality-gate.yml` into `.github/workflows/craftsman-quality-gate.yml`.
   - If `.github/workflows/` does not exist, create it.
   - If the file already exists, ask the user before overwriting.
4. Confirm the export with a summary:

```
Craftsman CI workflow exported to:
  .github/workflows/craftsman-quality-gate.yml

Detected stack: <stack>
Config: <strictness> strictness

Next steps:
  1. Commit and push: git add .github/workflows/craftsman-quality-gate.yml
  2. Open a PR to trigger the workflow
  3. Review docs/ci-integration.md for advanced configuration
```

### If the user runs `/craftsman:ci status`:

Check the following and report:

1. **Workflow file** - Does `.github/workflows/craftsman-quality-gate.yml` exist?
   - If yes: show `strictness` and `stack` from the embedded config, and the file's last modified date.
   - If no: suggest running `/craftsman:ci export`.

2. **craftsman-ci CLI** - Does `ci/craftsman-ci.sh` exist and is it executable?

3. **Config file** - Does `.craft-config.yml` exist?

4. **Stack detection** - Are `composer.json` / `package.json` / `deptrac.yaml` present?

Output a clear status table:

```
Craftsman CI Status
===================
Workflow file:   ✓ .github/workflows/craftsman-quality-gate.yml
craftsman-ci:    ✓ ci/craftsman-ci.sh (executable)
Config:          ✓ .craft-config.yml (strictness=strict, stack=fullstack)
Stack detected:  PHP (composer.json), Node.js (package.json)

Run /craftsman:ci export to generate the workflow if missing.
```

---

## Constraints

- Never modify `hooks/`, `agents/`, or `packs/` - CI is an additive integration layer.
- The exported workflow uses the same rules as the hooks; they must never diverge.
- If `ci/craftsman-ci.sh` is not present, warn the user - the workflow depends on it.
- All shell commands use `|| true` for optional tools (PHPStan, ESLint, deptrac) so the workflow degrades gracefully.

## Cross-Harness Doctrine Export

Teammates whose agent does not run this plugin's hooks can still read instruction files: Cursor, Gemini and Antigravity, which the plugin does not ship to; Copilot, whose adapter has no qualified surface yet; and a Codex or Grok session where the plugin's gate is not installed, wired and trusted as their quickstarts describe (both are qualified hosts in `hooks/host-capabilities.json` once it is). Export the active rules as those files so the doctrine travels with the repository:

```bash
craftsman-ci export --target agents-md   # AGENTS.md (read by most agents)
craftsman-ci export --target cursor      # .cursor/rules/craftsman.mdc
craftsman-ci export --target copilot     # .github/copilot-instructions.md
craftsman-ci export --target codex-agents [--into "$HOME/.codex/agents"]  # craftsman-<name>.toml, one role per agents/*.md; only ~/.codex/agents/ was seen offered on codex-cli 0.154.0
craftsman-ci export --target all
```

The rules engine remains the single source of truth: severity overrides and ignored rules in `.craft-config.yml` are reflected in the generated files. In `AGENTS.md` and `.github/copilot-instructions.md` the export owns one delimited block (`<!-- craftsman:doctrine:begin ... -->` to `<!-- craftsman:doctrine:end -->`), created when the file is absent, appended when the file has none, rewritten in place otherwise: everything the team wrote outside the markers is kept byte for byte, and a second export changes nothing. `.cursor/rules/craftsman.mdc` is a dedicated file and is regenerated whole. Enforcement is unchanged: hooks locally where craftsman runs, `craftsman-ci` in the pipeline for everyone else. Commit the generated files and re-run the export whenever the rules change.