Token导航 LogoToken导航

Agent Skill · 研究检索

drupal-intent-testing(Drupal 意图测试)

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

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

总安装 188周安装 8GitHub Stars 5下载 66核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/scottfalconer/drupal-intent-testing --skill drupal-intent-testing

这个 Skill 是做什么的

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

该技能用于 UI 驱动的端到端意图验证,模拟人工测试流程进行半随机测试。适用于 UX 验证、集成逻辑检查和回归测试,补充 PHPUnit 单元测试。使用 accessibility tree 定位元素,无需视觉模型即可驱动真实浏览器。安装需从 GitHub 仓库获取,使用前应确认测试环境和浏览器驱动配置。

涉及生产数据时,应使用测试夹具或模拟数据,避免污染真实用户信息。

来源仓库内路径:skills/drupal-intent-testing

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

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

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

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

常见问题

6 条

drupal-intent-testing 怎么安装?

在终端执行 npx skills add https://github.com/scottfalconer/drupal-intent-testing --skill drupal-inten…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

drupal-intent-testing 支持哪些 AI 工具?

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

drupal-intent-testing 需要什么权限?

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

drupal-intent-testing 是免费的吗?

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

drupal-intent-testing 用的人多吗?

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

drupal-intent-testing 安全吗?

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

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

值得选的地方

  • 同时适配 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调用外部服务未明确有提醒
drupal-intent-testing

Drupal 意图测试 · 本页

1885操作浏览器未明确有提醒

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

SKILL.md 原文

Drupal Intent Testing (agent-browser)

This skill is for “does this do what we meant?” testing — the semi-random, UI-first verification you’d do manually, but with an agent driving a real browser.

It is intentionally not a replacement for Drupal’s PHPUnit/Kernel/FunctionalJavascript tests. It complements them by validating UX, integration glue, and end-to-end intent.

Why agent-browser?

  • Works in CLI agents (Claude Code, Codex, Copilot, Cursor…) because it’s a shell tool.
  • Uses the accessibility tree + deterministic element refs, so it doesn’t require a vision model.
  • Still captures real rendering via screenshots for evidence.

Safety note

Exploratory testing can create content, change config, and click destructive buttons.

  • Prefer running against local/dev instances.
  • Use --safety read-only (fuzz mode) unless you explicitly want mutation.

Credentials note: examples use placeholder admin / admin. Do not store real credentials in public artifacts; prefer local overrides or env vars.


Setup

Install agent-browser and download Chromium:

npm install -g agent-browser
agent-browser install

On Linux you may need dependencies:

agent-browser install --with-deps

Core workflow (agent-driven)

  1. Navigate: agent-browser open <url>
  2. Get a snapshot: agent-browser snapshot -i -c --json
  3. Interact using refs (@e1, @e2) or semantic locators (find label, find role)
  4. Re-snapshot after page changes
  5. Capture evidence: agent-browser screenshot <path>

Evidence Pack + checkpoints

This skill treats checkpoints as the unit of evidence. A checkpoint captures:

  • Interactive snapshot (for driving)
  • Screenshot (visual evidence)
  • Console + JS errors
  • Current URL
  • Drupal messages (role=status / role=alert)
  • AI Agents Explorer output (non-interactive text blocks)
  • Optional backend probes (--probe-cmd)

AI Explorer extracts store pre_texts, final_answer, and tool_payload, plus summary metrics:

  • raw_in_final_answer vs raw_in_tool_payload
  • optional label checks via --label-term
  • raw-value regexes via --raw-value-regex

Intent manifest (autonomous loop)

Use an intent manifest to encode what to test and what counts as PASS/FAIL:

issue:
  url: "https://www.drupal.org/node/3551315"
  title: "Enum options should expose UI labels"

environment:
  base_url: "https://canvas-dev.ddev.site:8443"
  login_url: "/user/login"
  admin_user: "admin"
  admin_pass: "admin"
  probe_cwd: "/path/to/project"

adr:
  - "Consumers can reliably map labels to stored values without guessing."
  - "Translation correctness depends on cache context bubbling and serialization boundaries; labels are kept stringable until serialization."
  - "Additional schema warnings are logged in a dedicated channel for troubleshooting malformed enum metadata."

strategy:
  mode: "single"               # single | compare
  between_cmd: "ddev snapshot restore intent-baseline"
  retries: 1
  timeouts:
    page_load_ms: 120000
    ai_response_ms: 600000

steps:
  - open: "/admin/config/ai/agents/explore?agent_id=canvas_page_builder_agent"
  - action:
      type: run_ai_agent_explorer
      prompt_file: "resources/vienna-hero-labels-mini.txt"
      model: "gpt-4.1"
      completion_texts: ["Final Answer", "Ran"]
      run_buttons: ["Run Agent", "Run"]
      post_completion_timeout_ms: 60000
      post_completion_stable_ms: 1500
      pre_min_count: 1
  - checkpoint: "after_run"

assertions:
  - id: "no_raw_values_in_final_answer"
    type: "text_absent"
    scope: "final_answer"
    patterns: ["hg:", "flex-row"]
    severity: "fail"

guards:
  - id: "no_js_errors"
    type: "no_console_errors"
    severity: "fail"

Run it:

python3 -m scripts.intent.validate_manifest path/to/intent.yaml
python3 -m scripts.intent_test path/to/intent.yaml --output-dir test_outputs

Agent runbook: intent verification loop for Drupal.org issues

This is the default operating procedure for contrib fixes/features. If there is no Drupal.org issue, use the provided intent statement instead.

0) Mission statement

Your job is not “make tests pass.” Your job is:

  • Understand user intent (from Drupal.org issue if available)
  • Implement the change
  • Verify like a human in a tight loop:

- Doesn’t error - Actually does the thing the user wanted

  • If you can’t verify confidently, escalate with excellent evidence and a specific question

Default behavior: if the user says “test with drupal-intent-testing” and does not provide a scenario/manifest, you must author the verification artifact yourself from the intent and run it. Do not ask for a script unless you are blocked on missing environment details (base URL, credentials, or success criteria).

1) Inputs you start from

You will be given at least:

  • Drupal.org issue URL (or node id) if available
  • Local dev base URL (DDEV or other), and credentials if needed
  • Repo working tree/branch

2) Pick the right verification mode (decision tree)

Prefer the strongest behavioral proof available (rendered UI, saved config, persisted output) to minimize upstream maintainer burden; avoid tests that only check token presence if a behavioral proof is possible.

A) UI/behavioral issue (click here, see X, config form, node form, rendering):

  • Use Compare mode with a generated scenario script + assertions.

B) AI Agents Explorer output or tool payload shape:

  • Use intent manifest + python -m scripts.intent_test + judge.
  • Checkpoints auto-extract AI Explorer <pre> blocks into final_answer and tool_payload.

C) Unclear, hard to reproduce, or multiple workflows:

  • Do a short guided exploration to learn the UI path, then convert to Compare/Manifest.

D) Light fuzz smoke (optional but recommended):

  • After a likely fix, run seeded fuzz in read-only unless you have snapshot restore.

3) Core loop (bugfix + feature)

Step 1 — Pull “intent” from the issue (if available)

If available, use the drupal-issue-queue skill (https://github.com/scottfalconer/drupal-issue-queue) to extract:

  • Beneficiary persona: site builder, content editor, admin, dev
  • Expected behavior (“success looks like…”)
  • Repro steps (exact UI journey)
  • Edge cases + regression risks

If you do not have the skill installed, summarize the issue manually and proceed.

If there is no Drupal.org issue, use the provided intent statement instead.

Output (required): write a short “Intent statement”:

  • “The user is trying to ___”
  • “Success means ___”
  • “Failure modes to guard against: ___”

If an ADR applies, include its statements in the intent summary and translate each into assertions.

Step 2 — Generate a verification artifact

Option A: Scenario script (Compare mode) — preferred for UI issues Create: scripts/test_scenarios/issue_<nid>.txt

  • Direct route navigation (Drupal admin is URL-addressable)
  • Semantic locators (find label, find role)
  • Checkpoints at key moments
  • Assertions that encode success + regression guards

Option B: Intent manifest — preferred for AI Explorer/tool payload assertions Create: .intent/issue_<nid>.yaml

Minimum required fields:

  • issue.url, issue.title
  • environment.base_url
  • non-empty steps

If there is no Drupal.org issue, use intent_statement instead of issue.*.

If credentials are provided, add environment.admin_user/admin_pass to auto-generate login flow.

If an ADR applies, list it under adr: and map each statement to concrete assertions.

Step 3 — Baseline run

Run verification before code changes to prove the problem exists.

Compare mode:

python3 scripts/compare_runs.py   --url "https://YOUR.ddev.site"   --script "scripts/test_scenarios/issue_<nid>.txt"   --output-dir "test_outputs/issue_<nid>"   --output "comparison_report.json"   --output-md "comparison_report.md"

Manifest compare mode:

  • Use strategy.mode: compare and between_cmd to reset state.

Baseline expectations:

  • Bugfix: baseline should FAIL intent assertions or show the problem clearly.
  • Feature: baseline should show “not present yet.”
  • If you cannot reproduce, escalate.

Step 4 — Implement the change

Make code changes. Run built-in tests as normal.

Step 5 — Modified run

Repeat the exact same verification artifact.

Step 6 — Produce verdict + summary

If using manifest/judge:

  • python -m scripts.intent.validate_manifest validates required keys.
  • python -m scripts.intent_test runs and writes intent_run.json + verdict.
  • judge_intent.py produces ready_to_submit.

Supported judge assertion types:

  • no_console_errors
  • no_drupal_messages (alert/status)
  • url_contains
  • text_absent / text_present (AI Explorer final_answer / tool_payload)
  • yaml_path_equals

If using Compare mode:

  • assert-* results are recorded.
  • Checkpoints provide full evidence packs.

Required summary format:

  • Intent statement (1–3 sentences)
  • What you ran (commands + artifact paths)
  • Baseline outcome
  • Modified outcome
  • Regressions checked (JS errors / Drupal alerts / etc.)
  • Confidence level (high/medium/low) + why

4) How to write good verification artifacts (“like a human”)

  • Prefer direct routes (/admin/config, /node/add/article, etc.)
  • Prefer semantic locators (find label, find role)
  • Always include guardrails:

- No JS errors - No Drupal alerts (role=alert) - Expected status message (role=status) when saving

  • Place checkpoints at decision points:

- after login - after key action - after expected result

5) Escalation protocol

Escalate when:

  • You cannot reproduce baseline
  • Success criteria are ambiguous/subjective
  • Verification results are flaky
  • Environment prevents verification

Template:

ESCALATION: intent verification blocked / uncertain
Issue: <url or “no issue provided”>
Intent (my understanding): …
Verification mode: Compare / Manifest / Explore
Commands run: …
Artifacts: test_outputs/...
Baseline result: PASS/FAIL/ERROR + key evidence
Modified result: PASS/FAIL/ERROR + evidence
Why I’m not confident: …
What I need from you: …

6) Done criteria

Do not mark complete until:

  • You attempted to observe the intended outcome in the UI
  • You verified both:

- no errors (JS + Drupal alerts) - intended behavior occurs (assertion or strong evidence)

  • Prefer the strongest behavioral proof available; increase timeouts when needed instead of failing fast.
  • Bugfixes: baseline failure + modified success (or escalated if unreproducible)
  • You produced attachable artifacts (screenshots + reports + brief narrative)

7) Optional next improvements

  • Rely on assert-* heavily so judge output stays crisp.
  • Add more assertion types as needed.
  • Use default probes (e.g., drush ws) for root-cause context.

If you have a Drupal.org issue (source of intent)

When a specific issue is driving the work, the issue discussion is the intent. Use it to derive your test goals, steps, and expectations before you explore.

Recommended flow (uses the drupal-issue-queue skill; skip if you do not have it installed):

If installed, this command comes from that skill:

# Summarize the issue discussion (acceptance criteria, expected/actual, edge cases).
python scripts/dorg.py issue <nid-or-url> --format md --mode summary --comments 20

Then:

  • Extract intent statements (acceptance criteria, expected behavior, and repro steps).
  • Translate each into scenario steps with expect assertions.
  • Use the scenario as your baseline for Compare or Guided exploration.

Example mapping:

  • Issue: “When adding a context label, it should appear in the Canvas AI sidebar.”
  • Scenario: add label → expect --text "New Label" → screenshot.

Modes

Mode 1 — Watch (guided, human-validating)

Use when you want to visually inspect outcomes (new UI element appears, content looks right).

Suggested pattern:

agent-browser open "https://my.ddev.site/user/login"
agent-browser snapshot -i -c
agent-browser find label "Username" fill "admin"
agent-browser find label "Password" fill "admin"
agent-browser find role button click --name "Log in"
agent-browser wait --load networkidle

agent-browser open "https://my.ddev.site/admin/config/canvas-ai"
agent-browser wait --load networkidle
agent-browser screenshot test_outputs/canvas-ai-config.png

Mode 2 — Compare (paired A/B, semi-deterministic)

Runs the *same script* twice and produces a diff report + artifacts (including console/errors captured at each snapshot).

Useful flags:

  • --trace: capture trace.zip per run
  • --probe-cmd: run backend probes at each checkpoint (repeatable)
  • --probe-cwd: working directory for probe commands
  • --raw-value-regex / --label-term: AI output metrics
python3 scripts/compare_runs.py   --url "https://my.ddev.site"   --script scripts/test_scenarios/canvas_ai_context_label.txt   --output-dir test_outputs   --output comparison_report.json   --output-md comparison_report.md

Strongly recommended: reset DB/state between A and B so your script starts from the same world.

If you use DDEV, you can snapshot/restore:

  • ddev snapshot --name intent-baseline
  • ddev snapshot restore intent-baseline

compare_runs.py supports running an arbitrary “between” shell command and optional evidence probes:

python3 scripts/compare_runs.py   --url "https://my.ddev.site"   --script scripts/test_scenarios/canvas_ai_context_label.txt   --between-cmd "ddev snapshot restore intent-baseline"   --probe-cmd "ddev exec drush ws --count=50 --format=json"   --trace   --output-dir test_outputs

Mode 3 — Explore

3A — Guided mission (LLM-driven)

Best for requests like: “Build a microsite using Canvas and give feedback.”

Recommended loop (the agent does this):

  1. Decide a small next step toward the goal (e.g., “create a landing page”, “add a hero component”).
  2. Run:

- agent-browser snapshot -i -c --json - choose element(s) using refs or find - execute action(s) - agent-browser wait --load networkidle - agent-browser screenshot...

  1. Append observations to test_outputs/mission_log.md
  2. Repeat until timebox ends.
  3. Produce a structured summary: what worked, what was confusing, errors seen, suggestions.
3B — Seeded fuzz/monkey testing (scripted, no LLM required)

Good for: “click around like a distracted user and see what breaks” — for an hour.

python3 scripts/explore.py   --url "https://my.ddev.site"   --duration 60m   --mode fuzz   --seed 1337   --safety dangerous   --checkpoint-every 20   --probe-cmd "ddev exec drush ws --count=50 --format=json"   --output-dir test_outputs   --output exploration_report.md

safety levels:

  • read-only: no “Save/Submit/Apply” clicks; avoids mutation.
  • dangerous: anything goes.

Optional fuzz flags:

  • --checkpoint-every N: capture full evidence every N actions
  • --probe-cmd...: include backend probes at checkpoints
  • --probe-cwd...: working directory for probes (useful for DDEV)

Scenario script format (for Compare)

The compare runner understands a tiny DSL:

  • open /path (prefixes --url)
  • snapshot <name> (saves snapshot JSON to artifacts)
  • checkpoint <name> (full evidence bundle: snapshot + screenshot + console/errors + message extraction)
  • screenshot <file.png>
  • wait <seconds> (numeric)
  • expect … (assert/await; passed to agent-browser wait)
  • assert-present --text "..." / assert-absent --text "..." (basic assertions)
  • assert-no-js-errors / assert-no-drupal-alerts
  • assert-url --contains "/node/123"
  • assert-count --selector ".some-class" --eq 3
  • extract eval <name> <js> / extract text <name> <locator>
  • probe shell <name> -- <command> / probe drush <name> -- <args>
  • Any other line is passed through as a raw agent-browser … command

Best practice: prefer semantic locators (stable) over hard-coded refs. checkpoint is the preferred evidence capture; snapshot remains for legacy scripts.

Example:

open /user/login
wait --load networkidle
find label "Username" fill "admin"
find label "Password" fill "admin"
find role button click --name "Log in"
wait --load networkidle
expect --text "Log out"
screenshot 01_logged_in.png

open /admin/config/canvas-ai
wait --load networkidle
checkpoint config_page
screenshot 02_config_page.png

Drupal patterns

See references/drupal_patterns.md for practical Drupal UI patterns (login, messages, admin routes, CKEditor, AJAX).


Reading results

Artifacts are written under --output-dir (default ./test_outputs/):

  • baseline/ and modified/ subfolders (compare mode)
  • *.png screenshots
  • *.json snapshots (normalized in the report)
  • *.errors.json / *.console.json (captured at snapshot checkpoints)
  • *.drupal_messages.json (status/alert text at checkpoints)
  • *.ai_explorer.json (AI Agents Explorer output + summary metrics)
  • *.probe.N.json (optional backend probes)
  • *.trace.zip (if --trace enabled)
  • comparison_report.json (diff + summary)
  • comparison_report.md (human summary)
  • exploration_report.md (fuzz mode report)
  • intent_run.json / intent_verdict.json (manifest runner outputs)

平台分布

Codex

36.93%
按下载量换算24

Claude

31.88%
按下载量换算21

Cursor

18.08%
按下载量换算12

Gemini CLI

10.77%
按下载量换算7

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

操作浏览器

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

安装前确认

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

继续浏览同类 Skills