Scheduled watch

A check only helps when someone runs it. The scheduled watch runs the CLI every 4 hours in your CI and opens an issue when a heads-up, an alert or a security release is new for your stack. Quiet runs cost nothing and open nothing.

The profile

The watch reads .stackalarm.yaml at the root of the project. The skill writes it at the end of a /stackalarm run when you accept the watch, and refreshes it on later runs.

# Written by the stackalarm skill, refreshed on each /stackalarm run.
tags: [php, symfony, composer, gitlab, docker]
keywords: [frankenphp]
packages: [symfony/http-kernel, twig/twig]
stack:
  - {name: php, version: "8.3", precision: branch, from: Dockerfile}
  - {name: gitlab, version: unknown, precision: unknown, from: git remote}

The file is committed and may be public: it never holds host names, internal URLs, IP addresses or secrets (gitlab, not gitlab.acme.internal). Check it with stackalarm news --profile .stackalarm.yaml --since 24h.

GitHub Actions

Copy ci/github/stackalarm.yml to .github/workflows/:

name: stackalarm

on:
  schedule:
    - cron: "17 */4 * * *"
  workflow_dispatch:

permissions:
  contents: read

jobs:
  watch:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: yoanbernabeu/stackalarm@v0.6.0
        with:
          anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
          nvd-api-key: ${{ secrets.NVD_API_KEY }}

No token to create: the workflow's automatic github.token opens the issue and lifts the GitHub API cap. The optional secrets are ANTHROPIC_API_KEY (the triage, below) and NVD_API_KEY.

The workflow uses the yoanbernabeu/stackalarm action, which you can also call from your own workflows. Its inputs and outputs, as declared in action.yml:

Triage by Claude

Raw news is not a verdict: a Go release the project already runs is news, not a reason to act. With the ANTHROPIC_API_KEY secret, when the CLI finds something new, Claude runs the skill in triage mode and the issue depends on its decision. Claude is called only on the runs that find something new.

Claude reads text written by others, so it runs locked down. It cannot open issues, push or change the project's files: it can only write its verdict and its decision, and the action opens the issue from them. The tools it is allowed, read from action.yml:

• Skill
• Read
• Glob
• Grep
• WebSearch
• WebFetch
• Edit(./.stackalarm-triage/**)
• Bash(stackalarm:*)
• Bash(git remote:*)
• Bash(go list:*)
• Bash(composer audit:*)
• Bash(npm audit:*)
• Bash(pnpm audit:*)

GitLab CI

Include the job in .gitlab-ci.yml:

include:
  - remote: https://raw.githubusercontent.com/yoanbernabeu/stackalarm/main/ci/gitlab/stackalarm.yml

Then two steps only you can do:

1. Add a masked CI/CD variable STACKALARM_GITLAB_TOKEN: a project access token with the api scope and the Reporter role, to open the issues.
2. Create a pipeline schedule (Build > Pipeline schedules), every 4 hours: 17 */4 * * *. The job runs only on schedules.

Two optional variables, read by the CLI as on your machine:

The job's variables, which you can override:

GitLab has no triage by Claude: every new heads-up, alert or security release opens an issue with the raw news, to judge with /stackalarm triage <issue link>. Without the token, the job fails instead of staying silent.

Each item reported once

The CI cache keeps a state file of the items already handled. It is saved only once the run has dealt with them (issue opened, or none needed): if the issue cannot be opened, the next run reports the items again. An item may be reported twice, never missed. On GitLab runners without a shared cache, a few items may be reported twice.

The watch looks back 48 hours by default, longer than the 4-hour schedule, so a delayed or failed run misses nothing; the state removes the duplicates.

Next: Sources