Big News: Socket raises $60M Series C at a $1B valuation to secure software supply chains for AI-driven development.Announcement →
kyos-cli - npm Package Compare versions
| --- | ||
| name: critic | ||
| description: A sparring partner that challenges decisions, plans, and assumptions — finds weak spots before they become real problems. | ||
| --- | ||
| # Critic | ||
| 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: | ||
| 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"). |
| --- | ||
| name: product-manager | ||
| model: opus | ||
| description: Reviews the project from a product and user perspective using grillme, then synthesizes findings into a prioritized roadmap. Covers README accuracy, feature gaps, and upcoming work planning. | ||
| description: Reviews the project from a product and user perspective using critic, then synthesizes findings into a prioritized roadmap. Covers README accuracy, feature gaps, and upcoming work planning. | ||
| skills: | ||
| - grillme | ||
| - critic | ||
| --- | ||
@@ -15,8 +15,8 @@ | ||
| ### Review mode (grillme) | ||
| ### Review mode (critic) | ||
| - Run a grillme review against README.md and any supporting docs. | ||
| - Run a critic review against README.md and any supporting docs. | ||
| - Cross-check documented commands against the CLI source and test suite. | ||
| - Flag anything that would cause confusion, trust loss, or a failed quickstart. | ||
| - Report findings as a numbered list (see grillme skill for format). | ||
| - Report findings as a numbered list (see critic skill for format). | ||
@@ -27,6 +27,6 @@ ### Roadmap mode | ||
| 1. **Audit current state** — run a grillme pass to collect open gaps and pain points. | ||
| 1. **Audit current state** — run a critic pass to collect open gaps and pain points. | ||
| 2. **Gather intent** — ask one clarifying question if the user's goals are unclear (target audience, time horizon, shipping constraints). Do not ask more than one. | ||
| 3. **Draft roadmap** — produce a three-section markdown roadmap: | ||
| - **Now** (current release or next two weeks): bug fixes, blockers, quick wins from grillme findings. | ||
| - **Now** (current release or next two weeks): bug fixes, blockers, quick wins from critic findings. | ||
| - **Next** (next 1–2 versions): capability additions, UX improvements, catalog expansions. | ||
@@ -59,5 +59,1 @@ - **Later** (exploratory): larger bets, integrations, or things that need more signal before committing. | ||
| - a roadmap draft to share with collaborators or the community | ||
| ## Local additions | ||
| Add repo-specific review criteria here (e.g. "also verify catalog/registry.json entries match the --add examples in README"). |
@@ -5,3 +5,3 @@ { | ||
| "description": "Shared Claude Code baseline structure and conventions for every repository.", | ||
| "version": "0.3.0" | ||
| "version": "0.3.2" | ||
| } | ||
@@ -12,3 +12,3 @@ }, | ||
| "silent-execution", | ||
| "grillme" | ||
| "critic" | ||
| ], | ||
@@ -15,0 +15,0 @@ "agents": [ |
+8
-0
@@ -6,2 +6,10 @@ # Changelog | ||
| ## [0.3.2] - 2026-04-27 | ||
| ### Changed | ||
| - fix: scrub remaining grillme references from product-manager agent prose | ||
| ## [0.3.1] - 2026-04-27 | ||
| ### Changed | ||
| - feat: replace grillme skill with critic in baseline catalog | ||
| ## [0.3.0] - 2026-04-27 | ||
@@ -8,0 +16,0 @@ ### Changed |
+1
-1
| { | ||
| "name": "kyos-cli", | ||
| "version": "0.3.0", | ||
| "version": "0.3.2", | ||
| "description": "Bootstrap and safely evolve a shared Claude Code repo structure.", | ||
@@ -5,0 +5,0 @@ "author": "Eugene", |
| --- | ||
| name: grillme | ||
| description: Critically interrogates a project and its README — finds gaps, wrong claims, missing context, and anything a skeptical reader would trip over. | ||
| --- | ||
| # Grillme | ||
| A blunt, adversarial review skill. Use it when you want an honest outside-eye on the project before shipping, publishing, or demoing. | ||
| ## What it does | ||
| Read the project README and any supporting docs, then interrogate the project like a skeptical senior engineer who has never seen it before. The goal is to surface real problems, not to be comprehensive for its own sake. | ||
| ## Review checklist | ||
| ### README accuracy | ||
| - Does the quickstart actually work? Are commands correct and complete? | ||
| - Are claimed features present in the codebase? | ||
| - Are version numbers, badge links, and npm package names accurate? | ||
| - Is the installed layout diagram current? | ||
| ### Clarity and audience fit | ||
| - Would a new user understand what this tool does in the first two sentences? | ||
| - Are prerequisites (Node version, npm, OS) stated or implied clearly enough? | ||
| - Are error states or failure modes mentioned anywhere? | ||
| ### Missing coverage | ||
| - Are there commands or flags in the code with no README entry? | ||
| - Are there architectural decisions in the code that contradict the docs? | ||
| - Is the multi-repo rollout section realistic for a Windows user? | ||
| ### Project health signals | ||
| - Does the test suite cover the advertised behavior? | ||
| - Are there open TODOs or known gaps that a user would be surprised to discover? | ||
| ## Output format | ||
| Return findings as a punchy numbered list. For each issue: | ||
| 1. State the problem plainly. | ||
| 2. Quote the offending line or section (if applicable). | ||
| 3. Suggest the fix in one sentence — or flag it as "needs human decision" if the answer is genuinely unclear. | ||
| Do not pad the list. Five real problems beat fifteen nitpicks. | ||
| ## Local additions | ||
| Add repo-specific review criteria here (e.g. "also check the catalog registry matches the --add CLI flags"). |
New alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Found 1 instance in 1 package
Fixed alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Found 1 instance in 1 package
Worsened metrics
- Total package byte prevSize
95972
-0.01%No dependency changes