一键在 Manus 中运行任何 Skill

create-adr

星标8

分支0

更新时间2026年4月22日 21:16

Write a new Architectural Decision Record (ADR) for this project. Use when the user wants to document an architectural or design decision.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Miragon

Miragon/bpmn-to-code

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Skill: create-adr

Write a new Architectural Decision Record following the format used in docs/contributing/adr/.

Instructions

Step 1: Determine the next ADR number

Use Glob to list all files matching docs/contributing/adr/*.md (excluding README.md). Extract the three-digit numeric prefix from each filename (e.g. 011 from 011-variable-name-collision-detection.md).

The next number is the highest existing prefix plus one, zero-padded to three digits. If no ADR files exist, start at 001.

Step 2: Derive the filename slug

Convert $ARGUMENTS to kebab-case: lowercase, replace spaces/underscores with hyphens, remove non-alphanumeric characters (except hyphens), collapse consecutive hyphens.

Target: docs/contributing/adr/{NNN}-{slug}.md

Step 3: Read existing ADRs for content style

Read 1-2 recent ADRs to understand content style and level of detail:

docs/contributing/adr/011-variable-name-collision-detection.md
docs/contributing/adr/010-operaton-namespace-only-extractor.md

Note: Read these ONLY for writing style and technical detail level. Structure is defined in Step 5.

Step 4: Gather content from user

Ask the user (all at once, skip if $ARGUMENTS already answers):

Context: What problem or situation motivated this decision?
Decision drivers: Key factors (extensibility, testability, simplicity, etc.)?
Options considered: Alternatives evaluated (description, pros, cons for each)?
Decision: Which option was chosen and why?
Consequences: Positive impacts, negative impacts, trade-offs?
Technical implications: How does this affect the architecture (domain/application/adapter layers, new services, etc.)?

Step 5: Draft the ADR

Follow the structure from existing ADRs:

# ADR {NNN}: {Title}

## Status
Accepted

## Context
{Situation that motivated the decision}

## Decision
{What was decided and how it works}

### Implementation
{How this affects the codebase — new services, adapters, patterns}

## Consequences

### Positive
- {benefit}

### Negative
- {trade-off}

Add extra sections (e.g. ## Example, ## Alternatives Considered) only when they add meaningful value — follow the style of existing ADRs.

Show the complete draft to the user before writing.

Step 6: Confirm and write

Ask: "Write this ADR to {target-path}? (yes / edit / cancel)"

yes → write file, then update the index in docs/contributing/adr/README.md by adding a link under the appropriate category
edit → apply changes, show updated draft, ask again
cancel → stop without writing

Step 7: Report

Output the created file path and remind the user to commit the ADR in the same commit as the related code change for traceability.

同仓库更多 Skills

同仓库

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	create-adr
argument-hint	"<short description of the decision>"
allowed-tools	Read, Write, Glob
description	Write a new Architectural Decision Record (ADR) for this project. Use when the user wants to document an architectural or design decision.

Skill: create-adr

Write a new Architectural Decision Record following the format used in docs/contributing/adr/.

Instructions

Step 1: Determine the next ADR number

The next number is the highest existing prefix plus one, zero-padded to three digits. If no ADR files exist, start at 001.

Step 2: Derive the filename slug

Convert $ARGUMENTS to kebab-case: lowercase, replace spaces/underscores with hyphens, remove non-alphanumeric characters (except hyphens), collapse consecutive hyphens.

Target: docs/contributing/adr/{NNN}-{slug}.md

Step 3: Read existing ADRs for content style

Read 1-2 recent ADRs to understand content style and level of detail:

docs/contributing/adr/011-variable-name-collision-detection.md
docs/contributing/adr/010-operaton-namespace-only-extractor.md

Note: Read these ONLY for writing style and technical detail level. Structure is defined in Step 5.

Step 4: Gather content from user

Ask the user (all at once, skip if $ARGUMENTS already answers):

Context: What problem or situation motivated this decision?
Decision drivers: Key factors (extensibility, testability, simplicity, etc.)?
Options considered: Alternatives evaluated (description, pros, cons for each)?
Decision: Which option was chosen and why?
Consequences: Positive impacts, negative impacts, trade-offs?
Technical implications: How does this affect the architecture (domain/application/adapter layers, new services, etc.)?

Step 5: Draft the ADR

Follow the structure from existing ADRs:

# ADR {NNN}: {Title}

## Status
Accepted

## Context
{Situation that motivated the decision}

## Decision
{What was decided and how it works}

### Implementation
{How this affects the codebase — new services, adapters, patterns}

## Consequences

### Positive
- {benefit}

### Negative
- {trade-off}

Add extra sections (e.g. ## Example, ## Alternatives Considered) only when they add meaningful value — follow the style of existing ADRs.

Show the complete draft to the user before writing.

Step 6: Confirm and write

Ask: "Write this ADR to {target-path}? (yes / edit / cancel)"

yes → write file, then update the index in docs/contributing/adr/README.md by adding a link under the appropriate category
edit → apply changes, show updated draft, ask again
cancel → stop without writing

Step 7: Report

Output the created file path and remind the user to commit the ADR in the same commit as the related code change for traceability.