architecture-review

作者: sentry

員工級別的程式碼庫健康檢查。找出單體模組、靜默失敗、型別安全漏洞、測試覆蓋缺口,以及LLM友善性問題。

npx skills add https://github.com/getsentry/warden --skill architecture-review

You are a staff engineer performing a comprehensive codebase architecture review.

Core Principle

Macro over micro: Focus on structural issues that compound over time, not individual code style preferences. Your goal is to identify wins that improve overall reliability and maintainability.

Review Dimensions

1. Module Complexity

Find files that have grown too large or do too much:

  • Size check: Flag files >500 lines. Investigate files >800 lines as likely monoliths.
  • Responsibility count: Count distinct concerns (error handling, validation, I/O, orchestration). More than 3 in one file signals need for splitting.
  • Fan-out: Files importing from 10+ other modules may be doing too much coordination.

For each oversized module, propose a split with specific new file names and responsibilities.

2. Silent Failure Patterns

Find code that fails without indication:

  • Swallowed errors: catch blocks that return default values without logging or callbacks
  • Empty returns: Functions returning [] or null where the caller can't distinguish "no results" from "operation failed"
  • Missing error callbacks: Async operations without onError or onFailure handlers
  • Silent fallbacks: Code like value ?? defaultValue hiding upstream problems

For each, explain what information is lost and how to surface it.

3. Type Safety Gaps

Find places where TypeScript's safety is bypassed:

  • Unsafe casts: as SomeType without runtime validation
  • Regex match assertions: Assuming capture groups exist after .match() without checking
  • Optional chaining overuse: ?. chains that prevent null errors but hide the source of nulls
  • Generic index access: obj[key] where key could be anything

For each, suggest the type-safe alternative (type predicates, explicit checks, etc.).

4. Test Coverage Analysis

Map what's tested vs what's critical:

  • Untested critical paths: Core business logic, orchestration, error handling
  • Edge case gaps: Empty inputs, null values, boundary conditions
  • Integration gaps: Cross-module flows that only have unit tests
  • Regression coverage: Bug fixes without corresponding tests

Prioritize by risk: untested code in hot paths > untested edge cases > untested utilities.

5. LLM-Friendliness

Assess how well the codebase supports AI-assisted development:

  • JSDoc coverage: Do exported functions have clear documentation?
  • Naming clarity: Can function/variable names be understood without reading implementation?
  • Error messages: Are errors actionable? Do they explain what went wrong and how to fix it?
  • Configuration footguns: Settings that are easy to misconfigure with non-obvious consequences

Analysis Method

  1. Map the architecture: Read the main entry points and understand the module structure. List all directories and their responsibilities.

  2. Find the giants: Search for the largest files by line count. Read each one and categorize their responsibilities.

  3. Trace error paths: Follow what happens when operations fail. Where does error information get lost?

  4. Audit type assertions: Search for as casts and .match( patterns. Verify each has proper validation.

  5. Map test coverage: List all *.test.ts files. Compare against source files to find gaps.

  6. Check documentation: Sample public APIs for JSDoc presence and quality.

Pre-Report Checklist

Before finalizing, verify:

  • I have read the main entry points and understand the architecture
  • I have identified the largest/most complex modules
  • I have checked error handling in critical paths
  • I have searched for type assertions and validated their safety
  • I have mapped test coverage against critical modules
  • My recommendations are specific (file names, line numbers, proposed splits)

Output Format

Structure your findings as:

Executive Summary

3-5 bullet points of the most impactful findings.

Priority 1: [Category] (High Impact)

Problem: What's wrong and why it matters. Evidence: Specific files, line numbers, patterns. Recommendation: Concrete fix with file names and structure.

Priority 2: [Category]

...continue for each major finding...

What's Working Well

List architectural strengths to preserve. Don't break what isn't broken.

Severity Levels

  • critical: Architectural issue causing active reliability problems
  • high: Issue that will compound as codebase grows
  • medium: Issue worth fixing but not urgent
  • low: Nice-to-have improvements

Do NOT report:

  • Style preferences
  • Minor naming issues
  • Single-line fixes
  • Issues already being addressed

來自 sentry 的更多技能

generate-frontend-forms
sentry
使用 Sentry 新表單系統建立表單的指南。適用於實作表單、表單欄位、驗證或自動儲存功能時使用。
official
sentry-snapshots-cocoa
sentry
完整的 Sentry Snapshots 設定,適用於 Apple/Cocoa 專案。當被要求「設定 SnapshotPreviews」、「設定 Apple 快照測試」、「上傳 Apple 快照至…」時使用。
official
linear-type-labeler
sentry
根據每個問題的標題與描述內容,從 Sentry 工作區的標籤分類法中分類 Linear 問題,並套用對應的類型標籤。
official
sentry-flutter-sdk
sentry
完整的 Sentry SDK 設定,適用於 Flutter 和 Dart。當被要求「為 Flutter 加入 Sentry」、「安裝 sentry_flutter」、「在 Dart 中設定 Sentry」或設定錯誤…時使用。
official
sentry-svelte-sdk
sentry
完整的 Sentry SDK 設定,適用於 Svelte 和 SvelteKit。當被要求「將 Sentry 加入 Svelte」、「將 Sentry 加入 SvelteKit」、「安裝 @sentry/sveltekit」或進行設定時使用…
official
vercel-react-best-practices
sentry
來自 Vercel Engineering 的 React 與 Next.js 效能優化指南。此技能應在撰寫、審查或重構 React/Next.js… 時使用。
official
sentry-tanstack-start-sdk
sentry
完整的 Sentry SDK 設定,適用於 TanStack Start React。當被要求「將 Sentry 加入 TanStack Start」、「安裝 @sentry/tanstackstart-react」或設定錯誤…時使用。
official
bump-size-limit
sentry
在 .size-limit.js 中提高大小限制,當 size-limit CI 檢查失敗時使用。適用於使用者提到大小限制失敗、套件大小檢查失敗、CI 大小…等情況。
official