npx skills add smithery/clempat --skill gitea-tea
smithery.ai
gitea-tea
Work with Gitea using tea CLI for auth, repo, issue, pull request, and release workflows. Use when user references Gitea, self-hosted git forges, or asks for tea commands.
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Helps users discover and install agent skills when they ask questions like "how do I do X", "fi…
3.3M installsBrowser automation CLI for AI agents. Use when the user needs to interact with websites, includ…
810.4K installsReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "chec…
617.3K installsBuild, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and …
576.5K installsPrepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Te…
568.3K installsAlso in this package
Other skills from smithery.ai · top by installs.
npx skills add https://smithery.ai
More details
Agent compatibility
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Also listed on
Alternate registries and mirrors of this skill.
Package contents
Files included with this skill beyond the listing page.
-
skill md
SKILL.md3,239 B -
docs
SUMMARY.md188 B
History
- First seen on skills.sh
- First recorded snapshot · 70 installs
SKILL.md
Gitea + tea CLI
Use this skill when tasks target Gitea and the tea CLI, especially if the user would normally use gh on GitHub.
When To Use
- User mentions Gitea, self-hosted git, forgejo-compatible flows, or
tea - You need CLI automation for issues, pull requests, repos, comments, or releases
- You need host-specific auth profiles (multiple Gitea instances)
Core Rules
- Prefer
teaoverghfor Gitea targets. - Always scope commands to target explicitly when ambiguity exists:
- --repo owner/name - --login <profile> - --remote <remote-name>
- If command flags differ by tea version, run
tea <cmd> --helpfirst and follow local help text. - For PR/review actions, ensure local branches are pushed before create/merge operations.
Auth Workflow
Create login profile (token)
tea login add --name <profile> --url https://gitea.example.com --token <token>
Verify logins / switch default
tea login ls
tea login default -n <profile>
Optional env-based auth (automation)
GITEASERVERURLGITEASERVERTOKENGITEASERVERUSERGITEASERVERPASSWORD
Command Mapping (gh -> tea)
- Repo list:
gh repo list->tea repos ls - Issue list:
gh issue list->tea issues ls - Issue create:
gh issue create->tea issues create - PR list:
gh pr list->tea pr lsortea pulls ls - PR create:
gh pr create->tea pr createortea pulls create - PR checkout:
gh pr checkout <n>->tea pulls checkout <n> - Comment on PR/issue:
gh pr comment/gh issue comment->tea comment <index> [body] - Release list/create:
gh release list/create->tea releases ls/tea releases create
Practical Patterns
Work on a specific repo
tea issues ls --repo owner/name --login <profile>
tea pr ls --repo owner/name --login <profile>
Create issue / PR
tea issues create --repo owner/name --title "Title" --body "Details"
tea pr create --repo owner/name --head <branch> --title "Title" --description "Details"
Review / merge PR
tea pulls review <index>
tea pulls approve <index>
tea pulls merge <index>
Release workflow
tea releases create --repo owner/name --tag vX.Y.Z --title "vX.Y.Z"
tea release assets --help
Safety + Verification
- Run read-only commands first (
ls,list,view) before mutating operations. - If repo context unclear, require explicit
--repoand--login. - Before destructive actions (
delete,close,merge), confirm target index and repository. - If command fails, capture
tea <subcommand> --helpoutput and adapt flags to installed version.
Troubleshooting
- Auth failures: re-check login profile URL/token; verify
tea login ls. - Wrong target host/repo: pass both
--loginand--repoexplicitly. - PR creation errors: ensure branch is pushed and upstream is configured.
- TLS issues on internal hosts: prefer proper CA trust; use insecure flags only when user explicitly accepts risk.