Available Capabilities
Repository Operations
- Search repositories, list branches, get file contents
- Create/update files, create branches
- Compare branches, list commits
Issues
- Create, list, search, update, and comment on issues
- Use issues to track network findings, audit results, and remediation tasks
Pull Requests
- Create PRs for config changes, list PRs, get PR details
- Review and merge PRs, add comments
Code Search
- Search across repositories for configuration patterns
- Find references to specific IPs, VLANs, ACLs in config repos
GitHub Actions
- List workflow runs, get workflow status
- Trigger workflows for automated testing
Workflow Patterns
Network Finding → GitHub Issue
When you discover a network problem (via pyATS, health check, etc.):
- Create a GitHub issue with the finding details
- Include device name, symptom, recommended fix
- Label appropriately (bug, security, performance)
- Reference the GAIT session ID for audit trail
Config Change → Pull Request
When a config change is approved:
- Create a branch from main
- Commit the new/updated config file
- Open a PR with change details and ServiceNow CR number
- Link the PR in the GAIT audit trail
Audit Report → Repository
After health checks or audits:
- Commit the report as a markdown file
- Organize by date:
reports/YYYY-MM-DD/ - Include raw data and AI analysis
Environment Variables
GITHUB_PERSONAL_ACCESS_TOKEN— GitHub PAT with repo access
Important Rules
- Never commit secrets, passwords, or API keys to repositories
- Always create a branch for changes — never push directly to main
- Include meaningful commit messages describing the network change
- Reference ServiceNow CR numbers in PR descriptions when applicable
Failure Behavior
- On a tool error (timeout, unreachable host, malformed response), report the failure and its error message directly to the user rather than fabricating or guessing at results.
- For a confirmed read-only call, check connectivity and retry once if appropriate. For any call that changes state or sends a message, a timeout does not prove the action failed: inspect current state or delivery status before retrying, preserve the required approval/change gates, and do not repeat an action whose outcome is unknown.