---
name: tech-pov
description: "Give a decisive, project-grounded verdict on whether to adopt, switch to, or revisit a technology, library, pattern, or platform. Judged against THIS project, not in the abstract. Use for technology adoption decisions."
version: 1.0.0
author: Hermes Agent (merged from Every Inc compound-engineering ce-pov)
license: MIT
metadata:
  hermes:
    tags: [decision, evaluation, technology, verdict, compound-engineering]
    related_skills: [brainstorming, plan, compound-learning]
---

# Technology Point of View

Return a decisive, **graded verdict** on something from the outside world — judged against *this project*, not in the abstract.

**The one rule that is the whole moat:** Do not issue a verdict you did not earn against the project's own context. Generic web research already covers "tell me about X". The differentiator is the refusal to answer in the abstract.

## When to Use

- "Should we adopt/switch to/migrate to technology X?"
- "Is it time to revisit our choice of Y?"
- "Does this CVE/deprecation/ecosystem-shift affect us?"
- "Compare X vs what we already use — is it worth switching?"

**Not for:** neutral explainers, generating options (use `ideate`), or scoping what to build (use `brainstorming`).

## The Two Floors

A valid verdict must clear **two absolute floors**:

1. **Project floor** — a concrete verified project fact: a named incumbent + a touchpoint (where does X interact with our code?), or the verified absence of one + where it would fit, or a prior decision about it
2. **External floor** — at least one verified external source (docs, changelog, benchmark, CVE)

Both floors are independent. Strong external evidence never compensates for a thin project leg, and vice versa. Neither conversation claims nor user assertions substitute for grounding.

## The Process

### Phase 0: Frame and Classify

1. **Detect invocation context:**
   - Cold: user asks about adopting/switching to X
   - Warm: mid-session second opinion ("is X relevant to what we're doing?")

2. **Establish the frame** — orient before researching:
   - What is the candidate? (named technology/library/pattern)
   - What is the intent? (adopt / migrate / compare / is-this-our-problem)
   - If ambiguous, ask one clarifying question

3. **Classify reversibility tier:**

| Tier | Description | Examples | Scout Depth |
|---|---|---|---|
| **Tier 1** | Two-way door, trivially reversible | Dependency, lint rule, config | Single grounding pass |
| **Tier 2** | One-way but bounded blast radius | Data store, internal API, in-codebase migration | Full scout fleet |
| **Tier 3** | One-way, high-stakes | Security, legal, public API, irreversible data migration | Deep research + precedent search |

State the tier. Let the user override.

### Phase 1: Ground (dispatch scouts)

Grounding searches code, git, issue tracker, and docs. Dispatch to subagents so the raw search doesn't flood your context.

**For Tier 1** — single combined pass:
- One `delegate_task` for project facts (incumbent, call sites)
- One `delegate_task` for external evidence (docs, benchmarks)

**For Tier 2/3** — full fleet in parallel:

```python
delegate_task(tasks=[
    {
        "goal": "Project grounding: find the named incumbent for [candidate] in this codebase. Find call sites, configuration, and usage patterns. Report: what we currently use, where, and any pain points.",
        "context": "Candidate: [X]. Search the codebase for the current solution and its footprint.",
        "toolsets": ["terminal", "file"]
    },
    {
        "goal": "Precedent scan: search docs/solutions/, ADRs, design docs for prior decisions about [candidate] or its category.",
        "context": "Search for any previous evaluation or decision about [X] or similar technologies.",
        "toolsets": ["file"]
    },
    {
        "goal": "External evidence: research [candidate] — current version, stability, licensing, known issues, migration cost, community health, benchmarks.",
        "context": "Evaluate [X] externally: version, license, issues, migration difficulty, alternatives.",
        "toolsets": ["web"]
    }
])
```

For Tier 3, add: mandatory two-source corroboration on every load-bearing claim.

### Phase 2: Verify Against the Two Floors

Check the grounding:
- **Project floor met?** Is there a verified project fact (incumbent + touchpoint)?
- **External floor met?** Is there at least one verified external source?

If either floor fails → return Hold, not a verdict.

### Phase 3: Emit the Verdict

The verdict is a compact chat block, not a research report. Size it to the tier.

```markdown
## Verdict: [Candidate]

**Grade:** ADOPT | TRIAL | HOLD | REJECT | NOT-OUR-PROBLEM
**Reversibility:** Tier [1/2/3]

### Project Fit
[How does X fit our current stack? What does it replace/augment?]

### Migration Cost
[Effort estimate, risk, blast radius]

### Evidence
- [Verified source 1: what it says]
- [Verified source 2: what it says]

### Conditions
[Any prerequisites, caveats, or concerns]

### Confidence
[High/Medium/Low] — [why]
```

### Grade Definitions

| Grade | Meaning | Next Step |
|---|---|---|
| **ADOPT** | Worth committing to now | → `plan` to scope the adoption |
| **TRIAL** | Promising but unproven for us | → Timeboxed spike via `subagent-driven-development` |
| **HOLD** | Not now, revisit later | → No action, document the decision |
| **REJECT** | Not worth it for this project | → No action, document why |
| **NOT-OUR-PROBLEM** | External change doesn't affect us | → No action |

### Phase 4: Follow-up

Offer next steps based on the grade:
- **ADOPT, scope clear** → suggest `plan`
- **ADOPT, scope fuzzy** → suggest `brainstorming`
- **TRIAL** → suggest a timeboxed spike
- **HOLD/REJECT/NOT-OUR-PROBLEM** → done, optionally capture via `compound-learning`

For Tier 1 or REJECT: end with a single prose line, no menu.
For Tier 2/3 with actionable grade: offer the computed next step as the first option.

## Pitfalls

- **Don't issue abstract verdicts** — "X is generally good" is useless; "X fits our project because..." is the point
- **Don't skip the project floor** — strong external evidence doesn't compensate for not knowing how X interacts with OUR code
- **Don't over-research Tier 1** — a trivially reversible decision doesn't need a full scout fleet
- **Don't under-research Tier 3** — security/legal/public API decisions need deep diligence
- **Don't present a research report** — lead with the verdict grade, cite evidence, don't paste raw search output

## Integration with Other Skills

- **brainstorming** — routes verdict-shaped questions here (Phase 6.5)
- **plan** — receives ADOPT verdicts to scope the implementation
- **compound-learning** — captures tooling decisions for future reference
- **ideate** — for open-ended "what should we use for X?" (this skill is for bounded choices)

## Hermes Agent Integration

- `delegate_task` — dispatch grounding scouts in parallel
- `search_files` — find incumbents and prior decisions in the codebase
- `read_file` — read existing solutions/ADRs
- `terminal` — git log, dependency analysis
- Web tools — external research (docs, benchmarks, CVEs)

## Remember

```
Two floors: project fact + external source
Grade, don't explain
Size the verdict to the reversibility tier
Lead with the grade, cite evidence
Never issue a verdict you didn't earn against this project
```