add pov-doc skill for generating Verkada proof-of-value documents

pov-doc/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: pov-doc
+description: 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.
+version: 1.0.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.
+
+## 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 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
+
+Two 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
+
+Review these 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 Location
+
+Write the generated document to `~/notes/Inbox/` with the filename format `[Customer Name] POC Criteria.md`.