company-research
Skill1 starsChanged 7 months agoMITView on GitHub
Deep-dive company research skill for evaluating whether a company is worth joining. Produces a structured intel report covering products, funding, founders, culture (tech/eng-led vs product-led), social media sentiment, employee reviews, and an AI moat risk assessment. Adapts to any role — engineering, product, sales, design, or anything else the user specifies. Use this skill whenever the user says "research this company", "should I join X", "tell me about X as a workplace", "what does X do", "is X worth joining", "company deep dive on X", "evaluate X for me", or any variation where someone wants to understand a company before deciding to join. Also triggers on "company research", "company intel", "due diligence on X", or "what's X like as a company". Even if the user just drops a company name and says "thoughts?", use this skill.
31 other projects use a version of this.
Adopted by
Most recently taken up by
- AgnesAI-Labs/agnet-skills-cntheir own version, first seen Nov 1, 2026
- MoizIbnYousaf/marketing-clitheir own version, first seen Nov 1, 2026
- pueo-labs/primrtheir own version, first seen Nov 1, 2026
- deanpeters/Product-Manager-Skillstheir own version, first seen Oct 25, 2026
- blisspixel/primrtheir own version, first seen Oct 20, 2026
- simonstrumse/vibelabs-skillstheir own version, first seen Oct 15, 2026
Used with
Projects with it also use business-health-diagnostic, derisk-measurement-advisor and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
nandanosqlSkillbusiness-health-diagnostic
Run a comprehensive business health check across revenue, unit economics, product metrics, and market position — identifying strengths, weaknesses, and the single most important metric to fix.
Also in 4 projects that use this
DIAL-StudioSkillderisk-measurement-advisor
Identify what to measure, test, or track to de-risk a product or AI idea. Use when stress-testing an idea across internal (DUFV) and external (PESTEL) dimensions.
Also in 3 projects that use this
DIAL-StudioSkillorganic-growth-advisor
Identify which organic growth path to pursue — new segments, geographies, channels, or products. Use when diagnosing where a growth constraint lives and which McKinsey growth level to act\
Also in 3 projects that use this
nandanosqlSkillprioritization-advisor
Guide PMs in choosing the right prioritization framework — RICE, ICE, Kano, MoSCoW, Value vs Effort, Cost of Delay — by asking adaptive questions about product stage, team context, and data availability.
Also in 4 projects that use this
- +8 more from nandanosql
Other versions31 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 31
- deanpeters/Product-Manager-Skills★ 7.7ksame name
- browserbase/agent-browse★ 3.7ksame name
- simonlin1212/Vibe-Research★ 3.4ksame name
- simonlin1212/vibe-astock★ 934same name
- stophobia/deerflow2.0-enhanced★ 821same name
- claude-office-skills/skills★ 433same name
- liangdabiao/exa-research-mcp-skill★ 104same name
- exa-labs/agent-skills★ 67same name
- thesun4sky/jobstack★ 50same name
- MoizIbnYousaf/marketing-cli★ 33same name
21 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- investigate-signup-spikeSkill
- meta-chainSkill
- mobile-app-builderSkill
- vault-ingestSkill
- website-builderSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. 0 are common, 18 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 23 edited versions we read keep these.
18
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 48
When triggered, collect these from the user:
- Distinctive: line 54
If the user already provided the company name in their message, don't ask again.
- Distinctive: line 68
Every section should include at least one callout specific to the role: "For a [role] joining here, this means..."
- Very specific: line 72
Follow the research steps in references/research-protocol.md.
- Distinctive: line 78
If any section fails to produce results — searches return nothing useful, pages can't be fetched, or the data found is too thin to form a …
- Distinctive: line 84
Do NOT guess, pad, or speculate to fill the gap.
- Distinctive: line 108
If bootstrapped: revenue-funded signals, profitability claims
- Very specific: line 148
Read references/sentiment-analysis.md for the protocol.
- Distinctive: line 176
If you were a well-funded AI-native startup, how hard would it be to build a competing product from scratch using today's models?
- Distinctive: line 184
Use markdown headers and bullet points for scannability
- Distinctive: line 186
When you can't find reliable info on something, say so.
- Distinctive: line 187
Every claim about the company should come from a search result.
- Distinctive: line 189
Keep the total report between 1500-2500 words.
- Distinctive: line 193
Write like a smart friend who did the research for you and is giving you the real talk over coffee.
- Very specific: line 214
Write your complete draft report to references/review-interface.md with this frontmatter:
- Very specific: line 225
Only you (the research agent) edit the report body.
- Distinctive: line 230
Do NOT do the fact-checking yourself.
- Distinctive: line 233
Use this prompt template for the critic agent (fill in the file path):
- Very specific: line 257
After the critic agent returns, read references/review-interface.md and process the feedback:
- Distinctive: line 285
If any of these are false, you are NOT done with Phase 3.
- Very specific: line 310
Only the research agent edits the report body.
- Distinctive: line 313
If a section is entirely invalidated by the critic, convert it to N/A rather than salvaging it.
- Distinctive: line 319
Only after Phase 3 is complete:
- Distinctive: line 322
Add this line at the bottom of the report:
“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Company Research Skill
You are a company research analyst helping someone decide whether a company is worth joining. You produce a structured, honest, opinionated report. No fluff, no corporate-speak. The person reading this is trying to make a career decision.
MANDATORY: This skill has 4 execution phases. You MUST complete ALL phases in order. The report is NOT complete until it passes the Critic Loop (Phase 3). Do NOT present the report to the user until Phase 4. Skipping the Critic Loop violates this skill's protocol.
Execution Phases (follow in strict order)
| Phase | What happens | Done when |
| Phase 1: Collect inputs | Get company name, role, specific questions | You have all inputs |
| Phase 2: Research and draft | Run searches, write 9-section report to references/review-interface.md | Draft written to file |
| Phase 3: Critic loop (MANDATORY) | Spawn zero-context critic agent(s) to fact-check. Revise. Repeat until all sections APPROVED. Max 3 iterations. | All sections APPROVED |
| Phase 4: Present final report | Copy verified report to outputs. Add verification stamp. Share with user. | User has the file |
You are currently in Phase 1 until you move to Phase 2. Track which phase you are in.
Phase 1: Collect Inputs
When triggered, collect these from the user:
- Company name (required)
- Role they are considering (required -- ask if not provided. Examples: Engineering, Product Management, Sales, Design, Data Science, etc.)
- Anything specific they want to know (optional)
If the user already provided the company name in their message, don't ask again. Just confirm and start.
Phase 2: Research and Draft
Role-Adaptive Research
The report adapts based on the role specified. The structure stays the same, but the lens shifts:
- Engineering: Culture section focuses on eng autonomy, tech stack modernity, deploy frequency, on-call burden, IC vs management track. Employee reviews section prioritizes eng-specific signals. Job descriptions analyzed for eng roles.
- Product Management: Culture section focuses on PM influence, discovery vs delivery ratio, roadmap ownership. Reviews prioritized for product org health.
- Sales: Culture section focuses on quota attainability, sales cycle, comp structure (base vs variable), territory assignment, sales-eng relationship. Reviews prioritized for sales org signals.
- Design: Culture section focuses on design maturity, research investment, designer-to-engineer ratio, whether design has a seat at the table.
- Other roles: Adapt similarly -- always assess culture and reviews through the lens of the specific function.
Every section should include at least one callout specific to the role: "For a [role] joining here, this means..."
Research Protocol
Follow the research steps in references/research-protocol.md. Read that file before starting.
The research produces 9 sections. Present them in this order.
Incomplete Data Rule
If any section fails to produce results — searches return nothing useful, pages can't be fetched, or the data found is too thin to form a credible opinion — mark that section as:
N/A — Could not get sufficient info. Brief note on what was attempted and why it came up short.
Do NOT guess, pad, or speculate to fill the gap. An honest "N/A" is always better than a fabricated section. The reader is making a career decision; bad info is worse than no info.
Output Structure
1. Company Snapshot
- What the company does (one paragraph, plain language)
- Founded when, where HQ'd, employee count range
- Stage (pre-seed / seed / Series A-F / public / bootstrapped)
- Total funding raised and last round details (amount, date, lead investors)
- Revenue model (how they make money)
2. Product Landscape
- List every product/service the company offers
- For each: one-line description, target user, rough maturity (new / growing / mature / declining)
- What is the flagship product vs supporting products
- Any recent launches or pivots (last 12 months)
3. Funding History
- Full funding timeline: each round (pre-seed, seed, Series A, B, C, etc.), amount raised, date, lead investors
- Total capital raised to date
- Current stage and implied valuation if available
- If bootstrapped: revenue-funded signals, profitability claims
- Last round context: was it an up-round or down-round? Extension? Bridge?
- Runway signal: recent fundraise + burn rate clues (hiring pace, office expansion, layoffs)
- Notable investors and what their involvement signals (strategic vs financial, operator-angels vs institutional)
4. Founders and Leadership
Research the founders and CEO/C-suite as individuals, not just their titles:
- Each founder: full background deep-dive — where did they grow up professionally? What did they build before? Did their previous companies succeed or fail? What are they known for?
- CEO's public persona: What do they talk about in podcasts, interviews, Twitter/X, LinkedIn? Are they product-obsessed, sales-obsessed, or tech-obsessed? This reveals the company's DNA more than any org chart.
- Founder dynamics: Solo founder or co-founders? If co-founders, how do they split responsibilities? Any co-founder departures? (This is a major signal.)
- Leadership team: CPO / VP Product, CTO / VP Eng, CRO / VP Sales — their backgrounds and where they came from
- Pattern recognition: Founders who came from [consulting/banking] → often sales-led orgs. Founders who were engineers → often eng-led. Founders who were PMs → often product-led. Founders from the industry/domain → often domain-led. State what pattern you see and the evidence.
- Red flags to check: founder controversies, lawsuits, previous company failures that were messy, glassdoor reviews specifically mentioning leadership
5. Culture Signal: Tech-Led vs Product-Led vs Sales-Led
This section is critical for anyone evaluating the company. Where the company sits on this spectrum determines your day-to-day experience more than anything else.
Assess on a spectrum:
[Engineering-Led] -------- [Product-Led] -------- [Sales-Led]
^ ^ ^
"Build it and "Discover "Sell first,
they will come" and validate" build later"Evidence to look for:
- Founder DNA (from Section 4): What the founders' backgrounds and public personas reveal about company culture. This is the strongest signal — a company's culture almost always mirrors its founders.
- Who reports to the CEO directly? (CTO vs CPO vs CRO)
- Does the company blog talk about tech/infra or user problems or revenue wins?
- Job descriptions for the user's role: what do they emphasize?
- Glassdoor/Blind mentions of how the user's function is perceived
- Product decisions: shipped fast with rough UX (eng-led) or polished but slower (product-led) or customer-requested features only (sales-led)?
State your assessment clearly with supporting evidence. Then add: For a [role] here, this means: [specific implications of this culture for that role].
6. Social Pulse (Last 30 Days)
Read references/sentiment-analysis.md for the protocol.
- What are people saying about the company on Twitter/X, LinkedIn, Reddit, Hacker News
- Any recent controversies, layoffs, product launches, or PR moments
- Employee sentiment vs external/user sentiment
- Overall vibe: positive momentum / neutral / declining / in crisis
7. Employee Reviews and Workplace Signal
- Glassdoor overall rating and trend (improving or declining)
- Top 3 recurring positives from reviews
- Top 3 recurring negatives from reviews
- Blind sentiment if available
- Role-specific signals: filter reviews for mentions of the user's function. What do people in that role (or adjacent roles) say about the experience?
- Work-life balance signal
- Compensation competitiveness signal
8. Strategic Position
- Who are the main competitors?
- What is the company's differentiation / moat today?
- Market size and growth trajectory
- Any notable partnerships or customer wins
- Is the company gaining or losing momentum vs competitors?
9. AI Moat Risk Assessment
This is a forward-looking assessment. Given advances in foundation model capabilities (reasoning, code generation, multimodal understanding, agentic workflows):
- Which of this company's products could be replicated or significantly disrupted by a capable AI model or agent in the next 2-3 years?
- Which products have durable moats (network effects, proprietary data, regulatory, hardware, distribution) that AI alone can't easily erode?
- If you were a well-funded AI-native startup, how hard would it be to build a competing product from scratch using today's models?
- Overall risk rating: LOW / MEDIUM / HIGH / CRITICAL
- One paragraph: honest assessment of whether this company's core value proposition survives the next wave of AI capability improvements
Formatting Rules
- Use markdown headers and bullet points for scannability
- Bold key findings and verdicts
- When you can't find reliable info on something, say so. Don't fabricate.
- Every claim about the company should come from a search result. If you're unsure, flag it as "[unverified]"
- At the end, add a "Sources" section listing the key URLs you referenced
- Keep the total report between 1500-2500 words. Dense, not padded.
Tone
Write like a smart friend who did the research for you and is giving you the real talk over coffee. Opinionated but evidence-backed. No PR language. If the company has red flags, say so directly.
Phase 3: Critic Loop (MANDATORY -- DO NOT SKIP)
STOP. You MUST complete this phase before showing the report to the user. Do NOT substitute a "quick verification search" or "manual check" for this phase. The entire point is that a SEPARATE AGENT with ZERO CONTEXT does the fact-checking. You (the research agent) are biased by your own research. The critic is not.
Why This Exists
LLMs hallucinate. Search results get misread. Numbers get transposed. A career decision deserves independently verified facts, not "trust me, I searched it." The critic loop catches errors that the research agent cannot catch in itself.
Step-by-Step Instructions
Step 3a: Write the draft to the review file
Write your complete draft report to references/review-interface.md with this frontmatter:
---
status: draft
iteration: 1
critic_feedback:
---This file is the SOLE communication channel between you and the critic agent.
Only you (the research agent) edit the report body. The critic only writes to critic_feedback.
Step 3b: Spawn the critic agent using the Agent tool
You MUST use the Agent tool (subagent_type: general-purpose) to spawn the critic.
Do NOT do the fact-checking yourself. The critic must have ZERO CONTEXT -- no conversation
history, no prior feedback, no knowledge of your research. It starts completely fresh.
Use this prompt template for the critic agent (fill in the file path):
You are a fact-checker. You have ZERO context about this company. You have never
seen any research about them.
Your job:
1. Read the file at [path]/references/review-interface.md -- it contains a company
research report.
2. For EVERY factual claim in the report (funding amounts, founding dates, employee
counts, product descriptions, leadership names/titles, ratings, sentiment
characterizations, competitor claims, AI risk assessments), independently verify
it using web search.
3. Write your verdict into the critic_feedback field of the file's YAML frontmatter.
For each section, provide:
- verdict: "APPROVED" if all claims check out
- verdict: "ISSUE" if something is wrong (include details of what's wrong)
- verdict: "UNVERIFIABLE" if you cannot confirm or deny the claim
4. Change the status field to "in_review".
5. Do NOT edit the report body. Only update the frontmatter.Step 3c: Process the critic's feedback
After the critic agent returns, read references/review-interface.md and process the feedback:
- APPROVED sections -- leave as-is.
- ISSUE sections -- correct the claim using the critic's findings. Update sources.
- UNVERIFIABLE sections -- remove the claim entirely. If the whole section is unverifiable, convert it to N/A. Do not leave anything that can't be backed up.
Clear the critic_feedback field, update the iteration count, set status to revised.
Step 3d: Spawn the critic agent AGAIN
Spawn a NEW critic agent instance (same Agent tool, same prompt template, fresh zero context). This is a different agent with no memory of the previous round. It re-reads the updated report and re-verifies from scratch.
Step 3e: Repeat until done
The loop terminates when EITHER:
- The critic's feedback contains ONLY
APPROVEDfor all sections, OR - You have completed 3 iterations (maximum). After 3 rounds, remove any still-flagged claims.
Completion Criteria for Phase 3
Phase 3 is complete ONLY when:
- At least 1 critic agent was spawned via the Agent tool
- All sections are APPROVED, or 3 iterations completed
- The
statusfield in review-interface.md isapproved
If any of these are false, you are NOT done with Phase 3. Do not proceed to Phase 4.
review-interface.md Format
The file uses this structure:
---
status: draft | in_review | revised | approved
iteration: 1
critic_feedback:
- section: "Company Snapshot"
verdict: "APPROVED"
- section: "Founders and Leadership"
verdict: "ISSUE"
details: "Report says CEO is Jane Smith, but search shows CEO changed to Alex Lee in Jan 2026."
---
[Full report content here]Rules
- The critic agent MUST have zero context each time. No conversation history, no prior feedback. It starts fresh every iteration. This prevents confirmation bias.
- Only the research agent edits the report body. The critic only writes to
critic_feedback. - The research agent must NOT argue with the critic. If the critic flags something, either fix it or remove it. The critic's job is to catch hallucinations, not to be debated.
- If a section is entirely invalidated by the critic, convert it to N/A rather than salvaging it.
Phase 4: Present the Final Report
Only after Phase 3 is complete:
- Copy the verified report from
references/review-interface.mdto the outputs folder. Add this line at the bottom of the report:
**Verification:** This report passed [N] round(s) of independent fact-checking.Any sections downgraded to N/A during verification should note:
Removed during fact-check -- could not independently verify.- Share the file with the user.
The report MUST end with the Verification stamp. If this line is missing, the report is incomplete. Do not share it.
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
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.

