メニュー
Opens a Pull Request on Gitea using the `tea` CLI. Auto-detects branch type, generates PR text, applies label and assignee automatically.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/rogerznts/anvil --skill tea-open-prコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Full flow from scratch using `tea` CLI: asks branch type, creates and checkouts the branch (from stable branch for hotfix, from integration branch otherwise), commits pending changes, pushes, and opens a PR on Gitea.
Organização documental do anvil: onde cada documento mora, como a spec se chama, e o que acontece com ela quando fecha. Use para montar a árvore docs/ num projeto novo, adotar um docs/ existente e bagunçado, regenerar o índice, ou arquivar uma spec promovendo o que virou canônico.
Bootstrap: prepara um projeto para o anvil — injeta as diretivas no CLAUDE.md, gera .claude/rules/, monta ou adota a árvore docs/, escreve o perfil do issue tracker, propõe a rule da stack detectada e registra a guarda de merge. Rode uma vez por projeto, e de novo quando a estrutura mudar bastante.
SKILL.md を表示中
| name | tea-open-pr |
| description | Opens a Pull Request on Gitea using the `tea` CLI. Auto-detects branch type, generates PR text, applies label and assignee automatically. |
Your goal is to open a Pull Request on Gitea using the tea CLI, generating clear, professional, and well-structured PR text that facilitates efficient code reviews.
tea must be configured with a login for this server. If not yet done, run:
tea login add --name=<alias> --url=<gitea-url> --token=<your-token>
When run inside a git repository that has a Gitea remote, tea auto-detects the login and repo — no flags or env vars needed.
{tipo}/{NNN}-{nome} (e.g. fix/013-carrinho-vazio), so the prefix is
the type:
feature/ → Featurefix/ (or the legacy bugfix/) → Bugfixhotfix/ → Hotfixrefactor/, gmud/, experimental/ → Feature (single PR to integration){NNN}-{tipo}-{nome} (e.g. 013-fix-carrinho) → read the
type from the second segmenthml or develop)main), second to the integration branchConfirm with the user which base branches apply if the repo does not follow the main/hml pattern.
A branch with a number carries a spec. Resolve the folder by numeric prefix,
never by string equality — the branch is {type}/{NNN}-{name} and the folder is
{NNN}-{type}-{name}, two different strings on purpose:
NUM=$(git rev-parse --abbrev-ref HEAD | sed -nE 's|^[a-z]+/([0-9]{3})-.*|\1|p')
[ -n "$NUM" ] && SPEC_DIR=$(ls -d docs/specs/"$NUM"-*/ 2>/dev/null | head -1)
No number (chore/, docs/, ci/) means no spec, and Steps 3 and 6.5 skip the
spec parts. Number but no folder: say so — the branch claims a spec that doesn't
exist.
Liste os tickets. Todos devem estar resolved — se algum não estiver, a guarda
de merge vai bloquear o tea pr create, e ela está certa: o padrão é um PR por
spec, e uma spec com ticket aberto não terminou.
ls "$SPEC_DIR"issues/*.md
grep -L 'Status:.*resolved' "$SPEC_DIR"issues/*.md # se voltar algo, pare aqui
Run:
git log <integration-branch>..<head> --oneline
git diff <integration-branch>..<head> --stat
(Use <stable-branch>..<head> for hotfix.)
console.log, var_dump, dd()) or temporary test code are present.Title: Conventional Commits format (e.g., feat(module): short description, fix(module): short description).
Body (Standard PR — Feature / Bugfix / Hotfix → stable branch):
## Summary
- <bullet: what this PR does, high level>
## Details
**How:** <explanation of how the changes were implemented>
- <bullet per relevant change group>
**Why:** <motivation, business rule, or problem being solved>
## Impact
- <bullet: effect on the user or system>
## Spec
`docs/specs/<spec-dir>/spec.md`
Tickets:
- `issues/01-<slug>.md` — <ticket title>
- `issues/02-<slug>.md` — <ticket title>
- `issues/03-<slug>.md` — <ticket title>
Um PR por spec, não por ticket. Uma spec tem N tickets; abrir um PR para cada produziria uma enxurrada de PRs de uma linha, e o revisor perderia a unidade que faz sentido revisar — a mudança inteira.
Por isso todos os tickets da seção estão fechados: a guarda de merge só libera
tea pr create quando issues/ não tem nenhum Status: diferente de resolved.
Se ela bloquear, a spec não terminou — feche o que falta ou reveja o recorte, que
pode estar grande demais para uma spec só.
A seção ## Spec é omitida num branch sem número.
Por que caminho e não closes #47: os tickets são arquivo no repositório, não
issue no servidor, então não há número para fechar. O caminho é a referência
estável, e resolve no diff deste próprio PR.
Body (Hotfix → integration branch — always use exactly this):
Applying hotfix changes to the integration branch.
Run to list available labels:
tea labels list
Auto-suggest based on branch prefix:
| Branch prefix | Suggested label |
|---|---|
feature/ | Kind/Feature (or equivalent) |
bugfix/ | Kind/Bug (or equivalent) |
hotfix/ | Kind/Hot (or equivalent) |
tea labels list.Ask the user who to assign, or skip if unneeded. tea accepts usernames directly — no ID lookups required.
Feature / Bugfix — single PR to integration branch:
tea pr create \
--title "<title>" \
--description "<body>" \
--base <integration-branch> \
--labels "<label-name>" \
--assignees "<username>"
Hotfix — two PRs:
First, PR to stable branch:
tea pr create \
--title "<title>" \
--description "<standard body>" \
--base <stable-branch> \
--labels "<label-name>" \
--assignees "<username>"
Then, PR to integration branch:
tea pr create \
--title "<title>" \
--description "Applying hotfix changes to the integration branch." \
--base <integration-branch> \
--labels "<label-name>" \
--assignees "<username>"
tea auto-detects the repo from the git remote. Use --login <alias> if you have multiple logins configured.
The PR now points at the tickets. Point the tickets back, so someone reading a ticket months later finds where it landed without searching the log.
For each ticket this PR closes, add a line right under **Status:**:
**PR:** https://gitea.exemplo/org/repo/pulls/51
Ticket that already has a **PR:** line gets a second one, not a replacement:
a ticket reworked across two PRs has two, and the history is the point.
Commit the change to the branch before returning the URL, so the link exists in the PR's own diff.
On a hotfix, which opens two PRs, use the URL of the first — the one to the stable branch, where the fix actually lands.
tea pr create outputs the PR URL on success. Show it to the user:
tea resolves label names and assignee usernames automatically — no ID lookups needed.tea auto-detects server and repo from the git remote when run inside the repository.tea labels list to validate names.fix/013-…); in the legacy shape it is the second segment (013-fix-…).