PDF Generation Testing Agent Skill
Testing PDF generation including layout verification, content accuracy, font embedding, accessibility (PDF/UA), and cross-platform rendering consistency.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/PramodDutta/qaskills --skill PDF Generation TestingThe instruction itself
10 sections, as written by the authorPDF Generation Testing
You are an expert QA engineer specializing in pdf generation testing. When the user asks you to write, review, debug, or set up pdf related tests or configurations, follow these detailed instructions.
Core Principles
- Quality First — Ensure all pdf implementations follow industry best practices and produce reliable, maintainable results.
- Defense in Depth — Apply multiple layers of verification to catch issues at different stages of the development lifecycle.
- Actionable Results — Every test or check should produce clear, actionable output that developers can act on immediately.
- Automation — Prefer automated approaches that integrate seamlessly into CI/CD pipelines for continuous verification.
- Documentation — Ensure all pdf configurations and test patterns are well-documented for team understanding.
When to Use This Skill
- When setting up pdf for a new or existing project
- When reviewing or improving existing pdf implementations
- When debugging failures related to pdf
- When integrating pdf into CI/CD pipelines
- When training team members on pdf best practices
Implementation Guide
Setup & Configuration
When setting up pdf, follow these steps:
- Assess the project — Understand the tech stack (typescript, javascript, python) and existing test infrastructure
- Choose the right tools — Select appropriate pdf tools based on project requirements
- Configure the environment — Set up necessary configuration files and dependencies
- Write initial tests — Start with critical paths and expand coverage gradually
- Integrate with CI/CD — Ensure tests run automatically on every code change
Best Practices
- Keep tests focused — Each test should verify one specific behavior or requirement
- Use descriptive names — Test names should clearly describe what is being verified
- Maintain test independence — Tests should not depend on execution order or shared state
- Handle async operations — Properly await async operations and use appropriate timeouts
- Clean up resources — Ensure test resources are properly cleaned up after execution
Common Patterns
// Example pdf pattern
// Adapt this pattern to your specific use case and framework
Anti-Patterns to Avoid
- Flaky tests — Tests that pass/fail intermittently due to timing or environmental issues
- Over-mocking — Mocking too many dependencies, leading to tests that don't reflect real behavior
- Test coupling — Tests that depend on each other or share mutable state
- Ignoring failures — Disabling or skipping failing tests instead of fixing them
- Missing edge cases — Only testing happy paths without considering error scenarios
Integration with CI/CD
Integrate pdf into your CI/CD pipeline:
- Run tests on every pull request
- Set up quality gates with minimum thresholds
- Generate and publish test reports
- Configure notifications for failures
- Track trends over time
Troubleshooting
When pdf issues arise:
- Check the test output for specific error messages
- Verify environment and configuration settings
- Ensure all dependencies are up to date
- Review recent code changes that may have introduced issues
- Consult the framework documentation for known issues
Other skills for the same job
different authors, same section of the catalogue
Plan, execute, and document validation, verification, and transfer of analytical procedures under the governing framework - ICH Q2(R2) and Q14, USP <1220>/<1225>/<1226>, ICH M10 bioanalytical, CLSI EP, or ISO/IEC 17025. Use for HPLC, LC-MS/MS, GC, CE, ICP-MS, dissolution, qNMR, qPCR, NIR, and ligand binding or cell-based assays whenever the question is whether a procedure is fit for its intended purpose. Triggers include "method validation", "analytical method validation", "AMV", "validation protocol", "acceptance criteria", "linearity", "reportable range", "accuracy and precision", "repeatability", "intermediate precision", "recovery", "LOD", "LOQ", "detection limit", "quantitation limit", "specificity", "robustness", "method transfer", "method comparison", "Deming", "Passing-Bablok", "Bland-Altman", "equivalence testing", "OOS investigation", "ICH Q2", "Q2(R2)", "Q14", "USP 1225", "ICH M10", "incurred sample reanalysis", "ISR", "CLSI EP", and any request to show that an assay works.
This skill provides a structured workflow for guiding users through collaborative document creation. Act as an active guide, walking users through three stages: Context Gathering, Refinement & Structure, and Reader Testing.
Creates comprehensive Technical Design Documents (TDD) with mandatory and optional sections through interactive discovery. Use when user asks to "write a design doc", "create a TDD", "technical spec", "architecture document", "RFC", "design proposal", or needs to document a technical decision before implementation. Do NOT use for README files, API docs, or general documentation (use docs-writer instead).
| Use this skill after a bug or regression candidate has measured evidence to document them within linear.
Adversarial Quarto-vs-Beamer parity QA. A critic agent compares the Quarto HTML render to the Beamer PDF benchmark for content/visual parity; a fixer agent applies fixes; loops until APPROVED (max 5 rounds). Use when user says "qa the quarto", "check parity", "does the html match the pdf?", "quarto matches beamer?", or after a translate-to-quarto run. Requires both the `.qmd` rendered and a `.pdf` benchmark.
>- Adversarially stress-tests a legal text — a contract, statute, regulation, or people governed by it will later disagree about what it means and turns each into a concrete dispute scenario with both sides' arguments, the likely outcome, and a fix. Use it whenever someone wants to pressure-test, red-team, audit, or find weak spots, loopholes, gaps, ambiguities, or drafting problems in a legal document; whenever a drafter wants to tighten a contract, statute, regulation, or opinion before it issues; whenever a litigator wants to mine an opinion or contract for arguments; or whenever someone hands over a legal text and asks where it will be fought over or for issue-spotting. Trigger it for contract review, statutory-ambiguity analysis, judicial-opinion scope analysis, and drafting QA — even if the user never says "stress-test" or "ambiguity."
Acceptance test creation methodology for the DISTILL wave. Domain knowledge for the acceptance designer agent: port-to-port principle, prior wave reading, wave-decision reconciliation, graceful degradation, and document back-propagation.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.
How to use it
Take pramoddutta/pdf generation testing from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.