---
description: Run the ISP technology-review workflow from evidence to team decision
argument-hint: "<technology> [target-project or question]"
---

# Run a technology review

**Technology and context**:
$ARGUMENTS

Use the `twg`, `twg-confluence`, `twg-jira`, and `speak-as-oliver` skills.
Confluence is the process authority; read current source pages instead of relying
on remembered policy.

## Establish the review

1. Read the current `Tech Reviews` process page in the RD space, its review
   template, and the linked Open Source/COTS clearing and Developer Weekly
   instructions.
2. Find the Jira ticket carrying the `tech-review` label, or report that it is
   missing. Never create or mutate Jira state without explicit authorization.
3. State the concrete goal: which decision this review enables, for whom, and
   in which target project.
4. Identify the prototype or real product trial. Existing hands-on use counts;
   unsupported expectations do not. If no trial exists, stop at a bounded trial
   plan rather than writing a recommendation.

## Gather evidence

- Prefer official documentation, primary repositories, current project code,
  generated reports, and observed trial results.
- Separate facts, trial observations, unresolved questions, and judgments.
- Name exact artifacts and boundaries. Do not collapse an input payload,
  persisted event, report format, protocol, or API into vague terms such as
  `Wire-Format`.
- Check the technology and every required component against the current license
  matrix. A whitelist result is cleared; a blacklist result blocks adoption;
  anything else requires the documented clearing process.
- Evaluate the dimensions required by the current Techreview template, including
  functionality, performance, usability, compatibility, security,
  community/support, licensing/cost, and recommendation.

## Draft

- Use the current template, but keep the result terse and decision-oriented.
- Write in the language and register of the target space; for Oliver-authored
  German text, apply `speak-as-oliver` and natural technical German.
- Explain practical findings through concrete examples from the trial.
- Make the recommendation bounded: target project, initial scope, workflow,
  unresolved gates, and conditions for wider adoption.
- Leave the final accept/reject decision to the team.

Present the complete draft and its evidence links before any Confluence write.
Apply feedback narrowly. Wait for explicit authorization before publishing.

## Complete after approval

1. Create or update the Tech Review under the canonical parent using the
   current content type and template conventions.
2. Read it back and verify title, body, links, status, and parent.
3. Create the required Developer Weekly announcement in Oliver's voice, link
   the review, and add the `weekly` label.
4. Read back the announcement and verify its link and label.
5. Report direct URLs, remaining questions, and the team decision still needed.

Never claim a trial, license clearance, publication, label, or decision before
verifying it.