lp-skills
Skills do Furihata, distribuídas como plugins que Claude Code, Codex, Cursor, Copilot e VS Code instalam direto do GitHub — igual em Windows, macOS e Linux, sem symlink e sem hook. As skills são separadas em três categorias: Build (o método: /solve, /principles, /front, /method, /adr, /ticrd, /cr, /proto), Ship (a entrega — um pipeline só: os alvos /local, /gh, /homolog, /prod, que levam o trabalho de onde estiver até o próprio estágio; os modificadores /repro e /card, que compõem com qualquer alvo — o /repro, com card, comenta nele a descrição real, com telas; /update-jira, que confere o estado real dos meus cards abertos e o registra neles; e /setup, /jira, /infra, que configuram o processo, o Jira e a infra do projeto) e Toolbox (ferramentas avulsas: /brain, o parecer que entende o problema antes de decidir, /blind, a sessão que não vê nada, /runbook, um processo em YAML executado passo a passo, /prompts, tudo o que você digitou na conversa, /ask, /chat, /save, /sync…).
Este repo é as duas coisas ao mesmo tempo: os pacotes (plugins/<pacote>/, três, um por categoria) com os catálogos que cada cliente lê, e a landing page (Next.js) que ajuda a montar os comandos de instalação.
Uma cópia de cada skill, três clientes. Todos convergiram em skills/<slug>/SKILL.md e discordam só de onde o manifesto mora — e como cada um mora num lugar diferente, os três coexistem no mesmo diretório:
| Cliente | Manifesto que ele lê | Como acha as skills |
|---|
| Claude Code | .claude-plugin/plugin.json | escaneia skills/ na raiz do pacote |
| Agent Plugins v1 — Cursor, Copilot, VS Code, Codex | plugin.json na raiz | skills/ |
| Codex nativo | .codex-plugin/plugin.json | skills: "./skills/" |
Por isso não existe cópia de distribuição neste repo: um push atualiza todos os clientes.
Para usuários — Claude Code
O marketplace tem 3 pacotes (plugins), um por categoria — você instala o pacote, não skill por skill. Cada pacote já traz todas as skills da categoria dentro.
# 1) adicione o marketplace (uma vez por máquina)
/plugin marketplace add eduardofurihata/lp-skills
# 2) instale o pacote que quiser (um, alguns ou todos)
/plugin install furi-build@lp-skills # o método (/solve, /principles, /front, /method, /adr, /ticrd, /cr, /proto)
/plugin install furi-ship@lp-skills # a entrega (alvos: /local, /gh, /homolog, /prod · modificadores: /repro, /card · /update-jira · navegador: /pwx · config: /setup, /jira, /infra)
/plugin install furi-toolbox@lp-skills # ferramentas avulsas (/brain, /blind, /runbook, /prompts, /ask, /chat, /save, /sync, /make-dev, /make-skill, /video-teams…)
3) ligue o auto-update — ele nasce DESLIGADO. Marketplace de terceiro não atualiza sozinho por default; só os oficiais. Ligue de um dos dois jeitos:
// ~/.claude/settings.json — declarativo, e sincroniza entre máquinas
{
"extraKnownMarketplaces": {
"lp-skills": { "source": { "source": "github", "repo": "eduardofurihata/lp-skills" }, "autoUpdate": true }
}
}
Ou pela UI: /plugin → aba Marketplaces → lp-skills → ligue o auto-update (é o mesmo campo que o JSON grava). Confira que a entrada ficou com "autoUpdate": true.
Com ele ligado, o Claude Code busca versão nova em segundo plano depois que a sessão começa (com atraso de até ~10 min, para a sessão em curso não trocar de versão no meio) e avisa para rodar /reload-plugins — ou a versão nova entra no próximo start. Para puxar na hora: /plugin marketplace update lp-skills.
Os três pacotes são independentes — nenhum puxa nenhum. O furi-build é o método (do alvo à entrega no nível #1, provada por QA, sem commit) e não sabe o que é Jira, PR nem deploy; o furi-ship é o processo de entrega e o Jira, e declara o estágio do commit como estado exigido (implementado, revisado, testado com evidência, documentado, um commit) em vez de chamar quem constrói; o furi-toolbox são as avulsas. Instalar o furi-ship sozinho funciona — mas quem quiser o método que fecha aquele estado com protocolo instala o furi-build também; é a combinação recomendada.
Depois de instalado, cada skill é invocada pelo nome curto (/method, /repro, …) — a forma namespaced (/furi-build:method) também funciona. O Claude Code copia o pacote para o cache dele (~/.claude/plugins/cache/lp-skills/<pacote>/<sha>/) ele mesmo, por SO — por isso funciona igual em qualquer sistema, sem os problemas de symlink no Windows. Cada pacote é copiado separadamente, então um caminho plugins/<outro-pacote>/skills/… citado numa skill identificaria o arquivo no repo, não no cache — por isso nenhuma skill cita outro pacote (ver Critério de pacote).
Prefere escolher visualmente? Acesse a LP, filtre por categoria, selecione as skills e copie os comandos gerados.
Requisito: Claude Code recente (recomendado v2.1.142+). Se /plugin não aparecer, atualize o Claude Code.
Para um time/projeto: ponha o marketplace no .claude/settings.json do projeto (extraKnownMarketplaces, com autoUpdate: true) — todo mundo o conhece ao clonar, já atualizando; cada dev instala os pacotes que precisa.
Para usuários — Cursor, Copilot e VS Code
Cada pacote tem um plugin.json na raiz conforme o Agent Plugins v1, o padrão aberto que Cursor, Copilot e VS Code leem — nenhuma conversão, é o mesmo diretório que o Claude Code usa.
No Cursor: Customize → Plugins → importe a URL do repositório (https://github.com/eduardofurihata/lp-skills) como marketplace e instale os pacotes.
Para atualizar sozinho, ligue Enable Auto Refresh no marketplace importado — ele re-indexa a cada push (no máximo a cada ~10 min) e precisa do Cursor GitHub App instalado no repo. Ressalva que vale saber: auto-refresh atualiza o conteúdo dos pacotes existentes; quando um pacote novo aparece no repo, é preciso re-importar a URL para ele ser descoberto.
Para usuários — Codex
O Codex lê o catálogo nativo (.agents/plugins/marketplace.json) e o manifesto .codex-plugin/plugin.json de cada pacote:
# 1) adicione o marketplace uma vez; ele fica salvo em ~/.codex/config.toml
codex plugin marketplace add eduardofurihata/lp-skills --ref main
# 2) instale os pacotes
codex plugin add furi-build@lp-skills
codex plugin add furi-ship@lp-skills
codex plugin add furi-toolbox@lp-skills
# 3) confira o estado global
codex plugin list --marketplace lp-skills
Atualização no Codex não é automática — é o único dos três em que você puxa na mão. Os pacotes instalados ficam em cache (~/.codex/plugins/cache/lp-skills/<pacote>/<versão>/), então além de atualizar o marketplace é preciso reinstalar para o cache pegar a versão nova:
codex plugin marketplace upgrade lp-skills
codex plugin add furi-build@lp-skills # repita para os pacotes que você usa
Para o cache saber que mudou, o gerador acrescenta ao semver um cachebuster derivado do conteúdo das skills do pacote — editar uma skill muda a versão.
Para testar no checkout local antes de publicar, troque o primeiro comando por codex plugin marketplace add /caminho/absoluto/para/lp-skills. Abra uma conversa nova após instalar ou atualizar, para ela carregar as skills.
Estrutura
lp-skills/
├── plugins/ # os 3 pacotes — FONTE das skills, nada gerado aqui dentro de skills/
│ └── <pacote>/
│ ├── plugin.json # Agent Plugins v1 — Cursor, Copilot, VS Code, Codex (GERADO)
│ ├── .claude-plugin/plugin.json # Claude Code (GERADO)
│ ├── .codex-plugin/plugin.json # Codex nativo (GERADO)
│ └── skills/<skill>/SKILL.md # a skill — uma cópia, lida pelos três
├── .claude-plugin/
│ └── marketplace.json # catálogo do Claude Code — 1 pacote por categoria (GERADO)
├── .agents/plugins/
│ └── marketplace.json # catálogo do Codex (GERADO)
├── scripts/
│ ├── generate-plugins.mjs # frontmatter → os 3 manifestos de cada pacote + os 2 catálogos
│ └── validate-plugins.mjs # falha se um pacote não serve algum dos 3 clientes
├── .github/workflows/ci.yml # roda os dois acima: o que está no GitHub é o que foi gerado
├── setup/ # o padrão da minha máquina (o QUÊ, não o como) — ex.: claude-code.md; fora dos pacotes
├── runbook/ # o motor que executa processos passo a passo (comando `runbook`) — ver runbook/README.md
├── app/ # Next.js App Router (a LP)
├── components/ # React components
└── lib/ # categorias + leitor de skills + grafo de relações + gerador de comandos
runbook/ é o motor dos processos que não podem pular passo. Uma skill em texto é um pedido: o modelo segura o plano e decide o que pular. O runbook tira essa decisão dele — lê um processo em YAML e manda um passo por vez para a mesma conversa do agente (claude -p --resume), só avançando quando a resposta traz o que o passo exige; juiz em sessão cega, parada que espera o dev, comando sem IA. Fica fora dos pacotes, instalado na máquina como comando (runbook/install.sh), para qualquer skill de qualquer pacote poder usá-lo sem um depender do outro; o /runbook (toolbox) é a porta no chat. Detalhes em runbook/README.md.
Cada pasta em plugins/ é a raiz de um pacote, e as skills dela moram em plugins/<pacote>/skills/<slug>/. A categoria de cada skill é derivada do pacote (furi-build → build), e o mapa categoria↔pacote sai do catálogo gerado — a LP não repete essa lista. O nome de invocação (/homolog) vem do name no frontmatter do SKILL.md. Dependência entre pacotes seria derivada do requires — e não há nenhuma: os três são independentes.
Critério de pacote: a skill que não tem requires e de quem nenhuma outra skill depende ou invoca vai para furi-toolbox — funciona sozinha (o /brain e o /blind são os casos-limite: sem dependências, sem dependentes, sem citar outra skill e sem uma linha que cite empresa, linguagem ou forja — funcionam em qualquer repositório, então são toolbox). O /blind é o caso extremo: uma sessão que não vê nada — nem esta conversa, nem CLAUDE.md, nem arquivos, nem internet, nem ferramenta — e por isso nenhuma skill a invoca nem é invocada por ela; o /brain, que precisa da mesma segunda opinião, carrega o próprio bloco de sessão cega (claude -p --safe-mode) em vez de depender do /blind — é o preço de cada um ser instalável sozinho. As que entram no grafo se dividem pelo que tocam: furi-ship é o /jira, o /setup, o /infra e toda skill que os lista em requires — quem fala com board, GitHub ou ambiente. Dentro dele há uma escada só, com cada estágio numa skill: os quatro alvos (/local → /gh → /homolog → /prod) diagnosticam a própria faixa e invocam o alvo anterior quando um estágio de trás está aberto; os dois modificadores (/repro, /card) rodam a própria parte e delegam ao alvo, em qualquer ordem digitada (/repro /prod = /prod /repro); /setup, /jira e /infra são invocadas no Step 0 de todas e também digitáveis, para configurar um projeto novo; furi-build é o resto do grafo (/solve, /principles, /front, /method, /adr, /ticrd, /cr, /proto) — constrói sem saber o que é Jira, PR ou deploy. Cada conceito tem uma skill dona: o /solve (o nível #1) e o /principles (a doutrina de engenharia) são folhas — não invocam nenhuma skill; o /front (a de design) invoca o /principles e só soma o que é de design (requires: principles); o /qa (a prova) é folha; o /method (a doutrina obrigatória — cada linha dele e das skills que invoca vale, fechando com uma conferência ✅/❌ de cada critério, sem arquivo de acompanhamento e sem commit) invoca o , o , o (com superfície visual) e o ; o (o registro de decisão, do problema aos test cases, num arquivo só) é avulso e folha; o (Todo, Implementation, Code review, Run test, Done — do ADR ao commit, em steps com Gateway) é avulso, só digitável, e invoca o ; o (code review com nota de 0 a 100, numa sessão nova do ) é avulso, só digitável, e folha; e o invoca o e o .
build e ship não se conhecem. Nenhum campo de relação atravessa entre os dois — nem requires, nem handoff, nem boundary —, e nenhuma skill de um cita o nome, o caminho ou o comando de uma skill do outro. Nem o vocabulário: a pasta e o jargão de um pacote (track/, artefato, ledger, esteira de um lado; /local, /homolog, /prod, /jira do outro) não aparecem no .md do irmão — o nome de uma skill alheia um leitor humano percebe, a pasta passa batido, e foi por ela que o vazamento voltou em 2026-09-17: skills do ship mandavam gravar na pasta da esteira do /method, e o modelo construía o artefato do /method no meio de uma entrega. O pnpm check confere isso nos dois sentidos (regra 9). É o que faz cada um ser instalável e utilizável sozinho. Nenhum requires atravessa pacote nenhum, aliás: é por isso que nenhum manifesto tem dependencies. O que sobra entre pacotes são menções sem dependência — o /sync (toolbox) encaminha para o /prod, e o /prod o cita como fronteira: linha tracejada e pontilhada no grafo, nada que o instalador precise puxar. Onde o furi-ship precisava do método, ele declara o estado que o estágio exige (implementado, revisado, testado com evidência, documentado, um commit) e confere o sinal observável — a mesma forma que já usava nos outros estágios da escada; o furi-build fecha esse estado com protocolo — menos o commit, que ele não faz —, quando está instalado, e o ship não precisa saber disso.
O conhecimento permanente de um projeto mora em .claude/, versionado no repositório-alvo — quatro arquivos, um dono cada. Os do processo de entrega ficam na pasta .claude/ship/, um .md por skill, com o nome dela — cada skill do ship lê o seu no início, cria na primeira vez e atualiza ao aprender, curto e só com o específico do projeto: setup.md (convenções do time e o § Processo que liga branch × etapa × Jira × infra — /setup), jira.md (o mapa do board — /jira), infra.md (mapa da infra, .secrets/ e acessos, nunca um valor — /infra), local.md, gh.md, homolog.md, prod.md, repro.md, card.md. O .claude/patterns.md (padrões de código do projeto) fica na raiz de .claude/ e não em ship/: ele não é do processo de entrega — quem o escreve é quem implementa. Não é a esteira por feature (docs/01-problem/ … track/) nem a memória da máquina (~/.claude/projects/, onde só o board do Jira mora). Um .md solto em .claude/ não é auto-carregado — cada arquivo é lido sob demanda, por quem usa algo dele, nunca via CLAUDE.md. Cada um tem uma variante <x>.local.md — mesmo formato, nunca versionada (como o settings.local.json) — para o repositório de um time que não usa este processo: o setup de uma pessoa não vai pro git dos outros, e o /setup pergunta uma vez qual dos dois é o caso; o do time vence quando os dois existem. Quem não é o dono lê por caminho e não cria: quem fecha o commit aplica o § Commit do setup.md; escrever é do dono.
Workflow do autor
Fonte única = o frontmatter dos SKILL.md. Os manifestos e os catálogos são gerados, nunca escritos à mão — e não há cópia de skill para dessincronizar:
pnpm check # gera os manifestos + valida os 3 pacotes + typecheck da LP
git add -A && git commit && git push # publicar = dar push
pnpm check é exatamente o que o CI roda. Ele falha se um manifesto commitado não for o que o frontmatter produz — porque nesse caso o GitHub serviria aos clientes uma versão que ninguém gerou. Rodar pnpm gen:plugins sozinho também funciona; o check só acrescenta as provas.
Toda skill cabe no limite do pacote dela: cada SKILL.md, frontmatter incluído, tem no máximo 3333 caracteres no furi-build e no furi-toolbox e 4444 no furi-ship. O número mora num lugar só, LIMITE_POR_PACOTE em scripts/validate-plugins.mjs (regra 10); pacote novo sem limite declarado também reprova o check.
Para o Claude Code e para o Cursor, cada push já é a versão nova (Git SHA / re-index). Para o Codex, veja a seção dele: o usuário precisa reinstalar.
Skill que depende de outra a invoca via Skill tool no ponto de uso (furi-build:<nome> / furi-ship:<nome>) e a lista em requires — mencionar não é invocar. Hand-offs ("Próximo: /gh") e fronteiras ("isso é o /prod") ficam como menção: o próximo passo é decisão do usuário. Caminho de arquivo dentro de uma skill diz o escopo: <slug>/SKILL.md e references/x.md são do mesmo pacote (resolvem no cache instalado) — as skills do furi-ship, o /method e o /ticrd são mono-arquivo, com seções dentro do próprio SKILL.md; plugins/<pacote>/skills/<slug>/… é de outro pacote e por isso é proibido: nenhuma skill cita outro pacote, nem por caminho nem por nome; docs/…, .claude/…, .github/…, .secrets/… são do projeto-alvo — lidos por caminho no repositório onde a skill roda, e ler um deles não cria dependência entre pacotes (o validador conhece essas raízes em TARGET_PROJECT_ROOTS). track/… também é do projeto-alvo, mas só o furi-build pode citá-la: é a pasta da esteira do /ticrd, e no furi-ship a regra 9 a barra.
As três relações têm campo no frontmatter — é a regra acima em forma declarada, e é dela que sai o grafo da LP. Todos aceitam x ou [x, y], e o pnpm check falha se um alvo não for o name de nenhuma skill:
| campo | quando usar | efeito |
|---|
requires | a skill invoca a outra / não roda sem ela | linha cheia no grafo e dependência entre pacotes no manifesto |
handoff | o próximo passo é a outra skill, quando o usuário quiser | linha tracejada no grafo |
boundary | fronteira: isso é assunto da outra skill, não desta | linha pontilhada no grafo |
Só o requires vira dependencies do pacote: instalar tem que trazer o que a skill invoca, não para onde ela encaminha — é o que mantém o furi-toolbox avulso, mesmo com o /sync entregando para o /prod.
Nenhuma skill se ativa sozinha. Uma skill roda quando o usuário digita o comando (/x sem argumento = o objetivo é o que a conversa já está tratando) ou quando outra skill a invoca pela Skill tool — nunca porque o modelo achou que cabia. A description é o que o modelo lê para decidir, então ela descreve a capacidade ("Covers …") e nunca traz gatilho ("Triggers on …", "Use when you want …", "before any code change"). Duas defesas, e o pnpm check exige uma delas:
| defesa | quem leva | por quê |
|---|
disable-model-invocation: true no frontmatter | toda skill que nenhuma outra invoca pela Skill tool — o /proto, o /adr, o /ticrd, o /cr e o toolbox inteiro | é o gate do Claude Code: tira a skill da listagem do modelo e bloqueia a Skill tool. Só o usuário digitando /<name> a roda. Garantia por código |
a sentinela NEVER activate on your own initiative. na description | quem outra skill invoca pela Skill tool — o /solve e o /front pelo /method e na abertura do /proto, o /principles pelo /method e pelo /front, o /qa pelo /method, o /jira, o /setup e o /infra no Step 0, o próprio /method (ciclo de follow-up), e os 4 alvos e os 2 modificadores do ship, que se delegam na composição (/repro /prod) | a trava bloquearia essa chamada — inclusive na composição: digitar /repro /prod não libera o /prod para a Skill tool, porque o gate procura o token na mensagem do usuário e a expansão do comando não o deixa lá (provado na 2.1.272). A defesa é o texto; a sentinela é o que o pnpm check confere e o que a LP corta antes de exibir |
A trava também vale para todo subagente e para coordinator mode — um workflow não invoca uma skill travada. Quem precisar disso migra a skill para a sentinela.
Nenhuma skill declara effort: sem ele, cada execução roda no nível padrão da sessão (settings e /effort), em vez de forçar um nível. Skill que roda em subagente (context: fork) também não declara model. Sem model: o fork usa o modelo padrão de subagente (ou o da sessão), então acompanha a atualização de modelo em vez de ficar preso a um alias — o /save (background: false, a sessão espera o retorno inline) é o exemplo. model: só entra quando a escolha for deliberada e para baixo (haiku, sonnet): nunca para fixar o modelo grande, que é o default e muda de nome.
Skill que precisa de uma opinião que não herda nada abre uma sessão nova, não um subagente: env -u CLAUDECODE claude -p --safe-mode --tools "", num diretório temporário vazio, com o texto por stdin — sem a conversa, sem CLAUDE.md, sem memória, sem MCP, sem plugin, sem arquivo e sem ferramenta, com o login da sessão. Um fork herda o harness, o CLAUDE.md e o enquadramento de quem o chamou — tira o custo de contexto, não o viés. O /blind (toolbox) é essa sessão na mão do usuário: /blind <texto> manda o texto verbatim e devolve a resposta inteira; nenhuma skill o invoca — quem precisa do mecanismo (o /brain) carrega o próprio bloco. Mesma regra de modelo: --model só para rebaixar.
Editando uma skill com feedback imediato (sem republicar a cada tecla): carregue o pacote em modo dev, in-place, apontando para a raiz dele — carrega o pacote inteiro com todas as skills:
claude --plugin-dir ~/GitHub/lp-skills/plugins/furi-build # furi-build
claude --plugin-dir ~/GitHub/lp-skills/plugins/furi-ship # furi-ship
claude --plugin-dir ~/GitHub/lp-skills/plugins/furi-toolbox # furi-toolbox
Skills de outros repos (ex.: ui-ux-pro-max) permanecem instaladas por outros meios e não vivem aqui.
Stack
Next.js 16 (App Router) · TypeScript · Tailwind v4 · Radix UI · sonner · Geist · gray-matter.
Dev local
pnpm install
pnpm dev
Acesse http://localhost:3000.
Licença
MIT.
