From autodialectics
Examine Autodialectics run results, manifests, and stored artifacts. Use after a pipeline run completes or to review past runs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/autodialectics:inspectThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill to examine completed or in-progress pipeline runs and their artifacts.
Use this skill to examine completed or in-progress pipeline runs and their artifacts.
autodialectics-mcp must be on PATH (pip install autodialectics).
inspect_run(run_id) — retrieve the run manifest: status, decision, scores, timing, and artifact paths.read_artifact(run_id, artifact_name) — read a specific artifact by filename. Artifacts by pipeline stage:
submission.json — the original task submissioncontract.md — the immutable task contract (Markdown)evidence.json — gathered evidence bundle from the exploration stagedialectic.json — thesis/antithesis/synthesis from the dialectical plannerexecution.json — domain executor resultsverification.json — independent verification outputevaluation.json — slop scores and gate decisionsummary.md — human-readable run summarybenchmark_report.json — benchmark-specific metrics (only present for benchmark runs)autodialectics inspect <run_id>
inspect_run to get the overview, then drill into specific artifacts with read_artifact.running or starting, it may still be in progress — wait and re-inspect.verification.json against evaluation.json to understand whether the verifier and evaluator agree.dialectic.json to see how the planner resolved competing concerns (thesis vs antithesis).If the user passes a run ID after /autodialectics:inspect, inspect that run and summarize the results.
npx claudepluginhub hmbown/plugins --plugin autodialecticsGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Implements work from a spec or tickets using TDD at agreed seams, with regular typechecking and test runs, followed by code review.