feat: add uv-based project with pytest and CI workflow

- Add pyproject.toml and uv.lock for Python project with uv
- Add src/__init__.py with add(), multiply(), greet() functions
- Add tests/test_example.py with unit tests
- Add commit-message skill for Conventional Commits
- Add Gitea Actions workflow to run pytest

.opencode/skills/commit-message.md

@@ -0,0 +1,59 @@
+# skill: commit-message
+
+Follow these commit message conventions for all git commits:
+
+## Format
+
+```
+<type>(<scope>): <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+## Types
+
+| Type | Description |
+|------|------------|
+| `feat` | New feature |
+| `fix` | Bug fix |
+| `docs` | Documentation only |
+| `style` | Code style (formatting, semicolons) |
+| `refactor` | Code change that neither fixes nor adds |
+| `test` | Adding or updating tests |
+| `chore` | Maintenance, deps, build changes |
+
+## Rules
+
+1. Use imperative: "add" not "added" or "adds"
+2. Limit subject line to 50 chars
+3. Capitalize first letter of description
+4. No period at end of subject
+5. Use scope (module/file) when applicable
+
+## Breaking Changes
+
+If change breaks backward compatibility:
+- Add `BREAKING CHANGE:` in footer
+- Use `!` after type: `feat!:`
+
+## Examples
+
+```
+feat(auth): add login endpoint
+
+fix(api): resolve null pointer in user response
+
+docs(readme): update installation steps
+
+feat!: migrate to v2 API
+
+BREAKING CHANGE: auth header format changed
+```
+
+## When to Write Body
+
+- Explanation of "what" and "why" (not "how")
+- More detail than fits in subject line
+- References to issues/PRs