assistant-skills/pov-doc/SKILL.md

name	description	version
pov-doc	This skill should be used when the user asks to "write a POV doc," "create a proof of value document," "POV criteria," "proof of concept criteria," "generate a POC document," or discusses creating a proof-of-value or proof-of-concept document for a Verkada customer evaluation. Generates a customer-facing POC/POV criteria document for Verkada physical security product evaluations.	1.1.0

POV Doc

Generate a proof-of-value (POV) / proof-of-concept (POC) criteria document for a Verkada customer. This document is shared with the customer to formalize the scope, success criteria, and schedule of a product evaluation.

Information Gathering

Before generating the document, gather the following from the user's notes and conversation:

1. Customer name and any relevant context (industry, size, location)
2. Which Verkada products are in scope for the POC (cameras, access control, visitor management, alarms, Command Connector, etc.)
3. Business challenge the customer faces with their current physical security setup
4. Key stakeholders (names, titles, organizations)
5. POC timeline (discovery date, install date, review dates, etc.)
6. Success criteria specific to this customer
7. Integration requirements (Azure AD, POS, third-party cameras, etc.)
8. What the customer will provide (badges, infrastructure, network, etc.)

Search ~/notes for account notes, meeting notes, and inbox items related to the customer to populate these fields. Use ripgrep to find relevant content across all note files.

Logo and Mission Statement

In addition to the fields above, gather these for the document header:

Customer logo: Search the web for the customer's official logo. Prefer high-resolution PNG files (at least 1000px wide). Good sources include the customer's website, Wikipedia/Wikimedia Commons, and official brand asset portals. Download the logo to a temporary location (e.g., /tmp/). If no high-res version is available, download what you can find and upscale it 4x using Pillow.

Customer mission statement: Search the web for the customer's official mission statement. Prefer the most recent version from their website or official publications (district improvement plans, annual reports, etc.). If the customer has both a mission and vision statement, use the mission statement.

Leave both as placeholders in the markdown (<!-- Image goes here: ... --> and *"..."*). The rendering step below will inject them into the final document.

Document Generation and Rendering

Step 1: Generate Markdown

Follow the Document Structure section below to write the markdown document.

Step 2: Render to .odt

After generating the markdown, render it to a formatted .odt file using the bundled scripts/render_poc.py script:

python3 skills/pov-doc/scripts/render_poc.py \
  --input "path/to/[Customer Name] POC Criteria.md" \
  --customer-logo /tmp/customer-logo.png \
  --mission "Customer mission statement here" \
  --output "path/to/[Customer Name] POC Criteria.odt"

The script does the following:

1. Replaces logo HTML comments with the actual customer logo and Verkada logo images
2. Updates the mission statement if --mission is provided
3. Converts the markdown to .odt using pandoc with the clean reference template (examples/POC Reference Template.odt)

The reference template carries over professional formatting (fonts, heading sizes, table styles, page margins) from the City of El Paso example without any customer-specific content.

Dependencies: pandoc (on PATH), Pillow (for logo resizing).

Document Structure

The output document must follow this structure. Each section is required unless the user explicitly says it does not apply.

Header

• Document title: # **Verkada Proof of Concept Criteria**
• Customer logo placeholder: <!-- Image goes here: [Customer Name] logo -->
• Verkada logo placeholder: <!-- Image goes here: Verkada logo -->
• Customer mission statement (if known), formatted as a blockquote: *"MISSION STATEMENT HERE"*
• Table of contents with anchor links to each numbered section

1. POC Goals and Overview

• Document Purpose - Standard boilerplate: "The document will serve as the agreement between Verkada and [Customer] as to the scope and measures of success for a proof of concept engagement to demonstrate and document the proposed physical security solution."
• Business Challenge - Summarize the customer's current pain points with their existing security infrastructure. Be specific, not generic.
• Objective - List the specific objectives of this POC. Use this opening: "Verkada will be working with [Customer] in conducting a Proof-of-Concept (POC) to demonstrate the capabilities of the Verkada Physical Security platform." Then list objectives as bullet points.

2. POC Site Design

• Describe the physical deployment plan: what doors, cameras, or locations are included
• Note any special configurations (identity sync, card format, badge compatibility, etc.)
• Reference specific Verkada product pages where appropriate (link to verkada.com product URLs)

3. Scope

Two subsections:

• Verkada will provide the following: List hardware and services by product category (Video Security, Access Control, etc.)
• [Customer] will provide the following: List what the customer is responsible for (badges, infrastructure, network, personnel)
• Optional: Discussion Items for integrations or features being evaluated but not formally in scope

4. Success Criteria

Group criteria into themed subsections with bold headings. Each criterion should be a clear, measurable statement the customer can evaluate. Common themes include:

• Unified/Scalable Platform
• AI Capabilities & Advanced Features
• Integration Capabilities (list specific third-party integrations)
• Simplified Management / Bulk Operations
• Identity Management Integration
• Hardware Compatibility
• Proactive Maintenance & Updates
• Reduction in Maintenance Costs
• Scalability Without Added Complexity

Tailor these to the customer's stated business challenge. Do not include criteria that are irrelevant to the products in scope.

5. Stakeholders

A markdown table with columns: Name, Title/Role, Organization. Populate with all known stakeholders from the account notes.

6. POC Schedule

A markdown table with columns: Activity, Start Date, End Date (optional), Required Personnel. Standard activities include: Discovery, Site Walk, Installation, Configuration, Admin Scenarios Review(s), Success Criteria Review, Executive Review, Obtain Executive Approval. Use [TBD] for dates and personnel that are not yet confirmed.

7. Next Steps

Numbered list of concrete next actions. Include any steps that have already been completed with a "(Completed)" notation.

Style Notes

• Keep verbiage general and boardroom-appropriate. Avoid colloquial phrases.
• Do not use exaggerated adjectives. Keep problem statements curt and factual.
• Do not surround words with quotation marks for emphasis.
• Use bold formatting sparingly: only for section sub-headings and table headers, not for emphasis within body text.
• Do not use em-dashes; use commas, colons, or parentheses instead.
• The document should read like a formal agreement between two organizations, not an internal memo.

Formatting Requirements

• Output valid GitHub-flavored markdown.
• Use ## for top-level sections within the document (numbered sections 1-7).
• Use bold with asterisks only for sub-headings within sections and table headers.
• Use markdown tables for Stakeholders and POC Schedule.
• Include <!-- Image goes here: description --> comments as placeholders for logos and diagrams.
• Do not include horizontal rules between sections.
• Do not wrap the output in a code block; output raw markdown.

Examples

Example documents are provided in the examples/ folder:

• examples/City of El Paso POC Criteria.md - A completed POV document for a municipal access control evaluation
• examples/Proof of Concept Criteria - TEMPLATE.md - A template-style POV document for a retail environment
• examples/POC Reference Template.odt - Clean ODT reference template for pandoc rendering (styles only, no customer content)

Review the markdown examples to match tone, structure, and formatting conventions. The El Paso example shows how to write a finalized document with specific details filled in. The template example shows the structure with placeholder content for a broader product evaluation.

Output

Write the generated markdown document to ~/notes/Inbox/ with the filename format [Customer Name] POC Criteria.md.

After rendering, the .odt file should be placed alongside the markdown or in the same location the user specifies.