Back to Details

qa-project-context

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<objective> This skill writes the single file every other QA skill reads. Without it, each skill re-asks "what framework? what CI? where do tests live?" from scratch and gives generic advice. It produces `.agents/qa-project-context.md` in the project root, capturing product, tech stack, test stack, CI/CD, environments, quality goals, risk areas, team, and conventions — with no `[bracketed placeholders]` left behind. </objective>
Downstream skills consume specific sections: Risk Areas feeds 
risk-based-testing
and 
test-strategy
; Conventions → Selectors feeds 
playwright-automation
and 
test-reliability
; Quality Goals feeds 
qa-metrics
; Tech Stack feeds every automation skill. Fill those sections well and the rest of the library gets sharper for free.
<objective> 本技能负责编写所有其他QA技能都会读取的唯一文件。如果没有该文件，每个技能都会从头反复询问「使用什么框架？用什么CI？测试代码存放在哪里？」，并给出通用建议。本技能会在项目根目录生成.agents/qa-project-context.md文件，记录产品信息、技术栈、测试栈、CI/CD、环境、质量目标、风险领域、团队及约定——确保文件中没有遗留任何「[括号占位符]」。 </objective>
下游技能会调用特定章节的内容：风险领域为
risk-based-testing
和
test-strategy
提供数据；约定→选择器部分会被
playwright-automation
和
test-reliability
使用；质量目标为
qa-metrics
提供依据；技术栈则会被所有自动化技能调用。填好这些章节，整个技能库的实用性会自然提升。

Discovery Questions

信息收集问题

First, check whether 
.agents/qa-project-context.md
already exists — if it does, read it and skip every section already filled (no 
[brackets]
). Then scan the repo for config files (see Codebase Detection) and present detected values for confirmation rather than asking blind. Walk the remaining questions section by section, never all at once.
首先检查.agents/qa-project-context.md是否已存在——如果存在，读取文件并跳过所有已填充完成的章节（无「[括号]」）。然后扫描仓库中的配置文件（参见代码库检测部分），将检测到的值呈现给用户确认，而非盲目提问。分章节逐步推进剩余问题，切勿一次性全部抛出。

Product

产品信息

  • What is the product called, and what does it do in one sentence?
  • What type is it? (SaaS, e-commerce, media, mobile app, API service, internal tool) — changes which flows matter.
  • What are the production, staging, and development URLs?
  • What are the 5–10 most critical user journeys? ("If this breaks, we get paged at 2am.") This list drives every other skill's coverage priorities.
  • 产品名称是什么？用一句话描述其功能。
  • 产品类型是什么？（SaaS、电商、媒体、移动应用、API服务、内部工具）——这会影响核心流程的优先级。
  • 生产环境、预发布环境和开发环境的URL分别是什么？
  • 5-10个最关键的用户旅程是什么？（「如果这部分出问题，我们会在凌晨2点被叫醒」）该列表将决定所有其他技能的覆盖优先级。

Tech Stack

技术栈

  • Frontend framework and language? Backend framework, language, and API style (REST, GraphQL, tRPC, gRPC)?
  • Database, cache layer, ORM? Hosting, CDN, monitoring?
  • Monorepo? If yes, list each app separately (see Monorepo note) — sharding and detection differ.
  • 前端框架和开发语言？后端框架、开发语言及API风格（REST、GraphQL、tRPC、gRPC）？
  • 数据库、缓存层、ORM？托管服务、CDN、监控工具？
  • 是否为单体仓库？若是，请分别列出每个应用（参见单体仓库说明）——分片方式和检测逻辑会有所不同。

Test Stack

测试栈

  • E2E tests today? Framework, config location, test directory. Same for unit, API, visual, performance.
  • If a framework is detected from config files, populate Test Stack with its name + version + path — don't re-ask.
  • Zero test infrastructure? That's a valid answer; record "None selected yet" and note a default (see Core Principle 3).
  • 当前是否有E2E测试？使用的框架、配置文件位置、测试目录。单元测试、API测试、可视化测试、性能测试也需同样说明。
  • 如果从配置文件中检测到框架，直接将其名称+版本+路径填充到测试栈中——无需重复询问。
  • 无任何测试基础设施？这是合理的答案；请记录「尚未选择」并标注默认推荐（参见核心原则3）。

CI/CD

CI/CD

  • Platform? When do tests run (every push, PR only, nightly, manual)? Sharding/parallelism?
  • What blocks a deploy, and what artifacts are saved (screenshots, reports, coverage)?
  • 使用的平台？测试执行时机（每次推送、仅PR、夜间、手动）？是否采用分片/并行执行？
  • 哪些条件会阻止部署？会保存哪些产物（截图、报告、覆盖率数据）？

Environments

环境配置

  • How many environments, with URLs? How close is staging to production (infra, data shape, third-party integrations)?
  • Mock services or real APIs in development? — environment parity drives test reliability.
  • 共有多少个环境？对应的URL是什么？预发布环境与生产环境的相似度如何（基础设施、数据结构、第三方集成）？
  • 开发环境中使用模拟服务还是真实API？——环境一致性会影响测试可靠性。

Quality Goals

质量目标

  • Coverage targets today? Flake tolerance? Suite-duration budgets? Metrics tracked or wanted?
  • No targets yet? Suggest realistic ones by maturity (see Quality Goals section).
  • 当前的覆盖率目标？容错率？测试套件时长限制？已追踪或想要追踪的指标？
  • 尚未设定目标？根据项目成熟度建议合理目标（参见质量目标章节）。

Risk Areas

风险领域

  • Which parts cause the most production incidents? Which integrations are flakiest (payment, email, third-party APIs)?
  • Where is churn high and coverage low? Score everything with Impact × Likelihood (see Risk Areas section).
  • 哪些部分最容易引发生产事故？哪些集成最不稳定（支付、邮件、第三方API）？
  • 用户流失率高但测试覆盖率低的区域是哪里？用「影响程度 × 发生概率」为所有项目打分（参见风险领域章节）。

Team

团队信息

  • How many QA engineers, and their specializations? Developer-to-QA ratio? Methodology (Scrum, Kanban, Shape Up)?
  • When does QA engage (shift-left during spec, or after dev)? — sets the automation ownership model.
  • QA工程师数量及各自专长？开发与QA的人员比例？采用的方法论（Scrum、Kanban、Shape Up）？
  • QA参与项目的阶段（需求阶段提前介入，还是开发完成后介入）？——这会决定自动化测试的所有权模式。

Conventions

约定规范

  • Test file naming pattern? Co-located or separate? Branching strategy and PR requirements?
  • Selector strategy for E2E? Test-data strategy (factories, fixtures, seeded DB, API-per-test)?
  • 测试文件命名规则？测试代码与业务代码同目录存放还是单独存放？分支策略及PR要求？
  • E2E测试的选择器策略？测试数据策略（工厂模式、固定数据、预填充数据库、每次测试调用API）？

Core Principles

核心原则

  1. One file is the source of truth for the whole library. Every skill reads 
    .agents/qa-project-context.md
    first. Duplicating its facts into other docs guarantees drift — keep stack, goals, and risks here and let other skills reference them.
  2. Capture the real state, not the aspiration. If there are no E2E tests, write "None selected yet," not a wish. Downstream skills route on what's true: a missing framework triggers a setup suggestion; a fake one sends them building on sand.
  3. Detect before you ask; recommend a default only when there's nothing to detect. Read 
    package.json
    and config files first and confirm what you find. Tool recommendations belong to the specialized skills — the one exception is a project with zero test infrastructure, where you note Playwright (E2E) and Vitest (unit) as defaults in the Test Stack and hand off to 
    playwright-automation
    / 
    unit-testing
    . This is the single carve-out to the "no recommendations" rule; everywhere else, just record.
  4. Risk Areas is the highest-leverage section — never skip it. It is the direct input to 
    risk-based-testing
    and 
    test-strategy
    . Push for at least 3–4 entries scored by impact and likelihood even when the user says "everything's fine."
  1. 单一文件作为整个技能库的事实来源。所有技能都会优先读取.agents/qa-project-context.md。将其内容复制到其他文档中必然会导致信息不一致——请将技术栈、目标和风险信息集中存放在此处，让其他技能引用即可。
  2. 记录真实状态，而非理想状态。如果没有E2E测试，请写「尚未选择」，而非主观愿望。下游技能会根据真实状态调整流程：缺少框架时会触发设置建议；虚假信息则会导致后续工作建立在错误基础上。
  3. 先检测再提问；仅在无检测结果时推荐默认工具。先读取package.json和配置文件，将检测结果呈现给用户确认。工具推荐属于专业技能的范畴——唯一例外是完全没有测试基础设施的项目，此时需在测试栈中注明Playwright（E2E）和Vitest（单元测试）作为默认推荐，并将后续工作移交
    playwright-automation
    /
    unit-testing
    。这是「不推荐工具」规则的唯一例外；其他场景下仅需记录现状。
  4. 风险领域是价值最高的章节——切勿跳过。它是
    risk-based-testing
    和
    test-strategy
    的直接输入。即便用户表示「一切正常」，也要推动至少3-4个按影响程度和发生概率打分的条目。

Codebase Detection

代码库检测

Scan for these before asking about the stack. Present detected values for confirmation; when a test config is found, write the framework name into Test Stack rather than re-asking.
FileIndicates
package.json
Node.js project — check 
dependencies
for the framework
next.config.*
Next.js
nuxt.config.*
Nuxt/Vue
angular.json
Angular
astro.config.*
Astro
react-router.config.ts
React Router 7 / Remix
requirements.txt
/ 
pyproject.toml
Python project
go.mod
Go project
playwright.config.*
Playwright is set up → populate Test Stack E2E
cypress.config.*
Cypress is set up → populate Test Stack E2E
vitest.config.*
/ 
jest.config.*
Unit test framework → populate Test Stack Unit
.github/workflows/
GitHub Actions CI
.gitlab-ci.yml
GitLab CI
Jenkinsfile
Jenkins
docker-compose.*
Docker-based environments
wrangler.*
Cloudflare Workers
vercel.json
Vercel hosting
bun.lock
/ 
bun.lockb
Bun runtime
pnpm-workspace.yaml
/ 
turbo.json
/ 
nx.json
Monorepo — handle per the Monorepo note
src-tauri/tauri.conf.json
Tauri desktop app
.claude/
Project uses Claude Code skills/agents
.claude-plugin/plugin.json
Project ships a Claude Code plugin
AGENTS.md
Codex / multi-agent workflow conventions
在询问技术栈之前先扫描以下文件。将检测到的值呈现给用户确认；若找到测试配置文件，直接将框架名称写入测试栈，无需重复询问。
文件代表含义
package.json
Node.js项目——检查
dependencies
中的框架
next.config.*
Next.js
nuxt.config.*
Nuxt/Vue
angular.json
Angular
astro.config.*
Astro
react-router.config.ts
React Router 7 / Remix
requirements.txt
/ 
pyproject.toml
Python项目
go.mod
Go项目
playwright.config.*
已配置Playwright → 填充测试栈的E2E部分
cypress.config.*
已配置Cypress → 填充测试栈的E2E部分
vitest.config.*
/ 
jest.config.*
单元测试框架 → 填充测试栈的单元测试部分
.github/workflows/
GitHub Actions CI
.gitlab-ci.yml
GitLab CI
Jenkinsfile
Jenkins
docker-compose.*
基于Docker的环境
wrangler.*
Cloudflare Workers
vercel.json
Vercel托管
bun.lock
/ 
bun.lockb
Bun运行时
pnpm-workspace.yaml
/ 
turbo.json
/ 
nx.json
单体仓库——按单体仓库说明处理
src-tauri/tauri.conf.json
Tauri桌面应用
.claude/
项目使用Claude Code技能/Agent
.claude-plugin/plugin.json
项目发布Claude Code插件
AGENTS.md
Codex / 多Agent工作流约定

Workflow: Creating the Context File

工作流：创建上下文文件

  1. Check for existing context. Look for 
    .agents/qa-project-context.md
    in the project root.
  2. If absent: create 
    .agents/
    if needed, scaffold the section structure, run the Discovery Questions starting with Product, and write the file once filled.
  3. If present with placeholders: read it, list which sections are complete vs. unfilled, ask only about the unfilled sections, then update — preserve completed sections untouched.
  4. If present and complete: summarize the current context, ask what changed (new tools, team changes, shifted goals), and update only the deltas.
  5. After completion: confirm the file path, run Verification (below), and suggest the next skill from the context (no E2E → 
    playwright-automation
    ; no strategy → 
    test-strategy
    ; no unit tests → 
    unit-testing
    ).
For two full filled-in files (SaaS and a multi-site publisher) plus the monorepo layout, see 
references/examples.md
. One short illustrative snippet:
markdown
undefined
  1. 检查现有上下文。在项目根目录查找.agents/qa-project-context.md。
  2. 若不存在：必要时创建.agents/目录，搭建章节结构，从产品信息开始执行信息收集问题，完成后写入文件。
  3. 若存在但有占位符：读取文件，列出已完成和未填充的章节，仅询问未填充部分，然后更新文件——保留已完成章节不变。
  4. 若存在且已完成：总结当前上下文，询问有哪些变更（新工具、团队变动、目标调整），仅更新变化的部分。
  5. 完成后：确认文件路径，执行验证（如下），并根据上下文建议下一步使用的技能（无E2E测试→
    playwright-automation
    ；无测试策略→
    test-strategy
    ；无单元测试→
    unit-testing
    ）。
关于两个完整的填充示例（SaaS和多站点发布商）以及单体仓库布局，请查看
references/examples.md
。以下是一段简短的示例片段：
markdown
undefined

Test Stack

测试栈

E2E / Integration

E2E / 集成测试

  • Framework: Playwright 1.60
  • Config Location: playwright.config.ts
  • Test Directory: tests/e2e/
  • 框架： Playwright 1.60
  • 配置文件位置： playwright.config.ts
  • 测试目录： tests/e2e/

Unit / Component

单元 / 组件测试

  • Framework: None selected yet — Vitest recommended (see unit-testing)
undefined
  • 框架： 尚未选择——推荐Vitest（参见unit-testing）
undefined

Section Guidance

章节指导

What makes a good entry in each section. The blank template ships at 
.agents/qa-project-context.md
in the qaskills repo.
Product. Key user flows must be specific and testable: "Buyer searches products, adds to cart, checks out with Stripe, receives confirmation email" — not "user uses the app." This list is what every test skill uses to prioritize. Aim for 5–10.
Tech Stack. Record frontend, backend, database, hosting separately. Pin versions only when they change the testing approach (App Router vs. Pages Router differ materially). Don't copy a version just because an example shows one — read it from 
package.json
.
Test Stack. For each tool: framework name + version, config location, test directory. No infrastructure yet is valid — write "None selected yet" and the recommended default (Principle 3).
Monorepo. List each frontend app as its own Tech Stack and Test Stack entry; keep the shared API/backend as one entry. Shard E2E per app (a change in 
apps/admin
shouldn't run 
apps/storefront
E2E), and note in CI/CD which path filters gate which app's suite. Detection hint: 
turbo.json
/ 
pnpm-workspace.yaml
/ 
nx.json
. See 
references/examples.md
.
CI/CD. Answer what other skills need: what blocks a deploy, how fast feedback is, what evidence is preserved.
Environments. Note how staging diverges from production — a different DB engine in staging means staging-green tests can still fail in prod.
Quality Goals. Concrete and measurable only. Pick starting targets by maturity:
MaturityUnit coverageE2EFlakinessSuite duration
Early-stage startup60% on business logicTop 5 critical flows<2%Unit <3 min, E2E <15 min
Growth-stage80%All critical paths<2%Unit <3 min, E2E <15 min
Enterprise90%+Comprehensive + perf budgets<1%Unit <3 min, E2E <15 min
Write them as numbers: "80% line coverage measured by Istanbul," "flake rate <2% over a rolling 30-day window," "full E2E under 15 min with 4 shards." Never "we want great quality."
Risk Areas. Use the table — columns Area, Risk Level, Business Impact, Notes — and score with Impact × Likelihood:
  • Critical (test first): high impact + high likelihood (payment flow with known edge cases).
  • Important: high impact + low likelihood (auth — catastrophic if broken, rarely changes).
  • Monitor: low impact + high likelihood (notification formatting — breaks often, low severity).
  • Backlog: low impact + low likelihood (admin settings — stable, rarely used).
At least 3 entries, never vague ("everything breaks").
Team. Record actual headcount and the dev:QA ratio — it sets the automation ownership model:
Dev:QA ratioOwnership model
Solo / zero QA (effectively infinite)Devs own all tests. No manual regression suite; lean on low-barrier automation (Playwright + Vitest) and CI gates. QA "role" = strategy + critical-path E2E, done by the dev.
High (8:1+)Developers write tests; QA focuses on strategy, critical-path automation, exploratory testing.
Balanced (4:1)QA owns E2E, devs own unit, integration shared.
QA-heavy (<3:1)Dedicated automation engineers, comprehensive regression suites, scheduled exploratory cadence.
Conventions. Selector strategy especially — 
playwright-automation
and 
test-reliability
read it to generate matching selectors. Default to 
data-testid
for stability (
data-testid="invoice-create-button"
, kebab-case). If the team prefers semantic/ARIA selectors for accessibility-aware testing, record concrete tokens — 
role="button"
, 
role="heading"
, 
getByRole('link', { name: ... })
— and the tradeoff: ARIA roles double as a11y assertions and survive markup churn, but are less stable than 
data-testid
when copy or roles change, so pin a 
name
/
level
to keep them unambiguous.
各章节的优质填写标准。空白模板可在qaskills仓库的.agents/qa-project-context.md获取。
产品信息。关键用户旅程必须具体且可测试：「买家搜索商品、加入购物车、使用Stripe结账、收到确认邮件」——而非「用户使用应用」。该列表是所有测试技能的优先级依据。目标为5-10条。
技术栈。分别记录前端、后端、数据库、托管服务。仅当版本会影响测试方法时才标注版本（如App Router与Pages Router差异显著）。不要仅因为示例中有版本就复制——请从package.json中读取实际版本。
测试栈。对于每个工具：记录框架名称+版本、配置文件位置、测试目录。无基础设施是合理状态——请写「尚未选择」并标注推荐的默认工具（原则3）。
单体仓库。将每个前端应用作为独立的技术栈和测试栈条目；共享的API/后端作为一个条目。按应用分片执行E2E测试（
apps/admin
的变更不应触发
apps/storefront
的E2E测试），并在CI/CD章节中注明哪些路径过滤器控制哪些应用的测试套件。检测提示：
turbo.json
/
pnpm-workspace.yaml
/
nx.json
。参见
references/examples.md
。
CI/CD。回答其他技能需要的信息：哪些条件会阻止部署、反馈速度如何、保留哪些证据。
环境配置。注明预发布环境与生产环境的差异——预发布环境使用不同的数据库引擎意味着预发布测试通过后，生产环境仍可能失败。
质量目标。必须具体且可衡量。根据项目成熟度选择初始目标：
成熟度单元测试覆盖率E2E测试容错率测试套件时长
早期创业公司业务逻辑覆盖率60%覆盖Top5关键流程<2%单元测试<3分钟，E2E测试<15分钟
成长期公司80%覆盖所有关键路径<2%单元测试<3分钟，E2E测试<15分钟
企业级90%+全面覆盖+性能预算<1%单元测试<3分钟，E2E测试<15分钟
请用数字表述：「Istanbul测量的代码行覆盖率80%」「过去30天滚动窗口内容错率<2%」「4分片执行下完整E2E测试耗时低于15分钟」。切勿写「我们想要高质量」这类表述。
风险领域。使用表格——列包括领域、风险等级、业务影响、备注——并用影响程度 × 发生概率打分：
  • 优先测试（Critical）： 高影响+高概率（存在已知边缘案例的支付流程）。
  • 重要（Important）： 高影响+低概率（认证——一旦故障影响重大，但很少变更）。
  • 监控（Monitor）： 低影响+高概率（通知格式——经常出错，但严重程度低）。
  • 待办（Backlog）： 低影响+低概率（管理员设置——稳定，很少使用）。
至少3条条目，切勿模糊表述（如「一切都可能出问题」）。
团队信息。记录实际人数和开发与QA的比例——这会决定自动化测试的所有权模式：
开发:QA比例所有权模式
单人/无QA（实际比例无限大）开发人员负责所有测试。无手动回归测试套件；依赖低门槛自动化（Playwright+Vitest）和CI门禁。QA「角色」= 策略制定+关键路径E2E测试，由开发人员兼任。
高比例（8:1+）开发人员编写测试；QA专注于策略制定、关键路径自动化测试、探索性测试。
平衡比例（4:1）QA负责E2E测试，开发人员负责单元测试，集成测试由双方共同负责。
QA占比高（<3:1）配备专门的自动化工程师，拥有全面的回归测试套件，定期执行探索性测试。
约定规范。尤其注意选择器策略——
playwright-automation
和
test-reliability
会读取该部分生成匹配的选择器。默认推荐使用
data-testid
以保证稳定性（如
data-testid="invoice-create-button"
，短横线命名法）。如果团队偏好语义化/ARIA选择器以支持无障碍测试，请记录具体的标记——
role="button"
、
role="heading"
、
getByRole('link', { name: ... })
——以及权衡点：ARIA角色可同时作为无障碍断言，且能在标记变更时保持有效，但当文案或角色变更时，稳定性不如
data-testid
，因此需固定
name
/
level
以确保明确性。

Anti-Patterns

反模式

1. Asking all questions at once

1. 一次性抛出所有问题

Dumping 30 questions is overwhelming and gets shallow answers. Walk section by section, Product first.
一次性抛出30个问题会让用户不知所措，得到的答案也会很肤浅。请从产品信息开始，分章节逐步推进。

2. Leaving 
[brackets]
in the final file

2. 最终文件中遗留「[括号]」占位符

If the user has no answer, record the actual state ("None — no E2E framework selected yet"), not a placeholder. Placeholders left in the file silently break every downstream skill that parses it.
如果用户无法回答，请记录实际状态（如「无——尚未选择E2E框架」），而非占位符。文件中遗留的占位符会导致所有下游解析技能静默失效。

3. Inventing information

3. 编造信息

Detect the stack from 
package.json
, 
requirements.txt
, or config files — then confirm with the user before writing. Don't guess a database or hosting provider.
从package.json、requirements.txt或配置文件中检测技术栈——然后在写入前请用户确认。不要猜测数据库或托管服务提供商。

4. Skipping Risk Areas

4. 跳过风险领域章节

The single most valuable section for downstream skills. Push for at least 3–4 scored entries even when the user insists everything is fine.
这是对下游技能最有价值的章节。即便用户坚持表示一切正常，也要推动至少3-4个按影响程度和业务影响打分的条目。

5. Recommending tools beyond the zero-infra default

5. 超出无基础设施场景推荐工具

This skill records current state; tool selection belongs to 
playwright-automation
, 
unit-testing
, and the other specialized skills. The only recommendation you make here is the Playwright + Vitest default when there is no test infrastructure at all (Principle 3).
本技能仅记录当前状态；工具选择属于
playwright-automation
、
unit-testing
及其他专业技能的范畴。此处唯一的推荐是当完全没有测试基础设施时，默认推荐Playwright+Vitest（原则3）。

Verification

验证

Prove the produced file is complete, smallest check first. From the project root:
bash
test -f .agents/qa-project-context.md \
  && ! grep -q '\[.*\]' .agents/qa-project-context.md \
  && echo "context complete: file exists, no placeholders"
Exit 0 with the message means the file exists and every 
[bracketed placeholder]
is gone. A non-zero exit means either the file is missing or placeholders remain — fix those before handing off to any other skill. Then eyeball that all nine section headers are present:
bash
grep -c '^## ' .agents/qa-project-context.md   # expect >= 9
验证生成的文件是否完整，从最小检查项开始。在项目根目录执行：
bash
test -f .agents/qa-project-context.md \
  && ! grep -q '\[.*\]' .agents/qa-project-context.md \
  && echo "context complete: file exists, no placeholders"
返回状态码0并显示上述消息表示文件存在且无「[括号占位符]」遗留。非零状态码表示文件缺失或仍有占位符——在移交其他技能前需修复这些问题。然后检查所有9个章节标题是否存在：
bash
grep -c '^## ' .agents/qa-project-context.md   # 预期结果 >= 9

Done When

完成标准

  • .agents/qa-project-context.md
    exists in the project root and 
    grep -q '\[.*\]'
    returns non-zero (no bracketed placeholders remain).
  • All nine sections are present: Product, Tech Stack, Test Stack, CI/CD, Environments, Quality Goals, Risk Areas, Team, Conventions.
  • Product lists at least 5 specific, testable key user flows (no "user uses the app").
  • Test Stack names the actual frameworks + versions + paths in use, or states "None selected yet" with the recommended default noted.
  • Risk Areas table has at least 3 entries scored by impact and business impact.
  • Quality Goals are concrete numbers (coverage %, flake %, durations) — not aspirational prose.
  • Team section shows actual headcount and the dev:QA ratio (or "solo").
  • .agents/qa-project-context.md存在于项目根目录，且
    grep -q '\[.*\]'
    返回非零状态（无括号占位符遗留）。
  • 所有9个章节均存在：产品信息、技术栈、测试栈、CI/CD、环境配置、质量目标、风险领域、团队信息、约定规范。
  • 产品信息章节列出至少5个具体、可测试的关键用户旅程（无「用户使用应用」这类表述）。
  • 测试栈章节记录了实际使用的框架+版本+路径，或注明「尚未选择」并标注推荐的默认工具。
  • 风险领域表格至少有3个按影响程度和业务影响打分的条目。
  • 质量目标为具体数字（覆盖率%、容错率%、时长）——而非空泛的愿景描述。
  • 团队章节显示实际人数和开发:QA比例（或「单人」）。

Related Skills

相关技能

  • qa-start — bootstraps QA on a brand-new project end-to-end and calls this skill as its first step. Use qa-start when no QA exists yet; use this skill directly to (re)fill context.
  • risk-based-testing — turns the Risk Areas section into a prioritized risk matrix. Run it after this skill when the question is "where do we focus testing?"
  • test-strategy — consumes Risk Areas, Quality Goals, and Team to set multi-quarter direction.
  • qa-metrics — tracks the Quality Goals defined here; both reference the same targets.
  • playwright-automation / unit-testing — set up E2E / unit frameworks after the Test Stack section is filled; they read Conventions for selector and naming strategy.
  • ci-cd-integration — wires the pipeline described in the CI/CD section.
  • qa-start —— 为全新项目端到端启动QA流程，并将本技能作为第一步调用。当项目尚未开展任何QA工作时使用qa-start；直接使用本技能可（重新）填充上下文。
  • risk-based-testing —— 将风险领域章节转换为优先级风险矩阵。当问题为「我们应聚焦哪些测试？」时，在本技能之后运行该技能。
  • test-strategy —— 结合风险领域、质量目标和团队信息制定多季度方向。
  • qa-metrics —— 追踪此处定义的质量目标；两者引用相同的指标。
  • playwright-automation / unit-testing —— 测试栈章节填充完成后，用于搭建E2E/单元测试框架；它们会读取约定规范中的选择器和命名策略。
  • ci-cd-integration —— 对接CI/CD章节描述的流水线。

Reference Files (in 
references/
)

参考文件（位于
references/
目录）

  • examples.md — two complete filled-in context files (SaaS and a multi-site publisher) plus the monorepo Tech/Test Stack layout.
  • examples.md —— 两个完整的上下文文件示例（SaaS和多站点发布商）以及单体仓库的技术栈/测试栈布局。