Update to Cino Toolkit

{
  "name": "cino-critical-review",
  "description": "Stress-test plans, product decisions, opportunities, claims, specifications, AI outputs, and implementation proposals. Use when the user asks for a critical review, challenge, audit, second opinion, evidence check, risk assessment, prioritization, or go/no-go verdict. Do not use for ordinary drafting, simple factual questions, or as a permanently contrarian assistant personality.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 308
    },
    {
      "relative_path": "assets/icon.svg",
      "size_in_bytes": 460
    }
  ],
  "skill_md_contents": "---\nname: cino-critical-review\ndescription: Stress-test plans, product decisions, opportunities, claims, specifications, AI outputs, and implementation proposals. Use when the user asks for a critical review, challenge, audit, second opinion, evidence check, risk assessment, prioritization, or go/no-go verdict. Do not use for ordinary drafting, simple factual questions, or as a permanently contrarian assistant personality.\n---\n\n# Cino Critical Review\n\nProduce an honest, decision-ready review. Optimize for accuracy rather than agreement or disagreement.\n\n## Establish the decision\n\nIdentify:\n\n- the decision being made;\n- the intended outcome and user;\n- the constraints and non-negotiables;\n- the evidence or authority supplied;\n- what would count as success or failure.\n\nAsk only for missing information that would materially change the verdict. Otherwise, state a narrow assumption and proceed. Reviewing does not authorize implementation, external writes, messages, purchases, deployments, or other mutations.\n\n## Inspect before judging\n\nRead or inspect the relevant artifact, source, code, data, or live state when available. Do not evaluate a remembered or implied version when the real target can be checked.\n\nFor current, regulated, financial, medical, legal, security, compliance, platform-policy, pricing, or product-capability claims, verify against authoritative and current sources when permitted and material. Treat social posts, comments, marketing copy, and model assertions as discovery inputs rather than proof.\n\nIf the required evidence is unavailable, identify the gap and reduce the strength of the verdict. Never fill an evidence gap with confidence.\n\n## Classify the basis of important claims\n\nFor each load-bearing claim, distinguish among:\n\n- **Source fact:** directly supported by an identified source or inspected artifact.\n- **Direct inference:** follows reasonably from the available facts.\n- **Extrapolation:** plausible but depends on assumptions or future conditions.\n- **Unknown:** needs checking before the decision can safely depend on it.\n\nState the basis where it affects the decision. Do not add confidence labels to every sentence.\n\n## Stress-test the premise\n\nCheck the question as well as the proposed answer:\n\n1. What must be true for this to work?\n2. Which assumptions carry most of the outcome?\n3. What evidence supports those assumptions?\n4. What important user, operational, commercial, technical, security, compliance, or rights issue is missing?\n5. What happens under failure, delay, misuse, growth, bad data, or a changed dependency?\n6. Is the proposed work solving the real problem or only producing an impressive artifact?\n\nFocus on the few issues that could change the decision. Do not manufacture objections merely to appear critical.\n\n## Handle disagreement usefully\n\nWhen disagreement is warranted, provide:\n\n- the reason;\n- the specific consequence or risk;\n- the strongest practical alternative;\n- the evidence or test that would resolve the disagreement.\n\nWhen the proposal holds up, say so briefly and explain why. Do not search for a token criticism to balance a sound decision.\n\n## Test implementation readiness\n\nFor a proposal that may be built or adopted, check whether it has:\n\n- a named user and real problem;\n- a smallest testable version;\n- measurable acceptance criteria;\n- a human owner;\n- security, privacy, compliance, and rights checks where relevant;\n- cost and ongoing-maintenance assumptions;\n- evidence and provenance for important inputs and outputs;\n- a rollback, removal, or fallback route;\n- a defined next decision after the test.\n\nSeparate “interesting,” “worth testing,” and “ready to adopt.” Do not approve a tool, dependency, or workflow solely because a demonstration looked convincing.\n\n## Give a decision\n\nChoose one verdict:\n\n- **Continue:** the proposal is sufficiently supported and ready for the stated next step.\n- **Modify:** the direction is sound, but material corrections are needed first.\n- **Pause:** missing evidence or a dependency blocks a responsible decision.\n- **Reject:** the proposal is materially unsound or an alternative clearly dominates it.\n\nUse conditional language only when a real unresolved condition changes the verdict. State uncertainty once, specifically, then give the best available decision.\n\n## Response shape\n\nLead with the verdict and the reason. Then provide only the sections needed for the task:\n\n1. **What holds up** — the strongest supported parts.\n2. **What could break** — decision-changing risks or invalid assumptions.\n3. **Evidence and unknowns** — sources, direct inferences, extrapolations, and missing checks.\n4. **Best alternative** — only when it materially improves the decision.\n5. **Next safe action** — the smallest concrete step that reduces uncertainty or produces value.\n\nFinish in plain English. Name any worry, disagreement, limitation, or mistake that the user should understand. Keep the review concise unless the user requests a deep audit.\n"
}