🧠 Code Committer Agent Specification¶

🎯 Purpose¶

The Code Committer Agent is the GitOps executor responsible for transforming validated code artifacts into traceable, audit-ready, version-controlled commits in the platform's source repositories.

Its core mission is to:

🧩 Automate the process of staging, validating, formatting, and committing code to Azure DevOps Git repositories — ensuring all changes are trace-linked, convention-compliant, and ready for downstream pipelines and collaboration.

🛠️ Why This Agent Exists¶

Manual commits often lack traceability, naming discipline, or lifecycle awareness. Without this agent, the system would face:

❌ Unlinked commits with missing upstream context
❌ Traceability gaps across feature, ticket, and commit
❌ Inconsistent commit messages or commit hygiene
❌ Human bottlenecks in high-frequency service generation

With this agent:

✅ Every commit is auto-tagged, semantic, and traceable
✅ Commit metadata includes links to vision, feature, PR, or defect
✅ The agent ensures the branch is correct and policy-compliant
✅ Human engineers or other agents can build reliably atop a clean commit history

🧩 Position in the Agent Workflow¶

flowchart TD
    MicroserviceGenerator --> BackendDeveloper
    BackendDeveloper --> CodeCommitter
    CodeCommitter --> PullRequestCreator
    PullRequestCreator --> DevOpsAgent

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

The Code Committer Agent:

Receives code from:
- Microservice Generator Agent
- Backend Developer Agent
- Library Generator Agent
Pushes traceable commits to:
- Azure DevOps Repos
- Pull Request Creator Agent
- DevOps Agent for CI/CD triggers

🏷️ ConnectSoft Principles Alignment¶

Principle	Committer Agent Role
Clean Architecture	Enforces modular boundaries and layer-specific commits
DDD	Commits map to aggregate, use case, or bounded context
Observability-First	Includes trace IDs, span markers, and metadata for Git tracking
Event-Driven	Emits `CommitCreated`, `TraceLinkedCommit` events
Security-First	Signs commits, respects secret scanning, and branch permissions
Multi-Tenant SaaS	Supports tenant-specific repo structures or edition forks
Cloud-Native	Compatible with Azure DevOps REST APIs and GitOps patterns

🔁 Example Commit Trace Flow¶

sequenceDiagram
    participant DevAgent as Backend Developer Agent
    participant Committer as Code Committer Agent
    participant AzureGit as Azure DevOps Git Repo
    participant PR as Pull Request Creator Agent

    DevAgent->>Committer: Code changes with trace metadata
    Committer->>AzureGit: Git commit + push + tag
    Committer->>PR: Notify of commit and trigger PR creation
    AzureGit-->>Committer: Commit success response

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

📍 Summary¶

The Code Committer Agent turns disconnected source files into structured, traceable, and build-ready commit units that align with ConnectSoft’s trace-first engineering model. It is the Git orchestrator for all engineering agents and the enabler of hands-free GitOps delivery.

📋 Core Responsibilities¶

The Code Committer Agent is responsible for managing the entire commit lifecycle, from validating code artifacts to pushing version-controlled changes to Azure DevOps.

🧱 Functional Responsibilities¶

Responsibility	Description
Staging Code Artifacts	Gathers file changes from agent-generated code in a local or virtual working directory.
Trace Validation	Ensures each change is traceable to a `trace_id`, feature ID, or architecture blueprint (e.g., use case, domain event).
Commit Message Generation	Creates clear, structured, and semantically enriched commit messages (e.g., `feat(domain): add CreateOrderHandler [trace:abc123]`).
Pre-Commit Validation	Runs linting, formatting, or static checks before committing code (e.g., `dotnet format`, `eslint`).
Git Commit Creation	Uses Git APIs or CLI to commit changes to the correct working branch.
Commit Metadata Injection	Attaches commit info: `trace_id`, blueprint origin, author agent ID, source branch, timestamps.
Commit Signing (optional)	Applies GPG or Azure-based signing (if enabled in repo policy).
Branch Policy Compliance	Ensures commits go to the right feature or service branch; creates it if needed.
Push to Azure DevOps	Pushes commits to remote via authenticated APIs or Git remote URLs.
Trigger Pull Request Agent	Emits a `CommitCompleted` event to notify downstream agents.
Log & Tag Commits	Tags commits (e.g., `microservice-init`, `usecase-order-create`) for traceability.

📌 Special Agent Behaviors¶

Behavior	Details
Single Responsibility Commits	Splits grouped changes into atomic commits per use case or component.
Semantic Commit Rules	Enforces format: `type(scope): message [trace_id]` (e.g., `feat(billing): AddInvoiceJob [trace:xyz789]`).
Trace Link Enforcement	Fails commit if no trace ID, use case ID, or upstream reference is present.
Fallback Mode	If Git push fails (e.g., branch protection), queue it for manual review via Human Intervention Hook.

✅ Examples of Agent Output¶

$ git commit -m "feat(order): implement CreateOrderHandler [trace:fea-12345]"
$ git tag add usecase-order-create
$ git push origin feature/order-service

🎯 All commits must meet Git hygiene, include trace links, and follow branch strategy conventions for ConnectSoft.

🔄 Typical Execution Lifecycle¶

graph TD
    A[Receive File Bundle] --> B[Validate Traceability]
    B --> C[Run Format + Lint Checks]
    C --> D[Generate Commit Message]
    D --> E[Create Git Commit]
    E --> F[Push to Azure DevOps]
    F --> G[Emit CommitCompleted Event]

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

🔒 Compliance Alignment¶

The agent enforces commit policies aligned with:

✅ SOC2 and ISO audit trail requirements
✅ GitOps change control strategies
✅ Zero-trust code delivery (with trace-first commit model)

🧠 Summary¶

The Code Committer Agent is the gatekeeper of version control quality — ensuring that every software artifact entering the ConnectSoft factory's repositories is clean, compliant, and contextually linked to the upstream vision.

📥 Input Overview¶

The Code Committer Agent consumes a structured set of inputs that inform what code needs to be committed, how it should be tagged and traced, and which repository/branch it belongs to.

These inputs originate from Software Engineering Agents, Architectural Blueprints, and the GitOps environment.

🧾 Primary Input Channels¶

1. Code Artifacts¶

Source	Examples
Backend Developer Agent	`.cs`, `.csproj`, `.yaml`, `.md`
Generator Agents	Use case handlers, DTOs, mapping profiles, DI registrations
Library Generator Agent	Reusable classes, helpers, SDKs, infrastructure stubs

These artifacts are placed into the agent’s working directory or virtual file system via upstream agents or shared workspace mounts.

2. Commit Metadata¶

Field	Description
`trace_id`	Unique identifier connecting commit to upstream feature or domain model
`agent_id`	ID of the producing agent (e.g., `backend-dev-987`)
`artifact_type`	Code category: `usecase`, `infrastructure`, `controller`, `test`, etc.
`origin_blueprint_id`	Reference to the feature, vision doc, or domain model this commit realizes
`component_scope`	Logical module/bounded context (e.g., `billing`, `order`, `auth`)

3. Target Git Context¶

Field	Description
`repo_url`	Azure DevOps Git repo endpoint
`repo_name`	Logical name of repo (e.g., `ConnectSoft.OrderService`)
`branch_name`	Target branch (e.g., `feature/create-order-handler`)
`branch_strategy_metadata`	Indicates if the agent should create a new branch or append to an existing one
`auth_token`	Secure token for push access (from secret store or runtime identity)

4. Policy & Convention Config¶

Field	Description
`commit_format_rules.json`	Commit message format templates and enforcement regex
`traceability_policy.yaml`	Rules on mandatory metadata for commit acceptance
`git_hooks_config.yaml`	Pre-commit and post-commit hook definitions
`commit-signing-config`	Whether to sign, how to sign, and certificate/key references

5. Agent Runtime Context¶

Input	Description
`agent_execution_context`	Timestamp, run ID, environment metadata
`retry_token`	Indicates if this run is a retry attempt
`prior_commit_hash`	Used to identify deltas for incremental commits
`observability_context`	Span ID, logging context, telemetry injection hooks

🗂️ Example Input Bundle¶

{
  "files": ["src/Order/CreateOrderHandler.cs", "tests/Order/CreateOrderTests.cs"],
  "trace_id": "trace-ord-8128",
  "repo_url": "https://dev.azure.com/connectsoft/OrderService/_git/OrderService",
  "branch_name": "feature/order-create-handler",
  "agent_id": "backend-dev-92",
  "origin_blueprint_id": "usecase-order-create",
  "component_scope": "Order",
  "commit_type": "feat",
  "policy_profile": "strict-traceable-v1"
}

🧠 Summary¶

The Code Committer Agent works with a rich and controlled input envelope, ensuring that every commit is traceable, scoped, and aligned with architectural and security policies — all while automating the burden of Git hygiene and compliance.

📤 Output Overview¶

The Code Committer Agent produces structured and traceable outputs that serve as the canonical source of truth for what has been versioned, validated, and pushed into source control.

These outputs support downstream agents (like PR Creators, QA agents, DevOps pipelines) and provide a complete audit trail for governance and observability.

✅ Primary Output Artifacts¶

1. Git Commit (Tracked Artifact)¶

Field	Description
`commit_hash`	SHA of the commit
`message`	Semantically enriched message (e.g., `feat(order): add handler [trace:abc123]`)
`branch`	Name of the branch to which the commit was pushed
`repository`	Git repo path
`author_agent_id`	ID of the agent that performed the commit
`timestamp`	UTC timestamp of commit
`files_changed`	List of committed files
`tags`	Optional Git tags (e.g., `microservice-init`, `usecase-invoice-gen`)

✅ These commits are convention-compliant, trace-linked, and policy-validated before pushing.

2. Commit Metadata Record¶

Purpose	Stored as structured JSON or event
Fields	`trace_id`, `commit_hash`, `blueprint_ref`, `agent_id`, `file_list`, `use_case_ref`
Destination	Telemetry stream, vector DB, or central change registry (`/commit-events`)

This metadata enables reverse traceability — any system artifact can be traced back to its commit and originating blueprint.

3. Git Tag (Optional)¶

Example Tags
`feature/order-service-v1`
`adapter-init-payment`
`bugfix/fix-null-check`

🧠 Tags help downstream agents (e.g., ReleaseManagerAgent, DeploymentOrchestrator) identify functional milestones or patch boundaries.

4. CommitCompleted Event¶

Triggered To	`PullRequestCreatorAgent`, `ObservabilityAgent`, `ChangeControlSystem`
Fields	The `CommitCompleted` event payload includes the following fields:

{
  "event": "CommitCompleted",
  "trace_id": "trace-ord-8128",
  "commit_hash": "9fbc871...",
  "repo": "OrderService",
  "branch": "feature/order-handler",
  "agent": "code-committer-agent",
  "status": "success"
}

Explanation:

event: The name of the event being emitted (e.g., CommitCompleted), indicating that the commit process has finished.
trace_id: A unique identifier for tracking the event across different systems for traceability (e.g., trace-ord-8128).
commit_hash: The unique commit hash associated with the commit that was completed (e.g., 9fbc871...).
repo: The repository where the commit occurred (e.g., OrderService).
branch: The branch in the repository where the commit was made (e.g., feature/order-handler).
agent: The agent that emitted the event (e.g., code-committer-agent), indicating that the commit was completed by this agent.
status: The status of the commit operation (e.g., success, failure, or pending).

🛰️ Enables orchestration chaining to trigger PR generation, test job setup, or release queueing.

5. Observability Events¶

Format	OTEL-compatible spans or structured logs
Includes	The Observability Events should include the following:
	- Commit start/end: Marks the beginning and completion of a commit operation for traceability.
	- Errors: Logs any errors that occur during the commit process, including failure details.
	- Retries: Logs any retry attempts in case of failure, along with the retry strategy used.
	- Trace links: Links to traceable spans to maintain traceability throughout the system for debugging and monitoring.
Used by	- `ObservabilityAgent`: For real-time monitoring, logging, and trace injection. - Dashboards: For displaying metrics and visual representations of event processing. - Alert systems: To trigger alerts for abnormal behavior or failures during the commit process.

📂 Example Output Directory Structure (Local VFS)¶

/output/
├── commit.log.json
├── commit-completed-event.json
├── trace.txt
├── tags.txt
└── git-output.log

🧠 Summary¶

The Code Committer Agent produces fully traceable, semantically structured commit artifacts that anchor all engineering changes to a verifiable chain of upstream logic and downstream automation. It acts as the ledger writer of software production in the ConnectSoft AI Factory.

📚 Knowledge Base Overview¶

The Code Committer Agent operates on an enriched contextual and procedural knowledge base. This includes:

GitOps mechanics and conventions
Traceability schema and metadata relationships
Commit semantics and formatting rules
Azure DevOps API contracts
Organizational branch and tagging strategies
ConnectSoft-specific blueprint-to-artifact mappings

🧠 Embedded Knowledge Assets¶

1. Commit Format Templates¶

Name	Example
`SemanticCommitTemplate`	`feat({scope}): {message} [trace:{trace_id}]`
`FixTemplate`	`fix({module}): {fix_desc} [trace:{trace_id}]`
`RefactorTemplate`	`refactor({target}): simplify {logic} [trace:{trace_id}]`

These templates are embedded in prompt memories or as YAML/JSON policy files loaded at runtime.

2. Traceability Mapping Rules¶

Maps	From → To
`trace_id` → `blueprint_id`, `use_case_name`, `agent_origin`
`repo_name` → `bounded_context`, `microservice_id`
`file_path` → `layer` (`domain`, `app`, `infra`, etc.)

✅ Enables enforcement that each commit links to a valid architectural intent.

3. ConnectSoft Git Hygiene Policies¶

Includes:

Allowed commit types: feat, fix, refactor, test, docs, chore
Mandatory commit fields: scope, trace_id, message
Disallowed patterns (e.g., WIP, temp, fix this later)

Stored as:

commit_policy:
  require_trace_id: true
  allowed_types: [feat, fix, test, docs, refactor, chore]
  enforce_branch_prefix: true
  allowed_branch_prefixes: [feature/, bugfix/, hotfix/, chore/]

4. Azure DevOps Integration Schema¶

What It Knows

How to authenticate via OAuth PATs or agent-assigned identities
How to push to branches via GitHttpClient
How to handle errors like branch protection, permission denied, rebase conflicts

Includes retry logic, common failure patterns, and fallback messaging.

5. Blueprint-to-Artifact Memory¶

Stored in a vector or structured JSON store:

{
  "trace_id": "trace-ord-8128",
  "blueprint_id": "usecase-create-order",
  "files": [
    "src/Application/Handlers/CreateOrderHandler.cs",
    "src/Domain/Events/OrderCreated.cs"
  ]
}

This allows the agent to match files to their architectural source, even across multiple runs.

6. Agent Identity & Signature Rules¶

Known Values
Current Agent ID: `code-committer-agent`
Signature Style: `ConnectSoft GitOps Signature v1`
Optional GPG Config: Configurations for GPG key-based signing, used for secure verification of commits in CI/CD pipelines. Optional CI Key Reference: Reference to CI keys used for signing commits and ensuring authenticity and integrity during the commit process.

🧠 Agent Capabilities Based on Knowledge¶

Capability	Powered By
Commit validation	Commit policy knowledge + file layer mapping
Trace enforcement	Traceability rules + upstream blueprint map
Semantic formatting	Commit templates + regex validators
Branch strategy compliance	Git policy knowledge + repo naming map
Commit metadata population	Agent ID + runtime context config

🔄 Sample Internal Lookup Flow¶

flowchart TD
    A[Incoming File List] --> B[Match Files to Blueprint Trace ID]
    B --> C[Determine Commit Type]
    C --> D[Generate Message via Template]
    D --> E[Validate Against Policy]

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

🧠 Summary¶

The Code Committer Agent is not a generic Git bot — it is an intelligent, policy-driven GitOps executor that encodes rich ConnectSoft-specific engineering knowledge to produce compliant and traceable source control activity.

🔁 Internal Execution Workflow¶

The Code Committer Agent operates in a deterministic, trace-aware pipeline that ensures every commit is clean, traceable, validated, and policy-compliant. It also integrates tightly with Git APIs and emits telemetry for downstream consumption.

🧭 High-Level Workflow¶

flowchart TD
    A[Receive Inputs from Engineering Agents] --> B[Validate Traceability & Metadata]
    B --> C[Run Lint/Format/Tests if configured]
    C --> D[Generate Commit Message from Template]
    D --> E[Create Git Commit Locally]
    E --> F[Apply Tags and Sign (if needed)]
    F --> G[Push to Azure DevOps Branch]
    G --> H[Emit CommitCompleted Event]

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

🪜 Step-by-Step Process Breakdown¶

1. Input Ingestion¶

Receives a file delta and metadata bundle:
- File paths, trace_id, blueprint ID, component scope
- Target repo and branch
- Auth token or agent identity

2. Validation Phase¶

Ensures:
- All files map to a valid trace ID
- Agent origin is trusted
- Branch name follows allowed patterns
- Commit will not violate policies (WIP, no-trace, etc.)

3. Code Quality Enforcement¶

Runs formatting and linting if configured:
- .NET: dotnet format, dotnet build
- JS/TS: eslint, prettier
May block commit if errors exceed threshold

4. Commit Message Assembly¶

Chooses correct template (e.g., feat, fix, chore)
Applies scope, component, and trace reference
Example: feat(order): implement CreateOrderHandler [trace:ord-8128]

5. Git Commit Creation¶

Stages all relevant files (git add)
Executes commit with metadata message
Optionally signs commit (GPG or token-based)
Injects trace metadata into commit body or as separate file (.trace.json)

6. Tag Application¶

Applies semantic tags (e.g., usecase-create-order)
Tags are optional but emitted if enable_tags: true is in config

7. Push to Remote¶

Uses Azure DevOps Git API or git push over HTTPS
Ensures correct feature branch exists (creates if needed)
Handles conflict retries if commit race detected

8. Emit Events¶

Posts structured CommitCompleted event to:
- Event bus (e.g., Service Bus)
- PR Agent
- DevOps pipeline trigger
- Vector store or GitOps dashboard

🔄 Error/Edge Case Handling (Preview of Cycle 14)¶

Scenario	Action
Missing trace_id	Abort + emit error
Branch conflict	Retry push or switch to fallback branch
Lint error	Block commit + log
Git push error	Retry 3 times, then escalate to human hook

📌 Example Commit Output (End State)¶

✔ Files validated and traced
✔ Lint checks passed
✔ Commit created: 9fbc871
✔ Branch pushed: feature/order-handler
✔ Tag added: usecase-create-order
✔ Event emitted: CommitCompleted [trace:ord-8128]

🧠 Summary¶

The Code Committer Agent’s process flow ensures that no commit enters the system without verification, semantic formatting, traceability, and execution accountability. It is the backbone of ConnectSoft’s trace-first, GitOps-secure software delivery model.

🧠 Functional Capabilities Overview¶

The Code Committer Agent is built on a modular skillset powered by the Semantic Kernel, integrating code analysis, Git control, commit message generation, and DevOps orchestration.

These skills are either:

Native Semantic Kernel functions (SK Plugins),
Custom plugins built for ConnectSoft’s GitOps flows,
Or Azure DevOps-integrated tools via REST APIs and CLI wrappers.

🧩 Core Skills and Plugins¶

Skill Name	Type	Description
`FileReaderSkill`	Native	Reads and analyzes file diffs, structure, metadata
`GitSkill`	Custom	Interfaces with Git CLI or LibGit2Sharp to stage, commit, push, tag
`AzureDevOpsSkill`	REST API Plugin	Authenticates, lists repos, pushes branches, verifies permissions
`SemanticCommitMessageSkill`	LLM Plugin	Generates `feat(scope): msg [trace]` format using trace context
`ValidationSkill`	Native + Custom	Enforces commit policy (trace ID, naming, scope mapping)
`ErrorHandlingSkill`	AgentControl	Handles retries, escalation, and human feedback on failure
`TelemetryEmitSkill`	Custom	Sends OTEL spans or structured JSON logs for observability pipeline
`GitTagSkill`	Custom	Applies semantic tags to commits (e.g., feature-ready, module-init)

📦 Example Semantic Kernel Function Signatures¶

`GitSkill.StageFiles`¶

{
  "input": [ "src/Order/CreateOrderHandler.cs", "tests/OrderHandlerTests.cs" ]
}

`SemanticCommitMessageSkill.Generate`¶

{
  "type": "feat",
  "scope": "order",
  "message": "implement CreateOrderHandler",
  "trace_id": "ord-8128"
}

→ Output: feat(order): implement CreateOrderHandler [trace:ord-8128]

🧠 Composite Kernel Plan (Used at Runtime)¶

Plan: CommitSourceChange
Steps:
1. ValidateInputs (ValidationSkill)
2. GenerateCommitMessage (SemanticCommitMessageSkill)
3. StageFiles (GitSkill)
4. Commit (GitSkill)
5. TagCommit (GitTagSkill)
6. PushToAzureDevOps (AzureDevOpsSkill)
7. EmitTelemetry (TelemetryEmitSkill)
8. NotifyPRAgent (TelemetryEmitSkill / EventBus)

🤖 Agent-Level Behaviors Enabled by Skills¶

Behavior	Powered By
Smart commit message generation	`SemanticCommitMessageSkill`
Commit signing or tagging	`GitSkill`, `GitTagSkill`
Policy enforcement (no WIP, has trace ID)	`ValidationSkill`
Azure DevOps branch push and validation	`AzureDevOpsSkill`
Full telemetry + retries	`TelemetryEmitSkill`, `ErrorHandlingSkill`

🔄 Pluggability¶

All skills are:

Composable: Used across other agents (e.g., PR Creator Agent)
Overridable: Dev team can replace GitSkill with GitHub CLI or GitLab SDK
Secure: All outbound commits use injected identity or vault-based token

🧠 Summary¶

The Code Committer Agent’s skillset transforms it from a basic Git actor into a trace-aware, policy-enforcing, autonomous software agent. Each commit operation is powered by intelligent, modular skills fully compatible with the ConnectSoft AI orchestration fabric.

🧰 Core Technology Stack¶

The Code Committer Agent operates within a modular, cloud-native, AI-augmented stack that integrates deeply with Git version control, Azure DevOps, and Semantic Kernel.

✅ Primary Technology Components¶

Category	Technology / Service	Purpose
AI Kernel	Semantic Kernel	Orchestrates prompt workflows, skill execution, and planning
LLM Backend	OpenAI (Azure OpenAI preferred)	Generates commit messages, resolves ambiguity, formats trace links
Agent Runtime	MCP Server (Model Context Protocol)	Hosts agent executions, workflows, identities
Git Engine	Git CLI / LibGit2Sharp	Executes `add`, `commit`, `tag`, `push` operations
Source Control	Azure DevOps Repos	Primary Git provider with REST API integration
REST Integration	Azure DevOps Services API	Pushes commits, fetches branches, triggers pipelines
Observability	OpenTelemetry (OTEL)	Emits trace spans for commit steps, errors, duration
Identity & Auth	Managed Identity / Vaulted PATs	Secure push access to Git, authenticated REST calls
Error Handling	Retry/Rescue Planner + Feedback Queue	Detects push failures, missing trace, and escalates
Config Store	Agent Memory DB (Redis or Cosmos DB)	Stores trace-to-commit maps, retry state, and metadata

📦 Technology Integration Diagram¶

graph TD
    A[Semantic Kernel] -->|Skills & Plans| B[Git CLI / LibGit2Sharp]
    A --> C[OpenAI / Azure OpenAI]
    A --> D[MCP Server]
    A --> E[Azure DevOps API]
    B --> F[Azure DevOps Repos]
    D --> G[Observability Pipeline (OTEL)]
    D --> H[Vault / Secrets Store]

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

⚙️ Agent Bootstrapping Tools¶

Containerized Agent Host: connectsoft-agent-runner (runs inside AKS / container)
Plugin Loader: Loads GitSkill, ValidationSkill, etc., into SK planner
Trace Validator Plugin: Verifies trace → blueprint linkage via GraphStore or vector DB
GitOps Policy Loader: Loads commit rules and templates from commit-policy.yaml

🧠 Runtime Characteristics¶

Characteristic	Implementation
Stateless compute	Hosted per-run inside AKS pod or job
Retry-aware	Built-in exponential backoff for Git push or branch conflicts
OTEL-compliant	Each step emits a span with success/error tags
Isolated auth	PAT or managed identity scoped to agent role and repo
Audit-compliant	Every commit includes author ID, trace ID, and component scope

🔐 Security Considerations¶

All repo write access must:
- Use time-limited secrets or identity-based auth
- Be scoped per repo (e.g., Write on OrderService, not global)
Commits may include signature via:
- GPG (if configured) or Azure DevOps Identity Commit Signing

📘 Example Tools & Packages Used¶

Name	Use
`LibGit2Sharp`	In-memory Git operations
`Azure.Identity` + `Azure.DevOps.Clients`	Git push, branch list, REST calls
`OpenTelemetry.Exporter.Console`	For agent-local debugging traces
`connectsoft-sk-plugin-git`	SK plugin for staging, commit, push
`connectsoft-gitpolicy-core`	Shared rules engine for commit validation

🧠 Summary¶

The Code Committer Agent operates using a robust, secure, and fully observable tech stack built on Semantic Kernel, Git, and Azure DevOps — enabling trace-first, policy-driven source control automation for ConnectSoft’s AI-generated software.

📜 System Prompt¶

The System Prompt is the initial bootstrap instruction given to the agent's LLM/planner that governs its behavior, responsibilities, tone, constraints, and goals during each run.

It sets the agent’s context and ensures every interaction aligns with ConnectSoft’s principles and traceability model.

🧠 Code Committer Agent – System Prompt¶

You are the Code Committer Agent in the ConnectSoft AI Software Factory.

Your primary responsibility is to generate, validate, and push version-controlled commits to Azure DevOps Git repositories on behalf of other engineering agents.

You operate in a trace-first, policy-driven environment. Every commit you produce must:

- Include a valid `trace_id` linking it to a blueprint, use case, or feature
- Follow semantic commit message format: <type>(<scope>): <message> [trace:<id>]
- Comply with Git hygiene and branch naming policies
- Include only staged, formatted, lint-clean code
- Apply Git tags when required
- Push commits to the correct branch in the target Azure DevOps repo
- Emit telemetry and structured events about the commit

Your output is a Git commit, along with metadata such as commit hash, branch, trace ID, and status.

Only push when all validations pass. On failure, retry with exponential backoff or escalate to a human review queue if necessary.

Do not modify file content. Focus strictly on trace validation, commit preparation, and Git operations.

Follow ConnectSoft conventions at all times. Never commit without trace compliance.

Be deterministic, observable, and auditable.

🧭 Prompt Design Notes¶

Area	Guideline
✅ Scope Control	Limits agent to GitOps responsibilities — not file modification
✅ Compliance	Reinforces traceability, formatting, branch naming
✅ Failure Handling	Describes retry/escalation behavior
✅ Output Shape	Sets clear expectations for commit + metadata
✅ Identity & Policy Awareness	Instructs to respect Git hygiene and org-level controls

🧠 Summary¶

The Code Committer Agent’s System Prompt guarantees that each run is launched with a governance-first mindset, prioritizing traceable automation, semantic hygiene, and Azure DevOps policy alignment — consistent with ConnectSoft’s secure and observable engineering lifecycle.

📥 Input Prompt Template¶

This is the structured prompt that converts dynamic runtime inputs (files, trace IDs, repo targets, etc.) into a precise instruction format. It ensures consistent agent behavior and seamless integration across Semantic Kernel functions.

It leverages template variables, such as ${trace_id} or ${file_list}, that are substituted by upstream orchestration code before execution.

🧩 Input Prompt Template (Commit Mode)¶

You are preparing to commit code artifacts on behalf of an engineering agent in the ConnectSoft AI Software Factory.

Here is the context for this commit:

- **Trace ID**: ${trace_id}
- **Use Case / Blueprint**: ${blueprint_id}
- **Component Scope**: ${scope}
- **Commit Type**: ${commit_type} (e.g., feat, fix, chore)
- **Target Repository**: ${repo_name}
- **Branch Name**: ${branch_name}
- **Changed Files**:
${file_list}

Based on this context:

1. Generate a semantic Git commit message in the format:
   `<type>(<scope>): <summary> [trace:${trace_id}]`

2. Ensure the message is:
   - Clear and descriptive
   - Aligned with the scope/module
   - Contains no placeholders, "WIP", or temporary notes

3. Validate that all files align with the provided scope and blueprint.

Do not invent functionality or alter file contents. Only prepare the commit metadata and Git operation instructions.

Respond with a JSON payload containing:
- `commit_message`
- `commit_type`
- `branch`
- `repo_url`
- `tags` (optional, list of tag names)
- `files_to_stage` (explicit list)

All actions must comply with ConnectSoft commit policy and traceability standards.

🧪 Example Substituted Prompt¶

Trace ID: trace-ord-8128  
Blueprint: usecase-create-order  
Scope: order  
Commit Type: feat  
Repo: OrderService  
Branch: feature/order-handler  
Files:
- src/Application/Handlers/CreateOrderHandler.cs  
- tests/Order/CreateOrderHandlerTests.cs

→ Expected commit message: feat(order): implement CreateOrderHandler logic [trace:trace-ord-8128]

🧠 Benefits of Structured Prompt Template¶

Benefit	Result
✅ Predictability	Same format = consistent output across commits and services
✅ Traceability	Forces trace linkage at input level
✅ AI Alignment	Guides LLM away from hallucination and verbosity
✅ Clean Integration	Upstream orchestrators can auto-fill variables per agent run
✅ Auditability	Inputs can be logged or replayed for debugging/inspection

🧠 Summary¶

The Input Prompt Template ensures the Code Committer Agent always receives well-scoped, trace-linked, and policy-aware instructions — enabling semantic precision and full reproducibility across all ConnectSoft commits.

📤 Output Expectations¶

The Code Committer Agent must produce both:

A successful Git commit pushed to the specified Azure DevOps branch.
A structured metadata response (JSON) detailing the outcome for downstream agents (e.g., Pull Request Creator, ObservabilityAgent).

📦 Structured Output Schema (JSON)¶

✅ Standard Output Format¶

{
  "status": "success",
  "commit": {
    "hash": "9fbc871e932ac34...",
    "message": "feat(order): implement CreateOrderHandler [trace:trace-ord-8128]",
    "branch": "feature/order-handler",
    "repo": "OrderService",
    "author_agent_id": "code-committer-agent",
    "timestamp_utc": "2025-05-07T15:42:31Z",
    "files": [
      "src/Application/Handlers/CreateOrderHandler.cs",
      "tests/Order/CreateOrderHandlerTests.cs"
    ],
    "tags": ["usecase-create-order"]
  },
  "trace": {
    "trace_id": "trace-ord-8128",
    "blueprint_id": "usecase-create-order",
    "component_scope": "order"
  },
  "events": [
    "CommitCompleted",
    "TraceLinkedCommitRecorded"
  ]
}

🧪 Optional Debug Output (for ObservabilityAgent or DevBox)¶

{
  "pre_commit_validation": {
    "lint_passed": true,
    "trace_check": "valid",
    "branch_check": "feature/order-handler exists"
  },
  "git_command_log": [
    "git add src/Application/Handlers/CreateOrderHandler.cs",
    "git commit -m 'feat(order): implement CreateOrderHandler [trace:trace-ord-8128]'",
    "git tag usecase-create-order",
    "git push origin feature/order-handler"
  ]
}

❌ Error Response Format¶

{
  "status": "failure",
  "error_type": "validation",
  "reason": "Missing trace_id for one or more files",
  "trace_id": null,
  "files_affected": [
    "src/Application/Handlers/OrderService.cs"
  ],
  "suggestion": "Check blueprint linkage and retry",
  "can_retry": true
}

🎯 Summary of Output Responsibilities¶

Output	Used By	Purpose
`commit.hash`	Audit, CI/CD, PR Agent	Link to actual change
`trace_id`	QA, Doc Agent, Architecture Agent	Ensures traceability
`repo` + `branch`	DevOps Agent	Validates flow continuity
`tags`	Release Agent, QA Agent	Controls artifact grouping
`events[]`	Telemetry / Event Bus	Triggers downstream reactions
`status`	Human Ops, Retry Agents	For escalation or reprocessing

🧠 Summary¶

The Code Committer Agent's output is a dual-layer artifact:

The actual commit (with Git hash and trace),
A structured JSON response to link commit metadata across the ConnectSoft AI Software Factory pipeline.

This ensures full visibility, trace-first integrity, and automation-readiness.

🧠 Memory Strategy Overview¶

The Code Committer Agent uses both:

Short-term memory: volatile context used during a single execution cycle
Long-term memory: persisted knowledge to support traceability, retries, and historical linking

Both memory types ensure the agent maintains commit trace continuity, avoids duplicate work, and enables auditability over time.

🧠 Short-Term Memory (Ephemeral Context)¶

Used for one execution run (cleared after commit):

Data Type	Purpose
`Working file set`	Tracks files staged for current commit
`trace_id` and `blueprint_ref`	Ensures message, tags, and output are trace-linked
`commit_message_template`	Format used for generating commit message
`execution_context_id`	UUID/session to correlate logs, traces, retries
`prior_commit_state`	Tracks last commit hash in branch (for diff, deltas)
`retry_token`	If execution is a re-run (helps avoid duplication)

📘 Example (Runtime SK Context)¶

{
  "trace_id": "trace-user-102",
  "files": [
    "src/User/CreateUserHandler.cs",
    "tests/User/CreateUserHandlerTests.cs"
  ],
  "branch": "feature/create-user",
  "execution_context_id": "exec-2482-96de"
}

📦 Long-Term Memory (Persistent Knowledge)¶

Used across sessions and agent runs:

Storage	What is stored	Purpose
Vector DB / Embedding Store	Embeddings for trace ID ↔ file relationships, blueprint similarity	Used to validate trace alignment and detect reused patterns
Key-Value Store (e.g., Redis, Cosmos DB)	Maps of `trace_id → commit_hash`, `branch → last_commit`, `commit_hash → file_list`	Enables rollback, verification, PR linkage
Event History Log	`CommitCompleted`, `GitTagAdded`, `TraceLinkedCommit` events	Used by observability agents, auditors, and downstream pipelines
Failed Commit History	Records of validation failures, Git push errors	Enables retry orchestration and root cause analysis

🧠 Memory Usage Scenarios¶

Scenario	Memory Role
Retry after Git push failure	Loads last attempt and applies backoff window
Verifying commit lineage	Retrieves previous trace → commit mappings
Avoiding duplicate commits	Confirms that the same files weren’t just committed
Pull Request Creation	Uses stored commit metadata to generate PR description, diff preview
Blueprint Audit	Traces all commits linked to a blueprint or feature initiative

🧠 Sample Trace→Commit Record (Long-Term)¶

{
  "trace_id": "trace-auth-9932",
  "commits": [
    {
      "hash": "a13f42b",
      "branch": "feature/login-logic",
      "timestamp": "2025-05-06T13:45:00Z"
    },
    {
      "hash": "b24e88a",
      "branch": "hotfix/login-bug",
      "timestamp": "2025-05-07T08:20:15Z"
    }
  ]
}

🔒 Memory Governance & Security¶

Short-term memory: cleared after commit, trace data not persisted unless successful
Long-term memory:
- Scoped to tenant and agent
- Compliant with audit & SDLC traceability policies (SOC2, ISO27001)
- Can be anonymized or pruned on retention policy

🧠 Summary¶

The Code Committer Agent’s dual memory model gives it the intelligence to:

Stay contextually aware during execution,
Remain trace-linked and policy-compliant across runs,
And support auditable, recoverable, and automatable commit pipelines.

It ensures every commit knows where it came from — and what comes next.

✅ Validation¶

Validation is the agent’s commit gatekeeper process — it ensures traceability, compliance, and correctness before a commit is staged and pushed.

It protects the system from:

Incomplete commits
Missing trace links
Invalid formats
Violations of GitOps and branch hygiene

🧪 Key Validation Rules¶

Rule	Description
✅ Traceability Required	Every commit must include a valid `trace_id`, `blueprint_ref`, and `component_scope`
✅ Semantic Commit Format	Must follow `<type>(<scope>): <msg> [trace:<id>]`
✅ Branch Naming	Must match allowed prefixes (e.g., `feature/`, `bugfix/`, `hotfix/`)
✅ No “WIP” or Placeholder Messages	Reject if commit message includes `WIP`, `test`, `asdf`, etc.
✅ File Scope Compliance	All changed files must belong to the declared `component_scope`
✅ Commit Size Limits	Reject if file count or line delta exceeds thresholds (e.g., 50+ files)
✅ Lint/Format Pass	Commit is blocked if code fails formatting or linting rules (if enabled)
✅ Duplicate Prevention	Check long-term memory to prevent re-committing identical file diffs under same trace_id
✅ Auth & Push Validation	Agent must have valid token or identity to push to Azure DevOps

🧰 Validation Engine Sources¶

commit-policy.yaml defines the rules per environment or team
Loaded as SK memory or injected into ValidationSkill
Custom rules can be tenant-specific or overridden by upstream Tech Lead Agent

📘 Example Commit Policy File (YAML)¶

commit_policy:
  require_trace_id: true
  require_scope_alignment: true
  allowed_commit_types: [feat, fix, refactor, test, chore, docs]
  allowed_branch_prefixes: [feature/, bugfix/, hotfix/]
  block_keywords: [WIP, tmp, do-not-commit]
  max_files: 50
  max_lines_changed: 1000
  enforce_formatting: true

🔍 Validation Flow (Mermaid Diagram)¶

flowchart TD
    A[Start Commit] --> B[Check trace_id and blueprint linkage]
    B --> C[Validate commit message format]
    C --> D[Check branch naming]
    D --> E[Check scope-to-file alignment]
    E --> F[Run lint/format checks]
    F --> G[Compare to prior commits for duplication]
    G --> H{All Passed?}
    H -- Yes --> I[Proceed to commit]
    H -- No --> J[Abort + Report Error]

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

❌ Examples of Commit Rejections¶

Missing Trace ID:¶

{
  "status": "failure",
  "error": "Missing trace_id",
  "suggestion": "Attach valid trace metadata to blueprint input"
}

Invalid Branch Name:¶

{
  "status": "failure",
  "error": "Branch name 'misc-changes' is not allowed. Use 'feature/*' or 'bugfix/*'."
}

🧠 Summary¶

The Code Committer Agent’s validation logic ensures that only high-integrity, traceable, policy-compliant commits enter the ConnectSoft codebase.

It is the quality gate for source control, aligned to architectural scope, DevOps readiness, and auditability.

🔄 Retry / Correction Flow¶

The Code Committer Agent operates in a distributed, automated environment where:

Git operations may fail (conflicts, permissions, branch locks),
Inputs may be invalid (missing trace, wrong format),
Downstream systems may be temporarily unavailable.

To handle this gracefully and autonomously, the agent follows a self-healing retry and escalation protocol.

🔁 Retry Flow Scenarios¶

Failure Type	Retry Behavior
Validation Error	🚫 No retry — raise error and send feedback to upstream agent (e.g., missing trace_id, policy violation)
Git Push Failure	✅ Retry up to 3 times with exponential backoff (5s, 15s, 30s)
Branch Not Found	✅ Attempt to create branch if allowed; if not, escalate
Rate-Limit / Throttling	✅ Wait + Retry (respect Azure DevOps headers)
Network Timeout	✅ Retry once with fallback Git endpoint (if configured)
Commit Race (Fast-Forward Error)	✅ Pull/rebase once, reapply commit, push again
Unknown Exception	🚫 Capture full context, route to Human Hook for inspection

📘 Retry Policy Configuration¶

retry_policy:
  max_retries: 3
  backoff_strategy: exponential
  retry_on:
    - git_push_error
    - branch_not_found
    - api_rate_limit
    - network_timeout
  non_retryable:
    - missing_trace_id
    - invalid_commit_message
    - scope_violation

🧭 Retry & Escalation Flow (Diagram)¶

flowchart TD
    A[Execute Commit] --> B[Validation Passed?]
    B -- No --> C[Abort & Send Validation Error]
    B -- Yes --> D[Try Git Push]
    D --> E{Push Success?}
    E -- Yes --> F[Emit CommitCompleted Event]
    E -- No --> G[Increment Retry Count]
    G --> H{Retries Left?}
    H -- Yes --> D
    H -- No --> I[Escalate to Human Hook]

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

🧠 State Retention During Retry¶

State	Retained Between Retries
`trace_id`	✅
`execution_context_id`	✅
`files_to_commit`	✅
`commit_message`	✅
`previous_attempts`	✅
`agent_runtime_logs`	✅
`last_error_type`	✅

Stored in Redis or agent-local store.

📥 Correction Pathways¶

Trigger	Correction Flow
Validation errors	Send structured feedback to upstream agent (e.g., Backend Developer Agent) with suggested fixes
Retry exhausted	Emit `CommitFailed` event to Event Bus and notify `HumanOpsAgent`
Human Resumption	Allow manual override to resume commit with fixed metadata or file list

🧠 Example Commit Failure Output¶

{
  "status": "failure",
  "reason": "git_push_error",
  "attempts": 3,
  "trace_id": "trace-ord-8128",
  "last_error": "branch protection prevents force-push",
  "action_taken": "escalated",
  "next_step": "manual review by HumanOpsAgent"
}

🧠 Summary¶

The Code Committer Agent’s retry and correction flow ensures the system is both resilient and traceable — able to handle failures without duplication, crash loops, or silent corruption.

It’s fault-tolerant by design, ensuring ConnectSoft commits remain deterministic, policy-bound, and human-auditable even in failure.

🤝 Agent-to-Agent Collaboration¶

The Code Committer Agent is a mid-pipeline executor — receiving artifacts from engineering agents and delivering traceable outputs to collaboration and deployment agents.

📥 Receives Input From:¶

Source Agent	Interface Type	Purpose
`Backend Developer Agent`	Direct JSON payload or File Sync	Supplies new or modified code artifacts
`Microservice Generator Agent`	Blueprint-linked folder or shared VFS	Auto-generated service scaffolds
`Tech Lead Agent`	Commit policy rules, override approvals	May override branch naming or commit policy
`Architect Agents`	Trace linkages and scope constraints	Ensures alignment with DDD boundaries

📤 Sends Output To:¶

Target Agent	Interface Type	Purpose
`Pull Request Creator Agent`	Structured JSON event (`CommitCompleted`)	Triggers PR initialization based on commit
`Observability Agent`	OTEL spans + metadata	Logs commit trace, duration, failure types
`DevOps Agent`	Git tag notification, commit hash	Triggers pipelines, artifact builds
`Documentation Agent`	Commit → blueprint metadata	Enables doc generation from trace-aligned commits
`HumanOps Agent`	`CommitFailed` or manual intervention flag	Escalates issues when retries fail or require review

🔗 API & Event Interfaces¶

Integration	Protocol	Used For
Azure DevOps REST API	HTTPS / REST	Branch validation, repo queries, push via Git HTTP
MCP Event Bus	JSON-over-queue or webhook	Emitting `CommitCompleted`, `CommitFailed`
Shared VFS / File Store	Agent memory volume	For accessing artifact folders across agents
OpenTelemetry Exporter	OTLP / JSON spans	Reporting execution time, errors, commit latency
Redis / KV Store	gRPC / HTTP / Memory	State sharing, retry tracking, trace caching

📘 Example: Commit → Pull Request Trigger¶

{
  "event": "CommitCompleted",
  "trace_id": "trace-user-567",
  "commit_hash": "a19e33f",
  "branch": "feature/user-profile-refactor",
  "repo": "UserService",
  "agent": "code-committer-agent",
  "timestamp": "2025-05-07T19:22:11Z"
}

Consumed by: PullRequestCreatorAgent, ObservabilityAgent, DevOpsAgent

🔄 Supported Collaboration Modes¶

Mode	Description
🔌 Event-Driven	All downstream agents react to structured commit events
📁 File-Based Sharing	Artifacts exchanged through mounted storage (e.g., Azure File Share)
📡 API Interactions	Azure DevOps REST, Git service calls, OTEL APIs
🧠 Shared Semantic Kernel Context	Coordination with sibling agents via plan context and execution memory

🧠 Summary¶

The Code Committer Agent is a collaborative automation node — it connects the creative generation of code (developer agents) with governance, quality, and deployment (PR, DevOps, QA).

It ensures autonomous teamwork, enabling agents to contribute, commit, and coordinate at scale within the ConnectSoft Factory.

📈 Observability Hooks¶

The Code Committer Agent integrates deeply into ConnectSoft’s observability-first pipeline. All critical actions are traceable, diagnosable, and exportable using OpenTelemetry standards and structured logs.

✅ Telemetry Dimensions¶

Dimension	Purpose
`execution_id`	Correlates all steps in one agent run
`trace_id`	Links to blueprint or use case
`commit_hash`	Maps action to Git state
`action`	Stage, commit, tag, push, emit event
`duration_ms`	Time per step or end-to-end
`status_code`	`success`, `retry`, `failure`, `skipped`
`error_type`	`lint_fail`, `push_fail`, `trace_missing`, etc.

📘 Example OTEL Span (Simplified)¶

{
  "span_name": "commit.push",
  "trace_id": "trace-auth-001",
  "commit_hash": "f7eabc1",
  "branch": "feature/auth-improvements",
  "status": "success",
  "duration_ms": 1240
}

🔍 Logging Channels¶

Channel	Format	Used For
stdout logs	Structured JSON	Local debug, CI/CD traces
OTEL Collector	OTLP / gRPC	Real-time agent observability
File log stream	`.log` or `.jsonl`	Dev Box testing or forensics
EventBus (MCP)	`CommitCompleted`, `CommitFailed`, etc.	Workflow coordination

🧑‍💼 Human Intervention Hooks¶

When automated retries fail, or policy violations occur, the agent gracefully escalates issues.

🔁 Escalation Triggers¶

Trigger	Action
Exceeded max retries	Emit `CommitFailed` event with error summary
Unauthorized repo access	Notify `HumanOpsAgent` with access violation detail
Invalid commit format	Return structured validation error with suggestions
Trace-to-blueprint mismatch	Pause and route issue to `Tech Lead Agent` or human reviewer
Policy override requested	Wait for confirmation from `Tech Lead Agent` or `ManualOverrideFlag` in memory

📥 Sample `CommitFailed` Event¶

{
  "event": "CommitFailed",
  "reason": "Push blocked by branch protection",
  "repo": "PaymentService",
  "branch": "hotfix/late-fix",
  "trace_id": "trace-payment-991",
  "agent": "code-committer-agent",
  "attempts": 3,
  "timestamp": "2025-05-07T20:45:10Z"
}

Consumed by:

HumanOpsAgent
DevOpsAlertManager
Dashboards / SLA Monitors

📊 Visual Trace in ConnectSoft Dashboard¶

The agent emits traceable spans that appear in ConnectSoft’s Observability UI:

Agent Run #1938 → Commit Trace View
└── Stage Files         ✅ 103ms
└── Validate Metadata   ✅ 89ms
└── Generate Commit     ✅ 120ms
└── Push Branch         ❌ 3 retries → failed
└── Emit Failure Event  ✅ 42ms

👤 Manual Review Interface (Optional)¶

Feature	Description
Slack / Email Alert	Notifies DevOps team or team lead of failed commit runs
Retry Override CLI	Human can requeue or patch commit metadata for re-attempt
Commit Inspector UI	See commit preview, trace ID, reason for rejection

🧠 Summary¶

The Code Committer Agent is a first-class observable agent — it produces complete telemetry for every action and has graceful, policy-aware human intervention capabilities.

It ensures no invisible failures, no silent data loss, and no uncontrolled overrides, keeping ConnectSoft's GitOps process safe and auditable.

🧠 Code Committer Agent Specification¶

🎯 Purpose¶

🛠️ Why This Agent Exists¶

🧩 Position in the Agent Workflow¶

🏷️ ConnectSoft Principles Alignment¶

🔁 Example Commit Trace Flow¶

📍 Summary¶

📋 Core Responsibilities¶

🧱 Functional Responsibilities¶

📌 Special Agent Behaviors¶

✅ Examples of Agent Output¶

🔄 Typical Execution Lifecycle¶

🔒 Compliance Alignment¶

🧠 Summary¶

📥 Input Overview¶

🧾 Primary Input Channels¶

1. Code Artifacts¶

2. Commit Metadata¶

3. Target Git Context¶

4. Policy & Convention Config¶

5. Agent Runtime Context¶

🗂️ Example Input Bundle¶

🧠 Summary¶

📤 Output Overview¶

✅ Primary Output Artifacts¶

1. Git Commit (Tracked Artifact)¶

2. Commit Metadata Record¶

3. Git Tag (Optional)¶

4. CommitCompleted Event¶

5. Observability Events¶

📂 Example Output Directory Structure (Local VFS)¶

🧠 Summary¶

📚 Knowledge Base Overview¶

🧠 Embedded Knowledge Assets¶

1. Commit Format Templates¶

2. Traceability Mapping Rules¶

3. ConnectSoft Git Hygiene Policies¶

4. Azure DevOps Integration Schema¶

5. Blueprint-to-Artifact Memory¶

6. Agent Identity & Signature Rules¶

🧠 Agent Capabilities Based on Knowledge¶

🔄 Sample Internal Lookup Flow¶

🧠 Summary¶

🔁 Internal Execution Workflow¶

🧭 High-Level Workflow¶

🪜 Step-by-Step Process Breakdown¶

1. Input Ingestion¶

2. Validation Phase¶

3. Code Quality Enforcement¶

4. Commit Message Assembly¶

5. Git Commit Creation¶

6. Tag Application¶

7. Push to Remote¶

8. Emit Events¶

🔄 Error/Edge Case Handling (Preview of Cycle 14)¶

📌 Example Commit Output (End State)¶

🧠 Summary¶

🧠 Functional Capabilities Overview¶

🧩 Core Skills and Plugins¶

📦 Example Semantic Kernel Function Signatures¶

GitSkill.StageFiles¶

SemanticCommitMessageSkill.Generate¶

🧠 Composite Kernel Plan (Used at Runtime)¶

🤖 Agent-Level Behaviors Enabled by Skills¶

🔄 Pluggability¶

🧠 Summary¶

🧰 Core Technology Stack¶

✅ Primary Technology Components¶

📦 Technology Integration Diagram¶

⚙️ Agent Bootstrapping Tools¶

🧠 Runtime Characteristics¶

🔐 Security Considerations¶

📘 Example Tools & Packages Used¶

🧠 Summary¶

📜 System Prompt¶

🧠 Code Committer Agent – System Prompt¶

🧭 Prompt Design Notes¶

🧠 Summary¶

📥 Input Prompt Template¶

🧩 Input Prompt Template (Commit Mode)¶

`GitSkill.StageFiles`¶

`SemanticCommitMessageSkill.Generate`¶

📥 Sample `CommitFailed` Event¶