Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

web-dev

Estrelas8

Forks0

Atualizado17 de junho de 2026 às 07:14

Develop and visually verify changes to the web module (bpmn-to-code-web). Use when working on the vanilla JS frontend, Ktor backend, or validating UI changes with Playwright MCP.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

Miragon

Miragon/bpmn-to-code

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores webInformática e Matemática·SOC 15-1254

SKILL.md

readonly

name	web-dev
argument-hint	"<component or page to work on>"
allowed-tools	Read, Write, Edit, Glob, Grep, Bash(./gradlew ), mcp__playwright__
description	Develop and visually verify changes to the web module (bpmn-to-code-web). Use when working on the vanilla JS frontend, Ktor backend, or validating UI changes with Playwright MCP.

Skill: web-dev

Develop and visually verify changes to the bpmn-to-code web module.

IMPORTANT

No frameworks: The frontend uses vanilla HTML/CSS/JS per ADR 009. Never introduce React, Vue, or any JS framework.
No npm/build tooling: External libraries must be loaded via CDN <script> tags only.
Single files: All JS lives in app.js, all CSS in styles.css. Do not split into multiple files.
Read before editing: Always read the target files before making changes to understand existing patterns.

Instructions

Step 1 — Understand the architecture

Read ADR 009 (docs/contributing/adr/009-ktor-static-frontend-single-module.md) for architectural context.

Key facts:

Backend: Ktor 3.x (Kotlin) serving static files + REST API
Frontend: Vanilla HTML/CSS/JS — no frameworks, no npm, no build pipeline
Deployment: Single fat JAR with embedded frontend (./gradlew :bpmn-to-code-web:buildFatJar)
External libs: CDN only (e.g. highlight.js for syntax highlighting, bpmn.js for diagram rendering)
Static files location: bpmn-to-code-web/src/main/resources/static/

Step 2 — Review current state

Read the files relevant to $ARGUMENTS. The key files and their purposes:

File	Purpose
`bpmn-to-code-web/src/main/resources/static/index.html`	Page structure, sections, CDN script tags
`bpmn-to-code-web/src/main/resources/static/css/styles.css`	All styling, CSS custom properties in `:root`, responsive breakpoints
`bpmn-to-code-web/src/main/resources/static/js/app.js`	All logic: state management, API calls, DOM manipulation
`bpmn-to-code-web/src/main/kotlin/io/miragon/bpmn/web/Application.kt`	Ktor routing, static resource serving, plugin installation
`bpmn-to-code-web/src/main/kotlin/io/miragon/bpmn/web/routes/GenerateRoutes.kt`	API endpoint for BPMN code generation
`bpmn-to-code-web/src/main/kotlin/io/miragon/bpmn/web/service/WebGenerationService.kt`	Backend generation logic

API endpoints:

POST /api/generate — accepts base64-encoded BPMN files, returns generated code
GET /api/config — returns version and legal links for the frontend
GET /health — health check

Step 3 — Make changes

Follow these conventions:

CSS: Use existing custom properties from :root (e.g. --primary-color, --text-primary, --bg-gray). Add new styles to styles.css.
JS: Follow the existing pattern in app.js — state object, DOM references, event listeners, helper functions. Use const/let, template literals, async/await.
HTML: Follow existing section structure (.card wrapper, heading, content). Use semantic elements.
Responsive: Use existing media query breakpoints (640px, 768px). Test mobile layout.

Step 4 — Build and run locally

# Run backend tests
./gradlew :bpmn-to-code-web:test

# Start the web module (port 8080)
./gradlew :bpmn-to-code-web:run

The app will be available at http://localhost:8080/static/index.html.

Step 5 — Visual verification (only on request)

Do not run visual verification automatically. Use AskUserQuestion to ask the user what should be verified. Only proceed with the steps below if the user or $ARGUMENTS explicitly request visual testing.

Prerequisite: Playwright MCP must be configured in the agent's MCP settings.

Ensure the web module is running (./gradlew :bpmn-to-code-web:run in the background)
Navigate to http://localhost:8080/static/index.html
Perform only the verification steps the user requested
Store screenshots in .tmp/ (gitignored). Never check screenshots into git.
Name screenshots descriptively: web-{page}-{state}.png
Clean up .tmp/ when the skill terminates

To attach screenshots to a PR, upload them as draft release assets:

gh release create screenshots-pr-<NUMBER> --draft --title "PR #<NUMBER> Screenshots" --notes "Temporary" .tmp/*.png
gh release view screenshots-pr-<NUMBER> --json assets --jq '.assets[] | .url'
gh pr comment <NUMBER> --body "![description](<asset-url>)"

The draft release can be deleted after the PR is merged.

Step 6 — Report

Summarize:

What was changed and why
Which files were modified
Verification results (screenshots taken, issues found)
Any follow-up items

Mais deste repositório

mesmo repositório

create-unit-test

Miragon/bpmn-to-code

Write or refactor unit tests following the canonical project pattern. Use when adding new unit tests or standardizing existing ones.

2026-07-218

generate-rule-to-enforce-bpmn-styleguide

Miragon/bpmn-to-code

Generate a Kotlin SingleModelValidationRule implementation for ONE rule from BPMN_STYLE_GUIDE.md. Use when drafting / iterating on a single rule, or when the user asks to 'generate a rule for <slug>', 'create the element-id-format rule', or 'add just this one rule to the test module'. For all rules at once, use generate-rules-to-enforce-bpmn-styleguide.

2026-07-208

generate-rules-to-enforce-bpmn-styleguide

Miragon/bpmn-to-code

Generate Kotlin SingleModelValidationRule implementations for every deterministic (or hybrid) rule in BPMN_STYLE_GUIDE.md, so they can be enforced at test time by the bpmn-to-code-testing module. llm-only rules stay in the style guide for /validate-bpmn-style. Use when the user asks to 'generate validation rules from the style guide', 'enforce BPMN conventions in CI', or 'automate style checks in tests'. For a single rule, use generate-rule-to-enforce-bpmn-styleguide.

2026-07-208

build-bpmn-styleguide

Miragon/bpmn-to-code

Interactively author a BPMN_STYLE_GUIDE.md for your project — a handbook that explains how the team models BPMN processes (naming, allowed elements, IDs, topics, engine-specific special cases). The output is a document humans can read; embedded YAML annotations let downstream skills enforce the rules. Use when the user asks to 'create a BPMN style guide', 'set up BPMN conventions', or 'define BPMN naming rules'.

2026-07-178

create-process-service

Miragon/bpmn-to-code

Create a complete Spring Boot service project from a BPMN file with hexagonal architecture. Bootstraps via Spring Initializr, configures bpmn-to-code, and generates workers, use cases, and services wired to ProcessApi constants — no raw strings anywhere. Use when the user wants to start a new process service from a BPMN model.

2026-06-178

migrate-bpmn-to-code-v1-to-v2

Miragon/bpmn-to-code

Migrate generated API usage from bpmn-to-code v1.1.0 to v2.0.0. Use when the user asks to 'upgrade to v2', 'migrate from v1 to v2', 'fix TaskTypes references', or 'update bpmn-to-code API calls after upgrade'.

2026-06-178

name	web-dev
argument-hint	"<component or page to work on>"
allowed-tools	Read, Write, Edit, Glob, Grep, Bash(./gradlew ), mcp__playwright__
description	Develop and visually verify changes to the web module (bpmn-to-code-web). Use when working on the vanilla JS frontend, Ktor backend, or validating UI changes with Playwright MCP.

Skill: web-dev

Develop and visually verify changes to the bpmn-to-code web module.

IMPORTANT

No frameworks: The frontend uses vanilla HTML/CSS/JS per ADR 009. Never introduce React, Vue, or any JS framework.
No npm/build tooling: External libraries must be loaded via CDN <script> tags only.
Single files: All JS lives in app.js, all CSS in styles.css. Do not split into multiple files.
Read before editing: Always read the target files before making changes to understand existing patterns.

Instructions

Step 1 — Understand the architecture

Read ADR 009 (docs/contributing/adr/009-ktor-static-frontend-single-module.md) for architectural context.

Key facts:

Backend: Ktor 3.x (Kotlin) serving static files + REST API
Frontend: Vanilla HTML/CSS/JS — no frameworks, no npm, no build pipeline
Deployment: Single fat JAR with embedded frontend (./gradlew :bpmn-to-code-web:buildFatJar)
External libs: CDN only (e.g. highlight.js for syntax highlighting, bpmn.js for diagram rendering)
Static files location: bpmn-to-code-web/src/main/resources/static/

Step 2 — Review current state

Read the files relevant to $ARGUMENTS. The key files and their purposes:

File	Purpose
`bpmn-to-code-web/src/main/resources/static/index.html`	Page structure, sections, CDN script tags
`bpmn-to-code-web/src/main/resources/static/css/styles.css`	All styling, CSS custom properties in `:root`, responsive breakpoints
`bpmn-to-code-web/src/main/resources/static/js/app.js`	All logic: state management, API calls, DOM manipulation
`bpmn-to-code-web/src/main/kotlin/io/miragon/bpmn/web/Application.kt`	Ktor routing, static resource serving, plugin installation
`bpmn-to-code-web/src/main/kotlin/io/miragon/bpmn/web/routes/GenerateRoutes.kt`	API endpoint for BPMN code generation
`bpmn-to-code-web/src/main/kotlin/io/miragon/bpmn/web/service/WebGenerationService.kt`	Backend generation logic

API endpoints:

POST /api/generate — accepts base64-encoded BPMN files, returns generated code
GET /api/config — returns version and legal links for the frontend
GET /health — health check

Step 3 — Make changes

Follow these conventions:

CSS: Use existing custom properties from :root (e.g. --primary-color, --text-primary, --bg-gray). Add new styles to styles.css.
JS: Follow the existing pattern in app.js — state object, DOM references, event listeners, helper functions. Use const/let, template literals, async/await.
HTML: Follow existing section structure (.card wrapper, heading, content). Use semantic elements.
Responsive: Use existing media query breakpoints (640px, 768px). Test mobile layout.

Step 4 — Build and run locally

# Run backend tests
./gradlew :bpmn-to-code-web:test

# Start the web module (port 8080)
./gradlew :bpmn-to-code-web:run

The app will be available at http://localhost:8080/static/index.html.

Step 5 — Visual verification (only on request)

Prerequisite: Playwright MCP must be configured in the agent's MCP settings.

Ensure the web module is running (./gradlew :bpmn-to-code-web:run in the background)
Navigate to http://localhost:8080/static/index.html
Perform only the verification steps the user requested
Store screenshots in .tmp/ (gitignored). Never check screenshots into git.
Name screenshots descriptively: web-{page}-{state}.png
Clean up .tmp/ when the skill terminates

To attach screenshots to a PR, upload them as draft release assets:

gh release create screenshots-pr-<NUMBER> --draft --title "PR #<NUMBER> Screenshots" --notes "Temporary" .tmp/*.png
gh release view screenshots-pr-<NUMBER> --json assets --jq '.assets[] | .url'
gh pr comment <NUMBER> --body "![description](<asset-url>)"

The draft release can be deleted after the PR is merged.

Step 6 — Report

Summarize:

What was changed and why
Which files were modified
Verification results (screenshots taken, issues found)
Any follow-up items