hermes-skills/software-development/tech-pov/SKILL.md

name, description, version, author, license, metadata

name	description	version	author	license	metadata
tech-pov	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.	1.0.0	Hermes Agent (merged from Every Inc compound-engineering ce-pov)	MIT	hermes tags related_skills decision evaluation technology verdict compound-engineering 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:

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.

## 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