القائمة
Start here to scout an unfamiliar problem space — research existing solutions, patterns, anti-patterns, constraints, and technical feasibility before committing to an approach.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | feasibility-analysis |
| description | Start here to scout an unfamiliar problem space — research existing solutions, patterns, anti-patterns, constraints, and technical feasibility before committing to an approach. |
| context | fork |
| agent | researcher |
Scout the problem space and map the landscape. Find what already exists, how others solve this, and what could make it hard or impossible. Explore wide before going deep — survey many options, don't tunnel on the first.
Use the codebase, Context7, and web search together. Every claim you make must trace to a source.
Default to WIDE reconnaissance — breadth over depth. Go DEEP on a specific option only when asked. If you've spent more time than the question warrants, stop and report what you have.
A scout report: the landscape, viable options with their trade-offs, the key constraints, open questions, and red flags. Mark your confidence and cite the source for every finding. Say what you couldn't determine rather than guessing.
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.
Start here to ship built-and-tested code to its target safely — release steps, rollout, smoke checks, and rollback.
Start here to settle how a non-trivial change will be built — interfaces, contracts, file-level structure, and trade-offs.
Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
Start here to document what shipped — READMEs, API docs, ADRs, and usage — once a feature lands or an interface changes.
