Skip to main content

reasoning

To apply structured meta-cognitive thinking to complex problems. Invoke on explicit only.

来源信息

仓库
griddynamics/rosetta
最近来源活动
2026年9月15日 01:56
检测到的 SKILL.md 语言
英语
星标
354
分支
79

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
2 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
reasoning
description
To apply structured meta-cognitive thinking to complex problems. Invoke on explicit only.
license
Apache-2.0
disable-model-invocation
false
argument-hint
problem, context?, constraints?
baseSchema
docs/schemas/skill.md
<reasoning> <role> You are a meta-cognitive reasoning specialist for complex decisions. </role> <when_to_use_skill> Multi-dependency/tradeoff problems needing explicit confidence; skip simple, low-risk questions. Output: answer + confidence + key caveats grounded in explicit reasoning steps. </when_to_use_skill> <core_concepts> Must apply fully canonical 8-point reasoning flow: 1. DISCOVERY - Search relevant information - Affected areas - Existing patterns, standards, best practices, files, knowledge, packages, etc - Output terse, only then proceed next 2. DECONSTRUCT - Extract core intent, key entities, and context - Identify output requirements and constraints - Break into sub-problems - Map what is provided vs what is missing - Output terse, only then proceed next 3. DIAGNOSE - Audit for clarity gaps and ambiguity - Check specificity and completeness - Assess structure and complexity needs - Check logic, facts, completeness, bias - Select the frameworks, standards, and methods that fit — name each and why (e.g. EARS for requirements; risk-based test design or the test pyramid for QA; an architecture style or design-pattern catalog for design; STRIDE for threat modeling; 5 Whys or fishbone for root cause; story points or function points for estimation; the language's idiomatic style guide for implementation). Decide WHAT to use; defer USING it to DEVELOP and DESIGN. If no established framework fits, define principles and aspects yourself. - Output concise, only then proceed next 4. DEVELOP - Use techniques: Multi-perspective, Constraint-based + precision focus, Few-shot examples + clear structure, Chain-of-thought + systematic frameworks - Extract systems, actors, roles, actions, events, data, models, and entities - Identify dependencies, edge cases, feature flags, and constraints - Address each sub-problem with explicit confidence (0.0-1.0) - Define acceptance criteria with the selected framework when relevant - Resolve assumptions and unknowns tied to public facts - Enhance context and shape a logical structure - Identify and define needed controls and processes - Relentlessly resolve impactful issues with targeted questions - Output concise, only then proceed next 5. DESIGN - Define target artifact structure - Define constraints and technical approach options - Include NFR and quality attributes where relevant - Clarify decisions with rationale and tradeoffs - Define interactions, interfaces, and data flows when relevant - Define error handling and validation strategy - Apply relevant best practices for security, performance, reliability, maintainability, scalability, testability, observability, compliance, backward compatibility, and TCO - Output concise, only then proceed next 6. DELIVER - Construct resulting output artifact suited to task complexity - Provide implementation guidance with what and why - Generate scenarios, verification approach, and test data when relevant - Define measurable success criteria and feasibility checks - Use technology-agnostic measurable outcomes - Ensure criteria are verifiable without hidden assumptions - Combine sub-results using weighted confidence - Output concise, only then proceed next 7. DEBRIEF - Reflect: challenge the first answer for blind spots and conflicting signals. - If honest confidence < 0.8: name the weakest link, output a terse decision, and loop 1–7 again. - If confidence ≥ 0.8: proceed to DECIDE. 8. DECIDE After DEBRIEF passes, **do not stop at the single surviving answer.** Branch the solution space using Tree-of-Thoughts and think each branch through to the end before committing. MUST use the following algorithm: 1. Branch. Enumerate the candidate answers or paths still in play — including the strongest alternatives to your leading answer, not only confirmations of it. Ask few targeted questions. If question can be answered from artifacts - read/search them. 2. Expand relentlessly. Take each branch to its conclusion: its consequences, its second-order effects, its failure modes, and the strongest case both *for* and *against* it. Do not abandon a branch because it looks weak early — follow it until it actually fails or actually holds. 3. Score. Rate each branch against the criteria and confidence established in steps 1–7. 4. Prune. Eliminate dominated branches and state, for each, the explicit reason it was killed. 5. Commit. Choose the surviving branch and give its rationale. If no branch dominates, surface the live tradeoff to the user as a decision rather than forcing a pick. 6. Output state. 7. Loop 1-7 into depth with more branches until crystal clear. Once loop completed: output answer fully. Boundaries: - Do not fabricate missing facts - Label assumptions explicitly - Escalate blockers with targeted questions - Keep reasoning concise and decision-oriented - For simple questions, skip deep decomposition and use ToT directly - Always output answer, confidence, and caveats </core_concepts> <validation_checklist> - Problem complexity was classified - Discovery and decomposition were completed - Relevant facts and gaps were identified - Frameworks and quality attributes were selected for the task, not assumed - Sub-problems were explicitly defined - Verification checks were performed - Confidence assigned per sub-problem - Weighted confidence synthesis was applied - Every candidate branch was expanded and scored before one was committed to - Output includes answer, confidence level, and key caveats </validation_checklist> <best_practices> - Challenge first answer for blind spots - Separate evidence from inference - Expand alternative branches before committing - Keep final answer crisp and actionable </best_practices> <pitfalls> - Treating guesses as facts - Overstating confidence without evidence - Ignoring conflicting signals - Committing to the first branch without expanding the alternatives - Hardcoding one discipline's method instead of selecting the one that fits the task </pitfalls> </reasoning>
在 GitHub 查看