Run any Skill in Manus with one click

dialectic

Stars25

Forks1

UpdatedJuly 2, 2026 at 09:33

Prove and counter-prove a claim with parallel agents before concluding. Use for architecture claims, bug hypotheses, performance claims, refactor safety, review judgments, and "is this actually true?" questions.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

arsenyinfo

arsenyinfo/skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Computer Occupations, All OtherComputer and Mathematical Occupations·SOC 15-1299

SKILL.md

readonly

name	dialectic
description	Prove and counter-prove a claim with parallel agents before concluding. Use for architecture claims, bug hypotheses, performance claims, refactor safety, review judgments, and "is this actually true?" questions.
argument-hint	<claim>
compatibility	external review tool (e.g. codex:codex-rescue or opencode) is recommended

Run a dialectic check on: $ARGUMENTS

The goal is to reduce confirmation bias, not to generate debate theater.

Proportionality: if a single command or test can decide the claim, run it and skip the parallel agents entirely; report the evidence in the same output format.

Workflow

Restate the claim in one precise sentence. If the claim is vague, narrow it before launching agents; if narrowing changes the claim's meaning, confirm the restatement with the user first.
Launch two read-only reviewers in parallel, in a single message. Each reviewer prompt must state "investigate only; do not modify the working tree". Prefer one reviewer from a different model/tool for independence, e.g. codex:codex-rescue when available, usually as Antithesis. If no independent reviewer is available, use two separate subagents with opposing prompts:
- Thesis: find the strongest evidence that the claim is true.
- Antithesis: find the strongest evidence that the claim is false, risky, or incomplete.
Require concrete evidence: file paths, line numbers, failing/passing command output, data, logs, or docs. Agents must say when evidence is missing.
Verify the important cited evidence yourself by reading the referenced code or output. Do not trust agent summaries blindly.
Synthesize the result as one of: true, false, mixed, or unknown.
If the result affects implementation, state the smallest next action: proceed, change design, add a test/experiment, or ask the user.

Output

Use this structure:

**Claim:** ...

**Thesis evidence:**
- ...

**Antithesis evidence:**
- ...

**Verified conclusion:** true | false | mixed | unknown

**Next action:** ...

Rules

Evidence beats symmetry. Do not split the difference when one side has stronger proof.
Prefer one strong finding over many weak guesses.
Mark speculation as speculation.
If evidence conflicts, propose the smallest test or experiment that would decide it.
Do not implement changes inside the dialectic unless the user already asked for implementation and the conclusion clearly supports it.

More from this repository

same repository

tokenmaxxer

arsenyinfo/skills

Serious engineering work with a reviewed plan and adversarial review gates; the required first argument word picks the mode. `build` — features, root-caused fixes, cross-cutting changes (trivial ones skip planning, never the diff gate). `refactor` — consolidate one accreted component, behavior-preserving. `sweep` — unattended overnight cleanup of a named area, shipped as draft PRs. `experiment` — metric-driven experimentation: approved hypothesis tree, autonomous batch of runs, next-batch report. `followup` — work recorded out-of-scope findings with the user's decisions; no required argument. Invoke explicitly, e.g. `/tokenmaxxer refactor <component>`.

2026-07-0525

ml-project

arsenyinfo/skills

Guidelines for ML projects. Use when training or evaluating models, building ML pipelines, running experiments, or working with datasets/parquet files and CatBoost/PyTorch/Polars code.

2026-07-0225

rust-webapp

arsenyinfo/skills

Build full-stack web applications using Rust (Axum + SQLx) with server-rendered frontend patterns using HTMX + Alpine.js or DataStar, plus Neon (serverless PostgreSQL). Use when asked to create web apps, CRUD apps, dashboards, forms, or any stateful web application. Triggers on requests like "build a todo app", "create a voting app", "make a dashboard", "build a blog", etc.

2026-07-0225

investigate

arsenyinfo/skills

Evidence-first debugging and root cause investigation. Use for triaging bugs, test failures, incidents, performance regressions, flaky behavior, integration failures, or unexplained behavior before proposing fixes.

2026-07-0225

spymaster

arsenyinfo/skills

Design, build, audit, and improve the harness around an LLM agent — its tools, loop, permissions, context, skills, and evals. Use when building, reviewing, or debugging any agentic system: an agent runtime or loop, agent-facing tools, an MCP server, an approval/permission flow, a context or memory strategy, an eval suite, or an existing agent that underperforms (flaky, wrong tool calls, retry loops, burning tokens) — even when the request just says "add a tool" or "make the agent do X" without naming a harness. Provider-neutral (OpenAI, Anthropic, MCP). Not for ordinary app features that don't change agent behavior, tool execution, context, permissions, or validation.

2026-07-0225

name	dialectic
description	Prove and counter-prove a claim with parallel agents before concluding. Use for architecture claims, bug hypotheses, performance claims, refactor safety, review judgments, and "is this actually true?" questions.
argument-hint	<claim>
compatibility	external review tool (e.g. codex:codex-rescue or opencode) is recommended

Run a dialectic check on: $ARGUMENTS

The goal is to reduce confirmation bias, not to generate debate theater.

Proportionality: if a single command or test can decide the claim, run it and skip the parallel agents entirely; report the evidence in the same output format.

Workflow

Restate the claim in one precise sentence. If the claim is vague, narrow it before launching agents; if narrowing changes the claim's meaning, confirm the restatement with the user first.
Launch two read-only reviewers in parallel, in a single message. Each reviewer prompt must state "investigate only; do not modify the working tree". Prefer one reviewer from a different model/tool for independence, e.g. codex:codex-rescue when available, usually as Antithesis. If no independent reviewer is available, use two separate subagents with opposing prompts:
- Thesis: find the strongest evidence that the claim is true.
- Antithesis: find the strongest evidence that the claim is false, risky, or incomplete.
Require concrete evidence: file paths, line numbers, failing/passing command output, data, logs, or docs. Agents must say when evidence is missing.
Verify the important cited evidence yourself by reading the referenced code or output. Do not trust agent summaries blindly.
Synthesize the result as one of: true, false, mixed, or unknown.
If the result affects implementation, state the smallest next action: proceed, change design, add a test/experiment, or ask the user.

Output

Use this structure:

**Claim:** ...

**Thesis evidence:**
- ...

**Antithesis evidence:**
- ...

**Verified conclusion:** true | false | mixed | unknown

**Next action:** ...

Rules

Evidence beats symmetry. Do not split the difference when one side has stronger proof.
Prefer one strong finding over many weak guesses.
Mark speculation as speculation.
If evidence conflicts, propose the smallest test or experiment that would decide it.
Do not implement changes inside the dialectic unless the user already asked for implementation and the conclusion clearly supports it.