feat: add gitea-workflow skill with commit conventions and CLI reference
This commit is contained in:
@@ -0,0 +1,67 @@
|
||||
---
|
||||
name: gitea-workflow
|
||||
description: This skill should be used when working in a git repository with a git.sethpc.xyz remote, when the user asks to "commit", "push", "create a repo", "gitea", or when making changes to code that should be committed. Provides commit conventions, CLI reference, and credential safety rules.
|
||||
---
|
||||
|
||||
# Gitea Workflow — Commit Conventions & CLI
|
||||
|
||||
You're working with a repo hosted on Seth's Gitea instance (`git.sethpc.xyz`). Here's how we roll.
|
||||
|
||||
## Commit Conventions (default-on, overridable)
|
||||
|
||||
These conventions apply unless the project's CLAUDE.md says otherwise:
|
||||
|
||||
- **Conventional commits:** Prefix every commit message with a type:
|
||||
- `feat:` — new feature
|
||||
- `fix:` — bug fix
|
||||
- `docs:` — documentation only
|
||||
- `refactor:` — code restructuring, no behavior change
|
||||
- `test:` — adding or updating tests
|
||||
- `chore:` — maintenance, tooling, deps
|
||||
- **Commit immediately** — every meaningful change gets its own commit. Don't hoard changes.
|
||||
- **Always push after commit** — use `gitea push` or `git push`. Code that isn't pushed is just a fancy diary entry.
|
||||
- **No squashing** — every commit is a record. History is sacred (and also useful for debugging).
|
||||
- **No batching unrelated changes** — one commit, one concern. If you changed the auth system AND updated the README, that's two commits.
|
||||
|
||||
## CLI Reference
|
||||
|
||||
The `gitea` CLI handles repo operations against git.sethpc.xyz:
|
||||
|
||||
```
|
||||
gitea create <name> [--private] [--description "..."] # Create a new repo
|
||||
gitea remote <name> # Set/update git origin with token auth
|
||||
gitea push # Push current branch to origin
|
||||
gitea delete <name> # Delete a repo (with confirmation)
|
||||
gitea list # List your repos
|
||||
```
|
||||
|
||||
For creating a new project from scratch:
|
||||
```bash
|
||||
mkdir my-project && cd my-project && git init
|
||||
gitea create my-project --description "What it does"
|
||||
gitea remote my-project
|
||||
# ... write code ...
|
||||
git add -A && git commit -m "feat: initial commit"
|
||||
gitea push
|
||||
```
|
||||
|
||||
## Credential Safety
|
||||
|
||||
**Never commit these:**
|
||||
- `~/.config/gitea/token` or `~/.config/gitea/username`
|
||||
- `.env` files containing secrets
|
||||
- API keys, tokens, or passwords in any form
|
||||
|
||||
**Always ensure `.gitignore` includes:**
|
||||
```
|
||||
.env
|
||||
.env.*
|
||||
*.key
|
||||
*.pem
|
||||
```
|
||||
|
||||
If you see credentials in staged files, warn the user immediately and unstage them.
|
||||
|
||||
## Override Mechanism
|
||||
|
||||
Users can override any convention above in their project's CLAUDE.md. For example, if a project's CLAUDE.md says "squash commits before merge", follow that instead of these defaults. Project-level instructions always win.
|
||||
Reference in New Issue
Block a user