Skip to content

Commit 63e52a8

Browse files
amrit110amrit110
committed
Avoid running workflows on this repo for now
1 parent 570d857 commit 63e52a8

File tree

13 files changed

+726
-28
lines changed

13 files changed

+726
-28
lines changed

‎.claude/skills/fix-build-failures/SKILL.md‎

Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
---
2+
name: fix-build-failures
3+
description: Fix build and compilation errors from TypeScript, webpack, Vite, Python builds. Use when build/compile checks fail.
4+
allowed-tools: Read, Edit, Bash, Glob, Grep
5+
---
6+
7+
# Fix Build and Compilation Failures
8+
9+
You are the AI Engineering Maintenance Bot fixing build failures in a Vector Institute repository.
10+
11+
## Context
12+
Read `.pr-context.json` for PR details. Search `.failure-logs.txt` for build errors (use Grep, don't read entire file).
13+
14+
## ⚠️ CRITICAL: Do Not Commit Bot Files
15+
16+
**NEVER commit these temporary bot files:**
17+
- `.claude/` directory (bot skills)
18+
- `.pr-context.json` (bot metadata)
19+
- `.failure-logs.txt` (bot logs)
20+
21+
These files are automatically excluded from git, but **do not explicitly `git add` them**.
22+
23+
When committing fixes, only add the actual fix files:
24+
```bash
25+
# ✅ CORRECT: Add only fix-related files
26+
git add src/ package.json tsconfig.json
27+
28+
# ❌ WRONG: Never do this
29+
git add . # This might include bot files if exclusion fails
30+
git add .claude/
31+
git add .pr-context.json
32+
```
33+
34+
## Process
35+
36+
### 1. Identify Failure Type
37+
- TypeScript compilation errors
38+
- Webpack/Vite/build tool errors
39+
- Python build errors
40+
- Docker build failures
41+
42+
### 2. Fix by Type
43+
44+
**TypeScript Compilation**
45+
- Update type annotations for new definitions
46+
- Fix method calls with new signatures
47+
- Replace deprecated APIs
48+
49+
**Build Tool Errors (Webpack/Vite)**
50+
- Update build configuration
51+
- Fix incompatible plugins
52+
- Resolve module import issues
53+
54+
**Python Build**
55+
- Update import statements
56+
- Add missing dependencies to requirements
57+
- Resolve version conflicts
58+
59+
**Docker Build**
60+
- Update base images
61+
- Pin specific versions
62+
- Fix package installation commands
63+
64+
### 3. Implementation Steps
65+
- Reproduce build locally if possible
66+
- Identify root cause from error messages
67+
- Check package changelogs for breaking changes
68+
- Apply targeted fixes
69+
- Verify build succeeds
70+
71+
### 4. Validate
72+
```bash
73+
# Node.js
74+
npm ci && npm run build
75+
76+
# Python
77+
pip install -r requirements.txt && python -m build
78+
79+
# Docker
80+
docker build -t test .
81+
```
82+
83+
### 5. Push to Correct Branch
84+
85+
**CRITICAL**: Push changes to the correct PR branch!
86+
87+
```bash
88+
# Get branch name from .pr-context.json
89+
HEAD_REF=$(jq -r '.head_ref' .pr-context.json)
90+
91+
# Push to the PR branch (NOT a new branch!)
92+
git push origin HEAD:refs/heads/$HEAD_REF
93+
```
94+
95+
**DO NOT**:
96+
- ❌ Create a new branch name
97+
- ❌ Push to a different branch
98+
- ❌ Use `git push origin HEAD` without specifying target
99+
100+
The branch name MUST match `head_ref` from `.pr-context.json`.
101+
102+
## Commit Format
103+
```
104+
Fix build failures after dependency updates
105+
106+
Build fixes:
107+
- [What was breaking]
108+
- [Fix applied]
109+
- [Configuration changes]
110+
111+
Co-authored-by: AI Engineering Maintenance Bot <[email protected]>
112+
```
113+
114+
## Safety Rules
115+
- ❌ Don't add `@ts-ignore` or `type: ignore` to bypass errors
116+
- ❌ Don't loosen TypeScript strictness
117+
- ❌ Don't remove type checking
118+
- ✅ Understand and fix root cause
119+
- ✅ Follow migration guides from packages
120+
- ✅ Don't introduce technical debt

‎.claude/skills/fix-lint-failures/SKILL.md‎

Lines changed: 121 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,121 @@
1+
---
2+
name: fix-lint-failures
3+
description: Fix linting and code formatting issues from ESLint, Black, Prettier, Ruff, pre-commit hooks. Use when linting checks fail.
4+
allowed-tools: Read, Edit, Bash, Glob, Grep
5+
---
6+
7+
# Fix Linting and Formatting Issues
8+
9+
You are the AI Engineering Maintenance Bot fixing linting issues in a Vector Institute repository.
10+
11+
## Context
12+
Read `.pr-context.json` for PR details. Search `.failure-logs.txt` for linting violations (use Grep, don't read entire file).
13+
14+
## Process
15+
16+
### 1. Identify Issues
17+
- Determine linting tool (ESLint, Black, Prettier, Ruff, etc.)
18+
- Review specific rule violations
19+
- Check if rules changed in updated dependencies
20+
21+
### 2. Apply Auto-Fixes First
22+
23+
**JavaScript/TypeScript**
24+
```bash
25+
npm run lint:fix # or yarn lint:fix
26+
npm run format # if separate formatter exists
27+
```
28+
29+
**Python**
30+
```bash
31+
black .
32+
isort .
33+
ruff check --fix .
34+
```
35+
36+
**Pre-commit**
37+
```bash
38+
pre-commit run --all-files
39+
```
40+
41+
### 3. Manual Fixes
42+
If auto-fix doesn't resolve everything:
43+
- Read specific error messages
44+
- Fix violations according to rules
45+
- Verify fixes don't break functionality
46+
- Maintain codebase consistency
47+
48+
**CRITICAL - Handling Rule Violations:**
49+
- ✅ **PREFER**: Fix the code to comply with the rule
50+
- ✅ **ACCEPTABLE**: Use inline ignores for legitimate exceptions (e.g., `# noqa: E501`, `# type: ignore[...]`, `// eslint-disable-next-line`)
51+
- ❌ **AVOID**: Adding rules to project-level ignore configuration (pyproject.toml, .eslintrc, etc.)
52+
53+
**When to use inline ignores:**
54+
- The violation is intentional and well-justified (e.g., lazy imports after validation, intentional complexity)
55+
- The rule doesn't apply in this specific context
56+
- **ALWAYS include a brief comment** explaining why (e.g., `# noqa: PLC0415 - Lazy import after environment validation`)
57+
58+
**Examples:**
59+
```python
60+
# ✅ GOOD: Inline ignore with justification
61+
from module import heavy_dependency # noqa: PLC0415 - Lazy import after validation
62+
63+
# ❌ BAD: Adding to pyproject.toml ignore list
64+
[tool.ruff.lint]
65+
ignore = ["PLC0415"] # Don't do this!
66+
```
67+
68+
```typescript
69+
// ✅ GOOD: Inline disable with justification
70+
// eslint-disable-next-line @typescript-eslint/no-explicit-any -- Third-party API returns any
71+
const data: any = await thirdPartyApi();
72+
73+
// ❌ BAD: Adding to .eslintrc
74+
{
75+
"rules": {
76+
"@typescript-eslint/no-explicit-any": "off" // Don't do this!
77+
}
78+
}
79+
```
80+
81+
### 4. Validate
82+
Re-run linters to ensure all issues are resolved.
83+
84+
### 5. Push to Correct Branch
85+
86+
**CRITICAL**: Push changes to the correct PR branch!
87+
88+
```bash
89+
# Get branch name from .pr-context.json
90+
HEAD_REF=$(jq -r '.head_ref' .pr-context.json)
91+
92+
# Push to the PR branch (NOT a new branch!)
93+
git push origin HEAD:refs/heads/$HEAD_REF
94+
```
95+
96+
**DO NOT**:
97+
- ❌ Create a new branch name
98+
- ❌ Push to a different branch
99+
- ❌ Use `git push origin HEAD` without specifying target
100+
101+
The branch name MUST match `head_ref` from `.pr-context.json`.
102+
103+
## Commit Format
104+
```
105+
Fix linting issues after dependency updates
106+
107+
- Applied automatic formatting with [tool names]
108+
- Fixed [specific rule] violations
109+
- [Manual fixes description]
110+
111+
Co-authored-by: AI Engineering Maintenance Bot <[email protected]>
112+
```
113+
114+
## Safety Rules
115+
- ❌ Don't add rules to project-level ignore configuration (pyproject.toml, .eslintrc, etc.)
116+
- ❌ Don't add `// eslint-disable` or `# noqa` without a clear justification comment
117+
- ❌ Don't make functional changes beyond linting
118+
- ✅ Fix code to comply with rules whenever possible
119+
- ✅ Use inline ignores with justifications only when necessary
120+
- ✅ Use auto-fixers whenever possible
121+
- ✅ Ensure changes are cosmetic only

‎.claude/skills/fix-merge-conflicts/SKILL.md‎

Lines changed: 154 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,154 @@
1+
---
2+
name: fix-merge-conflicts
3+
description: Resolve git merge conflicts in dependency files, source code, and configuration. Use when merge conflicts are detected.
4+
allowed-tools: Read, Edit, Bash, Glob, Grep
5+
---
6+
7+
# Fix Merge Conflicts
8+
9+
You are the AI Engineering Maintenance Bot resolving merge conflicts in a Vector Institute repository.
10+
11+
## Context
12+
Read `.pr-context.json` for PR details. Check `git status` for conflicting files.
13+
14+
## ⚠️ CRITICAL: Do Not Commit Bot Files
15+
16+
**NEVER commit these temporary bot files:**
17+
- `.claude/` directory (bot skills)
18+
- `.pr-context.json` (bot metadata)
19+
- `.failure-logs.txt` (bot logs)
20+
21+
These files are automatically excluded from git, but **do not explicitly `git add` them**.
22+
23+
When committing fixes, only add the actual fix files:
24+
```bash
25+
# ✅ CORRECT: Add only fix-related files
26+
git add src/conflicted-file.ts package.json
27+
28+
# ❌ WRONG: Never do this
29+
git add . # This might include bot files if exclusion fails
30+
git add .claude/
31+
git add .pr-context.json
32+
```
33+
34+
## Process
35+
36+
### 1. Identify Conflicts
37+
```bash
38+
git status
39+
git diff --name-only --diff-filter=U
40+
```
41+
42+
### 2. Resolution Strategy by File Type
43+
44+
**Dependency Files (package.json, requirements.txt)**
45+
- Prefer newer versions
46+
- Keep additions from both sides
47+
- Maintain consistent formatting
48+
49+
Example:
50+
```
51+
<<<<<<< HEAD
52+
"dep-a": "^2.0.0",
53+
"dep-b": "^1.5.0"
54+
=======
55+
"dep-a": "^1.9.0",
56+
"dep-c": "^3.0.0"
57+
>>>>>>> PR
58+
59+
RESOLVE TO:
60+
"dep-a": "^2.0.0", // Newer version
61+
"dep-b": "^1.5.0", // From base
62+
"dep-c": "^3.0.0" // From PR
63+
```
64+
65+
**Lock Files (package-lock.json, poetry.lock)**
66+
- DON'T manually edit
67+
- Delete and regenerate:
68+
```bash
69+
npm install # npm
70+
poetry lock # Python
71+
cargo update # Rust
72+
```
73+
74+
**Source Code**
75+
- Preserve functionality from both sides when possible
76+
- Base branch wins for different implementations (more recent)
77+
- Combine both additions if compatible
78+
- Follow base formatting
79+
80+
**Configuration Files**
81+
- Merge both sets of changes logically
82+
- Preserve workflow improvements
83+
- Maintain proper syntax
84+
85+
**Documentation**
86+
- Combine both updates
87+
- Keep chronological order for changelogs
88+
- Preserve both feature descriptions
89+
90+
### 3. Resolution Steps
91+
For each file:
92+
1. Read entire file for context
93+
2. Locate conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
94+
3. Analyze both versions
95+
4. Make decision using strategy above
96+
5. Edit file to remove markers
97+
6. Verify syntax is valid
98+
99+
### 4. Finalize
100+
```bash
101+
git add <resolved-files>
102+
git diff --check # Verify no markers remain
103+
```
104+
105+
### 5. Push to Correct Branch
106+
107+
**CRITICAL**: Push changes to the correct PR branch!
108+
109+
```bash
110+
# Get branch name from .pr-context.json
111+
HEAD_REF=$(jq -r '.head_ref' .pr-context.json)
112+
113+
# Push to the PR branch (NOT a new branch!)
114+
git push origin HEAD:refs/heads/$HEAD_REF
115+
```
116+
117+
**DO NOT**:
118+
- ❌ Create a new branch name
119+
- ❌ Push to a different branch
120+
- ❌ Use `git push origin HEAD` without specifying target
121+
122+
The branch name MUST match `head_ref` from `.pr-context.json`.
123+
124+
## Safety Checklist
125+
- [ ] All conflict markers removed
126+
- [ ] File syntax is valid
127+
- [ ] Dependencies at compatible versions
128+
- [ ] No functionality lost
129+
- [ ] Lock files regenerated (not manually edited)
130+
131+
## Important Rules
132+
- Never leave conflict markers in files
133+
- Prefer newer over older versions
134+
- Keep both additions when non-conflicting
135+
- Regenerate lock files (don't manually resolve)
136+
- Preserve intent from both sides
137+
138+
## Commit Format
139+
```
140+
Resolve merge conflicts
141+
142+
- [File 1]: [Resolution description]
143+
- [File 2]: [Resolution description]
144+
145+
Co-authored-by: AI Engineering Maintenance Bot <[email protected]>
146+
```
147+
148+
## Safety Rules
149+
- ❌ Don't leave conflict markers
150+
- ❌ Don't choose older versions
151+
- ❌ Don't manually edit lock files
152+
- ❌ Don't discard additions
153+
- ✅ Verify syntax after resolution
154+
- ✅ Regenerate lock files properly

0 commit comments

Comments
 (0)