180 lines
7.3 KiB
Markdown
180 lines
7.3 KiB
Markdown
---
|
|
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
|
|
```
|