开源MCP工具

30-Second PR Demo

This is a real, unedited recording against the published @ivorycanvas/qamap package on a small Next.js app with zero committed tests: qamap qa names the affected flow and the bootstrap plan, qamap e2e setup writes the Playwright config and starter spec, and npm run test:e2e finishes with 1 passed. First-run assertions are smoke checks — the point is a runnable starting point, not finished coverage.

Try the same loop on your own branch:

pnpm dlx @ivorycanvas/qamap qa . --base origin/main --head HEAD

QAMap reads the changed files and project signals:

Input
- git diff: origin/main...HEAD
- project structure: package.json, routes, test config, selectors
- optional team context: .qamap/manifest.yaml, CONTEXT.md, ADRs, goals, QA runbooks

Then it returns reviewable verification work:

Output
- PR comment/checklist draft for this branch
- changed domain language and candidate user flows
- recommended E2E runner or manual checklist
- draft Playwright, Maestro, CLI, API, or manual test files
- readiness status: runnable-candidate, near-runnable, or review-only
- blockers such as missing runner config, selectors, fixtures, or assertions

Trimmed real qamap qa output for a small Next.js notes-page change in a repository with no tests and no manifest (full output also lists validation gaps and a PR checklist):

```txt

Configuration

Use qamap.config.json or .qamap.json to tune repository policy.

{
  "$schema": "https://raw.githubusercontent.com/IvoryCanvas/qamap/main/schema/qamap.schema.json",
  "failOn": "high",
  "ignoreRules": ["QM011"],
  "maxFiles": 2000,
  "validationCommands": ["make test", "make lint"],
  "severity": {
    "QM007": "info"
  }
}

See docs/configuration.md for details.

QAMap

A local-first QA skill for AI-generated PRs. QAMap turns a PR diff into affected flows, missing evidence, and E2E drafts. No cloud. No LLM token.

QAMap is a local-first CLI that reads git changes, project structure, runner signals, selectors, and optional repo QA memory, then returns a PR-ready QA draft: which user flow may be affected, which runner fits, what E2E or checklist should exist, and what evidence is still missing before merge.

It is built for the moment when a reviewer asks: "This PR looks plausible, but which user flow could it break, and what should we test before merge?"

QAMap does not call an LLM API, upload source code, or require a service account. It runs in the repository you already have.

The core loop is intentionally simple:

PR diff
  -> qamap qa

QAMap output
  -> PR comment draft + E2E/checklist draft + missing evidence

Optional team memory
  -> .qamap/manifest.yaml
  -> better future PR recommendations

QAMap QA Draft

Local-first PR QA skill output. No cloud. No LLM token. Manifest is optional, not required for first use.

What QAMap Is For

QAMap is intentionally small:

• time-saving: it surfaces missing context, risky settings, and validation gaps before agent work becomes review churn
• static by default: it does not execute scanned project code
• no-token by default: it does not call an LLM API
• verification-focused: it tells reviewers what evidence is missing, not how to style code
• PR QA skill output: qamap qa turns a branch into a PR-ready affected-flow summary, suggested E2E/checklist draft, missing evidence list, and copyable checklist
• packaged agent skill: skills/qamap-pr-qa/SKILL.md gives coding agents a compact PR QA workflow for running QAMap before handoff
• domain-aware E2E drafting: it turns branch changes into flow language, draft specs, readiness summaries, and action items
• repo-local verification base: shared manifests can be committed, while generated run history stays ignored by default
• context-aware baseline generation: manifest init can use repo-local context, ADRs, goals, agent instructions, harness files, skills, and runbooks as advisory bootstrap signals
• harness/skill role hints: instruction-derived context is classified as agent skill, harness config, workflow lifecycle, verification rubric, safety policy, release policy, or test runner context
• ecosystem-aware: it suggests validation commands for JavaScript/TypeScript, Python, Go, Rust, Gradle, and Maven projects
• CI-friendly: text, JSON, Markdown, and SARIF output are supported
• explainable: every finding includes a concrete fix

It is built for teams using AI coding agents, MCP-powered tools, or any workflow where an agent can read, edit, test, commit, or open pull requests.

For PR verification, QAMap treats the repository itself as the working base: committed manifests hold durable team language, ignored local history holds generated run observations, and the current branch diff supplies what changed now.

<details> <summary>한국어 소개</summary>

QAMap는 AI 코딩 에이전트가 만든 PR을 리뷰하기 전에 로컬에서 실행하는 QA 초안 CLI입니다.

PR diff와 repo 구조를 읽고 어떤 사용자 플로우가 영향받았는지, 어떤 E2E 또는 체크리스트가 필요한지, fixture/selector/assertion/runner/validation 근거 중 무엇이 부족한지 정리합니다. 클라우드나 LLM 토큰을 쓰지 않습니다.

pnpm dlx @ivorycanvas/qamap qa . --base origin/main --head HEAD

에이전트에게 넘길 때는 --format agent를 붙이면 같은 판단 내용을 약 2KB의 JSON으로 받을 수 있어, 매 세션 repo 탐색에 토큰을 쓰지 않아도 됩니다.

목표는 거대한 QA 플랫폼이 아니라, 유지보수자가 매번 에이전트에게 프로젝트 맥락과 검증 방법을 다시 설명하느라 쓰는 시간을 줄여주는 작고 선명한 도구입니다. Manifest 없이 바로 시작하고, 반복해서 틀리는 추천은 .qamap/manifest.yaml에 팀의 QA 언어로 보정해 향후 PR 추천을 개선합니다.

</details>

What QAMap Produces

On a changed branch, QAMap tries to produce reviewable verification artifacts instead of only saying "write more tests":

• a branch-aware verification plan that names the changed domain, actor, trigger, goal, success signal, and edge cases
• draft Playwright, Maestro, CLI command, or manual checklist files when the repository shape supports them
• a repo-level verification manifest loop where humans correct durable flows once and later PRs get sharper route/check/test draft suggestions
• a runner setup proposal that explains why Playwright or Maestro fits the changed surface and which files/commands would be created if the team accepts it
• readiness evidence that explains missing runner config, selectors, fixture data, assertions, validation commands, or flow manifests
• repo-local suggestions for .qamap/domains.yml, .qamap/flows.yml, and ignored .qamap/runs/ history so teams can improve the next run without spending LLM tokens

That means QAMap is most valuable when it becomes the team's verification base: humans define the durable language and critical flows once, QAMap reuses that base on each PR, and generated observations stay local unless the team intentionally promotes them into shared policy.

Where QAMap Fits

On the QA side, QAMap starts one step earlier than test-writing tools — it decides what a PR must prove before anyone records, generates, or writes a test:

On the guardrails side, QAMap is not trying to replace the larger security ecosystem: