Published once, applies afterwards
A rule you publish keeps applying to every task in that repository. A recommendation has to be recalled by every engineer on every task, or it quietly stops happening.
The setup that works, running for every engineer.
Skills, rules, hooks and sub-agents decide how well an engineer's agents behave. In most orgs the best of that lives on two or three machines and never travels, while the rest of the team runs on whatever their tool shipped with. Harness takes what is demonstrably working here and makes it the default everywhere.
Harness · recommendations
Components
719
Recommended
23
Diverged
36
code-reviewer9 of 11
pr-nudge hook7 of 11
rtk hook1 of 11
Adoption across engineers
What changes in the harness.
Today
- The setup that works exists, on one or two machines
- Rules drift apart and nobody notices until two teams behave differently
- Adopting anything new depends on someone reading a changelog and caring
With Tetriz
- Rules and templates derived from what actually shipped well here
- Conflicts and drift surfaced and realigned
- Approved changes published from one place, with a record of who published them
How a setup that works on one machine ends up on all of them.
Every step reads from your own history, so nothing here is a generic best-practice list.
See what is genuinely load-bearing
An installed component and a useful one are indistinguishable until you count what actually fires.
What Tetriz does here
- What is installed, and what runs
Every skill, hook, sub-agent and rules file across the org, with how often each one fires.
- And how many people have it
The number that separates a good idea from a good idea that spread.
Harness inventory
Components
719
Invocations
4,739
On one machine
31
Turn what worked into a rule
The reason good practice does not spread is that nobody has time to write it down while it is working.
What Tetriz does here
- Derived from what shipped
The patterns behind work that merged cleanly become rules and templates you can publish.
- Approved before it goes anywhere
An admin edits or accepts each one, and every push is recorded against the person who made it.
Component recommendations
| Component | Adopted | Suggested |
|---|---|---|
| code-reviewer | 9 of 11 | Org default |
| pr-nudge.sh | 7 of 11 | Org default |
| Explore | 5 of 11 | Opt-in |
Catch the drift before it splits your org
Two teams on nominally the same setup behave differently, and the cause is almost always a rules file that quietly diverged.
What Tetriz does here
- Divergence reported, per engineer and repo
So a difference in behaviour has a cause you can point at rather than a theory.
- Contradictions consolidated
Overlapping or conflicting skills get resolved instead of both firing and fighting.
Rules file drift
Synced582
Diverged36
Conflicting11
Rules files across the org
Adopt from outside, without importing risk
A third-party skill is executable code running with your repository's permissions. Most teams evaluate that by reading a README.
What Tetriz does here
- Scanned before it is offered
Third-party skills and templates are reviewed for what they execute and what they can reach, not just for whether they are popular.
- One curated shelf, not twenty repos
The alternative is every engineer independently assessing the same handful of community packages.
Marketplace review queue
Reviewed
140
Rejected
19
Deployed
23
Why this is the change that stays changed.
Everything else on this layer is a practice. This one is a setting, and settings do not need to be remembered.
Where a good setup came from stops mattering
A skill your strongest engineer wrote and a reviewed one from outside reach every machine the same way, so you can take the best of both without running two processes.
And competence stops being something people assemble
Someone joining inherits the accumulated setup on their first day instead of piecing it together over a year by noticing what colleagues do.
Questions leaders ask about Harness.
Your own history — the prompts, skills and rules behind work that shipped well here. That is why they differ between two orgs on identical tooling.
An admin. Each recommendation is a proposal with its evidence attached, and every approved push is recorded against the person who made it.
This decides what the setup should be. The Control Plane is the mechanism that pushes an approved setup to every machine, and it sits under Governance.
What the skill executes, what it can reach, and whether it handles credentials or data it has no reason to touch. Anything that fails is not offered.
It sets a floor. Deliberate variation stays possible and stays visible — what goes away is variation nobody chose and nobody knew about.