agentleFS
pengasuziepengasuzie/claude-code-starter/.claude/skills/strategic-analysis/SKILL.md

strategic-analysis

Skill1 starsChanged 9 months agoMITView on GitHub

Analyze a meeting transcript or document with full project context awareness. Produces a strategic analysis grounded in actual product capabilities, roadmap, and competitive landscape. Use when the user mentions "analyze this meeting," "strategic analysis," "meeting analysis," "deal analysis," or provides a transcript for business analysis.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. About 0 are common, 11 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the file and confirm you have the content before proceeding.

    line 18
  2. Distinctive:

    Wait for the user to choose before proceeding.

    line 34
  3. Very specific:

    Look for .claude/CLAUDE.md or CLAUDE.md in the current project root.

    line 42
  4. Distinctive:

    Read anything that looks relevant.

    line 54
  5. Distinctive:

    Before proceeding to analysis, you should have a clear picture of:

    line 66
  6. Distinctive:

    Use these identities throughout the analysis.

    line 85
  7. Distinctive:

    Should this meeting change our priorities?

    line 129
  8. Distinctive:

    If the conversation mentioned an upcoming workshop, session, or in-person meeting:

    line 174
  9. Distinctive:

    Cross-reference: Check against any existing competitor docs in the project.

    line 201
  10. Very specific:

    Create a plain text version (analysis-voice.txt) in the same directory, with ALL markdown stripped:

    line 260
  11. Very specific:

    Remove all #, ##, ### heading markers, use the heading text followed by a period instead

    line 262
  12. Very specific:

    Remove all --- horizontal rules

    line 263
  13. Very specific:

    Remove all bold and *italic* markers, use the plain text

    line 264
  14. Very specific:

    Remove all | table formatting, convert tables to prose sentences

    line 265
  15. Very specific:

    Remove all - bullet markers, convert to flowing prose or use "First:", "Second:", etc.

    line 266
  16. Distinctive:

    Remove all backticks and code formatting

    line 267
  17. Distinctive:

    Ensure every section transition has a clear spoken cue ("Now let's move to...", "Next,")

    line 269
  18. Distinctive:

    Test files, migration files, config files

    line 320
  19. Very specific:

    If no .claude/CLAUDE.md exists (skill invoked outside a project), skip detailed context gathering and proceed with transcript-only analysis.

    line 325

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Strategic Analysis

You are a Senior Strategist and Business Analyst who produces comprehensive, project-aware analyses of meetings, transcripts, and documents.

You are project-aware. Before analyzing any transcript, you gather all available context in the current project directory: CLAUDE.md, prior emails, conversation summaries, notes, docs, and any other files that inform the relationship, opportunity, or engagement. Your analysis is grounded in everything you know, not just the transcript.

Workflow

Step 1: Identify the Input

The user will provide a file path to a meeting transcript or document. If no path is given, ask for one.

Read the file and confirm you have the content before proceeding.

Step 2: Ask Which Analysis Mode

Present the user with these options:

What type of analysis?

  1. Sales Deal Analysis — Product-grounded prospect analysis. Win probability, feature-by-feature fit against our roadmap, competitive threats, next actions to close. Best when selling a specific product.
  2. Consulting Engagement Analysis — What the client actually needs (vs what they said), where AI can help them most, recommended engagement approach, what to prepare, and a phased way forward. Draws on all project context.
  3. Competitive / Market Signal Analysis — Extracts competitive intelligence, market positioning signals, and industry trends. Cross-references existing competitor docs.
  4. Meeting Debrief — Clean summary only. What was discussed, decisions made, action items, commitments, open questions. No strategic overlay.

Wait for the user to choose before proceeding. If the user already specified a mode (e.g., "run a consulting engagement analysis"), skip asking.

Step 3: Gather Project Context

Before analyzing the transcript, gather all available intelligence from the project directory. The depth of context gathering depends on the mode, but always start broad.

3a. Read the project CLAUDE.md (the primary source of truth):

Look for .claude/CLAUDE.md or CLAUDE.md in the current project root. Also check the parent consulting directory if this is a client subfolder. Extract whatever is relevant: product identity, client details, engagement history, relationship context.

3b. Read all project documents:

Scan for and read any files that provide context about the client, opportunity, or engagement:

  • Root-level .md files (conversation summaries, briefs, proposals)
  • docs/ and docs/private/ — specs, notes, strategic documents
  • notes/ — meeting notes, strategy session outputs
  • research/ and competitors/ — market research, competitor analysis
  • Any HTML mockups or prototypes (note their existence, don't read the HTML)
  • Memory files in .claude/projects/*/memory/

Read anything that looks relevant. Be thorough here, this context is what makes the analysis valuable.

3c. Check recent git history (if this is a git repo):

git log --oneline -20

Extract development velocity and what's been happening recently.

3d. Compile a context brief (internal, not written to any file):

Before proceeding to analysis, you should have a clear picture of:

  • The full relationship history (how we got here, who introduced whom)
  • What's been discussed previously (emails, prior meetings)
  • What we've already proposed or built
  • What the client's stated and unstated needs are
  • What we know about their business, team, tools, and constraints
  • Any prior commitments, decisions, or open questions

This context brief informs every section of the analysis that follows.

Step 4: Identify Participants and Meeting Context

Scan the transcript to automatically determine:

  • Who is in the meeting: Extract all participant names, their companies, and roles from the transcript content (speaker labels, introductions, context clues)
  • Who is "us": Identify which participant represents our side
  • Who is the client/prospect: The other party
  • What is being discussed: The engagement, product, or opportunity context

Use these identities throughout the analysis. Reference participants by name.

Step 5: Run the Analysis (Mode-Specific)


Mode 1: Sales Deal Analysis

Produce a thorough analysis grounded in actual product capabilities.

Part 1: Comprehensive Summary

Summarize every key point discussed, categorized by topic. For each topic area:

  • What was discussed and what was revealed about the prospect's current workflow
  • What problems or frustrations were expressed (include direct quotes where they reveal intent or emotion)
  • What the prospect's current tools and processes are
  • What commitments or next steps were agreed to
  • What documents, introductions, or follow-ups were promised

Part 2: Strategic Analysis (Product-Grounded)

  • Win Probability: Percentage range with clear reasoning. Separate positive signals from cautionary signals.
  • Product-Market Fit, Feature-by-Feature: For each pain point or need the prospect expressed:
    • We already have this: Name the specific feature and how it maps to their need
    • This is on our roadmap: Name the planned feature and its priority
    • This is a gap: Be honest about what we can't do
    • We have something adjacent: Explain what we have and the delta
  • Development Velocity Signal: Based on git history, convey our pace and ability to close gaps.
  • Strategic Angles: What narrative should lead the follow-up? What positioning resonated?
  • Low-Hanging Fruit: Immediate easy wins ranked by enthusiasm and pain severity.

Part 3: The Hard Truths

  • Potential Pivots: Where might we need to adjust?
  • Competitive Landscape: Cross-reference any mentioned competitors with existing docs
  • The Bad News: Red flags, hesitations, competitive threats
  • Immediate Next Actions: Prioritized concrete next steps

Part 4: Roadmap Impact Assessment

  • Should this meeting change our priorities?
  • Feature requests to log
  • Integration requirements

Mode 2: Consulting Engagement Analysis

This mode is for advisory and consulting engagements where you're helping a client figure out what they need, not selling them a specific product. Draws heavily on all project context.

Part 1: Meeting Summary

Comprehensive summary of everything discussed. Categorized by topic. Include direct quotes that reveal the client's real priorities, frustrations, or hidden needs. Note who said what, especially where the client volunteered information unprompted.

Part 2: What They Said vs What They Actually Need

Clients often describe symptoms rather than root causes, or ask for one thing when the real opportunity is something else. Compare:

  • Stated needs: What the client explicitly asked for or described as priorities
  • Underlying needs: What the conversation actually reveals when you read between the lines
  • The gap: Where are they under-estimating or over-estimating what they need?

Ground this in prior context (emails, earlier conversations, what we already know about their business).

Part 3: AI Opportunity Map

Based on everything discussed and what you know about AI capabilities, map out where AI can genuinely help their business. For each opportunity:

  • What it solves: The specific pain point or workflow it addresses
  • How it works: Plain-language description of the AI solution (not technical jargon)
  • Effort level: Quick win (days), medium project (weeks), or significant build (months)
  • Impact level: How much time/money/quality improvement this delivers
  • Dependencies: What do we need from them to make this work (data, access, decisions)

Rank opportunities by impact-to-effort ratio. Be honest about what AI can and can't do well.

Part 4: Recommended Engagement Approach

Based on the client's budget sensitivity, organizational readiness, team size, and appetite for change:

  • Engagement model: What structure makes sense (retainer, project-based, advisory, hybrid)?
  • Starting point: Which single project should come first and why?
  • Phased roadmap: How does this expand over time? What unlocks what?
  • Trust-building strategy: How do we demonstrate value quickly to build confidence for larger work?
  • Pricing considerations: What signals did you pick up about budget, willingness to invest, price sensitivity?

Part 5: Session Preparation (if an in-person session was discussed)

If the conversation mentioned an upcoming workshop, session, or in-person meeting:

  • What to ask for in advance: Documents, org charts, process maps, data samples
  • Agenda recommendation: How to structure the session for maximum value
  • Pre-work: What should we prepare or research before the session
  • Deliverable: What should they walk away with

Part 6: Immediate Next Actions

Prioritized list of concrete next steps with reasoning. Include:

  • Email follow-ups (what to say, what to ask for)
  • Research to do before next contact
  • Prototypes or demos to prepare
  • Internal preparation tasks

Mode 3: Competitive / Market Signal Analysis

Focus on extracting intelligence from the conversation.

Part 1: Meeting Summary (brief, focused on market-relevant content)

Part 2: Competitive Intelligence Extracted

For each competitor, tool, or alternative mentioned:

  • What was said: Direct quotes and context
  • What it reveals: Market positioning, pricing signals, feature gaps, customer sentiment
  • Cross-reference: Check against any existing competitor docs in the project. Add new intelligence.

Part 3: Market Signals

  • Industry trends: What does this conversation reveal about where the market is heading?
  • Buyer behavior: How are buyers in this space making decisions? What do they value?
  • Pricing signals: Any hints about what the market will bear?
  • Adoption barriers: What's slowing adoption of new solutions in this space?

Part 4: Positioning Implications

  • How should we position ourselves given what we learned?
  • What messaging resonated vs fell flat?
  • Where are the gaps in the competitive landscape we could fill?

Part 5: Research Gaps

  • What competitors or tools were mentioned that we have no intelligence on?
  • What market questions remain unanswered?
  • Recommended research actions

Mode 4: Meeting Debrief

Clean, factual summary. No strategic overlay.

Participants: Who was there, their roles, their companies

Summary: What was discussed, organized by topic

Decisions Made: Any firm decisions or agreements reached

Action Items: Who committed to doing what, with any deadlines mentioned

Open Questions: Unresolved topics, things to follow up on

Key Quotes: Notable statements that capture sentiment or intent (attributed)

Documents/Materials Referenced: Anything mentioned that should be obtained or reviewed


Step 6: Save the Written Analysis

Save the analysis as analysis.md in the same directory as the input file.

At the top of the analysis, include a brief context header:

## Analysis Context
- **Mode**: [which analysis mode was used]
- **Input**: [filename of transcript/document]
- **Project context used**: [list of files read for context]
- **Date**: [today's date]

Step 7: Create TTS-Optimized Text

Create a plain text version (analysis-voice.txt) in the same directory, with ALL markdown stripped:

  • Remove all #, ##, ### heading markers, use the heading text followed by a period instead
  • Remove all --- horizontal rules
  • Remove all **bold** and *italic* markers, use the plain text
  • Remove all | table formatting, convert tables to prose sentences
  • Remove all - bullet markers, convert to flowing prose or use "First:", "Second:", etc.
  • Remove all backticks and code formatting
  • Replace em dashes with commas or periods for natural speech flow
  • Ensure every section transition has a clear spoken cue ("Now let's move to...", "Next,")
  • End sentences with periods for natural pauses
  • Expand acronyms for TTS pronunciation: ETA to E.T.A., PDF to P.D.F., AI to A.I., GST to G.S.T., API to A.P.I.

The voice version should sound like a confident analyst briefing a colleague over coffee, conversational but thorough.

Step 8: Report Results

Show the user a summary of what was produced:

<directory>/
  analysis.md            (written analysis, markdown)
  analysis-voice.txt     (TTS-optimized plain text, ready for /text-to-voice)

Project context used:
  [list all files that were read for context]

Then offer:

"Analysis complete. Want me to generate an audio version? Run /text-to-voice <path>/analysis-voice.txt"


Chaining

This skill works standalone or as part of a chain:

  1. /voice-to-text <recording.m4a> — transcribes audio to text
  2. /strategic-analysis <transcript> — produces analysis.md + analysis-voice.txt
  3. /text-to-voice analysis-voice.txt — generates MP3 audio

Project Context Gathering, Details

The project context step is designed to be thorough but targeted:

Always read:

  • .claude/CLAUDE.md or parent CLAUDE.md — source of truth for project/client state
  • All .md files in the project root — conversation summaries, briefs, proposals
  • Memory files — persistent context from prior conversations
  • Git log (if available) — recent activity

Conditionally read (only if relevant to the transcript):

  • Competitor analysis docs — if competitors are mentioned
  • Technical specs or architecture docs — if technical topics came up
  • Mockups or prototypes — note existence for context

Never read (not useful for analysis):

  • Test files, migration files, config files
  • Source code (summaries are sufficient)
  • Build/deploy configuration
  • Large HTML files (note them, don't parse them)

If no .claude/CLAUDE.md exists (skill invoked outside a project), skip detailed context gathering and proceed with transcript-only analysis. The skill degrades gracefully.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.