variants
Skill3.3k starsChanged 2 days agoApache-2.0View on GitHub
Run two or three isolated probe implementations of one brief that differ in named decisions or approaches, judge them blind against fixed criteria, and return a decision brief from which the human or the lead picks or composes the final design. Use inside a delivery or intent flow once the alternatives are named and only implementation evidence can settle them, or when the user asks to try several approaches.
We split this skill into the rules it gives an agent
4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Never run a candidate that contradicts adopted intent.
- Distinctive: line 22
When no criterion can distinguish the candidates, return the question to the human rather than inventing a proxy.
- Distinctive: line 40
Write the decision brief from the template as an artifact, never committed.
- Distinctive: line 41
Keep the variant branches until the design they informed has merged, since the final implementer may read how a probe handled a decision.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
A variant is a probe: build it only far enough to measure the criteria and never merge it, because probe code carries shortcuts and has not been through the review loop; the chosen design - one variant, or the best decisions of several - is implemented fresh and the criteria rerun on it. A run answers a question nobody could settle on paper; when the facts or the human can settle it, ask instead, since three probes cost more than one question.
Two modes
- Tournament: intent and contract are fixed and the candidates are approaches; whoever runs it picks, within autonomy.
- Experiment: the candidates are decisions the human has not committed; the human picks and writes the commitment, so no intent file changes until they do.
Never run a candidate that contradicts adopted intent; that is drift with a budget, not an experiment.
Compose
Candidates come from alternatives the human voiced, the options of an escalation, or alternatives you derive and name before launch; without a named difference there is nothing to run.
Vary one decision when the open decisions are independent; when they are coupled, make each variant a coherent design - a full set of answers - and compare designs, because a bundle that mixes answers at random tests nothing.
Three variants by default, raised only by the human, because each costs a build.
Fix the criteria before the first variant starts, choosing from references/criteria.md, each with how it is measured; the acceptance checks are written then and shared, since a check a variant writes for itself proves only that it did what it did.
When no criterion can distinguish the candidates, return the question to the human rather than inventing a proxy.
Run
Same base commit, same brief apart from the named differences, same model for every variant; these reduce what else could explain a difference, without proving the design caused it. Each variant in its own worktree or session, never shown another's work, or they converge. The contract and any blind suite stay read-only in every variant, and a defect found in them is escalated outside the run, because a candidate that moves its oracle is not comparable. A variant stops once every criterion can be measured on it, or earlier when its candidate proves infeasible, since the run has answered for it; one that fails a must-pass criterion is disqualified from winning but keeps its measurements, since they still inform a composed design, and when all fail, investigate before concluding anything from the run.
Judge
A fresh context, from a different model family when available, gets the criteria, the measurements, and snapshots labelled A, B, C stripped of branch and commit metadata; never who or which model built which, the workers' transcripts or rationales, or your preference or proposed design, because each of those carries the framing the blind read is meant to remove. It ranks per criterion with the evidence it turned on, names an attribution to one decision only where the evidence isolates it, and reports bundled effects as unidentifiable otherwise. A variant another beats on every criterion that splits them is dropped, so the brief carries only the front where a trade exists; a criterion that split nothing is dropped from the brief too. "No clear winner" is a verdict; so is "none of these", with the decisions a better design would combine.
Brief and after
Write the decision brief from the template as an artifact, never committed; it is what the human reads instead of three implementations. Keep the variant branches until the design they informed has merged, since the final implementer may read how a probe handled a decision; then delete them, because the brief is what survives. In an experiment, proceed on the proposed design while the human is away only when the verdict is clear by the criteria, logged as provisional; the human adopts or reverses from the brief, at the latest when they merge, since nothing resting on a provisional decision merges without them. A verdict that is not clear stops this thread and waits; other threads continue.
# Experiment <n>: <question>
Base: <commit>. Variants: A <decisions>; B <decisions>; C <decisions>.
Criteria: <each with how it was measured; must-pass marked>.
| Criterion | A | B | C |
Verdict (blind): <ranking; evidence; attributions the evidence isolates; effects left unidentifiable>.
Per variant: <what it demands of callers; what it forecloses and the cost of switching later; surprises met>.
Proposed design: <a variant, or the decisions combined>, because <evidence>.
Status: proceeding provisionally | waiting.
To adopt or rewrite: <one candidate commitment sentence per decision>.Trending
More talk lately.about the whole repository
Who's talking about Devolutions/IronRDP
- A Hacker News story“IronRDP: a Rust implementation of Microsoft's RDP protocol”Hacker News · Mar 21, 2025 · 545 points
- @github-trending.bsky.social“🚀 Skyrocketing! 🚀 (200+ new stars) 📦 Devolutions / IronRDP ⭐ 1,328 (+276) 🗒 Rust Rust implementation of …”Bluesky · Mar 23, 2025 · 19 likes
- @hacker-news-jp.bsky.social“IronRDP: MicrosoftのRDPプロトコルのRust実装 IronRDP: a Rust implementation of Microsoft's RDP protocol 🔺 328 💬 45 …”Bluesky · Mar 21, 2025 · 5 likes
- fosrl/pangolin“Browser RDP fails with GNOME Remote Desktop And Windows Connection Errors”GitHub · Jun 14, 2026 · 3 reactions
- @rusttrending.bsky.social“Devolutions / IronRDP: Rust implementation of the Microsoft Remote Desktop Protocol (RDP) ★1304 …”Bluesky · Mar 23, 2025 · 3 likes
The biggest 5 of 60 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 60
Talked about on GitHub, Bluesky and Hacker News (60 times).
On GitHub · 50
- Jun 14, 2026Browser RDP fails with GNOME Remote Desktop And Windows Connection Errors — fosrl/pangolin3 reactions · 19 comments
- Jul 29, 2026fix(kerberos): remove unnecessary sequence number incrementation — Devolutions/sspi-rs1 reaction
- Feb 25, 2026Can't connect to Ubuntu RDP host — totoshko88/RustConn1 reaction · 5 comments
- Nov 18, 2025build(deps): no zlib for flate2 on WASM — Devolutions/sspi-rs1 reaction
- Oct 7, 2025chore(webapp): bump VNC and RDP WASM packages — Devolutions/devolutions-gateway1 reaction · 2 comments
45 more on GitHub
- Aug 28, 2025fix(webapp)!: add manual clipboard mode for RDP, VNC and ARD — Devolutions/devolutions-gateway1 reaction · 3 comments
- Oct 29, 2026chore(deps): bump ironrdp-graphics from 0.9.0 to 0.10.0 — kihyun1998/justrdp0 reactions
- Oct 24, 2026Bug: (IronRDP) (Windows Server 2025) Screen tearing on resize — meanaverage/tabby-rdp0 reactions · 5 comments
- Oct 23, 2026Vendored forks: upstream drift or advisories need review — armaxri/termiHub0 reactions
- Oct 22, 2026Embedded RDP: distorted display when connecting to xrdp — totoshko88/RustConn0 reactions · 1 comment
- Oct 21, 2026Stalled transport retains an old session and blocks reconnect until service restart — MuNeNiCK/hypr-rdp0 reactions
- Oct 19, 2026Bump ironrdp-graphics from 0.6.0 to 0.9.0 — Antxj/termcraft0 reactions
- Oct 19, 2026Bump ironrdp-pdu from 0.6.0 to 0.9.0 — Antxj/termcraft0 reactions
- Oct 19, 2026Bump ironrdp-cliprdr from 0.4.0 to 0.7.0 — Antxj/termcraft0 reactions
- Oct 19, 2026Bump ironrdp-core from 0.1.5 to 0.2.1 — Antxj/termcraft0 reactions
- Oct 19, 2026Bump ironrdp-dvc from 0.4.1 to 0.8.0 — Antxj/termcraft0 reactions
- Oct 15, 2026Windows desktop service 18.11.x fails RDP license exchange on windows hosts with RDS CALs — gravitational/teleport0 reactions · 1 comment
- Oct 9, 2026Vendored forks: upstream drift or advisories need review — armaxri/termiHub0 reactions
- Oct 2, 2026feat(unattended): pivot to native Windows Devolutions Gateway and RDP readiness — hamburger-os/PalmTTY0 reactions · 1 comment
- Sep 28, 2026Bump ironrdp-pdu from 0.8.0 to 0.9.0 — athiedepayit/rustrdp0 reactions
- Sep 26, 2026[test] vendored-fork drift sync self-test (#3498) — armaxri/termiHub0 reactions · 1 comment
- Sep 26, 2026Vendored forks: upstream drift or advisories need review — armaxri/termiHub0 reactions · 1 comment
- Sep 26, 2026Vendored forks: upstream drift or advisories need review — armaxri/termiHub0 reactions · 1 comment
- Sep 26, 2026Vendored forks: upstream drift or advisories need review — armaxri/termiHub0 reactions · 1 comment
- Sep 24, 2026feat(kerberos): add support for IAKerb extension for Kerberos client — Devolutions/sspi-rs0 reactions · 9 comments
- Sep 24, 2026feat(picky-krb): add IAKerb proxy message encoding/decoding — Devolutions/picky-rs0 reactions · 1 comment
- Sep 11, 2026Support Linux user authentication through PAM — MuNeNiCK/hypr-rdp0 reactions
- Sep 7, 2026Bump ironrdp-displaycontrol from 0.7.0 to 0.8.0 — athiedepayit/rustrdp0 reactions · 1 comment
- Sep 7, 2026Bump ironrdp-input from 0.6.0 to 0.7.0 — athiedepayit/rustrdp0 reactions · 1 comment
- Sep 4, 2026[no ci]: Bump ironrdp-pdu from 0.8.0 to 0.9.0 — athiedepayit/rustrdp0 reactions · 1 comment
- Sep 4, 2026[no ci]: Bump ironrdp-cliprdr from 0.6.0 to 0.7.0 — athiedepayit/rustrdp0 reactions
- Sep 4, 2026[no ci]: Bump ironrdp-graphics from 0.8.1 to 0.9.0 — athiedepayit/rustrdp0 reactions · 1 comment
- Sep 4, 2026[no ci]: Bump ironrdp-dvc from 0.7.0 to 0.8.0 — athiedepayit/rustrdp0 reactions · 1 comment
- Sep 4, 2026[no ci]: Bump ironrdp-session from 0.10.0 to 0.11.0 — athiedepayit/rustrdp0 reactions
- Aug 26, 2026chore(deps): bump ironrdp-session from 0.8.0 to 0.11.0 in /src-tauri — voktty/voktty0 reactions · 1 comment
- Jul 28, 2026build(deps): bump ironrdp-egfx from 0.2.0 to 0.3.0 in /rdp-kotlin/rust — GlassHaven/Haven0 reactions · 2 comments
- Jul 28, 2026build(deps): bump ironrdp-displaycontrol from 0.7.0 to 0.8.0 in /rdp-kotlin/rust — GlassHaven/Haven0 reactions · 2 comments
- Jul 28, 2026build(deps): bump ironrdp-session from 0.10.0 to 0.11.0 in /rdp-kotlin/rust — GlassHaven/Haven0 reactions · 2 comments
- Jul 27, 2026Bump ironrdp-pdu from 0.7.0 to 0.9.0 in /android/yyslide-android/rdp-kotlin/rust — wuyan1337/yySlide0 reactions
- Jul 27, 2026Bump ironrdp-cliprdr from 0.5.0 to 0.7.0 in /android/yyslide-android/rdp-kotlin/rust — wuyan1337/yySlide0 reactions
- Jul 25, 2026build(deps): bump ironrdp-input from 0.6.0 to 0.7.0 in /rdp-kotlin/rust — SkyL9ne/Haven0 reactions
- Jul 25, 2026build(deps): bump ironrdp-session from 0.10.0 to 0.11.0 in /rdp-kotlin/rust — SkyL9ne/Haven0 reactions
- Jul 25, 2026build(deps): bump ironrdp-displaycontrol from 0.7.0 to 0.8.0 in /rdp-kotlin/rust — SkyL9ne/Haven0 reactions
- Jul 25, 2026build(deps): bump ironrdp-egfx from 0.2.0 to 0.3.0 in /rdp-kotlin/rust — SkyL9ne/Haven0 reactions
- Jul 25, 2026build(deps): bump ironrdp-svc from 0.7.0 to 0.8.0 in /rdp-kotlin/rust — SkyL9ne/Haven0 reactions
- Jul 25, 2026build(deps): bump ironrdp-cliprdr from 0.6.0 to 0.7.0 in /rdp-kotlin/rust — SkyL9ne/Haven0 reactions
- Jul 21, 2026build(deps): bump ironrdp-tls from 0.2.1 to 0.2.2 in /rdp-kotlin/rust — GlassHaven/Haven0 reactions · 4 comments
- Jul 21, 2026build(deps): bump ironrdp-cliprdr from 0.6.0 to 0.7.0 in /rdp-kotlin/rust — GlassHaven/Haven0 reactions · 3 comments
- Jul 21, 2026build(deps): bump ironrdp-core from 0.2.0 to 0.2.1 in /rdp-kotlin/rust — GlassHaven/Haven0 reactions · 3 comments
- Jul 16, 2026bump ironrdp-graphics from 0.8.0 to 0.9.0 — kihyun1998/justrdp0 reactions · 2 comments
On Bluesky · 9
- Mar 23, 2025🚀 Skyrocketing! 🚀 (200+ new stars) 📦 Devolutions / IronRDP ⭐ 1,328 (+276) 🗒 Rust Rust implementation of the Microsoft Remote Desktop… — @github-trending.bsky.social19 likes and reposts
- Mar 21, 2025IronRDP: MicrosoftのRDPプロトコルのRust実装 IronRDP: a Rust implementation of Microsoft's RDP protocol 🔺 328 💬 45 🔗 HN Post | Article — @hacker-news-jp.bsky.social5 likes and reposts · 1 reply
- Mar 23, 2025Devolutions / IronRDP: Rust implementation of the Microsoft Remote Desktop Protocol (RDP) ★1304 https://github.com/Devolutions/IronRDP — @rusttrending.bsky.social3 likes and reposts
- Mar 22, 2025IronRDP: a Rust implementation of Microsoft's RDP protocol https://github.com/Devolutions/IronRDP [comments] [334 points] — @hnfeed.bsky.social2 likes and reposts
- Mar 21, 2025IronRDP: a Rust implementation of Microsoft's RDP protocol https://github.com/Devolutions/IronRDP… — @newsyc200.bsky.social2 likes and reposts
4 more on Bluesky
- Mar 21, 2025IronRDP: a Rust implementation of Microsoft's RDP protocol Discussion — @hackernewsbot.bsky.social2 likes and reposts
- Oct 9, 2026I want to reach feature parity with the first-party RDP client with IronRDP: github.com/Devolutions/... — @awakecoding.com1 likes and repost · 1 reply
- Mar 22, 2025🌐IronRDP: Microsoft の RDP プロトコルの Rust 実装 https://github.com/Devolutions/IronRDP via #HackerNews — @kdmsnr.com1 likes and repost
- Mar 22, 2025https://github.com/Devolutions/IronRDP Rustで実装されたMicrosoft Remote Desktop Protocol (RDP)の紹介です。 IronRDPという名称でGitHubで公開されています。… — @topickapp.bsky.social1 likes and repost
On Hacker News · 1
- Mar 21, 2025IronRDP: a Rust implementation of Microsoft's RDP protocol545 points · 214 comments
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- adityareddy-dev/deskstudio★ 42same name
- Pawel-Kica/ai-coding-100★ 2same name
- Pawel-Kica/claude-code-100★ 2same name
- harshil-1411/claude_plugin_video_studio★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository42 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agents-md-reviewSkill
- agents-mdSkill
- blind-testsuiteSkill
- code-compressorSkill
- commit-and-pr-conventionsSkill
- commit-scopeSkill
- contract-authoringSkill
- contract-reviewSkill
- contributeSkill
- crate-readme-writerSkill
- dependency-prunerSkill
- dependency-reviewerSkill
- docs-compressorSkill
- docs-writerSkill
- grill-intentSkill
- intent-drift-auditSkill
- intent-filesSkill
- intent-reviewSkill
- ironrdp-activex-mstsc-testingSkill
- leadSkill
- llm-comment-footerSkill
- markdown-writerSkill
- new-crateSkill
- orchestrate-effortSkill
- prose-verifierSkill
- prose-writerSkill
- protocol-reviewerSkill
- public-dependencySkill
- review-feedback-loopSkill
- rust-style-reviewerSkill
- rust-styleSkill
- skeptical-reviewerSkill
- skill-disciplineSkill
- tddSkill
- tessl-skill-lintingSkill
- test-oracle-reviewerSkill
- test-prunerSkill
- test-reviewerSkill
- test-writerSkill
- code-reviewSkill
- release-prepSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

