一键导入
tech-lead-triage
Tria tickets, cria tasks por domínio e delega execução síncrona. Ative quando o ticket estiver em "synced" e precisar de triagem.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Tria tickets, cria tasks por domínio e delega execução síncrona. Ative quando o ticket estiver em "synced" e precisar de triagem.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Gera artefatos visuais para review humano usando playwright-cli. Ative quando a implementação estiver concluída e pronta para review. Respeita expected_evidence do ticket.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to create/refine a ticket, stress-test a plan, or says "grill me", "poke holes in my plan", "challenge my assumptions".
Gera documentação de handoff entre backend e frontend. Ative quando uma task de backend for concluída e precisar comunicar endpoints, schemas e regras para o frontend. Frases gatilho: "create handoff", "document API", "frontend handoff".
Implementa tickets seguindo o plano técnico. Use com domain=frontend|backend|infra. Ativado pelo Tech Lead ou especialistas.
Gera plano técnico detalhado de implementação escaneando o repositório. Ative ANTES de delegar para especialistas, durante a triagem do Tech Lead.
Escaneia o repositório e gera AGENTS.md com stack, comandos e setup de ambiente. Parte do rito de inicialização do projeto, executado APÓS setup.sh.
| name | tech-lead-triage |
| description | Tria tickets, cria tasks por domínio e delega execução síncrona. Ative quando o ticket estiver em "synced" e precisar de triagem. |
| tools | ["read","write","run_command"] |
Esta skill analisa um ticket, gera o plano técnico, cria tasks por domínio e orquestra a execução síncrona na mesma worktree.
⚠️ Regra fundamental: Tickets multi-domínio executam na MESMA worktree, de forma SÍNCRONA. Backend SEMPRE primeiro.
⚠️ Storage de Tickets: TODOS os arquivos de ticket (.ai-tickets/issues/, .ai-tickets/templates/, .ai-tickets/learnings/) são armazenados EXCLUSIVAMENTE na worktree de storage em .ai-tickets/storage/.ai-tickets/. Esta worktree é persistente e nunca é deletada. As worktrees de código são efêmeras e contêm APENAS código.
.ai-tickets/storage/.ai-tickets/issues/issue-{id}-{slug}/ticket.md.ai-tickets/storage/.ai-tickets/issues/issue-{id}-{slug}/meta.jsonAGENTS.mdLeia o frontmatter e o body do ticket. Entenda:
frontend, backend, infra)expected_evidence)Ative a skill plan-implementation para escanear o repositório e gerar o plano detalhado.
Após a execução da skill, releia o plano gerado em artifacts/implementation-plan.md.
Atualize ticket.md frontmatter: status: planned
Baseado no plano gerado, crie uma task para cada domínio identificado:
mkdir -p .ai-tickets/storage/.ai-tickets/issues/issue-{id}-{slug}/tasks/{domain}
Cada task contém:
tasks/{domain}/ticket.md — subconjunto do plano técnico específico do domínio (descrição, arquivos impactados, passos)tasks/{domain}/meta.json — metadados da task:
{
"ticket_id": "{id}-{domain}",
"parent_id": "{id}",
"domain": "{domain}",
"status": "planned",
"agent_assigned": null,
"code_worktree_path": ".ai-tickets/worktrees/issue-{id}-{slug}",
"agent_steps_completed": [],
"completed_at": null,
"created_at": "{data}",
"updated_at": "{data}"
}
Atualize meta.json do parent: adicione o domínio em children_ids.
| Domínio no plano | Criar task em |
|---|---|
frontend | tasks/frontend/ |
backend | tasks/backend/ |
infra | tasks/infra/ |
| Múltiplos | Uma task por domínio |
BRANCH="ai-tickets/${TICKET_ID}-${SLUG}"
git worktree add ".ai-tickets/worktrees/issue-${TICKET_ID}-${SLUG}" "$BRANCH" 2>/dev/null || \
(git branch "$BRANCH" main && git worktree add ".ai-tickets/worktrees/issue-${TICKET_ID}-${SLUG}" "$BRANCH")
️ Tratamento de erro: Se a worktree não puder ser criada (conflito de branch, permissão), reporte o erro e não prossiga.
Atualize code_worktree_path no meta.json do parent e de cada task.
Ordem obrigatória:
infra (se existir) → primeirobackend (se existir) → segundofrontend (se existir) → terceiroPara cada task:
a) Atualize tasks/{domain}/ticket.md frontmatter: status: in_progress
b) Atualize tasks/{domain}/meta.json: status: in_progress
c) Invoque o especialista:
frontend → agente frontend-specialist com caminho tasks/frontend/backend → agente backend-specialist com caminho tasks/backend/infra → agente infra-specialist com caminho tasks/infra/
d) Passe para o especialista:.ai-tickets/storage/.ai-tickets/issues/issue-{id}-{slug}/tasks/{domain}/.ai-tickets/worktrees/issue-{id}-{slug}/review)
f) Se o especialista reportar erro, pare a execução e reporte ao usuárioHandoff entre tasks: Após a task de backend concluir (antes de iniciar frontend):
handoff para gerar artifacts/handoff.md com endpoints, schemas e regrasQuando todas as tasks estiverem review:
a) Invoque o agente qa-validator com a skill qa-validation
b) Passe para o QA:
.ai-tickets/storage/.ai-tickets/issues/issue-{id}-{slug}/.ai-tickets/worktrees/issue-{id}-{slug}/qa-validation que:artifacts/evidence/qa-report.md
d) Se QA PASS (todos ✅): prossiga para consolidar.
e) Se QA FAIL (algum ❌): entre no loop de correção (seção 7.1).Quando QA falha, o fluxo não morre — ele entra em um loop controlado de correção:
QA FAIL → Tech Lead analisa → reabre task → especialista corrige → QA re-executa
↑ |
└─────────────────────── até 3 ciclos ────────────────────────────────────┘
Passo a passo:
qa-report.md — entenda exatamente o que falhou e por quêtasks/{domain}/ticket.md → status: in_progresscorrection_cycles no meta.json do parent## Correção — Ciclo {N}/3
### O que falhou
{transcrição do erro do qa-report.md}
### O que precisa ser corrigido
{instrução específica baseada no relatório de QA}
### Evidências
{caminho para screenshots/logs que comprovam a falha}
status: review❌ Não foi possível corrigir após 3 tentativas.
📄 Último QA Report: artifacts/evidence/qa-report.md
🔍 Domínio com falha: {domain}
🛑 Ação necessária: revisão manual do usuário
Após QA passar, o ticket vai para review humano no Linear. O humano pode:
In Review → DoneIn Review → In Progress com comentáriomkdir -p .ai-tickets/storage/.ai-tickets/issues/issue-{id}-{slug}/tasks/correction
review_cycles no meta.json do parenttasks/correction/ticket.md contém:
---
status: in_progress
domain: correction
parent_id: "{id}"
---
## Revisão Humana
{comentário completo do revisor no Linear}
## O que precisa ser ajustado
{extraído do comentário pelo Tech Lead}
Antes de consolidar, ative a skill retro para gerar retrospectiva em .ai-tickets/storage/.ai-tickets/learnings/issue-{id}-{slug}/retro.md. Isso acumula aprendizado para tickets futuros.
Quando QA validar tudo:
npm run build passing:
cd .ai-tickets/worktrees/issue-{id}-{slug}
npm run build
Se o build falhar, reabra a task do domínio afetado e corrija antes de prosseguir.ticket.md frontmatter: status: donemeta.json do parent: completed_atevidence-gen para gerar artefatos visuais adicionais no parentApós o merge, a worktree de código pode ser removida para liberar espaço:
git worktree remove .ai-tickets/worktrees/issue-{id}-{slug}
git branch -d ai-tickets/${TICKET_ID}-${SLUG}
⚠️ IMPORTANTE: A worktree de storage (.ai-tickets/storage/) NUNCA é removida. Ela contém todo o histórico de tickets.
Informe no CLI: