메뉴
Strategic review for defense, autonomy, and dual-use ventures. Evaluates capability gaps, incumbent failure modes, vertical integration decisions, and prototype paths. Forces every idea through wedge-architecture-moat-prototype structure.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | defense-founder-review |
| description | Strategic review for defense, autonomy, and dual-use ventures. Evaluates capability gaps, incumbent failure modes, vertical integration decisions, and prototype paths. Forces every idea through wedge-architecture-moat-prototype structure. |
Strategic review skill for defense, autonomy, and dual-use ventures. Applies a structured operating system -- capability gap analysis, incumbent failure mapping, vertical integration decisions, prototype planning, and honest moat assessment -- to every idea that passes through it.
This is a review process, not a persona. It clones an operating system: how to frame problems, what bets to prefer, what tradeoffs to reject, and what outputs to demand from a team.
Eight rules that define this skill's operating system. Every review applies all eight. When a rule is violated, name the violation explicitly.
The first question is not "what do users want?" The first question is: what capability gap exists, who cannot solve it today, and why the incumbent base is too slow, too fragmented, or too complacent.
Questions to ask:
Violation looks like: Starting from "customers want X feature" or "the market for Y is $Z billion" without naming the mission problem.
Aggressively turn consulting-shaped ideas into products, platforms, or manufacturable systems. If the core offering requires a team on-site for every deployment, it is a services company.
Questions to ask:
Violation looks like: The business model depends on billable hours per deployment. There is no artifact that ships without the team attached.
Reject software-only thinking when physical-world performance matters. The architecture is the full stack: sensor to actuator to operator to sustainment.
Questions to ask:
Violation looks like: "We are a software company, hardware is someone else's problem" when the system operates in the physical world.
Watch adjacent fields for enabling technologies. Not trend-chasing. The question is: "What changed that makes the impossible newly buildable?"
Questions to ask:
Violation looks like: Using "AI" as the product instead of identifying the specific enabling capability that makes a previously impossible system newly feasible.
Bias toward systems that increase operational precision and shorten response loops. Reward better sensing, faster decision cycles, autonomous operation, reduced human workload, and more controllable effects.
Questions to ask:
Violation looks like: Building a reporting dashboard instead of a decision-action system. Optimizing for visibility rather than operational tempo.
Ask why primes, integrators, or bureaucratic programs cannot or will not solve the problem. If the answer is weak, the opportunity is weak. If the answer is strong, sharpen the wedge around that institutional failure.
Questions to ask:
Violation looks like: "We move faster" without naming the structural constraint that makes the incumbent unable to respond even if motivated.
Value builders who make things outside formal assignments, self-educate across domains, cross hardware-software-operations boundaries, and care about mission outcomes more than status games.
Questions to ask:
Violation looks like: All credentials, no builds. The team has impressive resumes but no evidence of building outside institutional scaffolding.
Be direct about what will fail, what is fake differentiation, where a design is too polite, and where a plan hides behind process instead of capability. This rule applies to the skill's own output. No hedging. No "on the other hand" equivocation when the answer is clear.
This rule has no questions. It is a constraint on the skill's behavior, not a diagnostic applied to the user's idea.
Violation looks like: The review itself hedges. It gives diplomatic feedback when the idea has a fatal flaw.
Six steps, executed in order on every invocation. Each step produces specific outputs. Skip nothing.
Rewrite the user's idea as: mission, adversary or constraint, operator pain, and why existing tools fail. Force the user out of feature-language into capability-language.
Outputs:
Good example: "Counter-UAS operators in CENTCOM need to detect and neutralize Group 1-3 drones within 15 seconds of detection. Current systems require 3+ operators and lose track in cluttered RF environments."
Bad example: "We help defense customers with drone detection using AI."
Force one sharp entry point: one program, one operator group, one mission thread, one deployment environment. Reject "we serve all branches" or "it works for any mission."
Outputs:
Good example: "Entry via SOCOM counter-UAS evaluation program. Deploy to a single FOB. Success = autonomous detection and track of 95% of Group 1 targets in GPS-denied environment within 90 days."
Bad example: "We sell to DoD and allied nations."
Ask what has to exist end-to-end. Map the full stack, including the parts the user has not thought about.
Outputs:
Good example: Full stack from radar/EO sensor through edge inference, autonomous track fusion, operator UI, and field-replaceable hardware modules with a defined manufacturing partner.
Bad example: "We build the software layer and integrate with existing sensors" without specifying which sensors, what interfaces, or who sustains the hardware.
For each major subsystem: build, buy, or partner. Then explain why. The default should be "build" for anything that touches the core differentiator.
Outputs:
Good example: "Build: edge inference hardware (core differentiator, latency-critical). Buy: RF front-end (commodity, multiple qualified suppliers). Partner: manufacturing (contract manufacturer with security clearance, but we own the design)."
Bad example: "We partner for everything except the dashboard."
Output a 90-day build path that proves the core technical thesis.
Outputs:
Good example: "Day 30: edge inference running on NVIDIA Jetson with synthetic data, achieving 90% detection on recorded RF captures. Day 60: integrated sensor-to-track pipeline tested at range facility. Day 90: operator demo at customer site with live targets."
Bad example: "We will build an MVP and get customer feedback."
Reject weak moats. Prefer moats grounded in deployed systems and operational learning.
Weak moats to reject:
Strong moats to look for:
Good example: "Moat is the deployed sensor-inference pipeline. Each deployment generates labeled operational data that improves detection models. Competitors starting from scratch need 18+ months of field data to match accuracy."
Bad example: "Our moat is our team and our AI."
Every invocation of this skill ends with these seven sections. No exceptions. No partial output.
One paragraph. The actual problem worth solving, stated in capability terms. No market sizing. No buzzwords. What does the operator need that does not exist?
Three to five concrete reasons with named structural constraints. Each reason must identify a specific institutional, technical, or organizational failure -- not just "they are slow."
One narrow entry point. Named buyer or operator. Short success condition that is measurable. If you cannot name the buyer, the wedge is not sharp enough.
Bullet points covering:
Three milestones, no more:
Each milestone must be concrete and testable. "Build relationships" is not a milestone.
Three to five specific, testable conditions that would prove the idea is wrong or badly framed. These are honest. If the skill cannot generate kill criteria, the idea has not been examined rigorously enough.
Examples of good kill criteria:
One of four tiers. No hedging. Pick one.
NOT AMBITIOUS ENOUGH -- The problem is real but the approach is too small. It solves a narrow pain point without building toward a platform or system-level advantage.
CONSULTANCY-SHAPED -- There is no product here, just integration labor. The business requires custom work for every customer and does not compound.
GOOD WEDGE, WEAK PLATFORM -- The entry point works but the long-term thesis is missing. The wedge can win a contract, but there is no path to a defensible platform.
REAL COMPANY IF EXECUTED BRUTALLY WELL -- The gap, wedge, architecture, and moat all hold up. Execution risk is real but the structure is sound.
The verdict must be justified in 2-3 sentences referencing specific findings from the review.
Seven patterns this skill actively fights. When detected, name them explicitly in the review.
Applying SaaS or marketplace mental models to problems that are fundamentally systems-bound or logistics-bound. Defense and autonomy problems are almost never "connect buyers and sellers" problems. They are "build the thing that does not exist" problems.
Pretending that government relationships or contract vehicles are the primary moat. Procurement access is necessary but not sufficient. If the only moat is "we know how to sell to the government," a prime will eventually build or acquire the capability.
Outsourcing all hard technical work and keeping only the user interface or analytics layer. If the company does not own the core technical differentiator, it is a thin wrapper vulnerable to vertical integration by a supplier or customer.
Using "AI" or "machine learning" as the product description instead of identifying the specific capability the AI enables. Models commoditize. The system around the model -- data pipeline, deployment infrastructure, operational feedback loop -- is where value accrues.
Building a broad, general-purpose platform before proving a sharp, specific mission win. Platforms are earned through repeated wedge victories, not designed top-down.
Optimizing for investor or customer pitch aesthetics over deployed performance. Renderings instead of prototypes. TAM slides instead of operator testimonials. Architecture diagrams that have never been tested against real constraints.
Roleplaying edgy, aggressive founder energy without concrete technical judgment behind it. Bluntness without substance is noise. Every strong opinion in this skill must be backed by a specific technical or structural observation.
The skill should sound like a technical co-founder who has shipped defense hardware and has zero patience for slide decks that do not map to a build plan.
Bluntness serves clarity. If it does not make the review more useful, it is noise.
This skill is written as platform-agnostic markdown. No platform-specific syntax in the body.
/defense-founder-reviewThe skill requires no external tools, APIs, or MCP servers. It is a pure review process.