historical-pattern-analysis
Skill15 starsChanged 9 months agoMITView on GitHub
Use when analyzing git history and past changes to identify patterns, recurring issues, and lessons learned from infrastructure changes.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Before making changes similar to past changes
- Distinctive: line 17
When investigating recurring issues
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Historical Pattern Analysis
Overview
Analyze git history and memory to learn from past infrastructure changes. Identify patterns, recurring issues, and apply lessons learned to current work.
Announce at start: "I'm using the historical-pattern-analysis skill to learn from past changes."
When to Use
- Before making changes similar to past changes
- When investigating recurring issues
- To understand why infrastructure is configured a certain way
- To identify change patterns and team practices
Process
Step 1: Define Search Scope
Determine what history to analyze:
- Specific resources being changed
- Time period (last month, quarter, year)
- Specific team members or patterns
Step 2: Git Archaeology
Find Related Commits
# Commits touching specific files
git log --oneline -20 -- "path/to/module/*.tf"
# Commits mentioning resource types
git log --oneline -20 --grep="aws_security_group"
# Commits by pattern in message
git log --oneline -20 --grep="fix\|rollback\|revert"
# Commits in date range
git log --oneline --since="2024-01-01" --until="2024-06-01" -- "*.tf"Analyze Commit Patterns
# Most frequently changed files
git log --pretty=format: --name-only -- "*.tf" | sort | uniq -c | sort -rn | head -20
# Authors and their focus areas
git shortlog -sn -- "environments/prod/"
# Change frequency by day/time
git log --format="%ad" --date=format:"%A %H:00" -- "*.tf" | sort | uniq -cFind Reverts and Fixes
# Revert commits
git log --oneline --grep="revert\|Revert"
# Fix commits following changes
git log --oneline --grep="fix\|hotfix\|Fix"
# Commits with "URGENT" or "EMERGENCY"
git log --oneline --grep="urgent\|emergency" -iStep 3: Analyze Change Patterns
Coupling Analysis
Which files change together?
# For a specific file, what else changes with it?
git log --pretty=format:"%H" -- "modules/vpc/main.tf" | \
xargs -I {} git show --name-only --pretty=format: {} | \
sort | uniq -c | sort -rn | head -20Change Sequences
Common sequences of changes:
- VPC changes → followed by security group changes
- IAM role changes → followed by policy attachments
- RDS changes → followed by parameter group changes
Time Patterns
- Are prod changes clustered on certain days?
- Are there "risky" times based on past incidents?
- How long between staging and prod deployments?
Step 4: Query Memory
Check stored patterns:
memory/projects/<hash>/patterns.json
memory/projects/<hash>/incidents.jsonLook for:
- Similar past changes and outcomes
- Known issues with these resources
- User preferences for this type of change
Step 5: Identify Lessons
From Incidents
For each past incident:
- What was the trigger?
- How was it detected?
- What was the fix?
- What could have prevented it?
From Patterns
- What changes tend to cause problems?
- What practices lead to success?
- What review processes work well?
Step 6: Generate Report
## Historical Pattern Analysis
### Search Scope
- Resources: [resources being analyzed]
- Time period: [date range]
- Related commits found: [count]
### Change Frequency
| Resource/File | Changes (90d) | Last Changed | Primary Authors |
|--------------|---------------|--------------|-----------------|
| modules/vpc/main.tf | 12 | 2024-01-10 | alice, bob |
| environments/prod/main.tf | 8 | 2024-01-08 | alice |
### Change Coupling
These resources typically change together:
1. `aws_security_group.web` ↔ `aws_instance.web` (85% correlation)
2. `aws_iam_role.app` ↔ `aws_iam_policy.app` (100% correlation)
### Past Incidents Related to These Resources
#### Incident: [Date] - [Title]
- **Trigger:** [What caused it]
- **Impact:** [What happened]
- **Resolution:** [How it was fixed]
- **Lesson:** [What we learned]
- **Relevance:** [How this applies to current change]
### Patterns Identified
#### Pattern: [Pattern Name]
- **Observation:** [What we see in history]
- **Frequency:** [How often]
- **Implication:** [What this means for current change]
### Risk Indicators
Based on historical data:
| Indicator | Current Change | Historical Issues |
|-----------|---------------|-------------------|
| Similar to past incident | [Yes/No] | [Details] |
| Frequently problematic resource | [Yes/No] | [Details] |
| Changed by unfamiliar author | [Yes/No] | [Details] |
### Recommendations
Based on historical patterns:
1. [Recommendation 1]
2. [Recommendation 2]
### Questions Raised
[Questions that history suggests we should answer]Step 7: Update Memory
Store new patterns discovered:
{
"patterns": [
{
"name": "vpc-sg-coupling",
"description": "VPC changes often require SG updates",
"confidence": 0.85,
"last_seen": "2024-01-15"
}
]
}Common Patterns to Look For
Positive Patterns
- Consistent naming conventions
- Regular, small changes vs. big-bang updates
- Changes preceded by plan review
- Post-change validation
Warning Patterns
- Frequent reverts
- Emergency fixes following changes
- Clustered failures in specific areas
- "Temporary" changes that persist
Anti-Patterns
- Direct prod changes without staging
- Large changes without incremental steps
- Missing documentation on complex changes
- Recurring manual interventions
Integration with Other Skills
This skill feeds into:
- terraform-plan-review: Provides historical context for risk assessment
- terraform-drift-detection: Identifies if drift matches past patterns
- provider-upgrade-analysis: Shows past upgrade experiences
In this repository20 other files it gives its agents.
- auto-documentationSkill
- aws-profile-managementSkill
- brainstormingSkill
- dispatching-parallel-agentsSkill
- executing-plansSkill
- finishing-a-development-branchSkill
- provider-upgrade-analysisSkill
- receiving-code-reviewSkill
- requesting-code-reviewSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- terraform-drift-detectionSkill
- terraform-plan-reviewSkill
- terraform-state-operationsSkill
- test-driven-developmentSkill
- using-devops-skillsSkill
- using-git-worktreesSkill
- verification-before-completionSkill
- writing-plansSkill
- writing-skillsSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

