القائمة
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يبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى 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-…).