需要关注的内容：

• tsconfig.json 严格模式设置
• any / unknown / // @ts-ignore / // @ts-expect-error 的数量
• 函数签名是否具有显式返回类型
• 共享类型定义与内联类型
• 边界处的模式验证（API 输入、环境变量、配置）
• 类型化的 ORM/数据库层与原始查询字符串

2. 可遍历性（权重：20%）

代理能以多快的速度找到正确的文件并理解依赖关系图？

需要关注的内容：

• 目录结构（基于功能 vs 基于分层 vs 混乱）
• 命名约定（一致吗？描述性强吗？还是 utils2.ts？）
• 桶文件 / 重导出链（需要多少跳才能找到源代码？）
• 循环依赖数量
• 代码集中放置（测试、类型、样式是否与其实现放在一起？）
• 导入路径深度和一致性

3. 测试覆盖率（权重：25%）

代理能否在不询问开发者的情况下验证其更改？

需要关注的内容：

• 是否存在测试运行器及其配置（vitest、jest、pytest 等）
• 覆盖率百分比（如果可能，运行覆盖率检查）
• 测试与源代码的比例
• 测试质量：测试是断言行为还是仅仅检查存在性？
• 测试是与源代码集中放置还是放在单独的目录树中？
• 测试能否在没有外部服务的情况下运行（模拟、夹具）？
• CI 是否在每个 PR 上运行测试？
• 测试的确定性（不稳定的测试会削弱代理的信心）

4. 反馈循环（权重：15%）

代理能以多快的速度知道其更改是否正确？

需要关注的内容：

• 是否存在单个 verify / check / test 命令？
• 完整检查套件需要多长时间？
• 错误信息是否可操作（文件、行号、修复建议）？
• 是否配置了预提交钩子？
• 测试/类型检查是否有监视模式可用？
• 构建/编译速度
• 是否为开发配置了热重载？

5. 自文档化（权重：15%）

代理能否在不借助外部文档的情况下，从代码本身理解意图和约定？

需要关注的内容：

• 命名清晰度（仅凭函数名和类型就能理解函数吗？）
• 公共 API 上的 JSDoc / 文档字符串
• README 质量（设置、架构概述、约定）
• Cursor 规则（.cursor/rules/）或代理指令（.claude/、AGENTS.md）
• ADR（架构决策记录）
• 错误信息（有帮助 vs 晦涩难懂）
• 注释解释“为什么”而不是“是什么”
• 可以复制的、一致的模式

工作流程

阶段 1：侦察

收集所有五个维度的数据。不要立即开始评分。

1. 项目结构扫描
   • 阅读顶级目录树（2 层深度，例如 find . -maxdepth 2 -not -path '*/.*' 或 ls 关键目录）
   • 识别语言、框架、包管理器
   • 阅读 README、CONTRIBUTING、任何代理指令（.cursor/rules/、.claude/、AGENTS.md）
   • 阅读配置文件：tsconfig.json、.eslintrc、biome.json、vitest.config、jest.config 等。
2. 类型系统分析
   • 检查严格模式设置
   • 在不同模块中抽样 10-15 个源文件以评估类型质量
   • 统计整个代码库中 any / @ts-ignore / @ts-expect-error 的出现次数
   • 查找共享类型定义、模式验证库
3. 结构分析
   • 映射目录结构
   • 检查桶文件、重导出深度
   • 查找循环依赖（导入链）
   • 评估命名一致性
4. 测试分析
   • 查找所有测试文件，统计其与源文件的数量比
   • 阅读测试配置，检查覆盖率设置
   • 抽样 3-5 个测试文件以评估质量（它们是在测试行为还是仅仅在运行？）
   • 如果可能，尝试运行测试套件，记录速度
5. 反馈循环分析
   • 查找 verify/check/lint/typecheck 脚本
   • 检查预提交钩子（.husky/、lint-staged、.pre-commit-config.yaml）
   • 估算完整检查周期时间
6. 文档分析
   • 评估命名约定（抽样函数/变量名）
   • 检查 JSDoc/文档字符串的覆盖率
   • 查找 ADR、设计文档
   • 检查错误处理模式（错误信息是否具有描述性？）

阶段 2：评分与报告

按照以下确切格式呈现发现结果：

## Agent-Native 评分卡

| 维度 | 分数 | 权重 | 加权分数 |
|-----------|-------|--------|----------|
| 完全类型化 | X/5 | 25% | X.XX |
| 可遍历性 | X/5 | 20% | X.XX |
| 测试覆盖率 | X/5 | 25% | X.XX |
| 反馈循环 | X/5 | 15% | X.XX |
| 自文档化 | X/5 | 15% | X.XX |
| **总分** | | | **X.XX/5** |

### 等级: [A/B/C/D/F]

- A: 4.5-5.0 — Agent-native。AI 代理可以自主工作。
- B: 3.5-4.4 — Agent-friendly。AI 代理可以高效工作，存在轻微摩擦。
- C: 2.5-3.4 — Agent-tolerant。AI 代理可以提供帮助，但需要人工指导。
- D: 1.5-2.4 — Agent-hostile。AI 代理工作困难，产出不可靠。
- F: 1.0-1.4 — Agent-incompatible。AI 代理弊大于利。

对于每个维度，提供：

• 分数及一行理由说明
• 2-3 个具体发现（文件路径、数量、示例）
• 一个最高影响力的修复建议

阶段 3：重构计划

在呈现评分卡后，询问用户：

您是否希望获得一份提高 Agent-Native 评分的重构计划？

如果用户同意，请按照以下规则生成一份优先计划：

优先级逻辑：

1. 快速见效优先。 如果一个更改只需一个下午，并且针对高权重的维度，则无论当前分数如何，都应放在首位。
2. 然后是高杠杆的结构性更改。 能同时改善多个维度的更改，其排名高于仅改善单一维度的更改。
3. 最后是大型工作。 多周的项目放在最后，即使它们针对的是评分最低的维度。

在同一工作量层级内，优先考虑分数较低且权重较高的维度。

计划格式：

## 重构计划

### 优先级 1: [维度] — [具体行动]
- 当前分数: X/5 → 目标: Y/5
- 工作量: [一个下午 / 几天 / 多周]
- 影响: [最高杠杆的更改及原因]
- 步骤:
  1. ...
  2. ...
  3. ...

### 优先级 2: ...

计划规则：

• 最多 5 个优先级
• 每个优先级针对一个维度的一个具体行动
• 尽可能包含具体的文件路径和命令
• 优先选择能同时改善多个维度的更改
• 优先安排快速见效的工作（能在短时间内提升分数的努力）
• 该计划应可由 AI 代理执行（具体，不模糊）

防护措施

• 切勿捏造指标。如果无法确定分数，请说明原因并解释需要哪些数据。
• 在审计期间，不要运行 rm、git push 或任何破坏性命令。
• 在审计阶段，不要修改任何源文件。
• 如果测试套件失败，报告失败情况——不要在审计期间尝试修复它们。
• 诚实评分。大多数代码库的分数在 2-3 分。5 分是例外且罕见。
• 此审计与语言无关。根据语言调整类型系统评估（例如 Python 类型提示、Go 接口、Rust 特征）。
• 如果代码库使用多种语言，为主要语言评分每个维度，并注明次要语言的不足。

完成清单

• 所有五个维度均已扫描，并附有具体证据
• 评分卡以确切的表格格式呈现
• 分配了等级（字母和描述）
• 每个维度都有包含文件路径的具体发现
• 每个维度都确定了最高影响力的修复建议
• 询问用户是否需要重构计划
• 如果需要，生成最多包含 5 个优先级的计划，按影响力排序
• 计划项足够具体，可以由 AI 代理执行

每周安装数

1

仓库

designxdevelop/…t-skills

首次出现

今天

安全审计

Gen Agent Trust HubPassSocketPassSnykPass

安装于

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1

What to look for:

• tsconfig.json strict mode settings
• Count of any / unknown / // @ts-ignore / // @ts-expect-error
• Whether function signatures have explicit return types
• Shared type definitions vs inline types
• Schema validation at boundaries (API inputs, env vars, config)
• Typed ORM/database layer vs raw query strings

2. Traversable (Weight: 20%)

How quickly can an agent find the right file and understand the dependency graph?

What to look for:

• Directory structure (feature-based vs layer-based vs chaotic)
• Naming conventions (consistent? descriptive? or utils2.ts?)
• Barrel files / re-export chains (how many hops to find source?)
• Circular dependency count
• Colocation (are tests, types, styles next to their implementation?)
• Import path depth and consistency

3. Test Coverage (Weight: 25%)

Can an agent verify its changes without asking the developer?

What to look for:

• Test runner present and configured (vitest, jest, pytest, etc.)
• Coverage percentage (run coverage if possible)
• Test-to-source ratio
• Test quality: do tests assert behavior or just existence?
• Are tests colocated or in a separate tree?
• Can tests run without external services (mocking, fixtures)?
• CI runs tests on every PR?
• Test determinism (flaky tests erode agent confidence)

4. Feedback Loops (Weight: 15%)

How fast can an agent know if its change is correct?

What to look for:

• Does a single verify / check / test command exist?
• How long does the full check suite take?
• Are error messages actionable (file, line, fix suggestion)?
• Pre-commit hooks configured?
• Watch mode available for tests/types?
• Build/compile speed
• Hot reload configured for dev?

5. Self-Documenting (Weight: 15%)

Can an agent understand intent and conventions from the code itself, without external docs?

What to look for:

• Naming clarity (can you understand a function from its name + types alone?)
• JSDoc / docstrings on public APIs
• README quality (setup, architecture overview, conventions)
• Cursor rules (.cursor/rules/) or agent instructions (.claude/, AGENTS.md)
• ADRs (Architecture Decision Records)
• Error messages (helpful vs cryptic)
• Comments explain "why" not "what"
• Consistent patterns that can be replicated

Workflow

Phase 1: Reconnaissance

Gather data across all five dimensions. Do NOT start scoring yet.

1. Project structure scan

   • Read the top-level directory tree (2 levels deep, e.g., find . -maxdepth 2 -not -path '*/.*' or ls key directories)
   • Identify language, framework, package manager
   • Read README, CONTRIBUTING, any agent instructions (.cursor/rules/, .claude/, AGENTS.md)
   • Read config files: tsconfig.json, .eslintrc, biome.json, vitest.config, jest.config, etc.

2. Type system analysis

   • Check strict mode settings
   • Sample 10-15 source files across different modules for type quality
   • Count any / @ts-ignore / @ts-expect-error occurrences across the codebase
   • Look for shared type definitions, schema validation libraries

3. Structure analysis

   • Map the directory structure
   • Check for barrel files, re-export depth
   • Look for circular dependencies (import chains)
   • Evaluate naming consistency

4. Test analysis

   • Find all test files, count them vs source files
   • Read test config, check coverage settings
   • Sample 3-5 test files for quality (are they testing behavior or just running?)
   • Try running the test suite if possible, note speed

5. Feedback loop analysis

   • Look for verify/check/lint/typecheck scripts
   • Check for pre-commit hooks (.husky/, lint-staged, .pre-commit-config.yaml)
   • Estimate full check cycle time

6. Documentation analysis

   • Evaluate naming conventions (sample function/variable names)
   • Check for JSDoc/docstrings coverage
   • Look for ADRs, design docs
   • Check error handling patterns (are errors descriptive?)

Phase 2: Score and Report

Present findings in this exact format:

## Agent-Native Scorecard

| Dimension | Score | Weight | Weighted |
|-----------|-------|--------|----------|
| Fully Typed | X/5 | 25% | X.XX |
| Traversable | X/5 | 20% | X.XX |
| Test Coverage | X/5 | 25% | X.XX |
| Feedback Loops | X/5 | 15% | X.XX |
| Self-Documenting | X/5 | 15% | X.XX |
| **Overall** | | | **X.XX/5** |

### Grade: [A/B/C/D/F]

- A: 4.5-5.0 — Agent-native. AI agents can work autonomously.
- B: 3.5-4.4 — Agent-friendly. Agents are productive with minor friction.
- C: 2.5-3.4 — Agent-tolerant. Agents can help but need human guidance.
- D: 1.5-2.4 — Agent-hostile. Agents struggle and produce unreliable output.
- F: 1.0-1.4 — Agent-incompatible. Agents cause more harm than good.

For each dimension, provide:

• The score with one-line justification
• 2-3 specific findings (file paths, counts, examples)
• The single highest-impact fix

Phase 3: Refactoring Plan

After presenting the scorecard, ask the user:

Would you like a refactoring plan to improve your agent-native score?

If yes, generate a prioritized plan following these rules:

Prioritization logic:

1. Quick wins first. If a change takes an afternoon and targets a high-weight dimension, it goes to the top regardless of current score.
2. Then high-leverage structural changes. Changes that improve multiple dimensions simultaneously rank above single-dimension improvements.
3. Then large efforts. Multi-week projects go last, even if they address the lowest-scoring dimension.

Within the same effort tier, prefer dimensions with lower scores and higher weights.

Plan format:

## Refactoring Plan

### Priority 1: [Dimension] — [Specific Action]
- Current score: X/5 → Target: Y/5
- Effort: [afternoon / few days / multi-week]
- Impact: [highest leverage change and why]
- Steps:
  1. ...
  2. ...
  3. ...

### Priority 2: ...

Rules for the plan:

• Maximum 5 priorities
• Each priority targets one dimension with one concrete action
• Include specific file paths and commands where possible
• Prefer changes that improve multiple dimensions simultaneously
• Front-load quick wins (afternoon efforts that boost score)
• The plan should be executable by an AI agent (specific, not vague)

Guardrails

• Never fabricate metrics. If you cannot determine a score, say so and explain what data you would need.
• Do not run rm, git push, or any destructive command during audit.
• Do not modify any source files during the audit phase.
• If the test suite fails, report the failures — do not attempt to fix them during the audit.
• Score honestly. Most codebases score 2-3. A score of 5 is exceptional and rare.
• This audit is language-agnostic. Adapt type system evaluation to the language (e.g., Python type hints, Go interfaces, Rust traits).
• If the codebase uses multiple languages, score each dimension for the primary language and note secondary language gaps.

Completion Checklist

• All five dimensions scanned with concrete evidence
• Scorecard presented in the exact table format
• Grade assigned with letter and description
• Each dimension has specific findings with file paths
• Highest-impact fix identified per dimension
• User asked whether they want a refactoring plan
• If yes, plan generated with max 5 priorities, ordered by impact
• Plan items are specific enough to be executed by an AI agent

Weekly Installs

1

Repository

designxdevelop/…t-skills

First Seen

Today

Security Audits

Gen Agent Trust HubPassSocketPassSnykPass

Installed on

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1