Communitygithub.com

perhapsspy/design-orientado-ao-proposito

Verifica se um design resolve o problema certo antes de codificar.

O que é design-orientado-ao-proposito?

Esta skill, `perhapsspy/purpose-first-design`, implementa a metodologia "Design Orientado ao Propósito". Ela é projetada para forçar uma decisão de design deliberada e mínima antes que qualquer código seja escrito, garantindo que o problema correto esteja sendo resolvido. A skill orienta o desenvolvedor ou agente a escolher a menor direção defensável para uma decisão de produto ou planejamento de implementação, primeiro estabelecendo o propósito (o que significa sucesso) e, em seguida, bloqueando decisões de usuário, autoridade, segurança, rollback, propriedade e limites operacionais. O fluxo de trabalho incentiva a separação de entradas em categorias como `LOCKED` (bloqueado), `EVIDENCE` (evidência), `ASSUMPTION` (suposição) e `OPEN` (aberto), evitando a promoção de itens resolvidos para o estado aberto. O resultado final é um handoff de decisão conciso, contendo a direção escolhida, as justificativas, os limites fixados e os próximos passos, ao invés de múltiplas alternativas especulativas. A skill é particularmente útil para prevenir o excesso de engenharia e o desalinhamento entre o produto e a implementação, sendo aplicável em qualquer plataforma onde um agente de IA auxilie no planejamento de software (como Claude Code, Cursor, Codex).

Funciona com~Claude Code~Codex CLI~Cursor
npx skills add perhapsspy/purpose-first-design

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Design Orientado ao Propósito

Trabalho e Saída

Escolha a menor direção defensável para uma decisão abertamente material de produto ou planejamento de implementação antes que a estrutura da solução seja fixada. O propósito define o que significa sucesso; decisões bloqueadas do usuário, autoridade, e os limites obrigatórios de segurança, rollback, propriedade e operação vinculam a resposta e nunca são alternativas.

Termine com uma direção provisória, a menor verificação que poderia mudar uma escolha realmente aberta, ou uma única pergunta bloqueadora. Se nenhuma direção material permanecer em aberto, declare isso brevemente e passe adiante sem inventar alternativas.

Contrato de Decisão

  • Declare apenas o propósito e o sucesso observável necessário para distinguir a escolha.
  • Separe as entradas relevantes para a decisão em LOCKED (BLOQUEADO), EVIDENCE (EVIDÊNCIA), ASSUMPTION (SUPOSIÇÃO) e OPEN (ABERTO). Nunca promova uma decisão bloqueada, uma restrição explícita, um escopo rejeitado ou um item resolvido por evidência para OPEN. Uma verificação com falha pode alterar apenas um mecanismo não resolvido, não o significado bloqueado do produto.
  • Trate a implementação existente, precedentes, padrões e urgência como evidência, a menos que sejam explicitamente autoritativos. Compare apenas alternativas que alterem materialmente o significado, a responsabilidade, o estado persistente, a política, o ciclo de vida, o contrato público, o risco aceito ou o acoplamento difícil de reverter.
  • Escolha a menor direção suficiente. Não adicione proprietários, processos, mecanismos de rollback, plataformas, programas futuros ou decisões em aberto, a menos que a fonte ou a direção escolhida os exija.

Handoff (Repasse)

Use source-owner-audit (auditoria de proprietário da fonte) primeiro quando a autoridade presente for desconhecida. Repasse o entendimento estabelecido — fluxo de código, estado, sequenciamento, interfaces, tratamento de falhas e ordem de implementação — para structure-first (estrutura-primeiro). Repasse a expressão e o empacotamento estabelecidos para tighten-docs (apertar-docs).

Retorne um handoff de decisão conciso: direção, base de mudança de decisão, limites bloqueados, suposições reais ou decisões em aberto, e a próxima verificação decisiva ou fluxo de trabalho responsável. Inclua um limite apenas quando ele restringir a direção escolhida.

Redução Final

Revise apenas o escopo, compromissos, suposições e decisões em aberto introduzidos pela sua resposta. Remova qualquer um que não seja exigido pelo propósito, limites bloqueados, autoridade, evidência ou direção escolhida. Mescle alternativas apenas quando seu significado de produto e os limites exigidos forem os mesmos.

Esta passagem pode reduzir, mas não deve criar escopo, compromissos, suposições, decisões em aberto ou handoffs, e nunca deve reabrir o significado LOCKED (BLOQUEADO). Se expor um limite obrigatório ausente, declare esse limite como obrigatório, não opcional. Preserve a complexidade necessária para segurança, rollback, propriedade, operações ou um modo de falha demonstrado.

Habilidades Relacionadas