Token导航 LogoToken导航TokenDH.com
研究检索操作浏览器github未标认证来源可访问许可证需确认审计通过

test-architect测试架构师

Agent Skill

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据,避免为了通过测试而改坏真实逻辑;涉及浏览器或外部服务时,应区分本地模拟、测试环境和生产环境。

总安装

329

周安装

14

GitHub Stars

2

下载量

115
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:test-architect(测试架构师)
来源仓库:https://github.com/wyattowalsh/agents
仓库路径:skills/test-architect
安装命令:
npx skills add https://github.com/wyattowalsh/agents --skill test-architect
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/wyattowalsh/agents --skill test-architect

简介

用于辅助测试设计、用例整理和回归验证。

  • 适合编写单元测试、端到端测试或定位失败日志问题。
  • 使用时需确认测试框架、运行命令和夹具数据。
  • 安装命令:npx skills add https://github.com/wyattowalsh/agents --skill test-architect。
  • 涉及浏览器或外部服务时应区分模拟环境与生产环境。

SKILL.md

Test Architect

Design test strategies, analyze coverage gaps, identify edge cases, diagnose flaky tests, and audit test suite architecture.

Scope: Test design and analysis only. NOT for running tests or CI/CD (devops-engineer), code review (honest-review), or TDD workflow.

Dispatch

$ARGUMENTSAction
design <feature/module>Design test strategy and pyramid for a feature or module
generate <file/function>Generate test cases (strategy text or actual test code based on context)
gapsAnalyze coverage gaps from coverage reports
edge-cases <function>Systematic edge case identification for a function
flakyDiagnose flaky tests from logs and code
reviewAudit test suite architecture
EmptyShow mode menu with examples

Canonical Vocabulary

Use these terms exactly throughout all modes:

TermDefinition
test pyramidLayered test distribution: unit (base), integration (middle), e2e (top)
coverage gapCode path with no test coverage, weighted by complexity risk
edge caseInput at boundary conditions, null/empty, type coercion, overflow, unicode, concurrent
flaky testTest with non-deterministic pass/fail behavior across identical runs
mutation scorePercentage of injected mutations detected by the test suite
test strategyDocument defining what to test, how, at what layer, with what tools
property-based testTest asserting invariants over generated inputs (Hypothesis/fast-check)
test isolationGuarantee that tests do not share mutable state or execution order dependencies
fixtureReusable test setup/teardown providing controlled state
test surfaceSet of public interfaces, code paths, and states requiring test coverage

Mode 1: Design

/test-architect design <feature/module>

Surface Analysis

  1. Read the feature/module code. Map the test surface: public API, internal paths, state transitions, error conditions.
  2. Classify complexity: simple (pure functions), moderate (I/O, state), complex (distributed, concurrent, multi-service).

Pyramid Design

  1. Design test pyramid:

- Unit layer: Pure logic, transformations, validators. Target: 70-80% of tests. - Integration layer: Database, API, file I/O, service boundaries. Target: 15-25%. - E2E layer: Critical user flows only. Target: 5-10%.

  1. For each layer, list specific test cases with: description, input, expected output, rationale.
  2. Recommend framework and tooling based on language/ecosystem.
  3. Output: structured strategy document with pyramid diagram, case list, and priority order.

Reference: read references/test-pyramid.md for layer guidance.

Mode 2: Generate

/test-architect generate <file/function>

  1. Read the target file/function. Identify signature, dependencies, side effects.
  2. Determine output format:

- If test file exists for target: generate actual test code matching existing patterns. - If no test file exists: generate test strategy text with case descriptions. - If user specifies --code: always generate test code.

  1. Generate test cases covering:

- Happy path (expected inputs and outputs) - Error path (invalid inputs, exceptions, timeouts) - Edge cases (run edge-case-generator.py if function has typed parameters) - Boundary conditions (min/max values, empty collections, null)

  1. Follow framework conventions: read references/framework-patterns.md for pytest/jest/vitest patterns.
  2. Output: test cases or test code with clear section headers per category.

Mode 3: Gaps

/test-architect gaps

  1. Locate coverage reports. Search for:

- coverage.json, coverage.xml, .coverage (Python/coverage.py) - lcov.info, coverage/lcov.info (JS/lcov) - htmlcov/, coverage/ directories

  1. Run coverage analyzer: uv run python skills/test-architect/scripts/coverage-analyzer.py <report-path>
  2. Parse JSON output. Rank gaps by complexity-weighted risk.
  3. For each gap, assess:

- What code is untested and why it matters - Complexity score (cyclomatic complexity proxy) - Recommended test type (unit/integration/e2e) - Priority (P0: security/auth, P1: core logic, P2: utilities, P3: cosmetic)

  1. Render dashboard if 10+ gaps: Copy templates/dashboard.html to a temporary file Inject gap data JSON into <script id="data"> tag Open in browser
  2. Output: prioritized gap list with recommended actions.

Reference: read references/coverage-analysis.md for interpretation guidance.

Mode 4: Edge Cases

/test-architect edge-cases <function>

  1. Read the function. Extract parameter types, return types, and constraints.
  2. Run edge case generator: uv run python skills/test-architect/scripts/edge-case-generator.py --name "<function_name>" --params "<param1:type,param2:type>"
  3. Parse JSON output. Review generated categories:

- Null/empty: None, "", [], {}, 0, False - Boundary: min/max int, float limits, string length limits - Type coercion: "123" vs 123, True vs 1, None vs "null" - Overflow: large numbers, deep nesting, long strings - Unicode: emoji, RTL text, zero-width chars, combining marks - Concurrent: race conditions, deadlocks, stale reads

  1. For each edge case, provide: input value, expected behavior, rationale.
  2. Flag cases where current code would likely fail (no guard, no validation).

Reference: read references/edge-case-heuristics.md for category details.

Mode 5: Flaky

/test-architect flaky

Log Collection

  1. Locate test result logs. Search for:

- CI logs, pytest output, jest output - .pytest_cache/, test-results/ - Ask user for log path if not found

  1. Run flaky test analyzer: uv run python skills/test-architect/scripts/flaky-test-analyzer.py <log-path>

Root Cause Classification

  1. Parse JSON output. For each flaky test:

- Failure count vs pass count - Failure pattern (timing, ordering, resource, state) - Likely root cause classification: - Timing: sleep/timeout dependencies, race conditions - Ordering: test execution order dependencies - Resource: external service, database, file system - State: shared mutable state between tests - Environment: platform-specific, timezone, locale

  1. Recommend fix strategy per root cause.
  2. Prioritize by failure frequency and blast radius.

Reference: read references/flaky-diagnosis.md for root cause patterns.

Mode 6: Review

/test-architect review

  1. Scan the test suite. Map: test file count, framework(s), directory structure.
  2. Assess architecture dimensions:

- Pyramid balance: ratio of unit:integration:e2e tests - Isolation: shared state, global fixtures, test ordering dependencies - Naming: consistency, descriptiveness, convention adherence - Coverage distribution: even vs clustered coverage - Fixture health: duplication, complexity, setup/teardown balance - Assertion quality: specific assertions vs generic assertTrue - Speed: identify slow tests (>1s unit, >10s integration) - Determinism: potential flakiness indicators

  1. Run coverage analyzer if reports exist.
  2. Cross-reference with source code:

- Untested public APIs - Tests for deleted/renamed code (orphaned tests) - Missing negative test cases

  1. Output: architecture audit report with scores per dimension, findings, and recommendations.

Reference: read references/test-suite-audit.md for scoring criteria.

Reference Files

Load ONE reference at a time. Do not preload all references into context.

FileContentRead When
references/test-pyramid.mdTest pyramid layers, distribution targets, anti-patternsMode 1 (Design)
references/framework-patterns.mdpytest, jest, vitest patterns and conventionsMode 2 (Generate), Mode 6 (Review)
references/coverage-analysis.mdCoverage report interpretation, complexity weightingMode 3 (Gaps)
references/edge-case-heuristics.mdEdge case categories by data type, generation strategiesMode 4 (Edge Cases)
references/flaky-diagnosis.mdFlaky test root causes, fix strategies, prevention patternsMode 5 (Flaky)
references/test-suite-audit.mdTest architecture scoring rubric, quality dimensionsMode 6 (Review)
references/property-testing.mdProperty-based testing with Hypothesis and fast-checkMode 1 (Design), Mode 2 (Generate)
references/mutation-testing.mdMutation testing plan design, tool integrationMode 1 (Design), Mode 6 (Review)
ScriptWhen to Run
scripts/coverage-analyzer.pyMode 3 (Gaps) -- parse coverage reports
scripts/edge-case-generator.pyMode 4 (Edge Cases) -- generate edge cases from function signature
scripts/flaky-test-analyzer.pyMode 5 (Flaky) -- parse test logs for flaky indicators
TemplateWhen to Render
templates/dashboard.htmlMode 3 (Gaps) with 10+ gaps -- coverage gap visualization

Critical Rules

  1. Never run tests -- design and analyze only. Suggest commands but do not execute.
  2. Never modify source code -- test architecture is advisory, not implementation.
  3. Always recommend the correct test layer (unit/integration/e2e) for each test case.
  4. Edge cases must include rationale -- "why this matters" not just "try this input."
  5. Coverage gaps must be prioritized by risk, not by line count.
  6. Flaky test diagnosis must identify root cause category before recommending fixes.
  7. Framework recommendations must match the project's existing stack.
  8. Property-based testing is recommended only when invariants are identifiable.
  9. Load ONE reference file at a time -- do not preload all references.
  10. Every finding must cite the specific file and function it applies to.
  11. Test generation must follow existing test patterns in the project when present.
  12. Dashboard rendering requires 10+ gaps -- do not render for small gap sets.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

37.78%
按下载量换算43

Claude

31.15%
按下载量换算36

Cursor

17.95%
按下载量换算21

Gemini CLI

10.45%
按下载量换算12

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills