Gougoubi Recovery Ops

Detect and repair partial failures in Gougoubi PBFT operations, including missing activation, missing risk LP, missing results, and pending reward claims. Us...

Security Scan

The skill's stated purpose (repair on-chain Gougoubi PBFT workflows) is plausible, but the runtime instructions reference local transaction scripts that are not included and never describe how signing/RPC credentials are provided — a notable mismatch that needs clarification before use.

Purpose & Capability

The skill claims to detect and repair on-chain PBFT conditions (activations, LP, results, claims). Those operations normally require a web3 provider endpoint and a signing key (private key, hardware signer, or similar). The skill declares no required environment variables, credentials, or config paths, and the packaged files do not include the referenced transaction scripts; this mismatch suggests the skill cannot perform its claimed purpose as-is or is missing clear instructions for required secrets/credentials.

Instruction Scope

SKILL.md instructs the agent to scan proposals and execute recovery modules implemented by several scripts (e.g., scripts/pbft-activate-and-add-risklp.mjs). The package does not include those scripts; INSTALL.md even warns to verify they exist in the local project checkout. The instructions do not explain how to obtain or use signer credentials, RPC endpoints, or safe dry-run modes, so following them could cause the agent to attempt transactions without clear authorization guidance.

Install Mechanism

There is no install spec (instruction-only), which limits direct disk changes by the skill itself. However, INSTALL.md gives manual install steps and explicitly tells users to confirm the recovery scripts exist in the local project. The absence of an automatic install reduces some risk, but it also means the skill depends on external project files that must be inspected before use.

Credentials

The skill requests no environment variables or credentials while its operation (submitting on-chain transactions and claiming rewards) would reasonably require RPC URLs and signing credentials. This under-declaration is disproportionate and potentially dangerous: the skill should explicitly declare what secrets it needs and how they are used; currently that is missing.

Persistence & Privilege

The skill is not always-enabled, is user-invocable, and has no install-time mechanism that would persistently modify other skills or system-wide settings. There is no evidence it requests elevated platform privileges.

What to consider before installing

Do not run this skill in a live environment until you verify and inspect the referenced scripts. Specifically: (1) Confirm that the listed scripts (scripts/*.mjs) exist in the repository you will use and review their source to see exactly which RPC endpoints and private keys they read or require. (2) Ensure the skill documents how signing is handled (private key vs. hardware wallet vs. offline signing) and only provide credentials via safe, auditable means. (3) If you must test, run on a forked or testnet environment and prefer a dry-run / simulation mode. (4) If the scripts are missing, ask the publisher for the complete code and an explicit description of required environment variables before granting the skill any ability to submit transactions. Because the package lacks the recovery scripts and does not document credential needs, treat it as incomplete and potentially risky until those gaps are resolved.

Use this skill to scan a proposal, identify gaps, and repair only the missing parts.

Use This Skill When

• A batch activation or LP workflow partially failed.
• Some conditions still have result=0.
• Rewards may be claimable but have not been claimed.
• The user wants targeted repair instead of rerunning everything.

Do Not Use This Skill When

• The user wants a fresh proposal creation flow.
• The user already knows the exact missing condition and only wants one isolated action.

Input

{
  "proposalAddress": "0x...",
  "repair": [
    "activate-missing",
    "risklp-missing",
    "submit-result-missing",
    "claim-pending"
  ],
  "riskLpPerCondition": "optional",
  "forcedResultForPending": "yes|no|optional"
}

Reviewer + Repair Flow

Step 1: Scan all proposal conditions and classify gaps.

Step 2: Report detections by repair class:

• activateMissing
• riskLpMissing
• resultMissing
• claimPending

Step 3: Build the smallest possible repair plan.

Step 4: Execute only the requested repair modules.

Step 5: Re-scan and return the final report.

Checkpoints

• Do not rerun healthy conditions.
• Prefer single-condition or smallest-scope repair first.
• Keep detection counts separate from repaired counts.

Output

{
  "ok": true,
  "proposalAddress": "0x...",
  "detected": {
    "activateMissing": 0,
    "riskLpMissing": 0,
    "resultMissing": 0,
    "claimPending": 0
  },
  "repaired": {
    "activate": 0,
    "riskLp": 0,
    "result": 0,
    "claim": 0
  },
  "txHashes": [],
  "failed": [],
  "warnings": []
}

Failure:

{
  "ok": false,
  "stage": "scan|repair|confirm",
  "error": "reason",
  "retryable": true
}

Project Scripts

• scripts/pbft-activate-and-add-risklp.mjs
• scripts/pbft-submit-all-condition-results.mjs
• scripts/pbft-submit-real-results-ba0c-resolved-only.mjs
• scripts/pbft-submit-remaining-no-ba0c.mjs
• scripts/pbft-claim-rewards-profile-method.mjs

Boundaries

• Recovery runs must stay idempotent where possible.
• Do not widen scope beyond the user's requested repair set.