technical-decision-record
Documentar Decisões Técnicas com ADRs
Equipes técnicas frequentemente perdem contexto quando decisões são tomadas informalmente. Esta skill cria Registros de Decisão de Arquitetura estruturados que capturam o problema, restrições, opções consideradas e consequências para referência futura.
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「technical-decision-record」を使用しています。 Criar um ADR para escolher PostgreSQL em vez de MongoDB para nosso serviço de perfil de usuário
期待される結果:
- # ADR-001: Use PostgreSQL for User Profile Service
- **Status**: Accepted
- **Date**: 2024-01-21
- **Deciders**: Engineering Team
- ## Context
- We need to select a database for storing user profile data in our new microservice. The service will handle user accounts, preferences, and authentication tokens.
- ## Constraints
- - Must integrate with existing Node.js backend
- - Need ACID compliance for transaction safety
- - Team has PostgreSQL experience, limited MongoDB experience
- - Budget does not support managed database services
- ## Options Considered
- ### Option 1: PostgreSQL
- - Pros: ACID compliance, strong relationships, team familiarity
- - Cons: Requires schema migration, less flexible for unstructured data
- ### Option 2: MongoDB
- - Pros: Schema flexibility, easy horizontal scaling
- - Cons: No ACID transactions, learning curve for team
- ## Decision
- We will use PostgreSQL.
- ## Consequences
- - Positive: Reliable transactions, clear data model
- - Negative: Schema changes require migrations
- - Risks: Performance at extreme scale
- - Reversibility: Moderate - data migration required
「technical-decision-record」を使用しています。 Documentar nossa decisão de adotar gRPC para comunicação interna entre serviços
期待される結果:
- # ADR-042: Adopt gRPC for Internal Service Communication
- **Status**: Accepted
- **Date**: 2024-01-21
- **Deciders**: Platform Team
- ## Context
- Our microservices currently use REST over HTTP for inter-service communication. Performance bottlenecks and payload size are becoming issues as we scale.
- ## Constraints
- - Must support TypeScript and Go services
- - Need backward compatibility with existing REST APIs during transition
- - Network efficiency is critical for high-volume services
- ## Decision
- We will adopt gRPC for new internal services with protobuf contracts.
- ## Consequences
- - Positive: Smaller payloads, faster serialization, type safety
- - Negative: Requires learning curve, browser clients cannot use gRPC directly
- - Risks: Debugging complexity increases
- - Reversibility: Difficult - contracts become tightly coupled
セキュリティ監査
安全This is a pure documentation skill containing ADR templates and guidance for documenting technical decisions. No code execution, network calls, or cryptographic operations exist. All static findings are false positives: the scanner incorrectly flagged JSON metadata URLs as network risks, markdown code fences as shell execution, and documentation text about architectural decisions as cryptographic patterns. Safe for publication.
品質スコア
作れるもの
Seleção de Nova Tecnologia
Documentar o processo de avaliação ao escolher entre React, Vue ou Angular para um novo projeto frontend, capturando todas as restrições e trade-offs.
Planejamento de Migração de Arquitetura
Registrar a decisão de migrar de um monólito para microserviços, incluindo a justificativa, riscos e plano de reversão.
Documentação de Mudança de Processo
Documentar formalmente um novo processo de revisão de código ou estratégia de testes com contexto claro e resultados esperados.
これらのプロンプトを試す
Preciso criar um ADR para [DECISION TOPIC]. Me ajude a documentar esta decisão técnica com o problema, restrições, opções e consequências.
Estamos decidindo entre [OPTION A], [OPTION B] e [OPTION C] para [USE CASE]. Crie um ADR que capture nossas restrições, avalie cada opção com prós e contras, e documente a decisão final com justificativa.
Preciso documentar nossa decisão de [ARCHITECTURAL CHANGE]. Inclua o gatilho para esta mudança, os riscos envolvidos e uma avaliação de reversibilidade. Use o template completo de ADR.
ADR-[NUMBER] precisa ser substituído porque [REASON]. Crie um novo ADR que referencie o original, explique o que mudou e forneça contexto e recomendações atualizados.
ベストプラクティス
- Sempre liste pelo menos 2 opções, mesmo que uma seja 'não fazer nada', para garantir que as decisões sejam justificadas
- Ajuste o tempo de deliberação à reversibilidade - dedique mais esforço a decisões irreversíveis
- Inclua todos os stakeholders no campo Deciders e obtenha aprovação explícita antes de finalizar
回避
- Tomar decisões sem explorar alternativas - você não pode justificar uma escolha sem saber contra o que escolheu
- Editar ADRs antigos quando o contexto muda - isso perde o registro histórico; em vez disso, crie um novo ADR que substitua o antigo
- Tomar decisões que afetam equipes sem envolvê-las - isso cria surpresa, resistência e retrabalho
よくある質問
O que é um ADR?
Quando devo criar um ADR?
Quão detalhado deve ser um ADR?
Posso editar um ADR existente?
O que deve constar na seção de Consequências?
Como devo numerar meus ADRs?
開発者の詳細
作成者
ChaiWithJaiライセンス
MIT
リポジトリ
https://github.com/ChaiWithJai/claude-code-mastery/tree/main/exercises/05-domain-expertise/solution参照
main
ファイル構成
📄 SKILL.md