Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

reasoning-semiformally

Estrellas0

Forks0

Actualizado8 de junio de 2026 a las 11:34

Apply semi-formal certificate reasoning to code analysis — patch verification, fault localization, patch equivalence. Use when reviewing patches, hunting bugs across scopes, comparing fixes, tracing execution across files/modules, analyzing name shadowing or scope resolution, or checking for regressions.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

antstanley

antstanley/skills

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·SOC 15-1253

Explorador de archivos

3 archivos

SKILL.md

readonly

name	reasoning-semiformally
description	Apply semi-formal certificate reasoning to code analysis — patch verification, fault localization, patch equivalence. Use when reviewing patches, hunting bugs across scopes, comparing fixes, tracing execution across files/modules, analyzing name shadowing or scope resolution, or checking for regressions.

Semi-Formal Code Reasoning

Structured certificate templates that force mandatory checkpoints before conclusions.

Skip Conditions

Do NOT apply semi-formal reasoning when:

The change is trivial: docs, formatting, version bumps, config changes
The bug is locally obvious: typo, off-by-one in the same function, missing comma
No execution paths cross scope boundaries
The task is not code analysis (text editing, data extraction, summarization)

If any skip condition is met, proceed with standard reasoning.

Model-Specific Instructions

If you are Haiku-class (Haiku 4.5 or similar): Read haiku.md in this skill directory. It contains full procedural templates with worked examples.

If you are Sonnet-class or above (Sonnet 4.6, Opus): Read sonnet.md in this skill directory. It contains compact verification checkpoints.

Composing Tasks

For complex tasks, apply templates sequentially:

Fault localization to find the bug
Patch verification to validate a proposed fix
Patch equivalence to compare alternative fixes

Each output feeds the next as premises.

Más de este repositorio

mismo repositorio

semi-formal-review

antstanley/skills

Review an implemented change with a semi-formal certificate to decide whether it correctly and completely does what was asked without breaking what it touched. The mandatory correctness gate after a spec-builder task is implemented, run by an agent other than the one that wrote the code. Triggers on "semi-formal review of the diff", "is this implementation correct", or spec-builder dispatching a post-implementation review. Produces a CORRECT / LIKELY_CORRECT / CONCERNS / BUGGY verdict. For a done-vs-definition-of-done check use validate-done-certificate; for a standalone patch verification or bug hunt outside a spec-builder build, use reasoning-semiformally.

2026-07-050

spec-builder

antstanley/skills

Implement a spec-planner plan by dispatching one sub-agent per task in its own isolated workspace (jj or git, jj preferred), gating every task through a semi-formal correctness review and a definition-of-done validation before it is merged and marked Done. Self-contained — workspace isolation is vendored, no other plugin required. Walks the dependency graph in waves, parallel by default (max 4 agents) or sequential. Triggers on "build this plan", "implement the plan", "execute the plan in .specs/plans/...", or handing a spec-planner plan folder over for implementation.

2026-07-050

development-guidelines

antstanley/skills

Add a development-guidelines page to a canonical spec — the "rules of the road" (toolchain, code style, defensive coding, limits, version control, testing, AI-agent rules, definition of done) rendered in a chosen coding style for the languages a repo uses. Triggers on "add development guidelines", "generate coding guidelines", "add coding standards to the spec", or when spec-creator needs its development-guidelines.md page. Produces a single global spec page at .specs/development-guidelines.md (or a thin per-package delta) following spec-creator's conventions.

2026-07-050

spec-creator

antstanley/skills

Create, expand, or change formal design specifications for an app, package, or codebase. Triggers on "create/write a spec", "document the design", "promote to a global spec", or proposing/merging a change spec ("draft a change spec", "RFC for X", "merge the change spec"). Output is a numbered, layered directory of markdown plus a JSON Schema sidecar (repo-wide globals + per-package specs); a change spec is a single document under .specs/changes/. To plan a spec's implementation, use spec-planner; to build that plan, use spec-builder.

2026-07-050

spec-reviewer

antstanley/skills

Review a canonical or change spec for inconsistencies, divergence, and implementation status, using semi-formal certificate templates. Three modes — (1) a change spec vs the canonical spec it targets (broken references, stale targets, contradictions); (2) a canonical spec vs the code (missing or incorrect implementations, and shipped features the spec never captured); (3) a change spec vs the code (whether its delta has shipped — none/partial/implemented — and which gaps remain). Triggers on "review the spec", "does the implementation match the spec", "find spec divergences", or "has this change spec been implemented". For a single planned task's done-ness use validate-done-certificate instead.

2026-07-050

done-certificates

antstanley/skills

Author a task-specific semi-formal done certificate — a structured verification protocol that a separate validating agent runs to decide whether a task is complete. For each task it restates the definition of done as proof obligations, names the exact evidence to collect and the resolution/regression checks to run, and leaves the status and verdict blank for the validator to discharge. Triggers on "create a done certificate", "add done certificates to the plan", or "generate a completion certificate". Works standalone over any task with a definition of done, and is the companion certificate-author for spec-planner task packages — one certificate per task. To run (discharge) an authored certificate, use validate-done-certificate instead.

2026-07-050

name	reasoning-semiformally
description	Apply semi-formal certificate reasoning to code analysis — patch verification, fault localization, patch equivalence. Use when reviewing patches, hunting bugs across scopes, comparing fixes, tracing execution across files/modules, analyzing name shadowing or scope resolution, or checking for regressions.

Semi-Formal Code Reasoning

Structured certificate templates that force mandatory checkpoints before conclusions.

Skip Conditions

Do NOT apply semi-formal reasoning when:

The change is trivial: docs, formatting, version bumps, config changes
The bug is locally obvious: typo, off-by-one in the same function, missing comma
No execution paths cross scope boundaries
The task is not code analysis (text editing, data extraction, summarization)

If any skip condition is met, proceed with standard reasoning.

Model-Specific Instructions

If you are Haiku-class (Haiku 4.5 or similar): Read haiku.md in this skill directory. It contains full procedural templates with worked examples.

If you are Sonnet-class or above (Sonnet 4.6, Opus): Read sonnet.md in this skill directory. It contains compact verification checkpoints.

Composing Tasks

For complex tasks, apply templates sequentially:

Fault localization to find the bug
Patch verification to validate a proposed fix
Patch equivalence to compare alternative fixes

Each output feeds the next as premises.