Generate audience-specific company tear sheets by pulling live data from S&P Capital IQ via the S&P Global MCP tools and formatting the result as a professional Word document.
Fetches tear-sheet from anthropics/financial-services-plugins and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/tear-sheet
Restart Cursor to activate tear-sheet. Access via /tear-sheet in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Generate audience-specific company tear sheets by pulling live data from S&P Capital IQ via the S&P Global MCP tools and formatting the result as a professional Word document.
Style Configuration
These are sensible defaults. To customize for your firm's brand, modify this section — common changes include swapping the color palette, changing the font (Calibri is standard at many banks), and updating the disclaimer text.
Section headers: 11pt bold (size: 22), Primary color
Body text: 9pt (size: 18)
Table text: 8.5pt (size: 17)
Footer/disclaimer: 7pt italic (size: 14)
Per-template overrides are specified in each reference file's Formatting Notes.
Company Header Banner:
The header is a navy (#1F3864) banner spanning the full page width with company name in white.
Below the banner, key-value pairs MUST be rendered in a two-column borderless table spanning the full page width. Left column: company identifiers (ticker, HQ, founded, employees, sector). Right column: financial identifiers (market cap, EV, stock price, shares outstanding). Each cell contains a bold label and regular-weight value on the same line (e.g., "Market Cap $124.7B"). Do not left-justify all fields in a single column — this wastes horizontal space and looks unprofessional. The two-column spread is the single most important visual signal that distinguishes a professional tear sheet from a default document.
Implementation: Create a 2-column table with borders: none and shading: none on all cells. Set column widths to 50% each. Place left-column fields (ticker, HQ, founded, employees) as separate paragraphs in the left cell. Place right-column fields (market cap, EV, stock price, shares outstanding) in the right cell. Each field is a single paragraph: bold run for the label, regular run for the value.
The specific fields in each column vary by audience — see the reference file's header spec. The principle is always: spread across the page, not clumped left.
Do not use a bordered table for the header key-value block. Bordered tables are reserved for financial data only.
Key metrics in the header (market cap, EV, stock price) should be displayed as inline key-value pairs, not in a separate bordered table.
Section Headers:
Each section header gets a horizontal rule (thin line, #CCCCCC, 0.5pt) directly beneath it to create clean visual separation between sections.
Render the rule as a bottom border on the header paragraph itself — do not insert a separate paragraph element for the rule. A separate paragraph adds its own before/after spacing and causes excessive whitespace below section titles.
Implementation: In docx-js, apply a bottom border to the section header paragraph via paragraph.borders.bottom = { style: BorderStyle.SINGLE, size: 1, color: "CCCCCC" }. Do not use doc.addParagraph() with a separate horizontal rule element. Do not use thematicBreak. The border must be on the heading paragraph itself with 0pt spacing after, so the rule sits tight against the header text.
Spacing: 12pt before the header paragraph, 0pt after the header paragraph, 4pt before the next content element.
Bullet Formatting:
Use a single bullet character (•) for all bulleted content across all tear sheet types. Do not mix •, -, ▸, or numbered lists within or across tear sheets.
Synthesis/analysis bullets (Earnings Highlights, Strategic Fit, Integration Considerations, Conversation Starters): indented block-style formatting with left indent 360 DXA (0.25") and a hanging indent for the bullet character. These should be visually offset from body text — they're interpretive content and should look distinct from data tables and prose paragraphs.
Informational bullets within relationship sections: standard body indent (180 DXA), no hanging indent.
Do not apply left-border accents to any bullet sections. Left-border styling renders inconsistently in docx-js and creates visual artifacts. Use indentation and text size differentiation to distinguish signature sections instead.
Tables (financial data only):
Header row: Table Header Fill (#D6E4F0) with bold dark text
Body rows: alternating white / Table Alternating Fill (#F2F2F2)
Borders: Table Border color (#CCCCCC), thin (BorderStyle.SINGLE, size 1)
Always use ShadingType.CLEAR (never SOLID — SOLID causes black backgrounds)
Layout:
US Letter portrait, 0.75" margins (1080 DXA all sides)
Number formatting:
Currency: USD. Use millions unless company revenue > $50B (then billions, one decimal). Label units in column headers (e.g., "Revenue ($M)"), not in individual cells.
Table cells: plain numbers with commas, no dollar signs. Example: a revenue cell shows "4,916" not "$4,916". The column header carries the unit.
Fiscal years: actual years (FY2022, FY2023, FY2024), never relative labels (FY-2, FY-1).
Negatives: parentheses, e.g., (2.3%)
Percentages: one decimal place
Large numbers: commas as thousands separators
Footer (document footer, not inline):
Place the source attribution and disclaimer in the actual document footer (repeated on every page), not as inline body text at the bottom. The footer is exactly two lines, centered, on every page:
Line 1: "Data: S&P Capital IQ via Kensho | Analysis: AI-generated | [Month Day, Year]"
Line 2: "For informational purposes only. Not investment advice."
Style: 7pt italic, centered, #666666 text color
This footer text must be identical across all tear sheet types for the same company. Do not vary the wording by audience.
This footer is required on every tear sheet, every audience type, every page. Do not omit it.
Component Functions
You MUST use these exact functions to create document elements. Do NOT write custom docx-js styling code. Copy these functions into your generated Node script and call them. The Style Configuration prose above remains as documentation; these functions are the enforcement mechanism.
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
