بنقرة واحدة
file-builder-expert
Convert C# template files to Fluent CSharpFile builder API.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Convert C# template files to Fluent CSharpFile builder API.
التثبيت باستخدام 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.
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.
Wire cross-module logic, DI/appsettings events, priority bands, and template lookups.
| name | file-builder-expert |
| description | Convert C# template files to Fluent CSharpFile builder API. |
| argument-hint | [source file] [target template name] |
[!TIP] Read more if you want to know about builder APIs, patterns, or troubleshooting:
- API Cheatsheet | Patterns | Troubleshooting (To conserve tokens, avoid reading these for minor updates.)
CSharpTemplateBase<TModel>, implement ICSharpFileBuilderTemplate, and expose CSharpFile.CSharpFile structure in constructor.DefineFileConfig() => CSharpFile.GetConfig(); and TransformText() => CSharpFile.ToString();.AddIfStatement, AddForEachStatement) and CSharpInvocationStatement.OnBuild/AfterBuild callbacks in constructor (Core=0, Enrichment=100, Extension=500, Final=1000).GetTypeName(...) for model/type references, GetTypeName(templateId, model) for TemplateId-based references, and UseType("Namespace.Type") for framework/external types — including method return/parameter types (e.g. method.AddParameter(UseType("System.Threading.CancellationToken"), "cancellationToken")). Do not use UseType(...) for types represented in the Intent model.IHasName.Name) and use the same model when resolving references via GetTypeName(templateId, model); handle name collisions before AddClass(...).param.IntroduceReadonlyField().method.AddStatement("// IntentInitialGen");
method.AddStatement($"// TODO: Implement {method.Name} ({@class.Name}) functionality");
method.AddStatement("""throw new NotImplementedException("Your implementation here...");""");
CSharpMethodChainStatement or AddMethodChainStatement.else/catch/finally as children of a block (must be siblings).=> or object initializer braces {}.field.WithAssignment(string) directly (use WithAssignment(new CSharpStatement(...))).AddTypeSource(templateId) is not sufficient for single-file templates. AddTypeSource enables GetTypeName(model) resolution for file-per-model templates — it looks up the template instance by model. For single-file templates (one output, no model) like IIntegrationEventHandler, there is no model to pass, so GetTypeName cannot resolve the type and the using is never injected. Use the pattern in builder-patterns.md § "Resolving Single-File Template Namespaces" instead.