vendor-positioning-report
Create or update independent vendor positioning matrix reports. Use when asked for magic quadrant style vendor comparisons, analyst-style market matrices, provider landscapes, technology shortlists, two-axis vendor charts, sourced scoring models, or PDF, Microsoft Word/DOCX, and Markdown vendor evaluation packages. Produces original, evidence-led reports with source ledgers, transparent scoring, bank/regulatory due diligence, and safeguards against Gartner or other analyst-firm imitation.
What this skill does
# Vendor Positioning Report Create independent, evidence-based vendor evaluation reports with an original two-axis positioning matrix. Treat requests for "magic quadrants" as requests for an **Independent Vendor Positioning Matrix** unless the user proves written permission and legal approval to use Gartner-owned naming or materials. ## Hard Rules - Do not title reports "Magic Quadrant" or imitate Gartner, Forrester, IDC, Everest, ISG, or other analyst-firm trade dress, rankings, labels, report language, or graphics. - Do not summarize, transform, scrape, or reconstruct paywalled analyst reports into a lookalike report. - Use original axes, labels, scoring, visual style, and report structure. - Cite every non-obvious factual claim with source IDs from `data/source_ledger.csv`. - Separate evidence from assessment. Use explicit gaps such as `No public evidence found`, `Vendor confirmation required`, or `Internal SME assessment required`. - Include the independent research disclaimer in every final report, including PDF and Microsoft Word outputs. - For regulated financial-services contexts, include security, resilience, data residency, outsourcing risk, exit, auditability, identity integration, and contractual-control checks. ## Quick Start When starting a new report package, scaffold the repository: ```bash python <skill-dir>/scripts/scaffold_report.py --target . --market "Market name" --as-of-date YYYY-MM-DD --target-format pdf ``` Then work in this order: 1. Read or update `report_config.yaml`. 2. Define the market before selecting vendors. 3. Create inclusion and exclusion criteria before scoring. 4. Build a vendor longlist from public sources and internal input. 5. Research each vendor and populate `data/source_ledger.csv`. 6. Create one factsheet per included vendor in `data/vendor_factsheets/`. 7. Fill `data/scoring_evidence.csv` with cited, dimension-level scoring evidence. 8. Run `scripts/score_vendors.py` to produce `data/scoring_results.csv`. 9. Run `scripts/render_matrix.py` to produce the matrix PNG. Use the default observed-axis viewport for readability; use `--axis-mode full` only when the report needs a fixed 0-100 benchmark view. 10. Confirm or read the target output from `outputs.target_format`: `pdf`, `docx`, or `both`. If the user has not specified a target and the deliverable format matters, ask whether they want PDF, Microsoft Word, or both. 11. Write the report Markdown. For PDF, run `scripts/build_report.py` and `scripts/verify_pdf.py`; if WeasyPrint is unavailable, use `scripts/build_pdf_reportlab.py` as the PDF fallback. For Microsoft Word, run `scripts/build_docx.py` and `scripts/verify_docx.py`. 12. Deliver the selected PDF and/or DOCX target plus Markdown, matrix PNG, source ledger, scoring results, and review checklist. ## References Load only the files needed for the current task: - `references/report_workflow.md`: repository structure, report workflow, deliverables, and quality gates. - `references/source_policy.md`: source tiers, source ledger schema, citation rules, and search patterns. - `references/scoring_model.md`: default axes, dimensions, scoring formula, confidence handling, and CSV schema. - `references/templates.md`: reusable text templates for AGENTS.md, market definition, vendor factsheets, RFI questions, disclaimer, and review checklist. - `references/pdf_style_guide.md`: PDF, Word, and chart style rules that avoid analyst-firm imitation. ## Scripts - `scripts/scaffold_report.py`: create the standard report repository structure and copy helper scripts. - `scripts/score_vendors.py`: compute axis scores from `scoring_evidence.csv` and `methodology/scoring_model.yaml`. - `scripts/render_matrix.py`: render an original two-axis matrix from `scoring_results.csv`. - `scripts/build_report.py`: render Markdown from Jinja templates and optionally write HTML/PDF when dependencies are available. - `scripts/build_pdf_reportlab.py`: build a simpler PDF from rendered Markdown when WeasyPrint or its native dependencies are unavailable. - `scripts/build_docx.py`: build a Microsoft Word `.docx` report from rendered Markdown. - `scripts/verify_pdf.py`: check that a PDF exists, has pages, has extractable text, and can render page PNGs. - `scripts/verify_docx.py`: check that a DOCX exists, is a valid Word package, has document text, and optionally includes images. Use the scripts as accelerators, not as a substitute for judgment. If dependencies are missing, install or adapt them in the report repository and document the verification result. ## Research Workflow Start with the market definition. State buyer problem, mandatory capabilities, excluded adjacent categories, deployment scope, geography, buyer segment, strategic relevance, risk/procurement implications, and research cut-off date. Create a vendor longlist before inclusion decisions. Acceptable sources include official product docs, security pages, release notes, pricing pages, customer stories, cloud marketplaces, certification registries, public filings, standards bodies, reputable technical media, internal inventories, and RFI/RFP responses supplied by the user. For current vendor facts, browse or otherwise verify live sources. Prefer primary sources for capabilities, security, compliance, pricing, release history, and support. Treat vendor-sponsored claims and customer stories as partial evidence, not proof of general performance. Create vendor factsheets with evidence summaries, confidence, assessment, evidence gaps, and due-diligence questions. Never fill missing evidence with plausible claims. ## Scoring And Matrix Use the default model unless the user provides a buyer-specific model. The standard axes are: - `Execution Strength` - `Strategic Direction Fit` Score each dimension from 0 to 5, then apply evidence-strength and recency modifiers. Normalize each axis to 0-100. Keep confidence separate from score so low-evidence vendors are visible without pretending certainty. Do not force an even quadrant distribution. Clustering is acceptable in the underlying scores. For readability, the chart may zoom the X/Y display axes to the observed score range, but the report must disclose that the scores remain normalized to 0-100 and the viewport is zoomed. Use `--axis-mode full` when absolute distance from 0 or 100 is the intended visual message. Use neutral quadrant labels such as `Strategic Leaders`, `Innovation Bets`, `Execution Anchors`, and `Specialist Plays`, or adapt them to the buyer context. ## Report Standards Write the report in plain internal research language. Avoid hype and vendor marketing phrasing unless clearly labeled as a vendor claim. Use absolute dates for time-sensitive statements. Final reports must include: - Executive summary and recommended next actions. - Market definition and inclusion/exclusion criteria. - Matrix and explanation of axes, thresholds, and confidence. - Vendor profiles with evidence, assessment, implication, confidence, and gaps. - Bank or regulated-enterprise due-diligence appendix when relevant. - Methodology appendix with dimensions, weights, and source policy. - Source appendix expanding all source IDs. - Independent research disclaimer. - Human review checklist. Before final delivery, verify the selected target format. For PDF, verify that the PDF renders, tables are legible, and page-render QA artifacts are kept outside `outputs/final`. For Microsoft Word, run structural verification with `scripts/verify_docx.py`; when document rendering tools are available, render the DOCX to page images and inspect the matrix and tables before delivery. In all formats, verify that citations resolve to the ledger and the report does not imply the top-right vendor is automatically the correct choice. Keep `outputs/final` clean for deliverables. If PDF page renders are needed for QA, write them to `outputs/draft/pdf-render-check` via `scripts/verify_pdf.py --render-dir outputs/draft/pdf-render-check`, or run
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.