Token导航 LogoToken导航

Agent Skill · 研究检索

ln-522-manual-tester(ln 522 手动测试仪)

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

ln-522-manual-tester 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为操作浏览器;许可证信息还不明确,第三方扫描有提醒项,按安装量在研究检索类的 73,675 个 Skill 里排第 17,925。

总安装 6,350周安装 270GitHub Stars 437下载 2,225核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-522-manual-tester

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于辅助测试设计、自动化测试、用例整理和回归验证。可编写单元测试、端到端测试或根据日志定位问题,提升测试效率。通过 npx skills add 命令从指定 GitHub 仓库安装使用。使用时需确认测试框架、运行命令,并区分模拟与生产环境。

ln-522-manual-tester 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/ln-522-manual-tester

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-5…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要操作浏览器,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

ln-522-manual-tester 怎么安装?

在终端执行 npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-522-manual-…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

ln-522-manual-tester 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

ln-522-manual-tester 需要什么权限?

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

ln-522-manual-tester 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

ln-522-manual-tester 用的人多吗?

公开数据是累计安装 6,350 次,近一周安装 270 次,下载 2,225 次,GitHub 437 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

ln-522-manual-tester 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
ln-522-manual-tester

ln 522 手动测试仪 · 本页

6,350437操作浏览器未明确有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If shared/ is missing, fetch files via WebFetch from https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.

MANDATORY READ: Load shared/references/ci_tool_detection.md — compact output flags, pipefail, and failure-artifact policy for bash/curl/Puppeteer scripts.

Inputs

InputRequiredSourceDescription
storyIdYesargs, git branch, kanban, userStory to process

Resolution: Story Resolution Chain. Status filter: To Review

Manual Tester

Type: L3 Worker

Manually verifies Story AC on running code and reports structured results for the quality gate.

Purpose & Scope

  • Create executable test scripts in tests/manual/ folder of target project.
  • Run AC-driven checks via bash/curl (API) or puppeteer (UI).
  • Save scripts permanently for regression testing (not temp files).
  • Document results in Linear with pass/fail per AC and script path.
  • No status changes or task creation.

When to Use

  • Use when a Story needs hands-on acceptance-criteria verification before automated planning
  • Research comment "## Test Research:" exists on Story (from ln-521)
  • All implementation tasks in Story status = Done

Test Design Principles

1. Fail-Fast - No Silent Failures

CRITICAL: Tests MUST return 1 (fail) immediately when any criterion is not met.

Never use: print_status "WARN" + return 0 for validation failures, graceful degradation without explicit flags, silent fallbacks that hide errors.

Exceptions (WARN is OK): Informational warnings that don't affect correctness, optional features (with clear justification in comments), infrastructure issues (e.g., missing Nginx in dev environment).

2. Expected-Based Testing - The Golden Standard

CRITICAL: Tests MUST compare actual results against expected reference files, not apply heuristics or algorithmic checks.

Directory structure:

tests/manual/NN-feature/
├── samples/               # Input files
├── expected/              # Expected output files (REQUIRED!)
│   └── {base_name}_{source_lang}-{target_lang}.{ext}
└── test-*.sh

Heuristics acceptable ONLY for: dynamic/non-deterministic data (timestamps, UUIDs, tokens - normalize before comparison; JSON with unordered keys - use jq --sort-keys).

3. Results Storage

Test results saved to tests/manual/results/ (persistent, in.gitignore). Named: result_{ac_name}.{ext} or response_{ac_name}.json. Inspectable after test completion for debugging.

4. Expected File Generation

To create expected files:

  1. Run test with current implementation
  2. Review output in results/ folder
  3. If correct: copy to expected/ folder with proper naming
  4. If incorrect: fix implementation first, then copy

IMPORTANT: Never blindly copy results to expected. Always validate correctness first.

Workflow

Phase 0: Resolve Inputs

MANDATORY READ: Load shared/references/input_resolution_pattern.md

  1. Resolve storyId: Run Story Resolution Chain per guide (status filter: [To Review]).

Phase 1: Setup tests/manual structure

  1. Read docs/project/infrastructure.md — get port allocation, service endpoints, base URLs. Read docs/project/runbook.md — get Docker commands, test prerequisites, environment setup
  2. Check if tests/manual/ folder exists in project root
  3. If missing, create structure:

- tests/manual/config.sh — shared configuration (BASE_URL, helpers, colors) - tests/manual/README.md — folder documentation (see README.md template below) - tests/manual/test-all.sh — master script to run all test suites (see test-all.sh template below) - tests/manual/results/ — folder for test outputs (add to .gitignore)

  1. Add tests/manual/results/ to project .gitignore if not present
  2. If exists, read existing config.sh to reuse settings (BASE_URL, tokens)

Phase 2: Create Story test script

  1. Fetch Story, parse AC into Given/When/Then list (3-5 expected)

- Check for research comment (from ln-521-test-researcher) — incorporate findings into test cases

  1. Detect API vs UI (API → curl, UI → puppeteer). IF UI: MANDATORY READ: Load references/puppeteer_patterns.md
  2. Create test folder structure:

- tests/manual/{NN}-{story-slug}/samples/ — input files (if needed) - tests/manual/{NN}-{story-slug}/expected/ — expected output files (REQUIRED for deterministic tests)

  1. Generate test script: tests/manual/{NN}-{story-slug}/test-{story-slug}.sh

- Use appropriate template: TEMPLATE-api-endpoint.sh (direct calls) or TEMPLATE-document-format.sh (async jobs) - Header: Story ID, AC list, prerequisites - Test function per AC + edge/error cases - diff-based validation against expected files (PRIMARY) - Results saved to tests/manual/results/ - Summary table with timing

  1. Make script executable (chmod +x)

Phase 3: Update Documentation

  1. Update tests/manual/README.md:

- Add new test to "Available Test Suites" table - Include Story ID, AC covered, run command

  1. Update tests/manual/test-all.sh:

- Add call to new script in SUITES array - Maintain execution order (00-setup first, then numbered suites)

Phase 4: Execute and report

MANDATORY READ: Load references/test_result_format_v1.md

  1. Rebuild Docker containers (no cache), ensure healthy
  2. Run generated script, capture output
  3. Parse results (pass/fail counts)
  4. Post Linear comment (per test_result_format_v1.md) with:

- AC matrix (pass/fail per AC) - Script path: tests/manual/{NN}-{story-slug}/test-{story-slug}.sh - Rerun command: cd tests/manual &&./{NN}-{story-slug}/test-{story-slug}.sh

Critical Rules

  • Scripts saved to project tests/manual/, NOT temp files.
  • Rebuild Docker before testing; fail if rebuild/run unhealthy.
  • Keep language of Story (EN/RU) in script comments and Linear comment.
  • No fixes or status changes; only evidence and verdict.
  • Script must be idempotent (can rerun anytime).

Runtime Summary Artifact

MANDATORY READ: Load shared/references/test_planning_summary_contract.md, shared/references/test_planning_worker_runtime_contract.md

Runtime profile:

  • family: test-planning-worker
  • worker: ln-522
  • summary kind: test-planning-worker
  • payload fields used by coordinators: worker, status, warnings, manual_result_path

Invocation rules:

  • standalone: omit runId and summaryArtifactPath
  • managed: pass both runId and exact summaryArtifactPath
  • always write the validated summary before terminal outcome

Test scripts always go to tests/manual/, never to the project root.

Monitor Integration (Claude Code 2.1.98+)

MANDATORY READ: Load shared/references/monitor_integration_pattern.md

When running test scripts expected to take >30 seconds: Monitor(command="bash tests/manual/{suite}/test-{slug}.sh 2>&1", timeout_ms=300000, description="manual test: {slug}")

Fallback: if Monitor is unavailable (Bedrock/Vertex), use Bash(run_in_background=true).

Definition of Done

  • tests/manual/ structure exists (config.sh, README.md, test-all.sh, results/ created if missing).
  • tests/manual/results/ added to project .gitignore.
  • Test script created at tests/manual/{NN}-{story-slug}/test-{story-slug}.sh.
  • expected/ folder created with at least 1 expected file per deterministic AC.
  • Script uses diff-based validation against expected files (not heuristics).
  • Script saves results to tests/manual/results/ for debugging.
  • Script is executable and idempotent.
  • README.md updated with new test suite in "Available Test Suites" table.
  • test-all.sh updated with call to new script in SUITES array.
  • App rebuilt and running; tests executed.
  • Verdict and Linear comment posted with script path and rerun command.

Script Templates

README.md (created once per project)

# Manual Testing Scripts

> **SCOPE:** Bash scripts for manual API testing. Complements automated tests with CLI-based workflows.

## Quick Start

cd tests/manual ./00-setup/create-account.sh # (if auth required) ./test-all.sh # Run ALL test suites


## Prerequisites

- Docker containers running (`docker compose ps`)
- jq installed (`apt-get install jq` or `brew install jq`)

## Folder Structure

tests/manual/ ├── config.sh # Shared configuration (BASE_URL, helpers, colors) ├── README.md # This file ├── test-all.sh # Run all test suites ├── 00-setup/ # Account & token setup (if auth required) │ ├── create-account.sh │ └── get-token.sh └── {NN}-{topic}/ # Test suites by Story └── test-{slug}.sh


## Available Test Suites

| Suite | Story | AC Covered | Run Command |
| --- | --- | --- | --- |
| — | — | — | — |

## Adding New Tests

1. Create script in `{NN}-{topic}/test-{slug}.sh`
2. **Update this README** (Available Test Suites table)
3. **Update `test-all.sh`** (add to SUITES array)

test-all.sh (created once per project)

#!/bin/bash
# =============================================================================
# Run all manual test suites
# =============================================================================
set -e
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source "$SCRIPT_DIR/config.sh"

echo "=========================================="
echo "Running ALL Manual Test Suites"
echo "=========================================="

check_jq
check_api

# Setup (if exists)
[ -f "$SCRIPT_DIR/00-setup/create-account.sh" ] && "$SCRIPT_DIR/00-setup/create-account.sh"
[ -f "$SCRIPT_DIR/00-setup/get-token.sh" ] && "$SCRIPT_DIR/00-setup/get-token.sh"

# Test suites (add new suites here)
SUITES=(
    # "01-auth/test-auth-flow.sh"
    # "02-translation/test-translation.sh"
)

PASSED=0; FAILED=0
for suite in "${SUITES[@]}"; do
    echo ""
    echo "=========================================="
    echo "Running: $suite"
    echo "=========================================="
    if "$SCRIPT_DIR/$suite"; then
        ((++PASSED))
        print_status "PASS" "$suite"
    else
        ((++FAILED))
        print_status "FAIL" "$suite"
    fi
done

echo ""
echo "=========================================="
echo "TOTAL: $PASSED suites passed, $FAILED failed"
echo "=========================================="
[ $FAILED -eq 0 ] && exit 0 || exit 1

config.sh (created once per project)

#!/bin/bash
# Shared configuration for manual testing scripts
export BASE_URL="${BASE_URL:-http://localhost:8080}"
export RED='\033[0;31m'
export GREEN='\033[0;32m'
export YELLOW='\033[1;33m'
export NC='\033[0m'

print_status() {
    local status=$1; local message=$2
    case $status in
        "PASS") echo -e "${GREEN}[PASS]${NC} $message" ;;
        "FAIL") echo -e "${RED}[FAIL]${NC} $message" ;;
        "WARN") echo -e "${YELLOW}[WARN]${NC} $message" ;;
        "INFO") echo -e "[INFO] $message" ;;
    esac
}

check_jq() {
    command -v jq &> /dev/null || { echo "Error: jq required"; exit 1; }
}

check_api() {
    local response=$(curl -s -o /dev/null -w "%{http_code}" "$BASE_URL/health" 2>/dev/null)
    if [ "$response" != "200" ]; then
        echo "Error: API not reachable at $BASE_URL"
        exit 1
    fi
    print_status "INFO" "API reachable at $BASE_URL"
}

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
export SCRIPT_DIR

Test Script Templates

See: references/templates/

TemplateUse CaseLocation
template-api-endpoint.shAPI endpoint tests (NO async jobs)template-api-endpoint.sh
template-document-format.shDocument/file processing (WITH async jobs)template-document-format.sh

Quick start:

cp references/templates/template-api-endpoint.sh {NN}-feature/test-{feature}.sh      # Endpoint tests
cp references/templates/template-document-format.sh {NN}-feature/test-{format}.sh    # Document tests

Reference Files

  • Script format reference: prompsit-api tests/manual/ (production example)
  • AC format: shared/templates/test_task_template.md (or local docs/templates/ in target project)
  • Risk-based context: shared/references/risk_based_testing_guide.md
  • Research findings: ln-521-test-researcher creates "## Test Research" comment on Story
  • Puppeteer patterns: references/puppeteer_patterns.md
  • Test result format: references/test_result_format_v1.md

Version: 1.0.0 Last Updated: 2026-01-15

平台分布

Codex

32.38%
按下载量换算720

Claude

30.29%
按下载量换算674

Cursor

18.62%
按下载量换算414

Gemini CLI

9.76%
按下载量换算217

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

操作浏览器

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

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills