Performs a thorough, repo-aware SWOT analysis of a software project by systematically reading all documentation, source code, architecture, dependencies, and git history before producing a structured strategic report. Invoke this skill whenever the user mentions "SWOT", "SWOT分析", "強み弱み", "強み・弱み・機会・脅威", "戦略分析", "ビジネス分析", "プロジェクト分析", "競合分析", "project analysis", "strategic analysis", or asks to understand the competitive positioning, health, or strategic direction of a project. Always invoke even if SWOT is mentioned briefly — this skill transforms a casual request into a deep, evidence-based strategic assessment grounded in the actual codebase.
Performs a thorough, repo-aware SWOT analysis of a software project by systematically reading all documentation, source code, architecture, dependencies, and git history before producing a structured strategic report. Invoke this skill whenever the user mentions "SWOT", "SWOT分析", "強み弱み", "強み・弱み・機会・脅威", "戦略分析", "ビジネス分析", "プロジェクト分析", "競合分析", "project analysis", "strategic analysis", or asks to understand the competitive positioning, health, or strategic direction of a project. Always invoke even if SWOT is mentioned briefly — this skill transforms a casual request into a deep, evidence-based strategic assessment grounded in the actual codebase.
SWOT Analysis Skill
This skill guides you through a rigorous, repo-grounded SWOT analysis. The goal is not a
surface-level four-box grid — it's a strategic intelligence report built from evidence
found in the repository itself, combined with contextual factors the user provides.
The output is always in Japanese (per project conventions), with actionable cross-SWOT
strategies that a product owner or engineering lead can act on immediately.
Read references/swot-framework.md for the theoretical underpinning if you need to refresh
on the SWOT methodology. Read references/software-dimensions.md for the full list of
analysis dimensions specific to software projects. Read references/report-template.md for
the exact output structure to produce.
Phase 1: Reconnaissance — Know the Project Before You Analyze It
Before touching the SWOT framework, you need enough context to make the analysis meaningful.
A SWOT built on incomplete information will produce generic, unhelpful output.
1-1. Clarify the Analysis Scope (ask if unclear)
If the user's request doesn't specify a scope, ask one focused question before starting:
分析対象と目的を確認させてください：
対象: リポジトリ全体 / 特定のサービス・モジュール / プロダクトのビジネス面
目的: 新機能開発の意思決定 / 投資家へのピッチ / 技術的負債の棚卸し / その他
比較対象: 競合プロダクトや代替技術はありますか？
If the user has already provided context, skip directly to 1-2.
1-2. Repository Reconnaissance Checklist
Work through these systematically. Read every file listed — don't skim:
Internal factors are things the project team controls. Evaluate each dimension honestly —
pretending weaknesses don't exist produces a useless analysis.
For each strength and weakness, note specific evidence from the codebase
(file name, pattern observed, metric).
Strength Dimensions to Evaluate
Architecture quality: Is the codebase well-structured? Clear separation of concerns?
Patterns that suggest deliberate design decisions?
Technology choices: Is the tech stack modern, well-supported, and well-matched to the
problem? Is it a competitive advantage?
Test coverage: Are there meaningful tests? Do they cover critical paths?
Documentation: Is the system well-documented? Can a new contributor onboard quickly?
Performance design: Evidence of performance-conscious design (caching, async, efficient
data structures)?
External factors are things outside the team's direct control. These come from the business
context provided by the user, the docs, and your knowledge of the technology landscape.
Opportunity Dimensions to Evaluate
Market trends: Is the problem this project solves growing in importance?
Technology tailwinds: Are the chosen technologies gaining adoption or ecosystem support?
Integration opportunities: Can this project leverage new APIs, services, or standards?
Community growth: Opportunity to grow contributors or users?
Regulatory / compliance advantages: Does this project position well for new regulations?
Partnership potential: Could strategic integrations amplify value?
Underserved needs: Are there adjacent use cases the project could expand into?
AI/automation opportunities: Can new AI capabilities enhance the project significantly?
Threat Dimensions to Evaluate
Competitive threats: Are there well-funded competitors or substitutes?
Technology obsolescence: Are core dependencies nearing end-of-life? Framework churn?
Security vulnerabilities: Known CVEs in dependencies? Architectural patterns that are
becoming security liabilities?
Talent/maintenance risk: Is key knowledge concentrated in one person who might leave?
Regulatory threats: Could new laws or regulations create compliance burdens?
Ecosystem abandonment: Is the community around key dependencies shrinking?
Market shifts: Could the problem this project solves become irrelevant?
Scalability walls: Could the current architecture become a hard limit on growth?
This is the most valuable phase — where evidence becomes strategy.
Create a 2×2 matrix and derive concrete strategies from each quadrant:
機会 (Opportunities)
脅威 (Threats)
強み (Strengths)
積極戦略 (S×O): 強みを活かして機会を最大化
差別化・防守戦略 (S×T): 強みで脅威を回避・無効化
弱み (Weaknesses)
改善・成長戦略 (W×O): 弱みを克服して機会を獲得
撤退・縮小・リスク最小化戦略 (W×T): 最優先で対処すべき危険地帯
For each quadrant, produce 2-4 specific, actionable strategies — not general principles.
Each strategy should reference specific evidence from Phase 2 and 3.
