메뉴
Agents should invoke this skill when choosing or evaluating libraries, frameworks, tools, platforms, models, databases, APIs, or architectures for a use case. Produces criteria scoring, ecosystem assessment, and recommendations.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Creates polished self-contained HTML explanation reports for complex, multi-step topics using overview tables, evidence cards, adaptive graphs or diagrams, meaningful SVG/media, and accessible tabs for long pages. Use when the user requests a browser-readable diagnostic report, technical guide, decision analysis, implementation plan, investigation, or research synthesis as HTML.
Agents should invoke this skill to create, migrate, inspect, apply, verify, or roll back versioned PATCH.md v2 lifecycle packages with machine-readable manifests, deterministic plans, drift detection, and transactional safety.
Safely inspect, search, render, edit, diff, validate, and commit Microsoft Word DOCX files with the dedicated docx_* tools. Use for DOCX/DOTX/DOCM/DOTM document work; enforces dry-run-first edits, active-content refusal, preservation checks, and save-as by default.
Agents should invoke this skill for high-stakes or complex research needing multi-source evidence, scientific/technical fact-checking, decision traces, or rigorous verification. Runs deterministic two-phase research with schema/policy validation.
Use when inspecting, reading, rendering, editing, formatting, diffing, or validating local .xlsx and .xlsm Excel workbooks. Provides fail-closed workbook tools with dry-run planning, SHA-256 conflict protection, PNG previews, and byte-identity checks for VBA and other protected OOXML parts. Do not use for CSV-only work or for executing/editing VBA.
Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
| name | tech-deep-dive |
| description | Agents should invoke this skill when choosing or evaluating libraries, frameworks, tools, platforms, models, databases, APIs, or architectures for a use case. Produces criteria scoring, ecosystem assessment, and recommendations. |
Evaluate and compare technologies for specific use cases.
If the requesting agent provides a fixed output contract, keep this evaluation process but deliver the final result in the requested structure instead of the default markdown sections below.
| Depth | When to use | Minimum distinct sources per candidate |
|---|---|---|
| Standard | Typical pick-one or compare-a-few decision | ≥ 3 (e.g. official docs + registry + one independent benchmark or reputable article) |
| Deep | High impact, contentious options, or regulatory/security-sensitive choice | ≥ 8 across docs, issues, benchmarks, adoption signals, and primary references |
If sources fall short, say so explicitly under each candidate and in the recommendation — do not pad with duplicate pages from the same site.
web_search / web_fetch per candidate rather than finishing A completely before starting B.Score each technology on these dimensions (1-5 scale):
| Criterion | What to Assess |
|---|---|
| Fitness for purpose | Does it solve the actual problem? How well? |
| Maturity | Stable releases, battle-tested, production users |
| Ecosystem | Documentation, community, plugins/extensions, examples |
| Maintenance health | Recent commits, release cadence, maintainer count |
| Performance | Benchmarks, known performance characteristics |
| API quality | Ergonomics, type safety, error handling, learning curve |
| Integration | Compatibility with current stack (Rust, TS, Python) |
| License | OSS license compatibility, commercial restrictions |
What exactly are we choosing? What problem does it solve?
**Decision:** Which [category] to use for [purpose] in [project/context]
**Constraints:** [Must support X, must be OSS, must work with Y]
**Current approach:** [What we're doing now, if anything]
For each candidate, produce the block below. Gather evidence in parallel across candidates (see Parallel evaluation), then fill each block before Step 4.
For each candidate:
### [Library Name]
**Version:** X.Y.Z | **License:** MIT | **Stars:** 5.2k | **Last release:** 2026-01-15
**Scores:**
| Criterion | Score | Notes |
|---|---|---|
| Fitness | 4/5 | Covers 90% of use case, missing X |
| Maturity | 5/5 | v3.x, used by [notable projects] |
| Ecosystem | 3/5 | Good docs, small community |
| Maintenance | 4/5 | Monthly releases, 3 maintainers |
| Performance | 4/5 | [benchmark reference] |
| API quality | 5/5 | Excellent types, good error handling |
| Integration | 4/5 | Works with our stack, minor adaptation needed |
| License | 5/5 | MIT, no restrictions |
**Strengths:** [What it does well]
**Weaknesses:** [Where it falls short]
**Risk factors:** [Maintenance, breaking changes, vendor lock-in]
Synthesize parallel streams into one view. Side-by-side comparison table:
| Criterion | Option A | Option B | Option C |
|---|---|---|---|
| Fitness | 4/5 | 3/5 | 5/5 |
| Maturity | 5/5 | 4/5 | 2/5 |
| ... | ... | ... | ... |
| **Total** | **33/40** | **28/40** | **30/40** |
## Recommendation
**Pick: [Option A]**
**Rationale:** [Why this is the best fit given the constraints]
**Trade-offs:** [What we give up by not choosing alternatives]
**Migration path:** [If switching from current approach, what's involved]
**Risk mitigation:** [How to handle the identified risks]
Scout skill — Technology evaluation and comparison · P1 parallel + source floors: 2026-04-10