Test And Report

Test & Report

A skill that packages the full flow: "Feishu test doc → browser evidence capture → dual-track submission (Bitable + GitHub issue)" so every piece of feedback includes environment info, screenshots, dedup conclusion, and priority, tracked in two systems.

Trigger Boundaries (when to use / when not to use)

Use this skill:

• User sends a Feishu test doc URL (usually contains test scope + code repo + Bitable link)
• User says "start testing / help me test / experience staging / collab on bugs / collect feedback"
• User describes a UX / functional issue and wants it tracked in both Bitable + GitHub
• User sends a known test Bitable URL (e.g. IJQPbTzZhaObMQsuL5OcbaoBnag / AdeDbC9VgaNkrEsXtk5cTMarn2e) with feedback

Do NOT use this skill:

• User asks you to write product code / open a PR → use normal dev flow
• User asks you to review an existing PR → use gh-pr-review skill
• CI / build failure debugging → use normal debugging
• User asks "how do I use this product / where do I download" → general answer

Prerequisites (check before executing)

Workflow Overview

Phase 1  Parse test doc (Feishu doc → config)
Phase 2  Browser setup (claude-in-chrome)
Phase 3  Accompany testing: user operates, agent observes
Phase 4  Per-bug submission (dedup → priority → upload screenshot → Bitable + GitHub dual-track)
Phase 5  Return to Phase 3 until user says "done"

Phase 1: Parse Test Document

User provides a Feishu document URL. Use lark-cli docs +fetch --doc <URL> --format pretty to pull full text, then extract:

If user only gives a Bitable URL without a document: identify the product (see auto-detection rules below), use the config from references/bitable-bases.md, and ask user for the staging URL if not found in the Bitable first record.

Auto-detect Current Product

Use these signals to determine which product, and therefore which repo + Bitable to use:

Known config details (field IDs, enum values, view shortcuts) are in references/bitable-bases.md.

Phase 2: Browser Setup

1. tabs_context_mcp { createIfEmpty: true } to check connection
2. If not connected → guide user to install claude-in-chrome extension (claude.com/chrome), click Connect, retry
3. Once connected, navigate to staging URL
4. Do a baseline capture before any bug is reported:
   • read_page --filter interactive for main interactive elements
   • read_console_messages / read_network_requests start recording
   • (Optional) note core script sources (third-party captcha / CDN / analytics)

Tool pitfalls:

• javascript_tool may throw Cannot access a chrome-extension:// URL of different extension when page loads cross-extension iframes (e.g. Geetest). Fall back to read_page + reading source.
• read_console_messages / read_network_requests need to be listening from page load — refresh once before reading.
• Don't use chrome-devtools MCP debug features simultaneously — they'll conflict with claude-in-chrome for Debugger protocol access.

Phase 3: Accompany Testing Loop

User operates manually. Agent does two things:

1. Passive observation: don't drive the user, don't click randomly
2. On-demand support: when user says "there's a problem / can't click / error / looks wrong", immediately collect evidence

Evidence package (collect for every bug):

Once evidence is complete, proceed to Phase 4.

Phase 4: Per-Bug Submission

Detailed procedure in references/submit-bug-sop.md. High-level steps (don't skip):

1. Dedup (mandatory, see SOP Section 2)

   • Search Bitable + GitHub issues (including closed) + GitHub PRs (including merged)
   • On hit, apply 5-category disposition: identical / fixed regression / in-progress PR / related but different / unrelated
   • Show comparison table to user, wait for instruction — confirm even when no hit

2. Assign priority (see SOP Section 3)

   • If inferable from symptoms → fill directly + brief rationale
   • If not inferable → AskUserQuestion with P0/P1/P2 options
   • Never default to P1 or guess randomly

3. Upload screenshot to R2 (see SOP Section 4)

   upload-img <local-path>
   # Returns https://pub-a9416c5573a34388b8d9465d8bef4257.r2.dev/YYYYMMDD/filename
   

4. Write to Feishu Bitable

   • +record-upsert required: issue title / description / category / priority / status (=pending confirmation) / submitter
   • +record-upload-attachment attach screenshot to the "Example image" field (do not stuff into upsert)

5. Create GitHub issue

   • Title: [Bug]: <one sentence> or [Feature]: <one sentence> (based on category)
   • Body follows generic issue format: English body first (with translation disclaimer), Chinese original collapsed in <details>, screenshots embedded as <img src="..."> with R2 URLs
   • Labels: category = Bug → type: bug; = UX improvement → type: feature

6. Report back: give user record_id, issue URL, and Bitable URL together, plus a summary: "title / category / priority / status"

Phase 5: Return to Phase 3

User continues testing. Every bug report goes through Phase 4.

When user says "done / finished / pause for today / stop" → output session summary: how many records created, how many issues filed, which regressions / in-progress PRs were identified, total time spent.

Reference Files

• references/bitable-bases.md — Known Base tokens / table IDs / field IDs / enum values, cross-base field naming conventions
• references/submit-bug-sop.md — Detailed submission protocol (5 dedup categories, priority rules, value formats, R2 upload, issue template)