菜单
Git and GitHub best practices for AWS Coworker change management
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
**AWS Coworker Development Guardrails** - MANDATORY when extending or modifying AWS Coworker itself. TRIGGERS (use this skill when ANY of these apply): - User asks to add new skills, agents, or commands to AWS Coworker - User asks to modify existing AWS Coworker components - User asks about AWS Coworker architecture or design - User wants to add support for new AWS services - Discussion involves directory structure or file organization - User mentions "extending", "customizing", or "adding to" AWS Coworker - Creating or modifying files in: skills/, .claude/agents/, .claude/commands/, config/ NOT for: Using AWS Coworker to interact with AWS (that's CLAUDE.md's domain)
Canonical AWS CLI patterns for discover, plan, deploy, validate, and rollback
AWS Well-Architected Framework alignment for planning and review
Organization governance policies - never do, always do, and compliance rules
Multi-account and OU strategy, landing zone patterns, and workload placement
Cost-aware AWS interaction and optimization patterns
| name | git-workflow |
| description | Git and GitHub best practices for AWS Coworker change management |
| version | 1.0.0 |
| category | core |
| agents | ["aws-coworker-meta-designer","aws-coworker-core"] |
| tools | ["Bash","Read","Write"] |
This skill provides Git and GitHub best practices for managing changes within AWS Coworker. It ensures consistent, reviewable, and reversible change management across all AWS Coworker components.
| Type | Pattern | Purpose | Merge Target |
|---|---|---|---|
| Main | main | Stable baseline | N/A (protected) |
| Feature | feature/{description} | New capabilities | main |
| Fix | fix/{description} | Bug fixes | main |
| Refactor | refactor/{description} | Code improvements | main |
| Docs | docs/{description} | Documentation updates | main |
| Release | release/v{version} | Release preparation | main + tag |
# Good branch names
feature/add-eks-skill
fix/guardrail-validation-error
refactor/simplify-planner-workflow
docs/improve-getting-started
# Avoid
feature/stuff # Too vague
my-branch # No type prefix
Feature/Add-EKS-Skill # Wrong case
feature/add_eks_skill # Underscores
<type>: <subject>
<body>
<footer>
| Type | Use For |
|---|---|
feat | New features |
fix | Bug fixes |
docs | Documentation |
refactor | Code restructuring |
style | Formatting (no logic change) |
test | Adding tests |
chore | Maintenance tasks |
# Simple commit
git commit -m "feat: add EKS discovery commands to aws-cli-playbook"
# Detailed commit
git commit -m "fix: correct region validation in executor agent
The executor was accepting invalid region codes due to
a regex pattern error. This fix:
- Updates the region validation regex
- Adds test cases for edge cases
- Documents valid region formats
Fixes #42"
Do:
Don't:
# 1. Create and switch to feature branch
git checkout -b feature/add-new-skill
# 2. Make changes
# ... edit files ...
# 3. Stage specific files
git add skills/aws/new-skill/SKILL.md
# 4. Commit with clear message
git commit -m "feat: add new-skill for [purpose]"
# 5. Push branch
git push -u origin feature/add-new-skill
# 6. Create PR via GitHub CLI or web
gh pr create --title "Add new-skill" --body "..."
## Summary
[Brief description of changes]
## Changes
- [Change 1]
- [Change 2]
- [Change 3]
## Testing
- [ ] Tested in sandbox environment
- [ ] Ran audit-library checks
- [ ] Verified documentation accuracy
## Related
- Fixes #[issue]
- Related to #[PR]
For reviewers:
Follow semantic versioning:
# Tag a release
git tag -a v1.2.0 -m "Release v1.2.0: Add EKS support"
git push origin v1.2.0
# List tags
git tag -l "v*"
For rollback points:
# Create baseline before major changes
git tag -a baseline/pre-org-customization -m "Baseline before org customization"
# Create date-based baseline
git tag -a baseline/2026-01-29 -m "Baseline 2026-01-29"
# Ensure main is current
git checkout main
git pull origin main
# Create feature branch
git checkout -b feature/descriptive-name
# While on feature branch
git fetch origin
git rebase origin/main
# Or merge if preferred
git merge origin/main
# Discard unstaged changes to a file
git checkout -- path/to/file
# Unstage a file (keep changes)
git reset HEAD path/to/file
# Undo last commit (keep changes)
git reset --soft HEAD~1
# Undo last commit (discard changes) - CAREFUL
git reset --hard HEAD~1
# Recent commits
git log --oneline -10
# Commits affecting a file
git log --oneline -- path/to/file
# Changes in a commit
git show <commit-hash>
# Diff between branches
git diff main..feature/my-branch
The main branch should have:
In genuine emergencies:
Add patterns when:
# Be specific
.terraform/ # Good: specific directory
# Avoid overly broad patterns
* # Bad: ignores everything
# Comment sections
# -----------------------
# Terraform
# -----------------------
.terraform/
*.tfstate
# When merge/rebase conflicts occur
# 1. See conflicting files
git status
# 2. Open files and resolve conflicts
# Look for <<<<<<< HEAD ... ======= ... >>>>>>> markers
# 3. After resolving, stage files
git add path/to/resolved/file
# 4. Continue rebase or complete merge
git rebase --continue
# or
git commit
# Create PR
gh pr create --title "Title" --body "Description"
# List PRs
gh pr list
# View PR
gh pr view 123
# Check out PR locally
gh pr checkout 123
# Merge PR
gh pr merge 123
# Create issue
gh issue create --title "Title" --body "Description"
documentation-standards — For documentation in commits/PRsskill-designer — For creating new skills via Git workflowcommand-designer — For creating new commands via Git workflow