菜单
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