# Hyperion Gpu Proofflow V0 1 Proofflow V0 1 > ProofFlow Maintainer - Skill: `tomevault-io/hyperion-gpu-proofflow-v0-1-proofflow-v0-1` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/hyperion-gpu-proofflow-v0-1-proofflow-v0-1` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/hyperion-gpu-proofflow-v0-1-proofflow-v0-1/raw - Safety review: pending (external: skill-scanner PASS, skillspector CAUTION) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/hyperion-gpu-proofflow-v0-1-proofflow-v0-1 --- # ProofFlow Maintainer Use this skill when the user asks to use ProofFlow from Codex for repository maintenance, including: - keep an Agent Work Ledger for complex code tasks, - review the current diff with ProofFlow, - create or export a Proof Packet for a PR, - triage issue text into a ProofFlow Case, - inspect or continue an existing ProofFlow Case, - preserve evidence, decisions, actions, and policy gates while maintaining a repository. Default to Agent Work Ledger for complex coding work. Use narrower workflows when the user's intent is clearly review-only, issue-intake-only, or packet export-only. ## Operating Principles - Keep the workflow local-first. The default ProofFlow backend is `http://127.0.0.1:8787`. - Prefer ProofFlow MCP tools over ad hoc notes when recording Cases, Artifacts, Claims, Actions, Decisions, or Proof Packets. - Treat the current AgentGuard review as provenance-first unless the returned Claims contain specific semantic findings. It proves what diff was reviewed and what evidence was captured; it does not by itself guarantee a complete semantic code review. - Do not treat AI output as trusted unless it points to evidence. If evidence is missing, label the statement as an assumption. - Do not run tests through ProofFlow unless the user explicitly asks and the backend is configured to allow test command execution. - Do not merge PRs, close issues, or bypass policy gates unless the user explicitly asks and the repository workflow allows it. ## Startup Check Before running a ProofFlow workflow: 1. Call `proofflow_health`. 2. If the MCP server or backend is unavailable, tell the user to start the backend and install `proofflow-mcp` if needed: ```bash pip install proofflow-mcp cd backend python -m uvicorn proofflow.main:app --port 8787 ``` ## Choose The Workflow - Use **Agent Work Ledger** for complex code tasks, multi-file changes, feature work, behavior changes, risky local actions, or any task that needs contract, algorithm decisions, cost budgets, snapshots, Evidence, Claims, done criteria evaluation, and packet export. - Use **AgentGuard review** when the user only asks to review a current diff, PR, or branch changes. - Use **Issue Triage** when the user provides issue text, logs, reproduction steps, or a bug report and wants it captured as a ProofFlow Case. - Use **Status / Proof Packet export** when a Case already exists and the user wants a handoff artifact or review summary. ## Review The Current Diff Use this path for prompts like "review current diff with ProofFlow". 1. Identify the repository root from the current workspace. 2. Decide whether the user means uncommitted work or a committed PR/branch: - For uncommitted local work, the ProofFlow default base is acceptable. - For a PR, branch review, or clean committed checkout, require a PR base ref and pass it to ProofFlow. Do not rely on the MCP/backend default, because the default is `HEAD` and a clean PR checkout would produce an empty diff. 3. Choose the base ref conservatively: - Use the user's requested base when provided. - Otherwise infer the base branch name from PR context when available, such as `gh pr view --json baseRefName`, `GITHUB_BASE_REF`, or the repository's tracked default branch. - Treat short names like `main` as branch names, not backend-ready refs. 4. Resolve the PR base before calling ProofFlow: - Prefer an existing local ref such as `refs/remotes/origin/` or a verified user-provided commit SHA. - If only a short branch name is available and no matching local ref exists, fetch the base branch from `origin` first, for example `git fetch --no-tags origin +refs/heads/:refs/remotes/origin/`. - Compute `git merge-base HEAD ` and pass that merge-base SHA as `base_ref`. - If the base cannot be resolved or fetched, ask for a usable base ref before calling ProofFlow. 5. Call `proofflow_review` with `repo_path`. Include the resolved merge-base `base_ref` whenever the workflow is reviewing committed PR or branch changes. 6. Do not pass a `test_command` unless the user asked for ProofFlow to run one. 7. Export the resulting Case with `proofflow_export_packet`. 8. Read the returned Claims before describing review depth. If the only Claim is a broad provenance claim such as changed file count, say that the packet captures review provenance but does not yet contain a deep semantic review. 9. Summarize: - Case ID, - base branch inferred or requested, - resolved base ref or merge-base SHA used, or that the workflow reviewed uncommitted work against the default base, - risk level or review status, - changed file count, - claim and evidence counts, - Proof Packet path, - findings that have evidence, - assumptions or missing evidence. ## Create A Proof Packet For A PR Use this path when a review Case already exists or when the user wants a packet for the current PR. 1. If the user gives a Case ID, call `proofflow_status` for that Case. 2. If no Case ID exists, run a PR-base review before exporting: - Use the user's requested base when provided. - Otherwise infer the PR base branch name from `gh pr view --json baseRefName`, `GITHUB_BASE_REF`, or the tracked default branch. - Resolve the base to an existing local ref or commit. If only a short branch name is available, fetch `origin/` before reviewing. - Compute `git merge-base HEAD ` and pass that SHA as `base_ref`. - If the base cannot be inferred, resolved, or fetched, ask for it instead of falling back to a default `HEAD` diff. 3. Call `proofflow_review` with `repo_path` and the resolved merge-base `base_ref`. This is required for clean PR checkouts, where an unqualified current-diff review would omit committed PR changes or fail when a short branch name is not available locally. 4. Call `proofflow_export_packet`. 5. Return the packet path, base branch, resolved base ref or merge-base SHA, and a concise PR-ready summary. 6. Do not post to GitHub unless the user explicitly asks. ## Triage Issue Text Into A Case Use this path when the user provides issue text, logs, reproduction steps, or a bug report and wants it captured in ProofFlow. 1. Extract the issue `title`, `body`, optional `source_url`, and labels from the user's text or the current issue context. 2. Call `proofflow_triage_issue` with that data. 3. Read the returned component, suggested labels, risk level, and completeness signals for reproduction steps, expected behavior, and environment details. 4. Call `proofflow_status` when you need the full Claims and Evidence. 5. Export the Case with `proofflow_export_packet` if the user asks for a shareable triage record. 6. Summarize: - Case ID, - captured source issue URL if available, - inferred component, - suggested labels, - missing triage evidence, - evidence-backed Claims, - recommended next step. 7. Do not create temporary issue markdown files unless the direct triage tool is unavailable and the user agrees to the fallback path. ## Agent Work Ledger For Complex Code Tasks Use this path when the task spans multiple files, requires several tool calls, or changes behavior that should be auditable later. 1. Start from a Case. If no suitable Case exists, create one with the most relevant ProofFlow workflow before making claims about the work. 2. Keep a short ledger while working: - Goal: the user-requested outcome. - Scope: files or modules intentionally touched. - Algorithm decision: the selected approach, alternatives considered, invariants, and forbidden approaches before implementation. - Cost budget: expected expensive operations and limits for token, API, GPU, CPU, runtime, or iteration cost. - Evidence: commands run, test results, diffs, screenshots, or source material used to support claims. - Decisions: user approvals, policy gate decisions, or notable tradeoffs. - Open risks: assumptions, skipped tests, or evidence still missing. 3. Use ProofFlow tools for durable records when available: - `proofflow_start_work_contract` before implementation, - `proofflow_record_algorithm_decision` before choosing an important or costly approach, - `proofflow_record_cost_budget` before expensive operations, - `proofflow_capture_snapshot` for start/checkpoint/final repo state, - `proofflow_record_evidence` for command output and test output, - `proofflow_record_claim` for evidence-backed claims, - `proofflow_evaluate_contract` before finish, - `proofflow_explain_risk_hint` when a maintainer accepts, mitigates, defers, or marks a Risk Hint as a false positive with Evidence, - `proofflow_finish_work_ledger` after final snapshot and evaluation, - `proofflow_review` for code changes, - `proofflow_status` to inspect Claims and Evidence, - `proofflow_export_packet` for the final handoff packet. 4. Keep claims evidence-backed. Do not say a behavior is fixed unless a command, test, diff, or review artifact supports it. 5. After `proofflow_evaluate_contract`, read and report `risk_hints`. If hints are present, include them in known gaps or open review items even when the evaluation status is `ready_for_review`. 6. If tests are required for the workflow, run them outside ProofFlow unless the user explicitly asks ProofFlow to execute a `test_command`. 7. Close the handoff with the Case ID, packet path if exported, tests or checks run, known gaps, and the recommended next step. ## Policy Gates When an action is blocked with `pending_decision`: 1. Explain that ProofFlow requires an owner Decision before execution. 2. Use `proofflow_decide` only when the user has clearly accepted or rejected the gate. 3. After acceptance, call `proofflow_approve_execute` again only when the user wants the action executed. 4. Preserve the two-step semantics: decision first, execution second. ## Response Shape For completed ProofFlow workflows, report: - what Case was created or used, - what evidence was captured, - whether the packet is provenance-only or contains semantic Claims, - what packet or action was produced, - what was intentionally not done, - the recommended next step. --- > Source: [Hyperion-GPU/ProofFlow-v0.1](https://github.com/Hyperion-GPU/ProofFlow-v0.1) — distributed by [TomeVault](https://tomevault.io).