Purpose
Produce a single, publication-ready Technology Radar entry that assigns a defensible ring placement (Adopt / Trial / Assess / Hold) to a specific tool or framework and backs it with structured evidence — so engineering leadership can make and defend horizon-scanning decisions instead of relying on hype or gut feel.
When to Use
Invoke this skill when the user asks to:
- Add a tool, framework, platform, language, or technique to a technology radar
- Decide whether to adopt, trial, assess, or hold a specific technology
- Justify or defend a ring placement for an internal radar review
- Run horizon scanning on an emerging technology for engineering leadership
- Compare a new technology against an incumbent already in production
- Produce a standardized writeup for a quarterly radar or architecture review
Inputs Required
Before starting, collect:
- Technology name: The exact tool, framework, platform, language, or technique
- Quadrant: Techniques / Tools / Platforms / Languages & Frameworks (if unsure, infer and state the choice)
- Use case under consideration: The specific problem or workload this would address
- Current incumbent: What it would replace or sit alongside, if anything
- Org context: Team size, tech stack maturity, risk tolerance (conservative / balanced / aggressive)
- Adoption status: Whether anyone internally has piloted it, and to what extent
- Constraints: Compliance, vendor lock-in concerns, hiring pool, budget, or timeline factors
If quadrant, incumbent, or adoption status is missing, infer reasonable values and flag the assumption explicitly in the entry.
Instructions
Step 1: Classify the Quadrant
Place the technology in exactly one quadrant and state why:
- Techniques: Practices, processes, ways of working (e.g., trunk-based development, contract testing)
- Tools: Components with a focused job (e.g., a CLI, a testing library, a build tool)
- Platforms: Things you build on top of (e.g., a database, a cloud service, a runtime)
- Languages & Frameworks: Languages and the frameworks around them
If a technology could span quadrants, choose the dominant use and note the alternative.
Step 2: Gather and Structure Evidence
Assemble evidence across five dimensions. For each, mark confidence as High / Medium / Low based on available signal:
- Maturity: Version stability, release cadence, breaking-change history, backward-compat track record
- Community & ecosystem: Adoption breadth, maintainer health, library/plugin availability, hiring pool
- Production fitness: Known production deployments at scale, operability, observability, failure modes
- Strategic fit: Alignment with the org's existing stack, skills, and direction
- Risk profile: Vendor lock-in, license terms, security posture, single-maintainer or single-vendor dependency
Where evidence is thin, say so — do not manufacture certainty.
Step 3: Assign the Ring with a Decision Rule
Apply this rule set and pick exactly one ring:
- Adopt: Proven in production for this org's context; the team should default to it for new work. Requires High maturity, High production fitness, and clear strategic fit.
- Trial: Worth pursuing on a real project that can absorb risk. Requires evidence it works, but not yet org-proven. Define the bounded pilot.
- Assess: Worth understanding and tracking; not yet ready for project commitment. Use when promise is high but evidence is early or context fit is unproven.
- Hold: Proceed with caution or avoid for new work. Use for declining tech, high lock-in with weak upside, or maturity/security concerns — even if popular.
State the single most important factor that drove the ring choice.
Step 4: Position Against the Incumbent
If an incumbent exists, give a direct head-to-head:
- What this technology does better
- What the incumbent still does better
- The migration or coexistence cost
- A clear verdict: replace, complement, or not worth switching
Step 5: Define the Recommended Next Move
Tie the next action to the ring:
- Adopt → rollout scope and the guardrails to set
- Trial → the specific bounded pilot, success metric, and timebox
- Assess → what signal to watch for and a re-evaluation date
- Hold → what conditions would move it off Hold
Step 6: Write the Radar Blurb
Produce a 90–140 word standalone blurb in ThoughtWorks Radar voice — opinionated, specific, written for a technical peer who hasn't read the rest of the entry. It must name the ring and the core reason in the first two sentences.
Output Format
- Structure: A single radar entry with a labeled header (name, quadrant, ring, confidence) followed by named sections
- Length: 650–900 words
- Format: Structured document — header block, an evidence table (5 dimensions × signal + confidence), and prose sections
- Sections: Header block → Quadrant rationale → Evidence table → Ring assignment & decision factor → Incumbent comparison → Recommended next move → Radar blurb
- Tone: ThoughtWorks Radar voice — opinionated, evidence-anchored, peer-to-peer technical, no hedging once the ring is chosen
Quality Checklist
Before delivering output, verify:
- [ ] Exactly one quadrant and exactly one ring are assigned — no straddling
- [ ] The evidence table covers all five dimensions, each with a confidence label
- [ ] The single most important factor driving the ring is named explicitly
- [ ] Incumbent comparison ends with a clear verdict (replace / complement / don't switch) or states no incumbent exists
- [ ] The recommended next move matches the assigned ring and is concrete (scope, metric, or date)
- [ ] The radar blurb is 90–140 words and names the ring in the first two sentences
Notes
- The most common error is rating popularity as maturity — a widely starred project can still be a Hold if production fitness or maintainer health is weak.
- Default toward Assess or Trial when org-specific evidence is thin; Adopt should require evidence from this org's own context, not the internet's.
- For conservative orgs, raise the bar one ring (what others would Trial, hold at Assess) and state that you've done so.
- A good Hold entry is as valuable as a good Adopt — it saves teams from chasing tech that looks better on a conference slide than in production.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills