home / skills / max-sixty / worktrunk / running-in-ci

running-in-ci skill

safe

This skill helps you enforce secure CI practices for GitHub Actions, monitor and diagnose runs, and format PR comments effectively.

npx playbooks add skill max-sixty/worktrunk --skill running-in-ci

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.0 KB

---
name: running-in-ci
description: CI environment rules for GitHub Actions workflows. Use when operating in CI — covers security, CI monitoring, and PR comment formatting.
---

# Running in CI

## Security

NEVER run commands that could expose secrets (`env`, `printenv`, `set`,
`export`, `cat`/`echo` on config files containing credentials). NEVER include
environment variables, API keys, tokens, or credentials in responses or
comments.

## CI Monitoring

After pushing changes to a PR branch, monitor CI until all checks pass:

1. Monitor with `gh pr checks` or `gh run list --branch <branch>`
2. Wait for completion with `gh run watch`
3. If CI fails, diagnose with `gh run view <run-id> --log-failed`
4. Fix issues, commit, push, and repeat
5. Do not return until CI is green — local tests alone are not sufficient (CI
   runs on Linux, Windows, macOS)

## PR Comment Formatting

Keep PR comments concise. Put detailed analysis (file-by-file breakdowns, code
snippets) inside `<details>` tags with a short summary. The top-level comment
should be a brief overview (a few sentences); all supporting detail belongs in
collapsible sections.

Example:

```
<details><summary>Detailed findings (6 files)</summary>

...details here...

</details>
```

Do not add job links, branch links, or other footers at the bottom of your
comment. `claude-code-action` automatically adds these to the comment header.
Adding them yourself creates duplicates and broken links (the action deletes
unused branches after the run).

## Tone

You are a helpful reviewer raising observations, not a manager assigning work.
Never create checklists or task lists for the PR author. Instead, note what you
found and let the author decide what to act on.

## PR Review Comments

For PR review comments on specific lines (shown as `[Comment on path:line]` in
`<review_comments>`), ALWAYS read that file and examine the code at that line
before answering. The question is about that specific code, not the PR in
general.

Overview

This skill defines safe, repeatable rules for operating in GitHub Actions CI for the Worktrunk project. It focuses on protecting secrets, monitoring CI runs until green, and producing concise, well-structured PR comments. Use these rules whenever you push changes or review pull requests that trigger CI.

How this skill works

It enforces never exposing environment variables or credentials in outputs, comments, or logs. It guides operators to monitor CI runs with GitHub CLI commands, inspect failures, and iterate until all platform checks (Linux, Windows, macOS) succeed. It also prescribes a compact PR comment format with detailed findings placed inside collapsible sections.

When to use it

After pushing a branch that triggers GitHub Actions for Worktrunk
When monitoring CI status for pull requests across multiple OS runners
Before posting any PR comment that might include sensitive information
When diagnosing failing CI jobs and producing a public review summary

Best practices

Never print or paste env variables, API keys, tokens, or file contents that contain credentials
Use gh pr checks, gh run list --branch <branch>, and gh run watch to follow CI progress
If a run fails, inspect with gh run view <run-id> --log-failed before commenting
Keep the top-level PR comment a short overview and move file-level detail into <details> sections
Do not add manual job or branch links in comments; automated tooling already inserts them
Adopt a helpful, observational tone; avoid checklists and prescriptive task lists

Example use cases

Push a fix for a failing Linux test, watch the run with gh run watch, and wait until all checks pass before completing the PR
Review a contributor’s PR: give a brief summary and include a file-by-file breakdown inside <details> tags
Diagnose a flaky Windows runner by using gh run view to capture failed logs and iterate locally before re-running CI
Ensure no secret or environment output appears in your review comments or pasted logs

FAQ

What commands should I use to monitor CI?

Use gh pr checks or gh run list --branch <branch> to see runs, and gh run watch to wait for completion. Inspect failures with gh run view <run-id> --log-failed.

How should I format a long investigation in a PR comment?

Put a brief top-level summary (a few sentences) and move detailed, file-level analysis into <details> collapsible sections using a clear summary line.