feat: submit pipefy-ipaas-flow-repair

[danielgualberto]

Skill

Folder / Pasta: submissions/danielgualberto/pipefy-ipaas-flow-repair/

What it does / O que faz: Diagnose an existing iPaaS flow from a failed/timed-out run, surgical patch, validate. Publish/retry only on explicit user intent.

Contact / Contato

Email: danielgualberto@live.com

Name for credit / Nome para crédito: Daniel Gualberto

The problem it solves / O problema que resolve

Failed runs were rebuilt from scratch instead of reading the run + current step tree.

What it built when you ran it / O que ela construiu quando você rodou

ap_get_run on a FAILED TESTING CODE run, surgical ap_update_step, ap_validate_flow, then sample-data SUCCEEDED. Playbook flow was not mutated. Disposable flow was later published and left DISABLED. See EVIDENCE.md.

What you had to fix / O que você teve que corrigir

PRODUCTION FAILED was empty; TESTING had the run. Failed-step name can be absent from current structure (flow evolved). Did not invent a patch.

Checklist

• I provided a contact email in this description.
• I ran this skill in a real Pipefy organization.
• SKILL.md and EVIDENCE.md are both in the folder.
• The frontmatter name matches the folder name.
• No tokens, keys, real IDs, customer names, or personal data.
• I wrote this skill, and I agree it is published under Apache 2.0 with credit to me.

[adriannoes]

Thank you for taking part in MCP Builders, Daniel.

What we verified

We checked the skill against the live iPaaS catalog on the hosted MCP server.

• All 17 catalog entries named in the skill exist.
• ap_get_run keys on flowRunId. The run listing has no date filter, caps at 50, defaults to PRODUCTION, and treats TIMEOUT as a status separate from FAILED. The advice to re-list with environment=TESTING and status=TIMEOUT follows from that and is correct.
• The webhook trigger schema exposes authType and authFields and nothing else, which confirms the finding in your evidence about the dropped property.

The skill starts from a failed run instead of a blank flow, which the toolkit's iPaaS skill does not cover. The failure classification table and the rule of never rebuilding with ap_build_flow when the user asked for an edit are the parts we would keep as they are. The three screenshots show the fail, patch and succeed sequence with the sensitive areas blurred.

Suggestions, not blocking

1. Steps 3, 5 and 6 show arguments={...} for the write calls. The real shapes are ap_flow_structure {flowId}, ap_update_step {flowId, stepName, sourceCode} for a CODE step, and ap_validate_flow {flowId}. Spelling them out saves the reader a schema expansion per step.
2. The relative links assume the file lives under skills/ipaas/ in the toolkit, so none resolve from the submission folder, and one points to a skill that is not in the toolkit.
3. A transcript of the MCP calls behind the screenshots, or the ap_get_run payload of the failed run, would make the evidence harder to argue with.

Next steps

Approved and accepted into the program. After we merge here, we will bring the skill into the official Pipefy AI Toolkit repository, adapted to its format and CI, referencing this pull request and crediting you as a contributor there. We will reach out by email about the details.