🗂️ Backend Library Generator Agent Specification¶

🧠 Agent Purpose and Factory Role¶

🎯 Purpose¶

The Backend Library Generator Agent is a foundational generative agent responsible for autonomously producing high-quality, production-grade .NET library solutions. It transforms structured input (template parameters, feature toggles, framework targets) into fully scaffolded ConnectSoft-compliant library solutions.

This agent ensures that all reusable backend components — utility libraries, domain packages, messaging clients, API integrations, and cross-cutting concerns — are generated with:

🔁 Consistency (naming, structure, pipeline)
🔍 Observability (metrics, traces, logging)
📦 CI/CD readiness (YAML, NuGet, code coverage)
🧱 Modularity (DI, Options, Conditional output)
📚 Documentation (README + versioning metadata)

It operates as a Library Factory Cell, and is invoked either:

📥 As part of a feature-driven build pipeline (e.g., “Generate library for metrics”), or
🛠️ Standalone in the CLI/Visual Studio workflows when a human or planner triggers a generation task.

🧩 Role in the Platform¶

The agent is a low-level artifact builder within the ConnectSoft AI Software Factory. It serves:

Role	Description
🧱 Code Generator	Synthesizes complete library solutions from blueprint specs and symbol-resolved CLI input
📡 Producer Agent	Publishes reusable .NET NuGet packages consumed by microservices, gateways, orchestrators
🧠 Knowledge-Aware Agent	Applies Clean Architecture, DDD alignment, ConnectSoft metadata, and semantic naming standards
🔁 Composable Cell	Operates independently or as a part of generation pipelines triggered by other agents
🧰 Template Harness	Leverages the official ConnectSoft Library Template + custom conditionals via `template.json`

🧬 Agent Placement in System Flow¶

flowchart TD
    A[📥 Feature Input] --> B[🧠 Planner Agent]
    B --> C[📦 Library Generator Agent]
    C --> D1[📁 Structured Solution Output]
    C --> D2[📜 CI/CD YAML]
    C --> D3[🧪 Unit Test Project]
    C --> D4[📚 README.md]
    D1 --> E[📤 NuGet Publisher Agent]
    D3 --> F[🧪 QA Agent]

    style C fill:#e0f7fa,stroke:#00acc1,stroke-width:2px
    style D1 fill:#e8f5e9
    style D2 fill:#e8f5e9
    style D3 fill:#fce4ec
    style D4 fill:#fff3e0

Hold "Alt" / "Option" to enable pan & zoom

🧠 Typical Triggers¶

Trigger Type	Description
`agent:generate-library`	Called directly by Factory Planner
`CLI Input`	Triggered via `dotnet new connectsoft-library ...`
`MCP Directive`	Received via Model Context Protocol in code-first planning session
`Upstream Feature`	Triggered after an Architectural or Feature agent defines reusable logic to externalize

📌 Summary¶

Agent Name: backend-library-generator-agent
Primary Role: Generate ConnectSoft-compliant backend libraries (reusable components, cross-cutting concerns, shared domain models, etc.)
Scope: Single library solution generation per invocation
Factory Role: Modular generative unit for reusable backend code

🧠 Responsibilities¶

🎯 Primary Responsibilities¶

The Backend Library Generator Agent is accountable for the end-to-end generation, validation, and packaging of .NET library solutions. These libraries are used as building blocks across the ConnectSoft platform — shared across microservices, orchestrators, gateways, or infrastructure.

📌 Detailed Responsibilities¶

#	Responsibility	Description
1️⃣	📁 Generate Full Solution Structure	Create a `.sln` with two core projects: the library and its MSTest-based test project.
2️⃣	🧠 Resolve CLI Parameters and Template Flags	Parse and resolve flags such as `--UseDI`, `--UseOptions`, `--UseLogging`, `--UseMetrics`, and apply template symbols accordingly.
3️⃣	🏗️ Apply Template Conditionals	Exclude or include folders/files conditionally (e.g., `Options/`, `Metrics/`) as specified in `template.json`.
4️⃣	🧪 Scaffold Unit Tests	Include a test project with MSTest setup, sample tests, and code coverage readiness.
5️⃣	📜 Inject CI/CD Pipeline YAML	Emit Azure DevOps `azure-pipelines.yml` preconfigured with build, test, pack, push, and code coverage gates.
6️⃣	📚 Generate Templated README.md	Auto-fill with project name, purpose, usage examples, badge placeholders, CLI instructions.
7️⃣	🔢 Embed Multi-Target Support	Set `TargetFrameworks` in `.csproj` for `net8.0;net9.0`, allowing broader compatibility.
8️⃣	🧩 Apply Dependency Injection Setup (if enabled)	Include `IServiceCollection` extension methods and service wiring templates.
9️⃣	⚙️ Inject Logging Integration (if enabled)	Add `ILogger<T>` usage patterns, default logs, and observability hooks.
🔟	🧾 Add Options Binding and Validation (if enabled)	Scaffold configuration models, bind to `appsettings.json`, validate via `IOptions<T>`.
1️⃣1️⃣	📊 Add Metrics Instrumentation (if enabled)	Include structure for custom metrics collection and registration.
1️⃣2️⃣	📦 Enable NuGet Packaging & Metadata	Generate `.nuspec`-like metadata, set semantic versioning via `buildDefinitionNumber`.
1️⃣3️⃣	🧪 Ensure Code Coverage Hooks	Integrate code coverage tooling in CI with enforcement threshold (`70%` by default).
1️⃣4️⃣	🧠 Collaborate with Other Agents	Integrate with Testing Agent (for test extension), Observability Agent (for metrics), and Packaging Agent (for NuGet push).
1️⃣5️⃣	🧹 Validate and Auto-Correct Output	Run output validators (YAML, .csproj, symbols used), fix incomplete artifacts or missing parts automatically.

🔄 Execution Scope¶

One execution = one generated library
Internal retry loops ensure valid pipeline, coverage, options, and DI stubs.
Structured output is versioned and ready for consumption by QA, CI/CD, and Artifact agents.

🧠 Intelligent Handling¶

Smart symbol exclusion/inclusion (via template.json)
Adaptive README.md based on flag usage
Automatic YAML CI correction if required steps are missing
Versioning alignment with buildDefinitionNumber

🧠 Inputs¶

📥 Overview¶

The Backend Library Generator Agent consumes a combination of structured inputs, feature flags, generation prompts, and symbolic configuration to orchestrate a fully automated, conditional library scaffold. Inputs can originate from CLI invocations, Planner Agents, or upstream context (e.g. task instructions, project blueprints).

📦 Input Categories¶

Input Type	Description
1. CLI Parameters	Structured options passed via `dotnet new connectsoft-library`
2. Template Symbols	Conditional flags (`UseDI`, `UseOptions`, etc.) resolved into `template.json` symbols
3. Generation Prompts	Free-form or guided instructions passed via Planner Agent or orchestrator
4. System Context	Information retrieved from memory graph (e.g. existing libraries, naming conventions)
5. Feature Metadata	Contextual information about intended library type (API client, utility, domain package)
6. Framework Targets	Choice between `.NET 8` or `.NET 9`, or multi-TFM configuration
7. Build Definition Number	Semantic versioning seed or CI/CD versioning tag used in output pipelines

🔠 CLI Parameter Example¶

dotnet new connectsoft-library \
  --name ConnectSoft.Extensions.Observability \
  --buildDefinitionNumber 47 \
  --UseDI true \
  --UseLogging true \
  --UseOptions true \
  --UseMetrics true \
  --Framework net8.0

🧩 Template Symbols (from `template.json`)¶

Symbol	Type	Description
`UseDI`	bool	Enables DI setup with `IServiceCollection`
`UseLogging`	bool	Adds structured logging with `ILogger<T>`
`UseOptions`	bool	Adds `IOptions<T>` with validation
`UseMetrics`	bool	Includes metric tracking infrastructure
`Framework`	choice	Target TFM (`net8.0` or `net9.0`)
`buildDefinitionNumber`	string	Optional override for build metadata
`AuthoringMode`, `IfDebug`, etc.	constant	Used for code generation scaffolding (conditional directives)

🧠 Prompt-Based Input (from other agents or user)¶

Example Prompt	Resolved Input
“Generate a metrics library with DI and logging using .NET 8”	`{ UseMetrics: true, UseDI: true, UseLogging: true, Framework: net8.0 }`
“Create a shared config package for our multi-tenant system”	`{ UseOptions: true, UseDI: true }`

📂 Additional Metadata Retrieved from Factory Context¶

Preferred output directory
Library naming conventions (ConnectSoft.*)
Common namespace strategy
Existing libraries or reuse constraints (to avoid duplication)

✅ Input Validation (Pre-flight)¶

Before generation begins, the agent validates:

All flags are valid booleans
Framework is a supported TFM (net8.0, net9.0)
name is unique within current workspace
If metrics are enabled, logging must be too (dependency validation)

🧾 Outputs¶

📦 Output Summary¶

The agent produces a fully structured .NET library solution aligned with ConnectSoft conventions. Outputs are emitted to disk (or repository) and returned as traceable artifacts for downstream agents like the QA Agent, Packaging Agent, and CI/CD orchestrators.

📁 Solution-Level Output Structure¶

ConnectSoft.MyLibrary/
├── ConnectSoft.MyLibrary.sln
├── ConnectSoft.MyLibrary/
│   ├── ConnectSoft.MyLibrary.csproj
│   ├── MyLibraryClass.cs
│   ├── Options/              (if UseOptions=true)
│   ├── Metrics/              (if UseMetrics=true)
│   ├── Observability.cs      (if UseLogging=true or UseMetrics=true)
│   └── IServiceCollectionExtensions.cs  (if UseDI=true)
├── ConnectSoft.MyLibrary.UnitTests/
│   ├── ConnectSoft.MyLibrary.UnitTests.csproj
│   └── MyLibraryClassTests.cs
├── azure-pipelines.yml
├── README.md
└── .gitignore

📘 Artifacts and Content¶

Output	Description
`.sln` File	References both the main and test project
`.csproj`	Contains `TargetFrameworks`, dependencies, optional DI/Options/Metrics package references
`README.md`	Pre-filled project metadata, usage instructions, CI badge placeholder
`azure-pipelines.yml`	Full CI pipeline with restore, build, test, coverage, NuGet pack/push
Source Code (`.cs`)	Core library files with conditional generation logic
Test Project	MSTest-based test setup with coverage enforcement and example test class
Observability Files	If enabled, includes metric collection and logging integration
Options Files	If enabled, includes `IOptions<T>` models and validation
Metrics Files	If enabled, includes metrics collection stub, interface, and sample usage
`IServiceCollection` Extension	Adds library registration helper if DI is enabled
NuSpec Metadata (inline)	Embedded in `.csproj` for automatic packaging

📤 Output Destinations¶

File System: Generated to a specified output directory
Artifact Registry (if invoked via DevOps Agent): Passed to next stage for packaging
Memory Graph: Stored in memory graph for traceability, reuse detection, and audit

📂 Conditional Outputs¶

Feature Flag	Resulting Folders/Files
`UseDI=true`	Adds `IServiceCollectionExtensions.cs`
`UseOptions=true`	Adds `Options/` folder with config models
`UseLogging=true`	Adds `ILogger<T>` wiring + `Observability.cs`
`UseMetrics=true`	Adds `Metrics/` folder with `IMetricsRecorder`

📌 Downstream Usage¶

✅ QA Agent: Executes tests and extends coverage
✅ NuGet Publisher Agent: Uses .csproj and pipeline outputs
✅ Release Planner Agent: Tags version and tracks module state
✅ Developer IDE: Opened in Visual Studio or Rider with full structure

🧠 Knowledge Base¶

🧩 Embedded Domain Knowledge¶

The Backend Library Generator Agent possesses deep, pre-trained knowledge about:

Domain	Description
ConnectSoft Library Architecture	Clean, modular design structure, dual-project solution (`Library + UnitTests`), ConnectSoft blueprint conventions
.NET SDK and Project File Semantics	Understanding of `.csproj` syntax, `TargetFrameworks`, NuGet metadata, build properties, MSBuild conditionals
Template Engine Logic	Familiarity with `template.json` schema, CLI parameters, `symbols`, conditional exclusions/inclusions
Cross-Cutting Concerns	Pre-encoded support for DI, logging, metrics, and configuration binding with validation using modern .NET practices
YAML and CI/CD	Knowledge of Azure Pipelines structure, tasks (`DotNetCoreCLI`, `PublishPipelineArtifact`, etc.), build quality checks, code coverage thresholds
Observability Standards	Uses ConnectSoft’s observability-first mindset: structured logs, metrics output, CI instrumentation awareness
Code Generation Strategies	Capable of mapping inputs to template features, injecting partial classes, or excluding content based on flags
Semantic Naming & Project Conventions	Adheres to `ConnectSoft.[Domain].[Purpose]` naming, folder structures, naming consistency, internal visibility standards

📚 Foundation Templates and Assets¶

The agent is pre-linked with:

✅ ConnectSoft.LibraryTemplate source files and template manifests
✅ template.json rules and CLI interface
✅ Shared NuSpec metadata patterns (e.g., authors, description, repositoryUrl)
✅ ConnectSoft observability and documentation stubs
✅ ConnectSoft DevOps YAML fragments for reuse

🧠 Pre-trained Prompt Knowledge¶

The agent is trained to infer feature intentions and correct mappings:

Prompt	Recognized Pattern
“Make this library include config validation”	→ `UseOptions=true`
“We need observability and metrics in this library”	→ `UseLogging=true`, `UseMetrics=true`
“No test project needed”	→ Invalid (auto-corrected, as test project is always included)
“Supports both .NET 8 and 9”	→ Sets `TargetFrameworks` to `net8.0;net9.0`
“Create reusable DI-wired library”	→ Adds `IServiceCollectionExtensions.cs`, resolves `UseDI=true`

🧠 Internal Ontologies and Inference Rules¶

Flag Dependency Resolution:
If UseMetrics=true → must also include UseLogging=true (implied dependency)
If UseOptions=true → auto-generates validation and OptionsValidatorAttribute
Semantic Group Mapping:
Prompt mentions like "API client" → triggers special stubs (e.g., HttpClient, configuration)
“Multi-tenant logic” → includes TenantContext or prewired options

📦 Linked Agent Knowledge¶

The agent also references:

📘 Testing Agent guidelines for code coverage and naming
📗 Packaging Agent rules for NuGet tags and metadata
📕 QA Agent needs for test layout and folder naming
📙 Observability Agent standards for metrics and logging layout

🔄 Process Flow¶

🧭 Overview¶

The Backend Library Generator Agent executes a deterministic, observable, and retry-capable workflow. It transforms intent + flags into a validated and production-ready library scaffold using ConnectSoft's library blueprint.

The process is modular, observable, and includes both symbol resolution and conditional generation logic.

🔁 High-Level Workflow¶

graph TD
    A[🧠 Receive Prompt or Parameters]
    B[🔍 Resolve Feature Flags<br/>--UseDI, --UseOptions, etc.]
    C[📚 Fetch Library Template<br/>ConnectSoft.LibraryTemplate]
    D[🔧 Apply Template Symbols<br/>via template.json rules]
    E[🧱 Emit Files<br/>.sln, .csproj, .cs, tests, README, YAML]
    F[🧪 Validate Output<br/>syntax, symbols, structure, coverage]
    G{✅ Output Valid?}
    H[📤 Return Artifacts<br/>Filesystem, memory graph]
    I[♻️ Retry/Autofix & Regenerate]

    A --> B --> C --> D --> E --> F --> G
    G -->|Yes| H
    G -->|No| I --> D

Hold "Alt" / "Option" to enable pan & zoom

🧬 Detailed Step Breakdown¶

Step	Action	Description
1. Input Parsing	Receives prompt or CLI args	Extracts name, flags, and optional metadata
2. Flag Resolution	Parses `template.json`	Sets active/inactive states for `UseDI`, `UseOptions`, etc.
3. Template Hydration	Loads ConnectSoft template	Reads folder structure, modifiers, exclusions, and source files
4. Symbol Substitution	Applies token replacements	Fills symbols like `Framework`, `buildDefinitionNumber`, `currentYear`
5. Conditional Assembly	Generates full solution	Resolves folders and content conditionally (Options/, Metrics/)
6. Test & CI Generation	Adds MSTest project, `azure-pipelines.yml`	Includes YAML for build/test/coverage/pack stages
7. Output Validation	Validates structure, content, readiness	Ensures required files exist, flags were respected, solution builds
8. Retry & Repair	If invalid output	Automatically fixes common errors (missing targets, invalid YAML)
9. Artifact Return	Final delivery	Emits files to local folder, memory graph, or CI system for next step

🧠 Factory-Wide Interactions¶

Triggers: Planner Agent, Studio CLI, MCP directive
Follows: Feature/Module declaration
Precedes: QA Agent, NuGet Publisher Agent, Documentation Agent

🔍 Observability Integration Points¶

Phase	Trace/Metric
Template load	`template.load.success`, `template.missing.symbol`
YAML generation	`ci.pipeline.generated`, `ci.missing.steps`
Retry logic	`generator.retry.triggered`, `retry.root_cause`
Final artifact output	`generator.success`, `artifact.path`, `output.size`

🛠 Skills and Semantic Kernel Functions¶

🧠 Overview¶

The Backend Library Generator Agent is equipped with a modular set of Semantic Kernel (SK) skills and function chains, enabling it to interpret prompts, conditionally generate templates, apply symbolic substitutions, validate output, and integrate into CI/CD flows.

These functions are used both declaratively (via planner chains) and programmatically (via direct agent invocation).

🧩 Core Skills¶

Skill Name	Purpose	Bound Tools or Actions
`resolve-template-flags`	Parses input prompt or CLI args and activates the correct feature symbols (`UseDI`, `UseMetrics`, etc.)	Built-in
`load-template-manifest`	Loads and parses the `template.json` file to understand available modifiers, symbols, and exclusions	File reader + JSON parser
`instantiate-template`	Applies the ConnectSoft.LibraryTemplate with the resolved symbols and emits raw output files	ConnectSoft Template Engine
`inject-conditional-content`	Adds/removes `.cs` files, folders, `csproj` elements, based on flags	Semantic engine + token resolver
`generate-pipeline-yaml`	Writes Azure Pipelines YAML file with build, test, pack, push, and coverage stages	YAML emitter
`generate-readme`	Synthesizes a project-specific `README.md` using prompt inputs, library metadata, and output structure	Markdown composer
`generate-test-stub`	Generates the test project with coverage-enabled configuration and a starter test class	Project and class scaffold engine
`validate-output-contract`	Checks if the output matches the expected solution structure, validates YAML syntax, `.csproj`, and NuGet metadata	Output validator skill
`retry-on-failure`	Reruns generation with fixed or fallback values if validation fails	Retry engine
`trace-generation`	Emits SK spans, metrics, and logging messages at each step	Observability skillset
`summarize-output`	Compiles a response with output location, project summary, flags used, and any warnings or notes	Output formatter

🔌 Example Function Chain¶

resolve-template-flags
→ load-template-manifest
→ instantiate-template
→ inject-conditional-content
→ generate-readme
→ generate-pipeline-yaml
→ generate-test-stub
→ validate-output-contract
→ retry-on-failure (if needed)
→ trace-generation
→ summarize-output

Each function is observable, retryable, and composable with other agents (e.g., QA Agent, CI Agent).

⚙️ Skills Categorized by Purpose¶

🧠 Interpretation & Setup¶

resolve-template-flags
load-template-manifest

📦 Generation & Synthesis¶

instantiate-template
inject-conditional-content
generate-readme
generate-pipeline-yaml
generate-test-stub

✅ Validation & Retry¶

validate-output-contract
retry-on-failure

📈 Observability & Reporting¶

trace-generation
summarize-output

💡 Extensibility Note¶

All skills are pluggable into:

🧠 Autonomous workflows (Planner-driven)
⚙️ Manual CLI prompts
🔄 Regeneration pipelines for template evolution (via MCP)

🧰 Technology Stack¶

🔧 Core Technology Components¶

Layer	Tool / Framework	Purpose
💡 AI Runtime	Semantic Kernel (SK)	Orchestrates prompt execution, skill composition, memory access, and retry logic
🤖 LLM Backend	OpenAI / Azure OpenAI	Interprets natural language instructions, transforms prompts into symbolic plans
🏗 Template Engine	.NET CLI + ConnectSoft Templates	Executes `dotnet new connectsoft-library` with symbol substitution and project instantiation
📁 File System	.NET File APIs	Handles solution generation, directory structuring, and code emission
📄 Configuration Management	template.json schema	Governs CLI parameters, conditional exclusions, project customization
🧪 Testing Engine	MSTest + Coverage Tools	Generates and validates a coverage-ready test project
⚙️ CI/CD	Azure DevOps Pipelines + YAML Generator	Generates `azure-pipelines.yml`, enforces CI standards, integrates versioning and publishing
📦 Packaging	NuGet Metadata + .csproj config	Embeds NuGet info into project files, prepares for packaging and publishing
🔍 Observability	SK Observability Hooks + OpenTelemetry (optional)	Traces execution, emits logs, captures performance spans
🧠 Memory Graph	Vector store / graph store	Stores relationships between generated libraries, naming, flags used, retry history

🧠 Agent Bootloader Environment¶

Element	Description
Agent Runtime Host	Hosted within MCP Server / Agent Orchestration Layer
Execution Mode	Stateless (ephemeral) or Stateful (cached context/memory)
Invocation Modes	CLI-based, prompt-based, or Planner-orchestrated
Platform Scope	Cross-platform, generates for Windows/Linux environments via .NET SDK 8/9
Semantic Plugin Support	Compatible with SK plugins (e.g., YAML emitter, C# syntax checker, project validator)

🌐 Integration Touchpoints¶

System	Interaction
ConnectSoft MCP Server	Can receive generation requests via `intent: generate-library`
Studio CLI Interface	Supports direct user input through `dotnet new` commands with parameters
Azure DevOps	Full integration with build pipelines, test runs, and artifact publishing
NuGet Artifact Registry	Output-ready for consumption via ConnectSoft’s internal NuGet feed
QA Agent & Publisher Agent	Outputs consumed by follow-up agents for validation, packaging, and deployment

🧱 Stack Visual¶

+---------------------------+
|     Azure DevOps         |  ← CI/CD integration
+---------------------------+
|     dotnet new CLI       |  ← Template execution
+---------------------------+
|  ConnectSoft Templates   |  ← LibraryTemplate, template.json
+---------------------------+
|  Semantic Kernel Agent   |  ← SK skills, prompts, retries
+---------------------------+
|      OpenAI LLM          |  ← Language understanding
+---------------------------+
|  File System & Memory    |  ← Output persistence, memory graph
+---------------------------+

🧾 System Prompt¶

🎯 Purpose of the System Prompt¶

The System Prompt is the foundational instruction set that boots and aligns the agent with its core responsibilities, standards, and execution patterns. It ensures the agent behaves consistently across autonomous runs, CLI executions, and planner-invoked workflows.

This prompt acts as the internal mission blueprint for the agent — guiding it to generate high-quality, production-grade backend libraries that follow the ConnectSoft blueprint and comply with factory-wide principles (e.g. Clean Architecture, Observability-First, Modularity).

📜 System Prompt (Verbatim)¶

You are the Backend Library Generator Agent in the ConnectSoft AI Software Factory.

Your role is to generate production-grade .NET library solutions using the official ConnectSoft.LibraryTemplate. These libraries serve as reusable backend modules within microservices, orchestrators, and shared system services.

Your outputs must follow Clean Architecture principles, support observability (if enabled), and be ready for automated CI/CD, NuGet publishing, and code coverage enforcement.

You support conditional generation features using the following CLI flags:

- UseDI: Enables dependency injection scaffolding
- UseLogging: Adds structured logging support
- UseOptions: Adds IOptions<T> configuration binding with validation
- UseMetrics: Adds built-in metrics tracking

You also support:
- buildDefinitionNumber: used for versioning and CI/CD pipeline injection
- Framework: one of `net8.0` or `net9.0` (or both)

Use the template.json schema to apply symbol substitutions and exclusions. Ensure that all expected outputs (solution, library project, test project, YAML pipeline, README, and optional folders) are generated.

Your output must be validated, retried if incomplete, and traceable via observability hooks.

If any optional feature (e.g., metrics or DI) is requested, it must be reflected in the output structure and code.

Your final output must include:
- A structured `.sln` and `.csproj` files
- Optional folders like Metrics/, Options/, DI setup
- Unit test project scaffold
- CI/CD pipeline YAML (Azure DevOps)
- README.md with metadata
- Valid .gitignore

You may emit logs, metrics, and retry events during execution. Respect ConnectSoft naming conventions and use internal knowledge to align each project with its intended use case.

Always prefer consistency, modularity, and CI/CD readiness.

🧠 Agent Behaviors Encoded in Prompt¶

Behavior	Activated by
Conditional folder output	Presence of flag in input or planner instruction
Retry execution	Validation fails on missing YAML, missing `.csproj`, or invalid symbols
Emit pipeline YAML	Always included
Observability	Metrics folder if enabled; logging otherwise
Multi-targeting support	If `Framework=net8.0;net9.0`

📝 Input Prompt Template¶

🎯 Purpose¶

The Input Prompt Template defines how user-facing agents, orchestrators, or developers should formulate their intent when invoking the Backend Library Generator Agent.

This input format ensures consistency, supports both free-form and parameterized instructions, and enables accurate resolution of template.json symbols.

🧩 Supported Input Modes¶

Mode	Description
🧠 Natural Language Prompt	User or Planner describes what kind of library is needed
🧪 Parameterized Prompt	Structured input with flags and settings
🛠️ CLI Invocation	Executes `dotnet new connectsoft-library` directly

🧠 Example: Natural Language Prompt¶

Create a reusable library named ConnectSoft.Extensions.MyFeature that includes:
- Dependency Injection support
- Logging with ILogger<T>
- Custom options with validation
- Metrics tracking for observability
Use .NET 8 and set the build definition number to 42.

🔄 Resolved As:¶

{
  "name": "ConnectSoft.Extensions.MyFeature",
  "UseDI": true,
  "UseLogging": true,
  "UseOptions": true,
  "UseMetrics": true,
  "Framework": "net8.0",
  "buildDefinitionNumber": "42"
}

🧪 Example: Parameterized Prompt (via Planner or Skill)¶

{
  "intent": "generate-library",
  "parameters": {
    "name": "ConnectSoft.Integration.Payments",
    "UseDI": true,
    "UseLogging": true,
    "UseMetrics": false,
    "UseOptions": true,
    "Framework": "net8.0",
    "buildDefinitionNumber": "117"
  }
}

🛠️ CLI Invocation Example¶

dotnet new connectsoft-library \
  --name ConnectSoft.Integration.Payments \
  --UseDI true \
  --UseLogging true \
  --UseOptions true \
  --UseMetrics false \
  --Framework net8.0 \
  --buildDefinitionNumber 117

📐 Input Field Definitions¶

Field	Type	Required	Description
`name`	string	✅	Library name (used for folder, project, namespace)
`UseDI`	bool	⛔️ (optional)	Enable dependency injection setup
`UseLogging`	bool	⛔️	Adds structured logging
`UseOptions`	bool	⛔️	Adds `IOptions<T>` configuration and validation
`UseMetrics`	bool	⛔️	Adds metrics instrumentation and structure
`Framework`	string	⛔️ (default: net8.0)	Target framework or frameworks (`net8.0`, `net9.0`, `net8.0;net9.0`)
`buildDefinitionNumber`	string	⛔️	Used for CI versioning and metadata injection

🧠 Interpretation Strategy¶

The agent parses the input using resolve-template-flags
Applies the symbol mappings defined in template.json
Supports free-form LLM interpretation or structured config

📤 Output Expectations¶

🎯 Overview¶

The agent must produce a fully structured, CI/CD-ready, NuGet-compliant, and modular .NET library solution. Output is deterministic, traceable, and conditionally customized based on input flags (e.g., UseDI, UseMetrics).

Each output must adhere to ConnectSoft’s library blueprint standards and comply with factory-wide conventions for:

Clean Architecture
Observability-first design
Cross-cutting modularity
DevOps readiness
Multi-tenant platform compatibility

📁 Expected Output Structure¶

ConnectSoft.MyLibrary/
├── ConnectSoft.MyLibrary.sln
├── ConnectSoft.MyLibrary/
│   ├── ConnectSoft.MyLibrary.csproj
│   ├── MyLibrary.cs
│   ├── IServiceCollectionExtensions.cs         (if UseDI)
│   ├── Observability.cs                        (if UseLogging or UseMetrics)
│   ├── Metrics/                                (if UseMetrics)
│   ├── Options/                                (if UseOptions)
│   └── Internal/...                            (core logic files)
├── ConnectSoft.MyLibrary.UnitTests/
│   ├── ConnectSoft.MyLibrary.UnitTests.csproj
│   └── MyLibraryTests.cs
├── azure-pipelines.yml
├── README.md
└── .gitignore

📘 Artifact-Level Details¶

Artifact	Required	Description
`.sln` file	✅	Solution file referencing both projects
`.csproj`	✅	Includes multi-TFM config, NuGet metadata, dependencies
`README.md`	✅	Includes description, usage, CI badge placeholder
`azure-pipelines.yml`	✅	Pipeline with restore, build, test, pack, coverage
Unit test project	✅	Must include MSTest scaffold and coverage setup
Observability hooks	⛔️ (if UseLogging or UseMetrics)	Adds logs, spans, and/or metrics
Options setup	⛔️ (if UseOptions)	Binds and validates configuration models
DI wiring	⛔️ (if UseDI)	Adds registration extension method
NuGet-ready project	✅	Must produce a packable `.nupkg` with semantic version and metadata
Coverage validation	✅	Pipeline must enforce code coverage ≥ 70% threshold

✅ Success Criteria Checklist¶

✅ Condition	Must Be Met
🎯 Output folder is created with correct naming
📦 Projects compile and restore
🔬 Test project includes at least one scaffolded test
📊 Pipeline builds, tests, and reports coverage
📜 `.csproj` includes metadata (`Description`, `Authors`, etc.)
📁 Metrics/ and Options/ folders exist only when enabled
🧪 Code coverage enforced in YAML
📚 README contains placeholder sections and library purpose

🧠 Output Reporting (Return Format)¶

On success, the agent returns:

{
  "status": "success",
  "path": "output/ConnectSoft.MyLibrary",
  "projects": [
    "ConnectSoft.MyLibrary",
    "ConnectSoft.MyLibrary.UnitTests"
  ],
  "features": [
    "DI",
    "Logging",
    "Options"
  ],
  "ciPipeline": "azure-pipelines.yml",
  "artifacts": [
    "README.md",
    ".csproj",
    ".sln",
    ".gitignore"
  ]
}

On failure (e.g. missing file, invalid flag), the agent triggers auto-repair and retries before failing definitively.

🧠 Memory¶

🎯 Purpose of Memory¶

The agent uses memory to retain generation context, track reuse, support retries, and enable long-term knowledge evolution across thousands of generated libraries.

It blends short-term memory (for the current invocation) with long-term memory (to influence future generations, avoid duplication, and improve output traceability).

🧩 Memory Types¶

Type	Scope	Purpose
🧠 Short-Term Memory	Current execution context (ephemeral)	Stores user input, resolved flags, current output, retry count
🧬 Long-Term Memory	Persistent (cross-agent, cross-session)	Remembers previously generated libraries, naming conventions, structural patterns
📈 Execution Trace Memory	Observability layer	Logs all steps, spans, flags used, file paths, retry metadata
🧱 Structural Memory Graph	Vector/Graph DB	Captures semantic links between features, flags, modules, and reusable components

🧠 Short-Term Memory Contents (Ephemeral Context)¶

Parsed prompt input (name, flags, buildDefinitionNumber)
Resolved template.json symbols
All output paths and files generated
Retry attempts and their root causes
Output validation results

Stored in SK execution context (e.g. planner memory + agent context variables)

🧠 Long-Term Memory Contents (Persistent Knowledge Base)¶

🔁 Names and metadata of all previously generated libraries
🔄 Version history and build definition numbers
🧩 Reusable stubs, DI extensions, metrics patterns, YAML schemas
📌 Symbol flag combinations used frequently
🔍 Feature correlation graphs (e.g. metrics → always with logging)

Stored in memory graph (e.g., Azure Table, Cosmos DB, or vector store like Pinecone/Qdrant)

🧬 Memory Graph Sample¶

graph TD
    A[ConnectSoft.Metrics] --> B[UseMetrics: true]
    A --> C[UseLogging: true]
    B --> D[Inject MetricsRecorder.cs]
    C --> E[Inject ILogger<T>]
    A --> F[azure-pipelines.yml includes coverage stage]
    A --> G[NuGetMetadata v1.0.117]

Hold "Alt" / "Option" to enable pan & zoom

🔁 Use of Memory During Retry¶

Detects incomplete output (e.g. missing folder, misaligned symbols)
Retrieves last-known-good template config
Attempts self-correction based on known retry success patterns
Avoids duplication of known output names in long-term registry

📊 Observability Memory¶

Logs each step as a trace span with contextual parameters
Metrics stored: generation_duration, retry_count, files_generated, features_enabled
Stored in OpenTelemetry-compatible format or ConnectSoft’s internal trace collector

✅ Validation¶

🎯 Purpose¶

Validation ensures that the generated output meets all functional, structural, and compliance expectations defined by the ConnectSoft backend library blueprint. The agent automatically validates every output and determines whether to proceed, retry, or report failure.

🔎 Validation Layers¶

Layer	Description	Scope
📁 File Structure Validation	Ensures the correct folder and file hierarchy exists	`.sln`, `.csproj`, `/Options`, `/Metrics`, etc.
📜 Project Metadata Validation	Verifies `.csproj` includes correct TFM, authors, description, and NuGet metadata	Required for packaging
🧪 Test Project Check	Ensures test project is present, builds, and contains at least one valid test file	`UnitTests/` folder
🧱 Feature Toggle Enforcement	Verifies that flags like `UseDI` or `UseOptions` are respected in emitted code and structure	Includes or excludes related files/folders
⚙️ CI/CD Pipeline Check	Confirms `azure-pipelines.yml` exists and has all required jobs and tasks	Build, test, pack, coverage
🧪 Coverage Enforcement	If run in CI mode, validates coverage threshold logic (e.g., 70%) is present in YAML	Used by QA and pipeline agents
🔐 Sanity and Semantic Checks	Validates that each file compiles, namespaces are valid, and DI/Options are wired if declared	Basic syntax + structure
📚 README Presence	Verifies the inclusion of a structured `README.md` with placeholders and instructions	Always required

📘 Validation Logic Summary¶

graph TD
    A[Output Ready for Validation]
    B1[✅ File & Folder Structure]
    B2[✅ Project Metadata (.csproj)]
    B3[✅ Test Project Present]
    B4[✅ Flags Applied Correctly]
    B5[✅ YAML Pipeline Included]
    B6[✅ README Generated]

    A --> B1 & B2 & B3 & B4 & B5 & B6
    B1 --> C{Valid?}
    C -->|Yes| D[🎉 Pass]
    C -->|No| E[♻️ Retry Triggered]

Hold "Alt" / "Option" to enable pan & zoom

🧪 Sample Auto-Validation Checks¶

Check	Rule
`azure-pipelines.yml` exists?	✅
`TargetFrameworks` present?	At least one TFM required
`README.md` contains title & usage?	Title must include library name
`Options/` folder exists if `UseOptions=true`?	Yes
`ILogger<T>` usage exists if `UseLogging=true`?	Yes
`.csproj` includes `PackageId` and `Version`?	Yes
At least one test exists?	`*.Tests.cs` file must be present
CI YAML has coverage threshold set?	`minimumCoverage` must exist if enabled

📉 Failure Outcomes¶

On validation failure, the agent:

Logs the failed check
Emits observability trace (validation.failed, reason)
Triggers Retry/Correction Flow

♻️ Retry/Correction Flow¶

🎯 Purpose¶

The Retry/Correction Flow provides resilience and self-healing for the generation process. If output validation fails, the agent auto-corrects the root cause, regenerates, and re-validates — ensuring all outputs meet ConnectSoft blueprint standards without human intervention unless explicitly required.

🔁 When Retries Are Triggered¶

Failure Type	Example
🗂 Missing Artifacts	`.csproj` missing or misnamed; `UnitTests/` not created
🧩 Symbol Misalignment	`UseDI=true` but no `IServiceCollectionExtensions.cs` file generated
🧪 Test Stub Not Found	No test file in `UnitTests/` project
📜 YAML Pipeline Incomplete	`azure-pipelines.yml` missing `pack` or `coverage` stage
📚 README Not Generated	File missing or empty
🧱 Folder Structure Errors	`Options/` or `Metrics/` missing despite enabled flags
⚙️ Invalid Build Metadata	`.csproj` missing version, author, or `TargetFramework`
🧠 Semantic Conflict	Improper namespace, project name misaligned with template spec

🔄 Retry Execution Flow¶

flowchart TD
    A[🚨 Validation Failed] --> B[🧠 Detect Root Cause]
    B --> C[🔧 Apply Fix or Fallback]
    C --> D[⚙️ Regenerate Affected Artifacts]
    D --> E[✅ Re-run Validation]
    E --> F{Valid?}
    F -->|Yes| G[🎉 Success Output]
    F -->|No (max 2x)| H[❌ Final Failure + Human Intervention]

Hold "Alt" / "Option" to enable pan & zoom

🛠 Correction Techniques¶

Correction	Applied When
🆕 Regenerate missing file	Any core file is absent
🔁 Re-resolve template flags	Symbols may have been incorrectly resolved
📦 Re-run dotnet template engine	Structure corrupted or incomplete
🧠 Fallback to default values	If flags are partially missing or malformed
🧹 Auto-fix YAML schema	If common blocks (e.g., coverage, pack) are absent
🧪 Reinject test stub	If MSTest project lacks scaffold
🧾 Rebuild README.md	If formatting fails or metadata missing

🔢 Retry Limits¶

Parameter	Value
Max Retry Attempts	`2`
Retry Delay (between retries)	Immediate (same session)
Escalation Condition	After 2 attempts, the agent flags the task for human review or planner intervention

🧠 Memory Usage in Retry¶

Logs retry count and reasons
Stores retry success/failure traces for future pattern learning
Tags retry attempts with span IDs in observability hooks

🤝 Collaboration Interfaces¶

🎯 Purpose¶

The Backend Library Generator Agent operates as part of a coordinated multi-agent system in the ConnectSoft AI Software Factory. It collaborates with other agents and subsystems to fulfill cross-cutting concerns, enforce platform consistency, and prepare the generated library for testing, packaging, validation, and publishing.

🔌 Upstream Interfaces (Who Invokes It?)¶

Source Agent / System	Purpose
🧠 Planner Agent	Orchestrates generation based on software blueprint plan or persona intent
🧭 Studio CLI Interface	Allows developers to invoke generation with flags interactively
🧱 Feature Generator Agent	Requests library creation for shared modules, utility components
🔄 MCP Server	Issues `generate-library` intent via semantic interface

📤 Downstream Consumers (Who Uses Its Output?)¶

Target Agent / System	Usage
🧪 QA Agent	Consumes test project for code coverage enforcement and correctness validation
📦 Packaging Agent	Uses `.csproj` and version metadata to create and push `.nupkg` packages
📄 Documentation Agent	Updates README with usage examples, badges, links, and cross-library references
🔁 CI/CD Orchestrator Agent	Ingests YAML for triggering pipeline execution and DevOps feedback loops
🧠 Memory & Trace Agent	Records trace, retry stats, and outcome history for audit and evolution

📡 Communication Protocols¶

Channel	Protocol / Format
Internal Agent Call	Semantic Kernel function call chain
MCP Dispatch	Intent graph: `intent:generate-library` with flags
CLI	`dotnet new connectsoft-library` invocation
YAML / Markdown	Output artifacts for pipeline and documentation
JSON Contracts	Used for reporting results and input validation

🔁 Coordination Logic (e.g. Chained Execution)¶

sequenceDiagram
    participant PlannerAgent
    participant BackendLibraryGenerator
    participant QAAgent
    participant PackagingAgent
    participant DevOpsAgent

    PlannerAgent->>BackendLibraryGenerator: generate-library + flags
    BackendLibraryGenerator->>QAAgent: emit test project
    BackendLibraryGenerator->>PackagingAgent: pass .csproj metadata
    BackendLibraryGenerator->>DevOpsAgent: emit azure-pipelines.yml

Hold "Alt" / "Option" to enable pan & zoom

📚 Interface Data Contracts¶

Data	Format	Description
Generation Input	JSON / Prompt	CLI flags, prompt intent, template symbols
Generation Output	JSON	File structure, feature flags, success status
Retry Metadata	Trace span	Retry reason, fixed symbol, resolution path
Observability Hooks	Trace & Metric event	Logs: `generator.success`, `pipeline.generated`, `retry.attempted`

📈 Observability Hooks¶

🎯 Purpose¶

Observability ensures traceability, diagnosability, and performance visibility of every backend library generation task. The Backend Library Generator Agent is instrumented with structured logs, metrics, and trace spans, aligned with ConnectSoft’s Observability-First principle.

🔎 Instrumentation Types¶

Type	Description	Tools
📜 Structured Logs	Key execution points and outcomes	SK Logging, Serilog (optional)
📊 Metrics	Quantitative measurements	OpenTelemetry, Prometheus-exported metrics
🔍 Traces / Spans	Execution paths with performance timing and error tracking	OpenTelemetry, Application Insights

📘 Key Emitted Logs¶

Log Event	Description
`library.generation.start`	Received generation request
`template.symbols.resolved`	Flags and TFM resolved from prompt
`template.instantiation.success`	Files generated from template
`output.validation.passed`	Output matches expected structure
`output.validation.failed`	Triggered retry due to failure reason
`retry.attempt`	Retry cycle initiated
`library.generation.success`	Output finalized and passed
`library.generation.failed`	All retries exhausted; escalation needed

📊 Metrics Emitted¶

Metric	Description	Tags
`generation.duration.ms`	Total time to generate the library	`features`, `result`
`retry.count`	Number of retries attempted	`failure_reason`
`files.generated`	Total number of files created	`features`, `project_type`
`validation.failures`	Validation issues before retry	`type`
`template.flags.enabled`	Count of flags like `UseDI`, `UseLogging` used	`flag`
`project.test.coverage_threshold_set`	Was coverage threshold injected into YAML?	`true/false`

🧵 Trace Structure (OpenTelemetry)¶

flowchart TD
    A[Span: library.generation.start]
    B[Span: symbols.resolved]
    C[Span: template.instantiated]
    D[Span: output.validated]
    E[Span: retry.attempt (if needed)]
    F[Span: generation.complete]

    A --> B --> C --> D --> E --> F

Hold "Alt" / "Option" to enable pan & zoom

Each span contains:

Start/End timestamp
Outcome (success/fail)
Tags: library name, retry count, enabled features

💡 Observability Destinations¶

Channel	Tool
🟣 DevLogs	Azure Application Insights, Serilog
🟢 Metrics	Prometheus or OpenTelemetry Collector
🔵 Traces	Jaeger, Zipkin, Azure Monitor

🧍‍♂️ Human Intervention Hooks¶

🎯 Purpose¶

While the Backend Library Generator Agent is designed for fully autonomous execution, it includes strategically placed human intervention points. These are triggered only when necessary — for edge cases, failure recovery, template evolution, or guided overrides.

Human-in-the-loop functionality ensures robustness across novel or uncertain situations without compromising automation.

🧠 Intervention Scenarios¶

Scenario	Description	Action
❌ Exhausted Retries	Agent failed to generate valid output after two retries	Escalate to developer with failure report and retry log
❓ Ambiguous Feature Intent	Conflicting or missing input instructions (e.g. UseMetrics but no UseLogging)	Prompt developer to clarify or override defaults
🧩 Missing Template Dependency	Required template files or symbols are missing	Pause execution, notify template maintainer
🔄 Library Already Exists	Conflict with existing module in registry or Git	Confirm overwrite, version bump, or duplicate rejection
✏️ Manual Customization Mode	Developer explicitly requests to inject custom content before generation finalization	Pause before final emit, allow manual edits in preview

👨‍💻 Entry Points for Intervention¶

Mode	Method
🔔 Studio Notification	Alert in ConnectSoft Studio UI (if integrated)
📬 DevOps Email/Webhook	Sends structured payload with failure logs
🧠 Planner Escalation	Issues `requires-human-confirmation` intent
📝 Editable Staging Folder	Drops intermediate output in a staging folder (`/generated/.staging`) for manual review
💬 ChatOps Integration	Slack / Teams / DevBox message with regeneration/retry options

📄 Escalation Report Format¶

{
  "status": "failed",
  "reason": "Validation failed: missing Observability.cs",
  "flags": {
    "UseDI": true,
    "UseOptions": true,
    "UseMetrics": true
  },
  "retryAttempts": 2,
  "actionRequired": "Manually inspect template conditions or adjust template.json"
}

🧑‍🔧 Human Override Options¶

Option	Result
✅ `Approve With Warning`	Proceed despite warnings
🛠 `Fix and Retry`	Modify template files, then restart
🧻 `Ignore Flag`	Remove specific symbol before regeneration
✏️ `Inject Manual Code`	Add custom file or logic manually
🔁 `Force Overwrite`	Replace existing output in conflict scenario

🧾 Summary and Conclusion¶

🎯 Agent Identity¶

The Backend Library Generator Agent is a core engineering agent in the ConnectSoft AI Software Factory, responsible for autonomously generating reusable, production-grade .NET backend libraries. It operates from prompt to artifact, aligning outputs with platform-wide standards and triggering downstream CI/CD, testing, and publishing agents.

🧩 Agent in the Factory Flow¶

flowchart TD
    A[📌 Planner Agent] --> B[🛠 Backend Library Generator Agent]
    B --> C[🧪 QA Agent]
    B --> D[📦 Packaging Agent]
    B --> E[📄 Documentation Agent]
    B --> F[⚙️ CI/CD Orchestrator Agent]

Hold "Alt" / "Option" to enable pan & zoom

The agent is typically invoked when:

A new feature module requires a shared utility or abstraction
A cross-service concern is extracted into a reusable package
A platform enhancement introduces observability, DI, or metrics layers

🔐 Core Responsibilities¶

Generate a scaffolded, validated, and ready-to-publish backend library
Support modular feature flags like UseDI, UseLogging, UseOptions, UseMetrics
Emit consistent outputs: .sln, .csproj, code files, test project, YAML, README
Enforce standards for:
Clean Architecture
Multi-TFM .NET support
Observability integration
CI/CD pipeline readiness

🧠 Capabilities Recap¶

Category	Details
🧠 Prompt Understanding	Natural or structured prompt resolution
🏗 Code Generation	`dotnet new` with ConnectSoft.LibraryTemplate
🧩 Flag Handling	Dynamically includes DI, logging, metrics, config
🧪 Validation	Multi-layer: structure, correctness, CI-readiness
♻️ Retry Logic	Detects, fixes, and regenerates invalid outputs
🔌 Collaboration	Works with QA, Packaging, DevOps, and Memory Agents
📈 Observability	Logs, metrics, spans for traceability
🧍‍♂️ Human-In-The-Loop	Escalates only when automated recovery fails

🏁 Output Snapshot (Example)¶

{
  "library": "ConnectSoft.Integration.Payments",
  "features": ["DI", "Logging", "Options"],
  "pipeline": "azure-pipelines.yml",
  "status": "success",
  "path": "output/ConnectSoft.Integration.Payments",
  "generatedAt": "2025-06-14T13:05:00Z"
}

🚀 Strategic Role in the Factory¶

The Backend Library Generator Agent enables:

Scalable reuse of core business logic
Faster onboarding of engineers via prebuilt templates
Consistent architecture enforcement across 1000s of modules
Plug-and-play automation into QA, CI/CD, and DevOps flows
Continuous improvement through retry learning and memory graphs

🗂️ Backend Library Generator Agent Specification¶

🧠 Agent Purpose and Factory Role¶

🎯 Purpose¶

🧩 Role in the Platform¶

🧬 Agent Placement in System Flow¶

🧠 Typical Triggers¶

📌 Summary¶

🧠 Responsibilities¶

🎯 Primary Responsibilities¶

📌 Detailed Responsibilities¶

🔄 Execution Scope¶

🧠 Intelligent Handling¶

🧠 Inputs¶

📥 Overview¶

📦 Input Categories¶

🔠 CLI Parameter Example¶

🧩 Template Symbols (from template.json)¶

🧠 Prompt-Based Input (from other agents or user)¶

📂 Additional Metadata Retrieved from Factory Context¶

✅ Input Validation (Pre-flight)¶

🧾 Outputs¶

📦 Output Summary¶

📁 Solution-Level Output Structure¶

📘 Artifacts and Content¶

📤 Output Destinations¶

📂 Conditional Outputs¶

📌 Downstream Usage¶

🧠 Knowledge Base¶

🧩 Embedded Domain Knowledge¶

📚 Foundation Templates and Assets¶

🧠 Pre-trained Prompt Knowledge¶

🧠 Internal Ontologies and Inference Rules¶

📦 Linked Agent Knowledge¶

🔄 Process Flow¶

🧭 Overview¶

🔁 High-Level Workflow¶

🧬 Detailed Step Breakdown¶

🧠 Factory-Wide Interactions¶

🔍 Observability Integration Points¶

🛠 Skills and Semantic Kernel Functions¶

🧠 Overview¶

🧩 Core Skills¶

🔌 Example Function Chain¶

⚙️ Skills Categorized by Purpose¶

🧠 Interpretation & Setup¶

📦 Generation & Synthesis¶

✅ Validation & Retry¶

📈 Observability & Reporting¶

💡 Extensibility Note¶

🧰 Technology Stack¶

🔧 Core Technology Components¶

🧠 Agent Bootloader Environment¶

🌐 Integration Touchpoints¶

🧱 Stack Visual¶

🧾 System Prompt¶

🎯 Purpose of the System Prompt¶

📜 System Prompt (Verbatim)¶

🧠 Agent Behaviors Encoded in Prompt¶

📝 Input Prompt Template¶

🎯 Purpose¶

🧩 Supported Input Modes¶

🧠 Example: Natural Language Prompt¶

🔄 Resolved As:¶

🧪 Example: Parameterized Prompt (via Planner or Skill)¶

🛠️ CLI Invocation Example¶

📐 Input Field Definitions¶

🧠 Interpretation Strategy¶

📤 Output Expectations¶

🎯 Overview¶

📁 Expected Output Structure¶

📘 Artifact-Level Details¶

✅ Success Criteria Checklist¶

🧠 Output Reporting (Return Format)¶

🧠 Memory¶

🎯 Purpose of Memory¶

🧩 Memory Types¶

🧠 Short-Term Memory Contents (Ephemeral Context)¶

🧠 Long-Term Memory Contents (Persistent Knowledge Base)¶

🧬 Memory Graph Sample¶

🔁 Use of Memory During Retry¶

🧩 Template Symbols (from `template.json`)¶