[Skill] Kanban padrão para desenvolvimento de software

[jpwf]

Skill

Folder / Pasta: submissions/jpwf/pipefy-software-pattern/

What it does / O que faz: A self-contained build-and-review guide for a Pipefy software-development pipe (backlog → refinement → dev → code review → QA → release) that guarantees cards carry everything a team needs to build the software. It enforces a Definition of Ready (DoR) as a phase-exit gate and a Definition of Done (DoD) before release, with the engineering standards written into the skill itself (naming, no hardcoded secrets, typed error handling, input validation, tests ≥70%, review, conventional commits, docs). Principle: capture at intake, gate at transitions — not "more fields", the right fields required on the right phase.

Contact / Contato

Email: wolfbytegames@gmail.com | jpwf01@gmail.com

Name for credit / Nome para crédito: João Pedro Weydt de Faria

The problem it solves / O problema que resolve

Software cards reach development half-specified — no testable acceptance criteria, no security impact, no dependencies — and rework starts. DoR/DoD usually live in an external doc nobody opens, so quality standards stay tribal knowledge instead of being enforced on the card.

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

A 9-phase pipe (Backlog, Refinement, Ready for Dev, In Development, Code Review, QA/Testing, Ready for Release, Done, and a lateral Blocked) with a lean start form (title, type, problem, value, requester email) and phase-level required fields for DoR (detailed requirements, Given/When/Then acceptance criteria, dependencies, security impact, estimate) and DoD (tests ≥70%, review approved, docs updated, no hardcoded secrets). Optional AI intake gate: a card_created behavior scores completeness via update_card + inputMode: fill_with_ai and flags gaps — the agent signals, a human decides.

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

Required fields set only on the start form don't gate transitions — they had to be marked required on the phase that needs them. Free-text acceptance criteria aren't testable, so they were standardized to Given/When/Then or a checklist_vertical. DoD had to move from an external doc into a visible phase checklist. The AI intake behavior must not auto-approve or auto-move cards (it hallucinates on empty fields) — it only writes a completeness-analysis field.

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, João.

What we verified

We rebuilt the gate on a scratch pipe.

• create_phase_field with required=true on a workflow phase is accepted and persists, which is the mechanism the Definition of Ready depends on.
• All ten field types named in the skill are valid, including checklist_vertical with options.
• The three AI intake behaviors (card_created, manually_triggered and field_updated, each with update_card and inputMode: fill_with_ai) pass validate_ai_agent_behaviors with no problems.

The design decisions hold up: required fields on the phase rather than on the start form, phase transitions left to the UI, and an agent that flags gaps while a human decides. The DoR and DoD tables and the per-type card templates are content the toolkit does not have.

Changes requested

1. Add EVIDENCE.md following template/EVIDENCE.md: a screenshot of the Refinement phase with the required fields, the transcript or a description of the run, and what broke on the first attempt.
2. Set the frontmatter name to pipefy-software-pattern so it matches the folder.
3. Add the When to use, Prerequisites, Tools needed and Steps sections. In Steps, show the create_pipe, create_phase and create_phase_field phase_id=<phase_id> label="..." field_type="long_text" required=true calls with placeholders. Today the build workflow names three read tools and never shows how phases or fields get created. For the verification step, create the test card directly on Refinement (create_card pipe_id=<pipe_id> phase_id=<refinement_phase_id> ... with the required start-form values filled): a card created from the start form lands in the default Inbox, whose only default connection is Doing, so it cannot be moved to Refinement on a fresh pipe.
4. Replace create_pipe_field, which does not exist, with create_phase_field.
5. In the AI intake section, say that update_card and send_email_template are agent behavior action types rather than MCP tools, and add event_params with triggerFieldIds to the field_updated behavior so it does not fire on every field change.

Items 2 and 4 are mechanical. Item 3 is what turns the document into something an assistant can execute.

Next steps

The submission is accepted into the program. The changes above are about the format; push them to this branch and we merge. After that, 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.

[adriannoes]

CI update: the validate check is red with EVIDENCE.md is missing. The script stops at the first missing file, so it does not yet list the other errors (frontmatter name mismatch and the missing When to use, Prerequisites, Tools needed and Steps sections). They are the items in the review above; after EVIDENCE.md exists the check will report them. Local run:

python3 scripts/validate_submission.py submissions/jpwf/pipefy-software-pattern