janusSAFE
Turn a product's contradictions into its positioning. A Claude Code skill — every other thinking framework dissolves a contradiction; this one refuses.
Overview
Turn a product's contradictions into its positioning. A Claude Code skill — every other thinking framework dissolves a contradiction; this one refuses.
51e5a725f8c0OBSERVED · 2026-10-12What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: janus
description: Turn a product's contradictions into its positioning. Use when a product, offer, or brand carries two opposed things that both must be true (private vs. social, premium vs. free, simple vs. powerful, subscription vs. ownership) and picking one side would kill the product. Also use when positioning reads generic and the differentiator is missing, or to audit an existing design doc for contradictions being carried unnamed. Not for architecture tradeoffs, debugging, or engineering decisions that should resolve.
---
# Janus
Named for the god who faces both ways at once. The method is Rothenberg's
**Janusian** thinking; this skill is the product.
Most frameworks treat a contradiction as a defect to dissolve. This one treats it as the
raw material. You hold both poles at full strength, refuse every resolution, and the
mechanism that lets both be true **is** the differentiator you were missing.
The refusal is the whole technique. Everything below exists to stop you resolving.
---
## When this applies
Use it when a contradiction is **structural**: when both poles have a constituency and
killing either one kills the product.
Do **not** use it for:
| Situation | Use instead |
|---|---|
| Architecture tradeoffs (fast vs. simple) | These should resolve. TRIZ, tradeoff analysis. |
| A bug that behaves paradoxically | That's diagnosis. Systematic debugging. |
| One pole is just a constraint, not a want | Nobody advocates "slow." That's a budget, not a tension. |
| The tension is really a resourcing problem | Scheduling, not creativity. |
---
## Step 1. Name the pair
Write the two poles as plain assertions, not adjectives.
> **A.** Your data never leaves your machine.
> **B.** Collaboration is the reason people switch to us.
### The fake-tension filter
**Name a living person who wants each pole, and say why.** Not a persona sketch. An actual
describable human with a reason.
If you cannot name a constituency for both sides, it is not a tension. It is a preference,
a constraint, or a decision someone is avoiding. **Stop and discard it.**
Common fakes:
- *"Secure and easy."* Nobody wants insecure. That's a UX budget.
- *"Fast and cheap."* Nobody wants slow. That's an engineering tradeoff.
- *"Good and profitable."* Too abstract to force anything.
A real pair sounds uncomfortable when you say it out loud. If it sounds reasonable, it's
probably fake.
---
## Step 2. Ban the three exits
Every existing framework takes one of these. Write them out and rule each one dead before
going further. Naming them is what stops you sliding into one without noticing.
| Exit | Sounds like | Why it's banned |
|---|---|---|
| **Compromise** | "Both, a bit less." Encrypted-but-shared. Freemium. | Halves both poles. Produces the average product. |
| **Sequence** | "A first, then B." Local-first, sync later. | Only ever ships A. B becomes the roadmap graveyard. |
| **Segment** | "A for these users, B for those." | Two products, half the focus, no position. |
State explicitly: *"Compromise is dead. Sequence is dead. Segment is dead."*
You now have no way out except through.
---
## Step 3. Force simultaneity
The question, asked exactly:
> **What must be true for both poles to be fully true, in the same thing, at the same time,
> for the same person?**
If that stalls, invert it. These are the productive forms:
- How does **A** *cause* **B**? Not tolerate it. Cause it.
- What would make **B** the *proof* of **A**?
- What kind of thing gets **more** A the more B it does?
- Who would be delighted by both at once, and what are they holding?
Stay here. This step is uncomfortable and that discomfort is the work. The first three
answers will be compromises wearing a disguise.
---
## Step 4. Harvest
The output is a **mechanism**, a concrete thing the product does. Not a slogan and not a
balance.
### The quality gate
**Does either pole come out weaker than it went in?**
If yes, you found a compromise and dressed it up. Go back to step 3. Both poles must survive
at full strength or the answer is wrong.
Second check: **is it a mechanism or an adjective?** "Balanced," "thoughtful," and
"best of both" are failures. "The server structurally cannot read your data" is a mechanism.
The positioning line falls out of the mechanism afterward. Never write the line first: a
line without a mechanism underneath it is marketing, and it will not survive contact with a
customer who asks *how*.
---
## Step 5. Register the tension
Append to `design.md` (or whatever your project's design doc of record is):
```markdown
## Held tensions
- **Private ⟷ Collaborative.** Do NOT resolve, both ship.
Mechanism: sharing grants a revocable, expiring capability; the host never holds the document.
Killed pole warning: any feature that stores a copy server-side kills Private.
```
This is the part everyone skips and it is the part that pays twice.
A registered tension can be **audited**. Six months later, a reasonable-looking decision
quietly kills one pole (a sync feature that caches server-side, a tier that charges for the
thing you said was free) and without the register, nobody notices until the website is
telling a lie the code stopped supporting.
Write the **killed pole warning** explicitly. It is the tripwire.
---
## Two entry modes
**Handed.** The user names the pair. Run steps 1–5.
**Extracted.** Point at an existing `design.md`, landing page, or product copy and find the
tensions being carried unnamed. Look for:
- Two claims that cannot both be maximally true (`totally private` + `share with your team`)
- A promise the pricing page contradicts
- A value in the design doc that no shipped feature expresses
- Hedging language ("while still," "yet also," "balanced with") which marks a compromise
that was never examined
Surface them as pairs, apply the fake-tension filter, then run the strongest one through
steps 2–5. Do not try to resolve five at once.
---
## Worked examples
### Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
51e5a725f8c0full audit observations/trust-audit/skill/pr1m4lc0d3__janus.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-12 | 51e5a725f8c0 | SAFE | B | 89 | first audit |
Questions
What does the janus skill do?
Turn a product's contradictions into its positioning. A Claude Code skill — every other thinking framework dissolves a contradiction; this one refuses.
Is janus safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can janus access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (51e5a725f8c0), read on 2026-10-12. The repository is watched, and a new audit runs when it changes — this is the first audit.