Wardn HubTrusted MCP server directory.

Registry

  • MCP Servers
  • Skills
  • Categories

Resources

  • API docs
  • Score method

Contribute

  • Submit server
  • Advertise
© 2026 Wardn Hub
Wardn Hub
MCP ServersSkillsCategoriesAPI docsSubmit server
Submit server
skills/mohitagw15856/pm-claude-skills/tech-radar

tech-radar

1
mohitagw15856/pm-claude-skills·Audit passed·Snapshot 5e8813ec774c

Summary

This source did not publish a separate summary. Review SKILL.md before using the skill.

SKILL.md

Tech Radar

Produce a complete technology radar document for an engineering team. The radar gives the team a shared, explicit position on every significant technology in their stack — what to standardize on, what to experiment with, what to evaluate, and what to actively stop using. Follow the ThoughtWorks Tech Radar format: four quadrants (Techniques, Tools, Platforms, Languages & Frameworks) each with four rings (Adopt, Trial, Assess, Hold). Each technology entry ("blip") gets a ring assignment, a one-paragraph rationale, and a date. Include a decision trail showing what moved and why, and a maintenance process the team can run to keep the radar current.

Required Inputs

Ask for these if not already provided:

  • Team or company name — for the document header
  • Current tech stack — list every significant technology, tool, language, and platform the team currently uses
  • Technologies under active evaluation — tools or frameworks the team is currently trying or considering
  • Technologies to deprecate or move off — anything the team wants to stop using or is actively migrating away from
  • Strategic technology bets — any technologies the company has made a deliberate bet on (e.g., "we're all-in on Kubernetes" or "migrating to event-driven architecture")
  • Team context — team size, product domain, and any constraints (regulatory, compliance, vendor lock-in concerns)

If a technology is mentioned without a ring placement, use the rationale inputs to determine the appropriate ring. When uncertain between two rings, ask.

Output Format

Technology Radar: [Team / Company Name]

Edition: [Month Year] Maintained by: [Team Name / Architecture Guild / CTO Office] Review cadence: Bi-annual (every 6 months) Next review: [Month Year + 6 months]

How to Read This Radar

This radar reflects [Team / Company Name]'s current thinking on technologies we use, evaluate, and retire. Use it to make consistent technology choices, onboard new engineers, and have structured conversations about the stack.

Quadrants categorize the type of technology:

QuadrantWhat belongs here
TechniquesMethods, patterns, and practices (e.g., trunk-based development, event sourcing)
ToolsSoftware tools used in the development and delivery process (e.g., linters, CI systems, observability platforms)
PlatformsInfrastructure and hosting environments (e.g., AWS, Kubernetes, Snowflake)
Languages & FrameworksProgramming languages and application frameworks (e.g., Go, React, FastAPI)

Rings express our recommendation:

RingMeaningWhat to do
AdoptIndustry-proven, working well for us — our standard choiceUse by default for new work; no special justification needed
TrialWorth pursuing — we are experimenting with it in limited production useUse in a bounded context with architectural oversight; share learnings
AssessWorth exploring — we have not used it in production yetSpike, prototype, or research; do not use in production without a review
HoldDo not start new work with this technologyComplete existing commitments; do not expand use; plan migration

Quadrant 1: Techniques

Adopt

TechnologySinceNotes
[Technique name, e.g., Trunk-based development][Month Year][One sentence: why we adopted it and what it replaced]
[Technique name][Month Year][One sentence rationale]
[Technique name][Month Year][One sentence rationale]

[Technique name] — Adopt [One paragraph rationale. Explain what problem this technique solves, why it works well in your context, and what the team should know before applying it. Reference any internal experience — e.g., "We rolled this out across 8 services in 2024 and saw a 40% reduction in merge conflicts."]

[Repeat for each Adopt-ring technique.]

Trial

TechnologySinceNotes
[Technique name][Month Year][One sentence: what we're testing and where]

[Technique name] — Trial [One paragraph. What are we trialing? In which teams or services? What hypothesis are we testing? What would cause us to move it to Adopt vs. Hold?]

Assess

TechnologySinceNotes
[Technique name][Month Year][One sentence: why we're interested]

[Technique name] — Assess [One paragraph. Why is this interesting to us? What would we need to see to move it to Trial? Who is responsible for the assessment?]

Hold

TechnologySinceNotes
[Technique name][Month Year][One sentence: why we're stopping and what replaces it]

[Technique name] — Hold [One paragraph. Why are we putting this on hold? What is the migration path? What is the target end-state for teams still using it?]

Quadrant 2: Tools

Adopt

TechnologySinceNotes
[Tool name, e.g., GitHub Actions][Month Year][One sentence rationale]
[Tool name][Month Year][One sentence rationale]

[Tool name] — Adopt [One paragraph rationale. Why is this our standard tool? What does it do well in our context? Any configuration or usage patterns the team should follow?]

[Repeat for each Adopt-ring tool.]

Trial

TechnologySinceNotes
[Tool name][Month Year][One sentence: what we're testing]

[Tool name] — Trial [One paragraph rationale and trial scope.]

Assess

TechnologySinceNotes
[Tool name][Month Year][One sentence: why we're evaluating it]

[Tool name] — Assess [One paragraph: what sparked interest, who is evaluating, and timeline.]

Hold

TechnologySinceNotes
[Tool name][Month Year][One sentence: what replaces it]

[Tool name] — Hold [One paragraph: deprecation rationale and migration path.]

Quadrant 3: Platforms

Adopt

TechnologySinceNotes
[Platform name, e.g., AWS EKS][Month Year][One sentence rationale]
[Platform name][Month Year][One sentence rationale]

[Platform name] — Adopt [One paragraph. What does this platform provide? What are the boundaries of its use? Any internal golden-path setup the team should follow?]

[Repeat for each Adopt-ring platform.]

Trial

TechnologySinceNotes
[Platform name][Month Year][One sentence: scope of trial]

[Platform name] — Trial [One paragraph rationale and trial boundaries.]

Assess

TechnologySinceNotes
[Platform name][Month Year][One sentence: why we're exploring it]

[Platform name] — Assess [One paragraph assessment plan.]

Hold

TechnologySinceNotes
[Platform name][Month Year][One sentence: migration target and timeline]

[Platform name] — Hold [One paragraph: what triggered the hold decision, migration target, and timeline.]

Quadrant 4: Languages & Frameworks

Adopt

TechnologySinceNotes
[Language/Framework, e.g., Go][Month Year][One sentence rationale]
[Language/Framework][Month Year][One sentence rationale]

[Language/Framework] — Adopt [One paragraph. What is this language or framework used for? What are the team's proficiency expectations? Any frameworks or libraries that go alongside it as part of the standard choice?]

[Repeat for each Adopt-ring language or framework.]

Trial

TechnologySinceNotes
[Language/Framework][Month Year][One sentence: bounded use case]

[Language/Framework] — Trial [One paragraph rationale.]

Assess

TechnologySinceNotes
[Language/Framework][Month Year][One sentence: interest driver]

[Language/Framework] — Assess [One paragraph assessment plan.]

Hold

TechnologySinceNotes
[Language/Framework][Month Year][One sentence: reason and migration path]

[Language/Framework] — Hold [One paragraph: deprecation rationale, existing system obligations, and timeline to retire.]

Decision Trail

This log records every ring movement since the radar's first edition. Use it to understand the evolution of our technology choices.

TechnologyQuadrantPrevious RingNew RingEditionReason
[Name][Quadrant]—Adopt[Month Year]First placement — [one sentence why]
[Name][Quadrant]AssessTrial[Month Year][What prompted the move — evidence, team feedback, production trial results]
[Name][Quadrant]TrialAdopt[Month Year][Adoption rationale — usage results, team satisfaction, scale proven]
[Name][Quadrant]AdoptHold[Month Year][Why moved to Hold — better alternative, security concern, cost, vendor issue]
[Name][Quadrant]—Hold[Month Year]First placement — added directly to Hold because [reason]

Radar Maintenance Process

Who Contributes

  • Architecture review group / CTO office — final ring placement decisions
  • All engineers — submit blip nominations via [channel or form]
  • Tech leads — triage nominations and prepare proposals for review sessions

Update Cadence

ActivityFrequencyOwner
New blip nominations acceptedOngoing — any engineer via [channel]Anyone
Nomination triageMonthlyTech leads
Full radar review sessionEvery 6 monthsArchitecture group
Published radar updateEvery 6 months[Owner name or role]

How to Nominate a Blip

  1. Submit to [Slack channel / form URL] with: technology name, quadrant, proposed ring, and one-paragraph rationale.
  2. A tech lead reviews within 2 weeks and either schedules it for the next review session or requests more information.
  3. At the review session, the architecture group discusses and votes. Simple majority wins; ties go to Hold pending further evidence.
  4. Approved blips are added to the radar doc and the decision trail within 1 week of the session.

Ring Change Criteria

To move TO AdoptTo move TO TrialTo move TO AssessTo move TO Hold
Proven in multiple production systems; team broadly trained; clear operational runbook existsAt least one production use case running; architectural oversight in place; learnings documentedConcrete use case identified; spike completed or in progress; interest from at least 2 engineersBetter alternative exists; known security/compliance risk; strategic direction change; unacceptable maintenance burden

Questions about this radar: [Slack channel] | Submit a nomination: [URL or channel]

Quality Checks

  • Every blip has a written rationale paragraph — not just a table row entry
  • The decision trail is populated with at least the initial placement date for every blip
  • Hold-ring entries include a concrete migration path or target technology, not just "stop using it"
  • Ring definitions are present and include both what each ring means AND what engineers should do in response
  • Maintenance process includes: nomination channel, review cadence, who decides, and ring-change criteria
  • Technologies identified as "strategic bets" in the inputs are placed in Adopt (if proven) or Trial (if being rolled out)
  • Technologies identified for deprecation are in Hold with a rationale that references the replacement

Anti-Patterns

  • Do not place a technology in Adopt without evidence it is proven at the team's scale — aspirational placements mislead engineers
  • Do not add a blip without a written rationale paragraph — table rows without context are unusable
  • Do not create a Hold entry without specifying a concrete migration path or target technology
  • Do not skip the maintenance process — a radar with no process for updates becomes stale within two quarters
  • Do not omit ring definitions — engineers need to know what they should do in response to each ring, not just what the ring means

Related skills

capacity-planningcompetitor-teardowncontext-engineering-reviewrunbook-writerreceipts-audit