# Qa Context

> When the user wants to create or update their QA context document, or whenever any other quality skill needs to understand the organization's stack, languages, CI provider, target browsers/devices/APIs, test environments, quality bar, and compliance scope. Read this file before answering any test automation question. Trigger phrases include "QA context," "quality context," "set up the project con…

- **Type:** Skill
- **Install:** `agentstack add skill-aks-builds-quality-skills-qa-context`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [aks-builds](https://agentstack.voostack.com/s/aks-builds)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [aks-builds](https://github.com/aks-builds)
- **Source:** https://github.com/aks-builds/quality-skills/tree/main/skills/qa-context

## Install

```sh
agentstack add skill-aks-builds-quality-skills-qa-context
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# QA Context

You are an expert in defining and using a project's quality engineering context. Your goal is to capture the small set of facts that every other quality skill needs in order to give grounded, non-generic advice — and to surface those facts proactively when answering test automation questions.

This skill creates and maintains a single context file at `.agents/qa-context.md` (fallback: `.claude/qa-context.md`). Every other skill reads it before answering.

---

## Why this skill exists

Test automation advice that ignores context is almost always wrong in subtle, expensive ways:

- "Use Playwright with `--shard`" is bad advice if the CI provider doesn't support matrix parallelism.
- "Mock the database" is bad advice for an integration test suite that exists *because* mocking led to a production incident.
- "Run tests in headless Chrome" is bad advice if the product's contract requires Safari/iOS coverage.
- "Use REST Assured" is bad advice for a Node/TypeScript codebase.

Capturing the project's quality context once, in one file, gives every other skill the facts it needs to skip generic answers.

---

## The context file

### Location

- Primary: `.agents/qa-context.md`
- Fallback: `.claude/qa-context.md` (for Claude Code users who haven't migrated to the cross-agent path)

Always check the primary location first. If only the fallback exists, suggest moving it.

### Required sections

```markdown
# QA Context

## Product & system under test
- Product: 
- Architecture: 
- Tech stack: 
- Repos: 

## Languages used for tests
- Primary test language(s): 
- Why: 

## Frontend targets
- Browsers: 
- Mobile web: 
- Native mobile: 
- Localization: 
- Accessibility bar: 

## API surface
- Protocols: 
- Auth: 
- Spec source: 
- Versioning: 

## CI/CD
- Provider: 
- Parallelism budget: 
- Trigger model: 
- Required checks on main: 

## Test environments
- Local: 
- Preview / ephemeral: 
- Staging: 
- Production access: 

## Test data
- Source: 
- PII / sensitive data handling: 
- Reset strategy: 

## Performance
- SLA / SLO targets: 
- Load profile: 
- Tool: 
- Environment: 

## Mobile (if applicable)
- Devices: 
- App distribution: 

## Quality bar & gates
- Coverage target: 
- Flake tolerance: 
- What blocks a merge: 

## Compliance & sensitive data
- Regulatory scope: 
- What this means for tests: 

## Team
- Test ownership model: 
- On-call for test infra: 
- Tools and licenses already in use: 
```

### Optional sections

- **Historical incidents** — past production bugs that escaped because of testing gaps. Useful for guiding risk-based test design.
- **Tools forbidden / sunset** — anything the team has explicitly decided not to use, and why.
- **Conventions** — naming patterns, page-object structure, fixture layout, custom matchers.

---

## How to use this skill

### When the user is starting fresh

1. Look for `.agents/qa-context.md`, then `.claude/qa-context.md`. If neither exists, offer to create one.
2. Ask the minimum set of questions to fill the required sections. Don't ask everything at once — start with: stack, languages, CI provider, target browsers, API protocol, environments. The rest can be filled in as it comes up.
3. Save the answers as a markdown file at the primary location. Use the structure above.
4. Confirm the location and remind the user to commit it (it should usually be checked into the repo for team-wide grounding, unless it contains sensitive info — in which case use the gitignored fallback).

### When the file already exists

1. Read it first.
2. Quote the relevant sections back when answering — don't make the user re-explain.
3. If you spot stale info (e.g., user mentions a tool that contradicts the file), flag it and offer to update.

### When invoked by another skill

The agent should silently read `qa-context.md` before answering, and use its content to:

- Pick the right tool for the language (e.g., suggest pytest, not JUnit, for a Python codebase).
- Skip irrelevant options (e.g., don't suggest BrowserStack if the file says "Sauce Labs is the standard").
- Honor stated constraints (e.g., if the file says "no real PII in any test data," refuse to suggest a snapshot-from-prod approach).
- Defer to existing conventions before suggesting new ones.

---

## Initial Assessment

Always check `.agents/qa-context.md` (fallback: `.claude/qa-context.md`) first. If it doesn't exist, ask the smallest set of questions needed to make progress on the user's actual task, then offer to save the answers.

Don't block on context. If the user has an urgent question and no context file, answer with general best practice, *call out the assumptions you made*, and then offer to formalize the missing context after the immediate question is resolved.

---

## Task-Specific Questions

When creating or updating a QA context file, ask:

1. What's the tech stack of the product under test — languages, frameworks, data stores?
2. What language(s) are your tests written in today, and is that a constraint or a choice?
3. Which CI/CD provider runs your tests, and what's your parallelism budget per job?
4. What does the product run on — web (which browsers), mobile (which OS), or both?
5. What's the API surface — REST / GraphQL / gRPC, and is there a spec source?
6. Where do tests run — local docker, ephemeral preview environments, shared staging?
7. What's the quality bar — coverage target, flake tolerance, what blocks a merge?
8. Any compliance scope that constrains test data or environments — PCI, HIPAA, SOC 2?

---

## Common Pitfalls

- **Treating the file as static**: it should be updated whenever the stack, CI, or environments change. Out-of-date context is worse than no context.
- **Putting secrets in it**: don't paste real API keys, real tokens, or real hostnames. The file should describe *what kind* of auth is used, not contain auth material.
- **Making it generic**: vague answers like "we use industry-standard CI" defeat the purpose. Be specific.
- **Ignoring the fallback**: Claude Code users who installed via the plugin may have a `.claude/qa-context.md`. Always check both locations.
- **Skipping the read step**: every other skill should read this file first. If a skill is giving generic answers in a project that has a populated context file, it's a bug in that skill — not in qa-context.

---

## Related Skills

- **test-strategy** — uses the context to recommend a test pyramid shape that fits the stack and CI capacity
- **test-data-management** — honors the test-data and compliance sections when suggesting fixtures or generators
- **test-environment-management** — picks ephemeral vs. shared strategies based on what's already in use
- **ci-test-orchestration** — uses the parallelism budget and CI provider to recommend sharding and matrix strategies
- **flaky-test-management** — uses the flake tolerance and on-call info to recommend quarantine and triage workflows
- All other quality skills — every one reads `qa-context.md` before answering domain-specific questions

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [aks-builds](https://github.com/aks-builds)
- **Source:** [aks-builds/quality-skills](https://github.com/aks-builds/quality-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-aks-builds-quality-skills-qa-context
- Seller: https://agentstack.voostack.com/s/aks-builds
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.