a6eb4da214
- .ai/ instruction set (root, behavior, skills, constraints) - apply.sh workflow documentation (apply.md) - architecture documentation (docs/architecture.md) - .github/copilot-instructions.md for VS Code auto-load - .gitignore (tmp/, .ai-instructions.conf)"
60 lines
1.9 KiB
Markdown
60 lines
1.9 KiB
Markdown
# Git Instructions
|
|
|
|
## 🚨 GIT POLICY - ABSOLUTELY CRITICAL
|
|
|
|
**NEVER EVER make git commands without explicit user approval!**
|
|
|
|
### Forbidden Commands - DO NOT RUN:
|
|
1. ❌ **git add** - User runs this themselves (including git add ., git add -A, git add <file>)
|
|
2. ❌ **git commit** - User runs this themselves
|
|
3. ❌ **git push** - User runs this themselves
|
|
4. ❌ **git push --force** - User runs this themselves
|
|
5. ❌ **git reset** - User runs this themselves
|
|
6. ❌ **ANY command that modifies git repository or server state**
|
|
|
|
### What You CAN Do:
|
|
- ✅ `git status` - Show current state
|
|
- ✅ `git diff` - Show changes
|
|
- ✅ `git log` - Show history
|
|
- ✅ Show the command user should run
|
|
- ✅ Explain what the command will do
|
|
|
|
### Exception:
|
|
Only if user explicitly says:
|
|
- "commit this now"
|
|
- "push this now"
|
|
- "go ahead and commit"
|
|
|
|
Otherwise: **SHOW the command, WAIT for user to run it**
|
|
|
|
---
|
|
|
|
## Best Practices
|
|
|
|
- Always show `git diff` before suggesting commits
|
|
- Show `git status` to verify what will be committed
|
|
- Explain impact of each git operation
|
|
- User controls git commands, you analyze and advise
|
|
- Never assume user wants to commit
|
|
- Production platform infrastructure: Stability > Speed
|
|
|
|
---
|
|
|
|
## Commit Message Workflow
|
|
|
|
When the user asks for a commit message:
|
|
|
|
1. **Run `git diff --staged` or `git diff`** — read what actually changed
|
|
2. **Documentation check** — scan the changed files and ask: does any `docs/` or `README.md` need updating based on these changes? If yes, flag it clearly before writing the message. Do not block the commit — just surface it.
|
|
3. **Write the commit message** — one short subject line, optionally a blank line and brief body if the change needs context
|
|
4. **Show the command** — display the full `git commit -m "..."` for the user to run themselves
|
|
|
|
Format:
|
|
```
|
|
<type>: <what changed>
|
|
|
|
<optional: why, or what is not obvious from the diff>
|
|
```
|
|
|
|
Types: `feat`, `fix`, `docs`, `refactor`, `chore`
|