Back to Details

analyze-project

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Project Analysis (Zoom Out)

项目分析（全局视角）

Perform a high-level analysis of this project. Follow the procedural workflow below; use the rubric sections as reference when interpreting findings.
对该项目进行高级分析。遵循以下流程步骤；解读结果时请参考评分标准部分。

Ground rules

基本原则

  • Reproduce before reporting — read the actual files and run the tooling; never assert a finding based on file names, directory shapes, or vibes alone.
  • Verify catalog-like claims mechanically — if a claim implies "all N of X", script the check rather than eyeballing a sample.
  • Mark anything you couldn't verify as "unverified"; never guess or extrapolate.
  • This is an assessment only: no code changes, no pushes, no triggering workflows or releases.
  • Honor the target repo's standing context file when present (see step 0).
  • 先复现再报告——阅读实际文件并运行工具；切勿仅凭文件名、目录结构或直觉就断言发现的问题。
  • 以机械方式验证类似目录的声明——如果某个声明暗示“所有X类中的N个”，请编写脚本检查，而非仅查看样本。
  • 将所有无法验证的内容标记为“未验证”；切勿猜测或推断。
  • 这仅为评估：不修改代码、不推送、不触发工作流或版本发布。
  • 若目标仓库存在固定上下文文件，请遵循该文件（见步骤0）。

Usage

使用方法

When asked to analyze project health:
当被要求分析项目健康状况时：

0. Load repo context

0. 加载仓库上下文

At start, read the target repo's 
AGENTS.md
and/or 
CLAUDE.md
if present. Precedence: 
AGENTS.md
is authoritative when both exist — do not also apply conflicting 
CLAUDE.md
instructions; if only one exists, use that file; if both conflict in a blocking way, stop and ask. Treat house standards, operating agreement, and standing constraints in the chosen file as binding for this assessment — including safety limits such as no paid LLM API calls or local-only storage. See the 
stand-general
skill's Per-repo agent context section for the expected file shape. If neither file exists, continue with chat instructions and 
stand-*
skills only.
开始时，读取目标仓库的
AGENTS.md
和/或
CLAUDE.md
（如果存在）。 优先级：当两个文件都存在时，
AGENTS.md
具有权威性——请勿同时应用
CLAUDE.md
中的冲突指令；如果仅存在一个文件，则使用该文件；如果两个文件存在阻塞性冲突，请停止并询问。将所选文件中的内部标准、操作协议和固定约束视为本次评估的绑定规则——包括安全限制，如禁止调用付费LLM API或仅本地存储。请参考
stand-general
技能的每个仓库的Agent上下文部分了解预期的文件格式。如果两个文件都不存在，请仅遵循聊天指令和
stand-*
技能。

1. Map structure

1. 映射结构

Understand layout and entry points:
bash
find . -maxdepth 3 -type f \( -name '*.py' -o -name '*.ts' -o -name '*.rs' -o -name 'Cargo.toml' -o -name 'package.json' -o -name 'pyproject.toml' \) | head -80
tree -L 3 -I 'node_modules|target|.venv|dist|build|__pycache__|.git' 2>/dev/null || find . -maxdepth 3 -type d | head -60
Note: source roots, module boundaries, config locations, and test directories.
了解项目布局和入口点：
bash
find . -maxdepth 3 -type f \( -name '*.py' -o -name '*.ts' -o -name '*.rs' -o -name 'Cargo.toml' -o -name 'package.json' -o -name 'pyproject.toml' \) | head -80
tree -L 3 -I 'node_modules|target|.venv|dist|build|__pycache__|.git' 2>/dev/null || find . -maxdepth 3 -type d | head -60
注意：源码根目录、模块边界、配置位置和测试目录。

2. Check CI/CD

2. 检查CI/CD

Inspect automation and pipeline coverage:
bash
ls -la .github/workflows/ 2>/dev/null
rg -l 'lint|test|build|deploy' .github/workflows/
rg -n --hidden "uses:.*@[0-9a-f]{40}\b" .github/workflows || echo "No SHA-pinned actions found"
Verify lint, test, and deploy stages exist; check for pinned action SHAs and reproducible builds. Then go beyond presence: is CI validating what actually matters, or just linting? Look for conditional skips (
if: ... == ''
, path filters that silently no-op a job) and for test suites that exist in the repo but never run in any workflow — CI claiming a check happens is not the same as it executing.
检查自动化和流水线覆盖情况：
bash
ls -la .github/workflows/ 2>/dev/null
rg -l 'lint|test|build|deploy' .github/workflows/
rg -n --hidden "uses:.*@[0-9a-f]{40}\b" .github/workflows || echo "No SHA-pinned actions found"
验证是否存在lint、测试和部署阶段；检查是否存在固定SHA的action和可复现的构建。然后深入检查：CI是否在验证真正重要的内容，还是仅做lint检查？查找条件跳过（
if: ... == ''
、会导致作业静默无操作的路径过滤器）以及仓库中存在但从未在任何工作流中运行的测试套件——CI声称进行检查并不等同于实际执行。

3. Dependency health

3. 依赖健康状况

Confirm lock files and manifest consistency:
bash
ls -1 *lock* uv.lock bun.lockb Cargo.lock package-lock.json poetry.lock Pipfile.lock 2>/dev/null
rg -n 'version|dependencies' pyproject.toml package.json Cargo.toml | head -30
Flag missing lock files, unpinned versions, or stale dependency patterns.
确认锁文件和清单的一致性：
bash
ls -1 *lock* uv.lock bun.lockb Cargo.lock package-lock.json poetry.lock Pipfile.lock 2>/dev/null
rg -n 'version|dependencies' pyproject.toml package.json Cargo.toml | head -30
标记缺失的锁文件、未固定的版本或过时的依赖模式。

4. README and docs check

4. README和文档检查

Assess onboarding and API documentation:
bash
test -f README.md && head -80 README.md
find . -maxdepth 2 \( -name '*.md' -o -name 'docs' -type d \) | head -20
rg -l 'TODO|FIXME|TBD' README.md docs/
Check for setup instructions, contribution guide, and documented public APIs.
评估入门和API文档：
bash
test -f README.md && head -80 README.md
find . -maxdepth 2 \( -name '*.md' -o -name 'docs' -type d \) | head -20
rg -l 'TODO|FIXME|TBD' README.md docs/
检查是否存在设置说明、贡献指南和已文档化的公共API。

5. Hardcoded config search

5. 硬编码配置搜索

Find scattered or environment-specific values in source:
bash
rg -n '(localhost|127\.0\.0\.1|0\.0\.0\.0|hardcoded|FIXME.*config)' --glob '!*.{lock,sum,md}'
rg -n '(API_URL|BASE_URL|DATABASE_URL)\s*=\s*["\x27]' --glob '!*.example' --glob '!*.env*'
Evaluate against externalized configuration expectations.
在源码中查找分散或特定环境的值：
bash
rg -n '(localhost|127\.0\.0\.1|0\.0\.0\.0|hardcoded|FIXME.*config)' --glob '!*.{lock,sum,md}'
rg -n '(API_URL|BASE_URL|DATABASE_URL)\s*=\s*["\x27]' --glob '!*.example' --glob '!*.env*'
对照外部化配置的预期进行评估。

6. Coupling and circular dependencies

6. 耦合和循环依赖

Assess module boundaries (adapt to language):
bash
undefined
评估模块边界（根据语言调整）：
bash
undefined

Python import graph (rough)

Python import graph (rough)

rg -n '^from |^import ' --type py | head -50
rg -n '^from |^import ' --type py | head -50

TypeScript/JavaScript cross-imports

TypeScript/JavaScript cross-imports

rg -n "^import .* from ['"]../" -t ts -t js | head -50
rg -n "^import .* from ['"]../" -t ts -t js | head -50

Rust crate modules

Rust crate modules

rg -n '^mod |^pub mod ' -t rust | head -30

Look for deep cross-package imports, god modules, and circular import chains.
rg -n '^mod |^pub mod ' -t rust | head -30

查找深度跨包导入、上帝模块和循环导入链。

7. Backlog, PR state, and release discipline

7. 待办事项、PR状态和发布规范

Check the project against its own tracking, not just its code:
bash
gh pr list --state open
gh issue list --state open
gh pr list --state merged --limit 20
If 
gh
is unavailable or unauthenticated, mark these GitHub-backed checks as "unverified" per the ground rules and continue the assessment.
Check for: stale or conflicting open PRs; issues claimed as done that are not actually done in the code (verify by reading the code, not by trusting labels or comments); merge history vs. stated milestones; lockfile version vs. manifest version drift; CHANGELOG entries vs. 
git log
; git tags vs. published releases.
对照项目自身的跟踪系统检查项目情况，而不仅仅是代码：
bash
gh pr list --state open
gh issue list --state open
gh pr list --state merged --limit 20
如果
gh
不可用或未认证，请根据基本原则将这些基于GitHub的检查标记为“未验证”，并继续评估。
检查：陈旧或冲突的开放PR；标记为已完成但代码中实际未完成的问题（通过阅读代码验证，不要信任标签或评论）；合并历史与声明的里程碑；锁文件版本与清单版本的偏差；CHANGELOG条目与
git log
；git标签与已发布版本。

8. Dead surface

8. 无效内容

Find things that look wired up but aren't — verify by reference, not by name:
  • Workflows that silently skip themselves (conditional gates on paths/branches that never match)
  • Scripts in the repo that no workflow, README, or Makefile ever calls
  • Modules or components with zero references (
    rg
    for imports/usages of the symbol, not just its existence)
  • Stale committed artifacts (build output, generated files checked in as source)
  • Orphaned docs/content unreachable from any nav, index, or README link
查找看似已连接但实际未启用的内容——通过引用验证，而非仅通过名称：
  • 会静默跳过自身的工作流（路径/分支的条件门从未匹配）
  • 仓库中没有任何工作流、README或Makefile调用的脚本
  • 零引用的模块或组件（使用
    rg
    查找符号的导入/用法，而非仅检查其存在）
  • 陈旧的已提交工件（构建输出、作为源码提交的生成文件）
  • 无法从任何导航、索引或README链接访问的孤立文档/内容

9. Product-quality scorecard

9. 产品质量评分卡

Build one row per area of the codebase — the full catalog, not a sample. Columns:
AreaCorrectness risk (low/med/high)Test coverage (y/partial/none)Consistency (ok/drifts)Staleness / dead-code flagsAction
Sort worst-first. Follow with the distribution across risk levels, the top 5-10 highest-risk areas, and any repo-wide patterns the scorecard reveals.
为代码库的每个区域创建一行——完整目录，而非样本。列：
区域正确性风险（低/中/高）测试覆盖率（有/部分/无）一致性（良好/不一致）陈旧/死代码标记行动
按问题严重程度从高到低排序。随后列出风险级别的分布情况、前5-10个最高风险区域，以及评分卡揭示的任何仓库范围模式。

10. Rate and report findings

10. 评级并报告发现

For each issue, assign severity:
  • Critical — no CI, no lock files in production apps, secrets in repo, broken build
  • Should Fix — poor docs, hardcoded config, unclear boundaries, missing tests in CI
  • Nice to Have — naming inconsistencies, missing ADRs, UX polish
Output contract: lead with a TLDR verdict, then findings with 
file:line
references, then the scorecard and its summary, and end with one prioritized fix list ordered by impact — not one list per section.
为每个问题分配严重程度：
  • 关键——无CI、生产应用中无锁文件、仓库中存在密钥、构建失败
  • 应修复——文档不佳、硬编码配置、边界不清晰、CI中缺少测试
  • 建议优化——命名不一致、缺少ADR、UX优化
输出约定：先给出TLDR结论，然后是带有
file:line
引用的发现，接着是评分卡及其摘要，最后以一个按影响优先级排序的修复列表结束——而非每个部分单独列出一个列表。

Full audit

全面审计

For a complete audit rather than a zoom-out-only pass, follow this skill with analyze-code and analyze-tests, then merge all three sets of findings into the single prioritized fix list described above.
如果需要进行完整审计而非仅全局视角检查，请在本技能之后执行analyze-code和analyze-tests，然后将三组发现合并到上述的单一优先级修复列表中。

Reference — Architecture & Design

参考 — 架构与设计

  • Overall design quality and alignment with stated objectives
  • Adherence to SOLID principles and separation of concerns
  • Are layers (transport, business logic, data) clearly separated?
  • API/interface design—are contracts clean, consistent, and hard to misuse?
  • Code complexity—is it appropriately simple or over-engineered?
  • Whether it reinvents solutions that existing libraries handle well
  • 整体设计质量与既定目标的契合度
  • 对SOLID原则和关注点分离的遵循情况
  • 各层（传输、业务逻辑、数据）是否清晰分离？
  • API/接口设计——契约是否简洁、一致且不易误用？
  • 代码复杂度——是否适当简洁或过度设计？
  • 是否重复发明了现有库已能很好处理的解决方案

Reference — Maintainability

参考 — 可维护性

  • How easily could a new developer onboard and contribute?
  • Is the code self-documenting, or are complex sections unexplained?
  • Consistent naming conventions and project structure
  • Boundary clarity—are public vs internal APIs clearly delineated?
  • Change impact—how localized is the blast radius of a typical change?
  • Configuration management—is config externalized properly vs scattered/hardcoded?
  • 新开发者能否轻松入门并做出贡献？
  • 代码是否自文档化，还是复杂部分未加说明？
  • 一致的命名约定和项目结构
  • 边界清晰度——公共API与内部API是否明确区分？
  • 变更影响——典型变更的影响范围有多局部化？
  • 配置管理——配置是否正确外部化，而非分散/硬编码？

Reference — CI/CD & DevOps

参考 — CI/CD & DevOps

  • Is the build reproducible?
  • Are lint, test, and deploy pipelines in place?
  • Are dependencies pinned and lock files committed?
  • 构建是否可复现？
  • 是否存在lint、测试和部署流水线？
  • 依赖是否已固定且锁文件已提交？

Reference — Documentation

参考 — 文档

  • README quality—does it cover setup, usage, and contribution?
  • API documentation—are public interfaces documented?
  • Architecture decision records (ADRs) or equivalent for key decisions
  • README质量——是否涵盖设置、使用和贡献内容？
  • API文档——公共接口是否已文档化？
  • 架构决策记录（ADR）或关键决策的等效文档

Reference — User Experience

参考 — 用户体验

  • Interface design and usability
  • Consistency of behavior and feedback
  • Accessibility considerations
  • 界面设计与可用性
  • 行为和反馈的一致性
  • 可访问性考量

Reference — Retrospective

参考 — 回顾

If starting this project today, what would you do differently?
如果今天启动这个项目，你会有哪些不同的做法？