skills.rest
dotCMS
dotCMSOFFICIAL
Explore all skills by this author →
WebsiteGitHub

dot-test-plan

Generates manual post-merge QA test plans for merged dotCMS pull requests.

950|482|Updated Mar 15, 2012
Search Tags:#QA#regression#test plan#dotcms#gitHub#post-merge#Pull request
One-click install
npx skills add https://github.com/dotCMS/core --skill dot-test-plan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dot-test-plan
Source: https://github.com/dotCMS/core/tree/main/.claude/skills/dot-test-plan
Command: npx skills add https://github.com/dotCMS/core --skill dot-test-plan

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

After a dotCMS pull request merges, someone still has to verify the fix by hand against the build that contains it. This Skill removes the blank-page work of writing that verification plan: it reconstructs the issue and PR context, consolidates every issue the PR fixed into one plan, and produces numbered manual test cases with reproducible steps and observable expected results.

Core Features & Use Cases

  • Multi-issue consolidation: Derives the full issue set from the branch name, the PR description, and GitHub Development links, then emits one plan posted verbatim to every related issue.
  • Structured test cases: Maps acceptance criteria and a nine-axis coverage matrix (permissions, sites, languages, cache, workflow, push publish, UI/UX, and more) to TC-### cases with risk, scenario, self-contained steps, and expected results.
  • Interactive or unattended CI runs: Asks clarifying questions when a human is present, or applies documented defaults and always emits a complete plan when running in a GitHub Actions workflow.
  • Plan revisioning: Finds the previous plan by its comment marker, preserves still-relevant cases, adapts affected ones, and resets all results to Not Run Yet for the new execution pass.
  • Use Case: A backend PR fixing two permission issues merges; the post-merge workflow invokes the Skill, which posts an identical test plan comment to both issues, ready for a reviewer to approve and an independent executor to run.

Quick Start

Ask the assistant to generate the post-merge QA test plan for a specific merged dotCMS pull request by number, for example by requesting a QA plan for PR #12345.

Frequently Asked Questions about dot-test-plan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a QA test plan for a merged pull request?▼

Invoke the Skill with the merged PR number, for example by asking for a post-merge test plan for PR #12345. It reads the PR diff, linked issues, and acceptance criteria, then produces numbered manual test cases with steps and expected results.

How does the test plan handle a PR that fixes multiple issues?▼

It consolidates all fixed issues into one plan rather than one plan per issue. The issue set comes from the branch name, the PR description's fix statement, and GitHub Development links, and the identical plan is posted to every related issue.

Can this run unattended in a GitHub Actions workflow?▼

Yes. When triggered with EXECUTION: automated or in a CI environment, it never asks questions, applies documented defaults for ambiguities, and always posts a complete plan comment to every related issue using the GitHub CLI.

Does the test plan generator execute or automate the tests?▼

No. Every case it writes is manual and starts as Not Run Yet. It never runs tests, records results, assigns an executor, or approves a plan; those are reserved for the human Plan Reviewer and Test Executor.

What happens when a later PR touches the same issue?▼

The Skill finds the previous plan by its comment marker, preserves cases that still apply, adapts or replaces cases the new PR affects, drops obsolete ones, and resets every result to Not Run Yet as a new revision comment.

What are the limitations of the generated test plan?▼

It only inspects the merged PR's diff, not broader main-branch test coverage, and it deliberately avoids recommending automation. Cases are grounded in the diff, so anything not visible there is marked as an assumption for the reviewer.

Related Skills

Explore More Software Engineering Skills→
DayMoonDevelopmentDayMoonDevelopment
68

pull-request

Create a pull request for a monorepo sibling and link it to a Linear issue.

Official
Advanced
foomakersfoomakers
6

execute-manual-tests

Execute manual test suites against released artifacts and generate PASS/FAIL reports.

Official
Advanced
s0613s0613
1

sj-ship

Automates release workflows for Node.js, Python, or Go feature branches.

Community
Advanced
InteligentsensingsolutionsInteligentsensingsolutions
1

e2e-testing

Validate end-to-end user workflows through the UI with Playwright.

Official
Intermediate