axioblade

Skill: Axioblade

Definition

Axioblade is a general reasoning and review framework for complex problem analysis and decision-making. Starting from first principles, it reconstructs the problem structure from basic facts and minimal assumptions, keeping elements independent while preserving decision-relevant completeness. Through axiomatic decomposition, information-gain-driven Grill me questioning, razor-based complexity control, sustained operating-cost constraints, and adversarial review, it improves correctness, explainability, and executability while suppressing over-engineering and hidden risk.

Scope

This skill applies to the following task types:

• •Overall architecture planning or system-level design decisions;
• •Multi-option tradeoff analysis or architecture decisions;
• •Automation processes and agent workflow design;
• •Engineering implementation, code changes, and system design;
• •Product design and strategy decisions;
• •Tasks requiring high reliability, low hallucination, or long-running operation;
• •Research investigation and factual judgment;
• •Academic research design and methodology selection;
• •Academic paper topic selection, structure design, and argument-path planning;
• •Academic experiment design, variable control, and result analysis;

Simple, low-risk tasks with clear boundaries should not use the full workflow.

Trigger Conditions

Activate this skill when the task involves any of the following:

• •The user explicitly requests rigorous reasoning, first-principles reasoning, cost constraints, adversarial review, Grill me, or deep analysis;
• •The goal, boundary, success criteria, or risks are unclear;
• •The task involves a long-running system or complex engineering;
• •Multiple solutions, technology stacks, or paths need to be weighed;
• •The task depends on external facts, tools, papers, benchmarks, or market information.

Core Principles

1. Axiomatic Decomposition

Build a minimal and as-complete-as-necessary problem structure from the most basic facts, constraints, goals, and assumptions.

Requirements:

• •Before decomposing, check whether the structure covers all key dimensions that could change the conclusion;
• •Keep elements at the same level as independent as possible, reducing overlap and hidden dependencies;
• •Control the number of elements and avoid adding categories merely to look complete;
• •Distinguish facts, inferences, and assumptions, and avoid mixing information with different epistemic status;
• •Avoid replacing concrete mechanisms or causal relationships with abstract but empty terms;
• •For complex problems, first ensure the structure covers the information needed to support the current decision, then compress and simplify without reducing judgment quality;
• •If completeness cannot be fully determined, explicitly mark potentially missing areas or uncertain boundaries.

2. Information-Gain-Driven Grill me

Grill me refers to interactive questioning focused on project boundaries, goals, constraints, success criteria, key assumptions, and tradeoff preferences. It is used to clarify boundaries that can affect the solution, not to ask questions for their own sake.

Ask only questions that could change the solution. Do not fix the number of questions or rounds.

Continue questioning until:

• •The goal, constraints, and success criteria are sufficient to support the decision;
• •Remaining unknowns would not significantly change the main solution;
• •The user cannot judge, but a reasonable default can be adopted;
• •The marginal information gain from further questioning is no longer sufficient to change the solution.

Each question should, where possible, include:

Question and why it affects the solution:
Possible answers:
Default choice:

Principles:

• •Control questioning intensity: prioritize high-impact uncertainties and avoid low-value debate;
• •Preserve the ability to ask follow-up questions: whenever a boundary could significantly change the solution, continue questioning or provide default options;
• •Avoid hallucination: explicitly mark uncertain information;
• •Aim to move forward: when a boundary issue is found, provide a correction, alternative path, or default assumption;
• •Make intelligent tradeoffs: align only on key points that could change the solution;
• •When the user cannot judge, the AI may choose a default based on current evidence and explain the basis.

3. Razor Principle

Start from the minimal sufficient solution by default, but do not mechanically pursue the simplest possible option.

Core principles:

• •Under the current constraints, usually prefer a cost-effective solution rather than the absolutely simplest one;
• •Simplification is the default strategy, but when a more complex solution is significantly better in effectiveness, stability, or sustained operating cost, allow the added complexity and briefly note why;
• •Avoid sacrificing long-term maintainability, extensibility, or overall operating cost for short-term simplification;
• •Complexity should match the problem scale, risk, and expected benefit rather than being compressed uniformly.

Default preferences, when no clearly superior option exists:

• •If simple rules can solve the problem, do not rush to introduce an LLM;
• •If an explicit workflow can connect the steps, do not rush to build an autonomous agent;
• •If a single agent can handle the task, do not rush to split it into multiple agents;
• •After necessary external research and multi-source verification, if a mature tool can satisfy the need, prefer reuse over self-development;
• •If a local fix is sufficient, do not start with a global refactor;
• •If small-scale validation is possible, do not jump directly into large-scale construction.

4. Sustained Operating-Cost Constraint

Here, cost mainly refers to the total cost incurred after the project is completed, deployed, or made runnable, across continuous operation, scaling, maintenance, and correction. It does not refer to the research, verification, or reasoning effort needed during development to improve correctness.

Costs include, but are not limited to, the following examples. Their weights should be evaluated dynamically for each project:

Model call cost, tool/API/cloud service cost, compute and storage cost, latency cost, human review and operation cost, maintenance cost, complexity cost, error and rollback cost, migration and scaling cost, opportunity cost

Principles:

• •Satisfy effectiveness and reliability first, then optimize sustained operating cost;
• •Minimize total cost only when doing so does not significantly reduce effectiveness, reliability, or maintainability;
• •Prioritize long-term, marginal, and post-scaling costs rather than one-time implementation cost alone;
• •Reduce unnecessary calls, context, toolchains, human intervention, and state complexity during system operation;
• •Do not trade away correctness, safety, or verifiability for cost reduction;
• •External research, multi-source verification, rigorous reasoning, and practical trial-and-error during development are necessary investments in solution quality and should not be mistaken for operating costs that must be minimized.

5. External Verification and Fact Layering

When factual judgment is involved, distinguish:

Verified facts / user-provided facts / external-source facts / reasonable inferences / temporary assumptions / unknowns:

Evidence priority:

1. Actual runtime results, logs, and tests;
2. Official documentation, source code, papers, and benchmarks;
3. First-party data and experiments;
4. High-quality analysis;
5. Community and open-platform information, used only as clues or supplements and subject to strict filtering.

Active research requirements:

• •Cross-verify key facts across multiple sources and avoid conclusions from a single source;
• •Prefer authoritative, timely, and broad-coverage platforms and sources;
• •Filter community information, such as Twitter, Zhihu, Xiaohongshu, Reddit, and Quora:

Prefer highly interacted and widely recognized content, but do not equate interaction volume with truth; Prefer authors with clear professional background, long-term activity, and stable history of high-quality output; Prefer content containing first-hand experience, data, screenshots, code, links, reproducible details, or traceable sources; Evaluate interaction data relatively, considering publish time, platform size, topic popularity, and same-topic baselines instead of relying on absolute numbers alone; Comment scale and discussion depth may be considered, for example whether there is enough substantive discussion, refutation, supplementation, or cross-validation of experience, but fixed thresholds should not be used mechanically; Avoid low-quality reposts, emotional expression, clickbait, advertorials, or strong claims without verification;

• •Treat community information only as clues or supplements, not as core factual evidence;
• •Mark, down-rank, or remove information that may be biased, outdated, or misleading.

Risk control:

• •Community and open platforms are high-noise, high-hallucination-risk sources, so filtering standards must be raised;
• •Key judgments should be traced back to higher-priority evidence whenever possible;
• •The model should actively identify conflicts, anomalies, and inconsistent conclusions, then review or down-rank them.

Unverifiable information must not be written as fact.

6. Adversarial Review

When the full workflow is activated, adversarial review is mandatory.

Adversarial review mainly happens after the overall solution is formed and before the final output, as an acceptance-stage review. It actively attacks the current solution, judgment chain, and key assumptions to expose counterexamples, hidden risks, implicit costs, and over-engineering tendencies. Its goal is to improve solution quality and robustness, not to create unproductive debate or block progress. If key risks or uncertainties are found, adjust the solution or mark the risk. If an unclear boundary would significantly affect the main solution, return to information-gain-driven Grill me for clarification, while controlling the scope and intensity of further questioning to avoid low-value repeated discussion.

Principles:

• •Control review intensity: prioritize high-impact risks and avoid low-value debate or repeated questioning;
• •Be oriented toward progress and outcomes: review should serve decision-making and implementation; when an issue is found, adjust the solution, mark the risk, or provide an alternative path rather than staying on the problem itself;
• •Limit low-value issues: avoid repeatedly challenging issues that have been sufficiently verified or have minimal impact on the solution;
• •Check whether key dependencies are fragile or unverified;
• •Check whether a simpler alternative path exists;
• •Check whether the solution is being misled by a local case or intuition;
• •Check whether overgeneralization or hidden assumptions exist;
• •Check whether long-term or runtime costs have been ignored;
• •Check whether hidden maintenance, testing, or rollback costs exist;
• •Check whether key judgments have sufficient evidentiary support;
• •Avoid hallucination: explicitly mark uncertain information;
• •Set a stopping condition: when additional review no longer significantly improves solution quality, stop deepening the review and proceed to execution or final output.

Execution Strategy

1. Lightweight Mode

Use this mode for relatively clear, lower-risk tasks that only require local judgment or quick advice.

Execution:

• •Do not explicitly expand the full structure;
• •Preserve only the necessary goal, basis, solution, risk, and next step;
• •Implicitly apply the razor principle, cost constraint, and fact layering;
• •Do not require a full information-gain-driven Grill me, but still avoid obvious hallucination and over-engineering.

2. Full Mode

Use this mode for most complex tasks, especially high-risk, long-running, complex-architecture, multi-option, external-fact-dependent, or user-requested deep-analysis tasks.

Execution:

• •First clarify key boundaries that could change the solution;
• •Build the necessary problem structure;
• •Identify the baseline solution and main candidate paths;
• •Review complexity, cost, risk, and evidence;
• •Externally verify important facts when necessary;
• •Apply razor review to complexity upgrades;
• •Analyze sustained operating cost;
• •Conduct adversarial review before final output;
• •Provide a complete conclusion, basis, default assumptions, solution, cost impact, risks, verification method, and next steps.