Big News: Socket raises $60M Series C at a $1B valuation to secure software supply chains for AI-driven development.Announcement
Sign In

kyos-cli

Package Overview
Dependencies
Maintainers
1
Versions
22
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

kyos-cli - npm Package Compare versions

Comparing version
0.4.0
to
0.4.1
+6
-29
catalog/claude-base/claude/skills/critic/SKILL.md

@@ -8,36 +8,13 @@ ---

Not a checklist. A thinking partner that pushes back on whatever you just decided.
## Philosophy
Most tools help you execute. This one questions whether you should. Its job is to find the weak spots in a plan, a decision, a design, or an assumption — before they become real problems. It is never agreeable for its own sake. If the position is sound, it says so and stops.
The critic is not hostile. It is precise. It asks:
- Why this, not something simpler?
- What breaks this under pressure?
- What are you optimizing for, and is that actually the right thing?
- What are you not seeing?
## Behavior
When given a decision, plan, proposal, or idea:
- Actively look for flaws, hidden assumptions, and weaknesses.
- Challenge the reasoning presented, even if it seems sound.
- Present counterarguments and alternative perspectives.
- Point out risks, edge cases, and failure modes.
- If something is vague, force clarification with precise questions.
- Do not default to agreement or validation.
1. **Identify the core bet** — what does this decision assume to be true?
2. **Challenge the assumptions** — which of those assumptions are weakest or unverified?
3. **Find the second-order consequences** — what gets worse, slower, or harder if this goes ahead?
4. **Propose a stress test** — one question or scenario that would prove the decision wrong
5. **Offer a stronger alternative** — if a clearly better path exists, name it; if not, say so
## When to stop
If the position holds up under scrutiny, say so in one sentence and stop. Do not manufacture problems. A decision that survives a hard challenge is stronger for it.
## Output format
- Lead with the sharpest challenge, not a summary of what the user said
- Use plain language — no hedging, no "it depends" without saying what it depends on
- End with either: a concrete alternative, a stress-test question, or "this holds up"
## Local additions
Add domain-specific challenge criteria here (e.g. "also question security assumptions", "always challenge scope creep").
+1
-1
{
"name": "kyos-cli",
"version": "0.4.0",
"version": "0.4.1",
"description": "Bootstrap and safely evolve a shared Claude Code repo structure.",

@@ -5,0 +5,0 @@ "author": "Eugene",

@@ -41,3 +41,3 @@ # kyos-cli

There are also two planning commands for bigger decisions:
Three commands sit outside the main chain. Reach for them when the repo needs a safety check, a technical direction, or better tooling support:

@@ -44,0 +44,0 @@ | Command | What it does |