メニュー
Complete the three release documentation artifacts for an Intent Architect .NET module: release-notes.md, docs/README.md, and .imodspec metadata fields (summary, description, tags, projectUrl, releaseNotes). Enforces canonical repo format and style.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
The accumulated strategic playbook for building Intent.Modules.NET modules — the judgment calls a veteran module builder makes, distinct from the mechanical process. Covers module decomposition (root/bridging/common), template vs factory-extension choice, file cardinality, managed modes, design-time configuration (setting vs stereotype), convention-vs-explicit, and two-phase verification. LOAD THIS at every design decision point: during kickoff, pattern research, ecosystem analysis, reference-app building, and the increment loop. Referenced by all module-building chain skills.
Use after tech-pattern-researcher produces a Pattern Document and before module-ecosystem-analyst. Scaffolds a real Intent-managed Clean Architecture application with standard modules installed, runs the Software Factory to get the actual generated output, then hand-crafts the technology-specific files on top of that real output. Proves the code shapes compile and the handler is hit at runtime. The running app becomes the ground truth that module-ecosystem-analyst reads to understand what the ecosystem already generates. TRIGGER: mandatory after Pattern Document, before ecosystem analysis — never skip. BLOCK on this skill until the reference app is green.
Use after module-kickoff produces a Requirements Summary. Researches the technology in isolation, maps it to Clean Architecture, and defines exactly what the module must generate. TRIGGER: when a Requirements Summary is in hand and the next step is understanding how to implement it. Produces a Pattern Document — the input to reference-app-builder.
Convert C# template files to Fluent CSharpFile builder API.
Intent Architect MCP workflow: designer operations, element discovery, model modification, Software Factory execution, compilation verification, and cross-module integration patterns. If you find yourself wanting to edit `.xml`, `.config`, `.settings` files inside an `intent` metadata folder directly, perform the change via the IA MCP. This workflow is designed to keep models as the single source of truth — direct file edits are a last resort for truly exceptional cases.
Use after module-ecosystem-analyst produces an Attack Plan. Uses the Intent Architect Module Builder designer via MCP to scaffold the new module: creates the package, templates, factory extensions, and NuGet declarations, then runs Software Factory to generate the code scaffold. TRIGGER: when an Attack Plan is in hand and the next step is scaffolding the module structure. Produces a compiled module skeleton ready for implementation.
| name | module-docs |
| description | Complete the three release documentation artifacts for an Intent Architect .NET module: release-notes.md, docs/README.md, and .imodspec metadata fields (summary, description, tags, projectUrl, releaseNotes). Enforces canonical repo format and style. |
| keywords | ["release-notes","readme","imodspec","documentation","module"] |
Invoke before releasing or publishing an Intent Architect module. Produces or completes:
release-notes.md — version changelogdocs/README.md — feature/usage documentation*.imodspec — metadata fields consumed by the Intent Architect module registryBefore writing any artifact, determine and apply the correct version bump. State the impact assessment and reasoning.
| Situation | Rule | Example |
|---|---|---|
| New module | 1.0.0-pre.0 | — |
| Already on a prerelease | Increment pre component only | 1.0.0-pre.4 → 1.0.0-pre.5 |
| Release version, patch change | X.Y.(Z+1)-pre.0 | 1.0.2 → 1.0.3-pre.0 |
| Release version, minor change | X.(Y+1).0-pre.0 | 1.0.2 → 1.1.0-pre.0 |
| Release version, major change | (X+1).0.0-pre.0 | 1.0.2 → 2.0.0-pre.0 |
Impact is assessed from the requirements — what changed, how much of the public surface moved, whether existing users need to change their designer models or generated code.
Align version in three places: .imodspec, .csproj, and the designer Module Settings (designer wins if already higher).
Before writing anything, read these files from the target module directory:
| File | What to extract |
|---|---|
*.imodspec | Current <version> (or version in filename), existing <summary>, <description>, <tags>, <projectUrl>, <releaseNotes> |
release-notes.md | Existing version entries — determine what's already documented to avoid duplication |
docs/README.md | Existing sections — fill gaps only, never overwrite sections that already have content |
Template *TemplatePartial.cs files | Class names and roles — becomes the "What This Module Generates" list |
Factory extension *FactoryExtension.cs files | What cross-cutting concerns they add (DI registrations, appsettings, template modifications) |
NugetPackages.cs | NuGet packages the module introduces — informs tags and README dependency callouts |
release-notes.md### Version X.Y.Z
- New Feature: [description]
- Improvement: [description]
- Fixed: [description]
> ⚠️ **NOTE**
>
> [Breaking change explanation and migration guidance.]
### Version X.Y.Z — h3 only, "Version" prefix, version from .imodspec with -pre.X suffix stripped (e.g. 1.0.0-pre.0 → ### Version 1.0.0)New Feature:, Improvement:, Fixed: — no others> ⚠️ **NOTE** blockquote directly under the version heading, before bulletsNew Feature: — one entry per template or major capability addedImprovement: — NuGet version bumps, dependency updates, refactors, performanceFixed: — only for known bugs resolved; include the scenario that triggered the bugNew Feature: entries covering each template/feature### Version 1.0.0
- New Feature: Added `NServiceBusConfiguration` template that scaffolds NServiceBus endpoint configuration with transport, serialization, and DI setup.
- New Feature: Added `NServiceBusMessageBus` infrastructure implementation wiring `IMessageBus` to NServiceBus send/publish operations.
- New Feature: Added support for SQL Persistence outbox pattern when `OutboxPattern` is set to `EntityFramework` on the application settings.
docs/README.md# [Module.Name]
[1-2 sentence purpose statement: what pattern/technology + what the module generates.]
## What is [Technology/Pattern]?
[Explanation of the external technology. Link to official docs. Omit if the technology is well-known and self-explanatory.]
## What This Module Generates
[Bullet list of file/class names the module produces.]
## [Feature Section — one H2 per major capability]
[Explain the pattern/concept. Show modeled input → generated output with C# code examples.]
### [Sub-concept — H3 for detailed breakdowns]
## Module Settings
### [Setting Group Name]
[Describe what the setting controls and its effect on generated code. Not just the name.]
## Related Modules
### [Module Name](link)
[1-2 sentences: what this module provides and how it integrates with the documented module.]
## External Resources
[Links to official docs, GitHub, specification pages. Optional.]
What This Module Generates: bullet list of class/file names; include the role each plays only — never embed binary content> [!NOTE] / > [!WARNING] syntaxModule Settings: H3 per setting group; describe effect on generated code, not just the setting nameRelated Modules: always present as the last content section; H3 per module; explain the integration relationship| Source | Target section |
|---|---|
| Template class names + roles | What This Module Generates bullets |
| Factory extension contributions | Feature section describing what gets added/configured |
AppSettingRegistrationRequest keys registered | Module Settings section |
ContainerRegistrationRequest / HasDependency targets | Related Modules hints |
| NuGet packages introduced | Callout in relevant feature section or External Resources |
.imodspec FieldsEdit the *.imodspec file in the module directory directly. Do not edit files inside .intent/ folders.
| Field | Rule |
|---|---|
<summary> | 5–15 words; name the technology and what it does. Specific, not generic. |
<description> | Mirror <summary> exactly. Only expand (max 2 sentences) if the module is complex enough to warrant it. |
<tags> | 3–7 space-separated lowercase keywords (see tag guide below) |
<projectUrl> | https://github.com/IntentArchitect/Intent.Modules.NET/blob/master/Modules/[ModuleFolderName]/README.md |
<releaseNotes> | Copy release-notes.md content verbatim — the imodspec embeds the same history |
<authors> | Intent Architect (always) |
Include:
nservicebus, masstransit, entityframework, serilog, etc.eventing, messaging, outbox, cqrs, ddd, persistenceinfrastructure, applicationcsharp, dotnetrabbitmq, azureservicebus, amazonsqsAvoid: generic words like module, common, helper, base unless the module is genuinely a base/utility module.
<summary>NServiceBus messaging infrastructure for Intent Architect .NET applications.</summary>
<description>NServiceBus messaging infrastructure for Intent Architect .NET applications.</description>
<tags>nservicebus messaging eventing infrastructure csharp dotnet</tags>
<projectUrl>https://github.com/IntentArchitect/Intent.Modules.NET/blob/master/Modules/Intent.Modules.Eventing.NServiceBus/README.md</projectUrl>
After completing all three artifacts:
release-notes.md — entry exists for current module version (stripped); uses only New Feature: / Improvement: / Fixed: prefixes; reverse chronologicaldocs/README.md — H1, opening paragraph, What This Module Generates, at least one feature section, Module Settings (if applicable), Related Modules all present; no placeholder text.imodspec — <summary> is specific (not generic); <tags> has 3–7 keywords; <projectUrl> points to the module's README on GitHub; <releaseNotes> matches release-notes.md