メニュー
Updates changelog documentation for contract developers and node operators by analyzing branch changes relative to 'next'. Use when preparing a PR, updating migration notes, documenting breaking changes, or when asked to update changelog/release notes.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Spot-check the health of a live Aztec network deployment by sweeping recent GCP logs for warn/error messages, mapping each to the deployed code, classifying expected vs unexpected, and verifying the hard invariants (no slashing, no attestation timeouts, no unexplained prunes/conflicts). Use when asked to "spot-check", "review logs", or "health check" a network (staging, testnet, devnet, ...) over a recent window.
Reference for merge-train automation internals -- workflows, scripts, CI integration, and configuration. Use when modifying or debugging merge-train infrastructure.
Build and update the developer documentation site for a new release
Guide for working with merge-train branches -- creating PRs, choosing the right base branch, understanding labels, handling failures, and bypassing checks.
Create a well-formed Linear issue — with complete context for a fresh agent, a point estimate (1/2/3/5), and acceptance criteria. Works standalone or as part of planning a project with multiple issues. Use when asked to file/create/open a Linear issue, "make a ticket", or when breaking a plan into tracked work.
Build or adjust a Linear cycle — for a whole team or just yourself. Size capacity from last-3-cycle velocity, fill with backlog bugs/high-priority items first and project work after (in your chosen project focus order), with no unassigned issues. Use when planning/prepping a cycle for a team, or when one member wants to fill/rebalance their own cycle work.
| name | updating-changelog |
| description | Updates changelog documentation for contract developers and node operators by analyzing branch changes relative to 'next'. Use when preparing a PR, updating migration notes, documenting breaking changes, or when asked to update changelog/release notes. |
Read .release-please-manifest.json to get the version (e.g., {"." : "4.0.0"} → edit v4.md).
Target files:
docs/docs-developers/docs/resources/migration_notes.mddocs/docs-operate/operators/reference/changelog/v{major}.mdRun git diff next...HEAD --stat for overview, then git diff next...HEAD for details.
Categorize changes:
Present draft entries for review BEFORE editing files. Match the formatting conventions by reading existing entries in each file.
After approval, add entries to the appropriate files.
File: docs/docs-developers/docs/resources/migration_notes.md
Add entries under ## TBD section:
### [Component] Brief description
Explanation of what changed.
**Migration:**
```diff
- old code
+ new code
```
Impact: Effect on existing code.
Component tags: [Aztec.nr], [Aztec.js], [PXE], [Aztec Node], [AVM], [L1 Contracts], [CLI]
File: docs/docs-operate/operators/reference/changelog/v{major}.md
Breaking changes:
### Feature Name
**v{previous}:**
```bash
--old-flag <value> ($OLD_ENV_VAR)
```
**v{current}:**
```bash
--new-flag <value> ($NEW_ENV_VAR)
```
**Migration**: How to migrate.
New features:
### Feature Name
```bash
--new-flag <value> ($ENV_VAR)
```
Description of the feature.
Changed defaults: Use table format with Flag, Environment Variable, Previous, New columns.