메뉴
Release management, changeset workflow, firewall log parsing, breaking CLI change rules, and Go module summaries for gh-aw.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/github/gh-aw --skill developer-release명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
GitHub Agentic Workflows (`gh-aw`) is a GitHub CLI extension for writing Agentic Workflows in markdown and compiling them to GitHub Actions.
Operate safely and efficiently inside a gh-aw workflow with a restricted tools/bash allowlist, and correctly triage tool-denial events before they exhaust the session's denial budget.
Optional Sergo examples for cache formats and reporting templates.
SOC 직업 분류 기준
| name | developer-release |
| description | Release management, changeset workflow, firewall log parsing, breaking CLI change rules, and Go module summaries for gh-aw. |
Use this reference for release management procedures, understanding what constitutes a breaking CLI change, firewall log parsing, and Go module summaries.
The project uses a minimalistic changeset-based release system inspired by @changesets/cli.
The version command operates in preview mode and never modifies files:
node scripts/changeset.js version
# Or
make version
This command:
.changeset/ directoryThe release command creates an actual release:
node scripts/changeset.js release
# Or (recommended - runs tests first)
make release
This command:
CHANGELOG.md with new version and changesFlags:
--yes or -y: Skip confirmation promptgraph TD
A[Add changeset files] --> B[Preview with version command]
B --> C{Changes look good?}
C -->|No| D[Modify changesets]
D --> B
C -->|Yes| E[Run release command]
E --> F[Update CHANGELOG.md]
F --> G[Delete changeset files]
G --> H[Commit changes]
H --> I[Create git tag]
I --> J[Push tag to remote]
Changeset files are markdown files in .changeset/ directory with YAML frontmatter:
"gh-aw": patch
Brief description of the change
Bump types:
patch - Bug fixes and minor changes (0.0.x)minor - New features, backward compatible (0.x.0)major - Breaking changes (x.0.0)When running release, the script checks:
main branch to create a releaseFor maintenance releases with dependency updates:
# Defaults to patch release
node scripts/changeset.js release
# Or specify release type explicitly
node scripts/changeset.js release minor
# Skip confirmation
node scripts/changeset.js release --yes
The script will:
The firewall log parser provides analysis of network traffic logs from agentic workflow runs.
Firewall logs use space-separated format with 10 fields:
timestamp client_ip:port domain dest_ip:port proto method status decision url user_agent
Example:
1761332530.474 172.30.0.20:35288 api.enterprise.githubcopilot.com:443 140.82.112.22:443 1.1 CONNECT 200 TCP_TUNNEL:HIER_DIRECT api.enterprise.githubcopilot.com:443 "-"
graph TD
A[Parse log line] --> B{Check status}
B -->|200, 206, 304| C[Allowed]
B -->|403, 407| D[Denied]
B -->|Other| E{Check decision}
E -->|Contains TCP_TUNNEL, TCP_HIT, TCP_MISS| C
E -->|Contains NONE_NONE, TCP_DENIED| D
E -->|Other| F[Denied by default]
Allowed Indicators:
Denied Indicators:
Default: Denied (for safety when classification is ambiguous)
🔥 Firewall Log Analysis
Total Requests : 8
Allowed Requests : 5
Denied Requests : 3
Allowed Domains:
✓ api.enterprise.githubcopilot.com:443 (1 requests)
✓ api.github.com:443 (2 requests)
Blocked Domains:
✗ blocked-domain.example.com:443 (2 requests)
{
"firewall_log": {
"total_requests": 8,
"allowed_requests": 5,
"blocked_requests": 3,
"allowed_domains": [
"api.enterprise.githubcopilot.com:443",
"api.github.com:443"
],
"blocked_domains": [
"blocked-domain.example.com:443"
],
"requests_by_domain": {
"api.github.com:443": {
"allowed": 2,
"blocked": 0
}
}
}
}
The logs and audit commands automatically:
.log files in firewall-logs/ or squid-logs/ directoriesrun_summary.jsonFiles:
pkg/cli/firewall_log.go (396 lines) - Core parser implementationpkg/cli/firewall_log_test.go (437 lines) - Unit testspkg/cli/firewall_log_integration_test.go (238 lines) - Integration testsTesting:
# Unit tests
make test-unit
# Integration tests
go test ./pkg/cli -run TestFirewallLogIntegration
This section defines what constitutes a breaking change for the gh-aw CLI. These rules help maintainers and contributors evaluate changes during code review and ensure stability for users.
Breaking changes require special attention during development and review because they can disrupt existing user workflows. This section provides clear criteria for identifying breaking changes and guidance on how to handle them.
The following changes are always breaking and require:
major changeset type1. Command Removal or Renaming
Breaking:
gh aw logs)gh aw compile → gh aw build)gh aw mcp inspect)Examples from past releases:
--no-instructions flag from compile command (v0.17.0)2. Flag Removal or Renaming
Breaking:
--strict flag)--output → --out)-o → -f)Examples from past releases:
3. Output Format Changes
Breaking:
Examples from past releases:
agent with engine_id, removed frontmatter and prompt fields4. Behavior Changes
Breaking:
strict: false → strict: true)Examples from past releases:
5. Schema Changes
Breaking:
Examples from past releases:
The following changes are not breaking and typically require:
minor changeset for new featurespatch changeset for bug fixes1. Additions
Not Breaking:
Examples:
--json flag to status command (v0.20.0)2. Deprecations
Not Breaking (when handled correctly):
Requirements for deprecation:
3. Bug Fixes
Not Breaking (when fixing unintended behavior):
Note: Fixing a bug that users depend on may require a breaking change notice.
4. Performance Improvements
Not Breaking:
5. Documentation Changes
Not Breaking:
graph TD
A[CLI Change Proposed] --> B{Removing or renaming<br/>command/subcommand/flag?}
B -->|Yes| BREAK1[BREAKING]
B -->|No| C{Modifying JSON output<br/>structure?}
C -->|Yes| BREAK2[BREAKING]
C -->|No| D{Altering default<br/>behavior?}
D -->|Yes| BREAK3[BREAKING]
D -->|No| E{Modifying exit codes<br/>for existing scenarios?}
E -->|Yes| BREAK4[BREAKING]
E -->|No| F{Removing schema fields<br/>or making optional required?}
F -->|Yes| BREAK5[BREAKING]
F -->|No| SAFE[NOT BREAKING]
BREAK1 --> REQ[Requires:<br/>- major changeset<br/>- Migration guide<br/>- Maintainer review]
BREAK2 --> REQ
BREAK3 --> REQ
BREAK4 --> REQ
BREAK5 --> REQ
SAFE --> ACT[Allowed:<br/>- minor for features<br/>- patch for fixes]
When Making CLI Changes:
Changeset Format for Breaking Changes:
"gh-aw": major
Remove deprecated `--old-flag` option
**⚠️ Breaking Change**: The `--old-flag` option has been removed.
**Migration guide:**
- If you used `--old-flag value`, use `--new-flag value` instead
- Scripts using this flag will need to be updated
**Reason**: The option was deprecated in v0.X.0 and has been removed to simplify the CLI.
Changeset Format for Non-Breaking Changes:
For new features:
"gh-aw": minor
Add --json flag to logs command for structured output
For bug fixes:
"gh-aw": patch
Fix incorrect exit code when workflow file not found
Reviewers should verify:
The CLI uses standard exit codes:
| Exit Code | Meaning | Breaking to Change |
|---|---|---|
| 0 | Success | No (adding is fine) |
| 1 | General error | No (for new errors) |
| 2 | Invalid usage | No (for new checks) |
Breaking: Changing the exit code for an existing scenario (e.g., changing from 1 to 2 for a specific error type).
When adding or modifying JSON output:
Special consideration for strict mode changes:
CHANGELOG.md for examples of breaking changesThe scratchpad/mods/ directory contains AI-generated summaries of Go module usage patterns in the gh-aw repository, created by the Go Fan workflow.
Go module summaries provide:
Module summary files follow a consistent naming pattern where the Go module path has slashes replaced with dashes:
| Module Path | File Name |
|---|---|
github.com/goccy/go-yaml | goccy-go-yaml.md |
github.com/spf13/cobra | spf13-cobra.md |
github.com/stretchr/testify | stretchr-testify.md |
The summaries are generated by the Go Fan workflow:
graph LR
A[Scheduled Trigger<br/>Weekdays 7 AM UTC] --> B[Load Cache Memory]
B --> C[Select Next Module<br/>Round-Robin]
C --> D[Analyze Module Usage]
D --> E[Research GitHub Repo]
E --> F[Generate Summary]
F --> G[Write to scratchpad/mods/]
G --> H[Update Cache Memory]
H --> I[Commit & Push]
Update Frequency: Daily on weekdays (Monday-Friday) at 7 AM UTC
Round-Robin Selection: The workflow uses cache-memory to track which module was analyzed last, ensuring each module gets updated in rotation.
When working with Go modules in the codebase:
scratchpad/mods/ for module-specific patterns and best practicesEach module summary includes the following sections:
Last Updated: 2025-12-01 Maintainers: GitHub Next Team