ashlr-stack

Pilha Ashlr

O plano de controle para toda a sua pilha de desenvolvimento. Um único comando para provisionar, conectar e operar cada serviço de terceiros no seu projeto.

Status: pré-alfa, em desenvolvimento ativo.

Experimente em 30 segundos

Estes comandos somente leitura não precisam de contas ou chaves de API. A CLI roda em Bun.

bunx @ashlr/stack providers                                         # the 29-provider catalog
bunx @ashlr/stack recommend "B2B SaaS with auth, AI, and payments"  # ranked provider picks with rationales
bunx @ashlr/stack scan                                              # in an existing repo: detect services (writes nothing)

Para provisionar um serviço real, instale a Stack (abaixo) e execute stack add <provider>.

Por que a Stack

• Um comando em vez de dez painéis. A Stack cria o recurso upstream e conecta seus segredos, .env e .mcp.json para você.
• Segredos ficam em um cofre. Cada credencial passa pelo Phantom, então os valores reais permanecem na sua máquina.
• Nativo para agentes. O mesmo catálogo e ações estão disponíveis como ferramentas MCP (ashlr-stack-mcp) para Claude Code e outros clientes MCP.

Instalação

Três formas, escolha uma:

# One-liner, macOS / Linux (also installs Phantom Secrets if missing)
curl -fsSL stack.ashlr.ai/install.sh | bash

# One-liner, Windows (PowerShell)
irm https://stack.ashlr.ai/install.ps1 | iex

# npm / bun registry
bun add -g @ashlr/stack ashlr-stack-mcp     # or: npm i -g

Instalação para desenvolvimento (a partir de um clone local deste repositório):

git clone https://github.com/ashlrai/ashlr-stack && cd ashlr-stack
bun install
bun run packages/cli/src/index.ts --help
# Optional: alias stack=`bun run $(pwd)/packages/cli/src/index.ts` so it's on your PATH

Usando a Stack com um agente de IA para codificação? Veja STACK.md — um resumo de projeto autossuficiente para agentes que extraem contexto do repositório.

O que a Stack faz

Em um mundo nativo de Claude Code, o atrito ao iniciar um projeto não é escrever código — é alternar entre abas para criar e conectar dez serviços. Cada npx create-next-app é seguido por uma hora de:

• criar um projeto Supabase, copiar URL + chave anônima + chave de função de serviço para .env
• gerar um token Vercel
• escolher uma região Neon e copiar a string de conexão
• configurar um projeto Sentry e colar o DSN
• registrar um app OAuth, gerar um PAT, colar chaves, adicionar servidores MCP ao .mcp.json…

A Stack reduz essa hora a um único comando:

stack init --template nextjs-supabase-posthog-sentry
# Stack does the OAuth dance per provider,
# creates the upstream resource,
# stores every secret in Phantom,
# writes .env + .mcp.json,
# and hands you a project ready for `bun dev`.

Como ela se relaciona com o resto da Ashlr

• Phantom Secrets — o cofre. Os valores reais dos segredos nunca saem da sua máquina. A Stack escreve cada credencial por meio do Phantom.
• ashlr-plugin — camada de eficiência de tokens para Claude Code. Ortogonal à Stack.
• ashlrcode — CLI de IA para codificação com múltiplos provedores. Ortogonal.

A Stack é o plano de controle. O Phantom é o cofre. O ashlr-plugin é o compressor de contexto. Eles se compõem.

Catálogo curado de provedores v1

Banco de dados — Supabase · Neon · Turso · Convex · Upstash · Firebase Deploy — Vercel · Railway · Fly.io · Cloudflare · Render Nuvem — AWS IA — OpenAI · Anthropic · xAI · DeepSeek Analytics — PostHog Erros — Sentry Pagamentos — Stripe Código — GitHub Tickets — Linear E-mail — Resend Autenticação — Clerk

29 provedores no total. Execute stack providers para ver o catálogo ao vivo.

Uso

stack init                    # interactive template picker
stack add supabase            # OAuth → new project → secrets → .mcp.json
stack providers               # full catalog (29 services across 11 categories)
stack doctor --fix            # verify every service; re-run setup for anything broken
stack exec -- bun dev         # run with Phantom's secret proxy active

Camada de recomendação por IA

Descreva o que você está construindo — a Stack escolhe os provedores.

stack recommend "B2B SaaS with auth, AI, and payments"
# → ranked list of matching providers with rationales

stack recommend "serverless postgres" --save
# → freezes a Recipe to .stack/recipes/<id>.toml

stack apply <recipe-id>
# → runs `stack add` for each provider + pre-wires Phantom rotating envelopes
#   + drops webhook stubs for Stripe / Clerk / Supabase / GitHub
#   (add --noWire to opt out of the Phantom auto-wiring)

Dentro do Claude Code, o mesmo fluxo é uma única chamada de ferramenta:

stack_recommend { query: "B2B SaaS with auth + payments", save: true }
stack_apply     { recipe_id: "<id>" }

O raciocínio acontece no Claude — a Stack é dona do catálogo + execução. Fora do Claude, stack recommend --synth usa um SLM local (LM Studio no :1234, Ollama no :11434) para justificativas. Nenhum SDK de LLM remoto vive na Stack.

Traga a Stack para um projeto existente

Já tem um repositório com serviços conectados? Você não começa do zero.

# In an existing repo:
stack scan                    # detects Supabase / Sentry / OpenAI / etc. from package.json, config files, .env.example
stack scan --auto             # scans, then interactively runs `stack add` for each detection
stack import                  # or: inhale an existing .env straight into Phantom + .stack.toml

# Clone someone else's project:
stack clone github.com/org/repo
# → git clone + scans the checkout + prints next steps

# Across every project on this machine:
stack projects list           # everywhere you've used Stack
stack doctor --all            # run health check across all registered projects

Como funciona o compartilhamento via git

A Stack divide sua configuração em dois arquivos para que você possa commitar a forma de uma stack sem vazar IDs de recursos específicos de cada desenvolvedor:

• .stack.toml — commitado. Nomes dos serviços, seus slots de segredos, conexões MCP.
• .stack.local.toml — ignorado pelo git automaticamente. project_id, resource_id, timestamps. Único para cada clone.

Outro desenvolvedor que clonar o repositório executa stack doctor --fix e a Stack reautentica / reprovisiona cada serviço para ele, gravando um novo .stack.local.toml.

Estrutura do monorepo

packages/
  core/     — @ashlr/stack-core — shared logic, provider adapters
  cli/      — @ashlr/stack — the `stack` binary
  mcp/      — ashlr-stack-mcp — MCP wrapper
  plugin/   — Claude Code plugin wrapper
  site/     — Astro landing page (deploys to stack.ashlr.ai)
templates/  — starter stacks
docs/       — auth matrix, schema reference

Publicação

Três pacotes são publicados no npm: @ashlr/stack-core, ashlr-stack-mcp, @ashlr/stack. Para desenvolvimento no monorepo, @ashlr/stack depende de @ashlr/stack-core via workspace:* — é isso que permite que bun install vincule o checkout local. Um npm install @ashlr/stack simples de fora do workspace não consegue resolver workspace:*, então o fluxo de publicação precisa reescrever esses intervalos para uma versão real (ex.: ^0.1.0) logo antes de npm publish.

Não edite manualmente as entradas workspace:* em packages/*/package.json — o desenvolvimento precisa delas. Use o script de publicação:

scripts/publish.sh --version 0.1.0

Ele incrementa o version de cada pacote, troca workspace:* → ^<version>, executa npm publish --dry-run para verificação, pede confirmação explícita, publica na ordem de dependências (core → mcp → cli), restaura workspace:* para que o desenvolvimento local continue funcionando e cria a tag do release. Veja o cabeçalho do script para detalhes.

Página de destino

cd packages/site
bun install
bun run dev       # http://localhost:4321
bun run build     # static output in dist/

Escuro primeiro, destaque magenta, Astro + Tailwind v4 + Framer Motion. Três ilhas React interativas (terminal animado, comparação em abas "com vs sem Stack", simulação de chat do Claude Code). prefers-reduced-motion respeitado.

Licença

MIT.