메뉴
Processes all open Dependabot PRs sequentially — rebases if needed, analyzes for breaking changes and security issues, then merges or requests changes. Use when you want to handle pending Dependabot dependency updates.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Generates machine_readable execution logic for Dutch law YAML files through an iterative generate-validate-test loop. Creates machine_readable sections, validates against the schema, runs BDD tests, and iterates until correct (up to 3 iterations). Use this skill proactively when: editing or creating machine_readable sections in law YAML files, working with corpus regulation files, or when user mentions 'generate', 'machine_readable', or wants to make a law executable. Activate automatically when user discusses law YAML files that need executable logic.
Writing rules for the regelrecht docs site (docs/). Use when writing or editing prose under docs/ — RFCs, guides, component docs, concept pages, and the NL/EN landing copy. Keeps docs prose free of AI-generated tells and consistent with the site's government-technical register. Not for code, commit messages, or PR descriptions.
Genereert uit een (semi-)gevalideerd regelrecht-corpus een geloofwaardige service-PoC (burger- + behandelaar-portaal, of een headless beslis-service) en zet die in als validatie-instrument met uitvoeringsexperts — om tastbaar te maken wat nodig is om een wet rechtvaardig in de praktijk te brengen, gezien vanuit de betrokkene. Gebruik dit als workshop-fase ná de logica-/scenariovalidatie (audit-products) om de dienstverlening-kant te valideren: welke service impliceert de wet, waar zit menselijk oordeel, welke last ligt bij de burger, welke termijnen, waar is de wet hard of onduidelijk. Dossier-agnostisch; de regelrecht-methode (hooks, legal_character, untranslatables, source/implements, type_spec, receipts) is de vaste taal. Voor de logica-/scenariovalidatie zelf: zie de zusterskill regelrecht-audit-products.
Audits whether a machine-readable regelrecht law model is faithful to the LETTER of the wettekst — and strictly separates the wettekst (leading) from the toelichting (Nota/Memorie van Toelichting; explanatory, not a norm). Runs in critical passes per article/lid and detects four deviation classes: toelichting-bleed (a modeled criterion that the letter only states as an open norm, or not at all), missing verbatim elements (a word/condition such as a "tenzij" or a qualifier dropped from the model), wrong legal_basis anchoring (an endpoint hung on a "kapstok"-article while the operative norm lives elsewhere), and verbatim-drift in text: (an ingetrokken/older redaction). Also detects positief-lid vs uitsluitings-lid conflicts and checks the chapeau for an explicit derogation rule ("zo nodig in afwijking van het eerste lid") before judging precedence. Classifies every finding as modelfout (fix), wettekst-gevolg (report, do not fix), or letter-vs-toelichting-question (jurist decides what is leading + revision signa
Performs a hallucination check on machine_readable sections by verifying every element traces back to the original legal text. Use this skill proactively when: machine_readable sections have been generated or modified, after /law-generate completes, when reviewing corpus YAML files for legal accuracy, or when user mentions "validate", "verify", or "hallucination check" for law YAML files. Activate automatically after editing machine_readable sections in corpus regulation YAML files.
Detects version drift between machine-readable law YAML files and the binding geldende wettekst on wetten.overheid.nl at the YAML's claimed valid_from. Catches the silent failure where authored content lags behind ingevoerde wijzigingen — a YAML dated 2025-01-01 still carrying pre-Stb.-X text. Activate as Step 0 of every regelrecht-stelselanalyse micro-cycle, before any YAML edit. Strict by design: no bypass, no normalization beyond whitespace within a single paragraph; the geldende wettekst is leading and is mirrored verbatim, including errata. Use proactively when starting a stelselanalyse cycle, before harvest/migrate/extend, or when user mentions "drift", "versie", "geldende tekst", or worries that a YAML may be stale relative to wetten.overheid.nl.
| name | dependabot |
| description | Processes all open Dependabot PRs sequentially — rebases if needed, analyzes for breaking changes and security issues, then merges or requests changes. Use when you want to handle pending Dependabot dependency updates. |
| user-invocable | true |
| allowed-tools | Bash, Read, Grep, Glob, WebSearch, WebFetch, Task, AskUserQuestion |
Processes all open Dependabot pull requests one at a time: analyze for risks first, then rebase and merge if safe, or request changes if not.
For each open Dependabot PR:
1. Analyze update for breaking changes and security issues
2. If risky → request changes with explanation → move to next PR
3. If safe → check if up-to-date with base branch
4. If not up-to-date → comment "@dependabot rebase" → poll until done
5. Merge
6. Move to next PR
gh pr list --author "app/dependabot" --state open --json number,title,headRefName,baseRefName,url,labels,body --limit 100
Parse the JSON output. If no PRs found, report "No open Dependabot PRs" and stop.
Sort PRs by number (ascending) to process oldest first.
Print a summary table of all found PRs before starting processing.
For each PR, execute steps 2a through 2e before moving to the next.
Analyze the update before rebasing — no point wasting a rebase if the update is problematic.
Extract from the PR body and title:
Major version bumps (e.g., 6.x → 7.x): HIGH risk — likely contains breaking changes.
Minor version bumps (e.g., 6.1 → 6.2): MEDIUM risk — could contain new features or deprecations.
Patch version bumps (e.g., 6.1.1 → 6.1.2): LOW risk — typically bug fixes only.
Use web search to check for issues:
Search: "<package-name> <new-version> breaking changes"
Search: "<package-name> <new-version> changelog"
Search: "<package-name> <new-version> security vulnerability CVE"
Also check the PR body itself — Dependabot usually includes a changelog summary and release notes.
Evaluate the following and document findings:
gh pr checks <NUMBER>
| Condition | Action |
|---|---|
| Patch update, CI passes, no known issues | Proceed to rebase/merge |
| Minor update, CI passes, no breaking changes found | Proceed to rebase/merge |
| Major update, CI passes, no breaking changes found | Proceed to rebase/merge (with note) |
| CI fails | Request changes |
| Breaking changes found | Request changes |
| Security vulnerability introduced | Request changes |
| Cannot determine safety | Request changes (err on the side of caution) |
If the analysis found problems → skip to step 2e (request changes). If the analysis is positive → continue to step 2b.
gh pr view <NUMBER> --json mergeable,mergeStateStatus
Also check if the PR branch is behind the base branch:
git fetch origin <baseRefName> <headRefName>
git rev-list --count origin/<headRefName>..origin/<baseRefName>
If the count is > 0, the PR needs a rebase (likely because a previous PR was just merged into the base branch). Proceed to step 2c. If the count is 0, the PR is up-to-date. Skip to step 2d.
Post a comment to trigger Dependabot's rebase:
gh pr comment <NUMBER> --body "@dependabot rebase"
Then poll until the rebase is complete. Check every 60 seconds:
sleep 60
git fetch origin <headRefName>
git rev-list --count origin/<headRefName>..origin/<baseRefName>
gh pr merge <NUMBER> --squash --auto
Use --squash to keep the git history clean. Use --auto to let GitHub merge once all checks pass.
IMPORTANT: Wait until the PR is actually merged before moving to the next PR. Merging one PR changes main, which makes other Dependabot PRs outdated. If you move on too early, the next PR may fail to merge or produce conflicts.
Poll every 30 seconds until the PR state is MERGED:
gh pr view <NUMBER> --json state --jq '.state'
MERGED → log and move to next PRCLOSED (without merge) → log warning and move to next PRAfter confirming the merge, do a brief sleep 10 before starting the next PR to allow GitHub to update the remaining PR branches.
Log: "Merged PR #<NUMBER>: <title>"
If the analysis in step 2a found problems:
gh pr review <NUMBER> --request-changes --body "$(cat <<'EOF'
## Dependabot Auto-Review: Changes Requested
This dependency update was flagged for manual review.
### Findings
<list specific findings here>
### Reason
<explain why this cannot be auto-merged>
### Recommended Action
<suggest what the maintainer should do>
EOF
)"
Log: "Requested changes on PR #<NUMBER>: <title> — Reason: <brief reason>"
After processing all PRs, print a summary:
## Dependabot Processing Complete
| PR | Package | Version | Action | Reason |
|----|---------|---------|--------|--------|
| #123 | vite | 6.0 → 7.0 | Merged | Patch update, CI green |
| #124 | serde | 1.0 → 2.0 | Changes requested | Major version, breaking API |
| #125 | node | 22 → 24 | Skipped | Rebase timed out |
**Merged:** N
**Changes requested:** N
**Skipped:** N
MERGED. Each merge changes the base branch, making other PRs outdated@dependabot rebase command is the standard way to trigger a rebase; Dependabot responds with a reaction emoji and rebases asynchronouslysleep 10 before starting the next PR to allow GitHub to process webhooks and update remaining PR branches