Run any Skill in Manus with one click

backend-config-maintenance

Stars3

Forks0

UpdatedJuly 1, 2026 at 01:33

How the backend agent keeps the Dependencies section of Docs/Application/Architecture/backend-config.md in sync with the real project. Load only when a task adds, removes, or upgrades a NuGet package. Reconciles the Dependencies list from the actual .csproj PackageReference entries — never touches the architect's decision fields.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Ezefeola

Ezefeola/Temper-AI

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	backend-config-maintenance
description	How the backend agent keeps the Dependencies section of Docs/Application/Architecture/backend-config.md in sync with the real project. Load only when a task adds, removes, or upgrades a NuGet package. Reconciles the Dependencies list from the actual .csproj PackageReference entries — never touches the architect's decision fields.
requires	["backend-dotnet-csharp"]

Backend Config Maintenance — TemperAI

Docs/Application/Architecture/backend-config.md is read by every downstream agent to know the stack and installed packages. Its Dependencies section drifts the moment a package is installed and not recorded. This skill defines how the backend agent keeps that section true to the real project, using the .csproj files as the single source of truth.

🚨 NON-NEGOTIABLE RULES — ZERO TOLERANCE

ONLY edit the Dependencies: block of backend-config.md. Every other field (Framework, Language, ORM, Data Access, Architecture, Database, Auth, API Docs, Health Checks, Messaging, Caching, Logging) is owned by the architect and is read-only for you.
RECONCILE from the real .csproj, never from memory. Derive the list from the actual <PackageReference> entries, not from "what I think I added". This self-heals prior drift.
NEVER invent or guess versions. Use the exact Version from the .csproj. If a version is centrally managed (Directory.Packages.props), read it from there.
NEVER touch a decision field even if it looks wrong. If reality contradicts a decision field (e.g. the real ORM package is not the one in ORM:), STOP and ask — do not "fix" it.
ALWAYS preserve the exact template format of the Dependencies block (package name + version, one per line). Do not add justification text — this list is purely technical.

When this skill applies

Load and run this reconciliation only when the task added, removed, or upgraded a NuGet package (i.e. the task changed a .csproj). If the task touched no packages, do nothing — leave backend-config.md untouched.

Which projects count

Include packages referenced by the application/runtime projects (the backend solution's source projects — API, Application, Domain, Infrastructure, etc.).
Exclude test-only projects (anything referenced only by *.Tests/*.UnitTests projects). Test frameworks belong to the test setup, not the runtime config.
Exclude analyzers and build-only PrivateAssets="all" tooling references unless the task added one deliberately as a runtime concern.

Reconciliation procedure

Locate the runtime .csproj files of the backend solution (skip test projects).
Read every <PackageReference Include="..." Version="..." /> across them. If versions are centrally managed, resolve each from Directory.Packages.props.
Build the deduplicated, sorted set of Package Name + version (alphabetical by name).
Open Docs/Application/Architecture/backend-config.md and replace the contents of the Dependencies: block with that set, keeping the exact template shape:
```
Dependencies:
  - MailKit 4.8.0
  - ClosedXML 0.104.1
```
If the runtime projects reference no third-party packages beyond the base stack, write:
```
Dependencies:
  - None beyond base stack
```
Leave every other line of the file byte-for-byte unchanged.
If a decision field clearly contradicts the real packages, do NOT edit it — emit the stop-and-ask report and let the orchestrator route it to the architect.

Completion note

After reconciling, report it in the backend agent's completion summary, e.g.:

🗂️ backend-config.md synced — Dependencies reconciled from .csproj
   Added:   [pkg version, …]
   Removed: [pkg, … or "none"]

More from this repository

same repository

clean-architecture

Ezefeola/Temper-AI

Structure and rules for .NET projects using Clean Architecture with DDD. Use when the project has complex business domain, multiple use cases, need to test business logic in isolation, or when the system is enterprise, e-commerce, ERP, CRM, or any rich domain. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.

2026-07-013

hexagonal-architecture

Ezefeola/Temper-AI

Structure and rules for .NET projects using Hexagonal Architecture (Ports & Adapters). Use when the project has multiple input channels (API, CLI, message queue), need to test the domain in isolation, or when adapters change frequently. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.

2026-07-013

onion-architecture

Ezefeola/Temper-AI

Structure and rules for .NET projects using Onion Architecture. Use when the project has a strong domain-centric focus with DDD, aggregate roots, and the Specification pattern. All dependencies point inward toward the domain core. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.

2026-07-013

dbcontext-setup

Ezefeola/Temper-AI

Canonical DbContext setup and registration rules for EF Core. Load when creating or modifying DbContext classes or their DI wiring.

2026-07-013

dotnet-linq

Ezefeola/Temper-AI

Pure LINQ standards for .NET 10 projects. Covers language operators, query composition, projection patterns, filtering, grouping, and performance best practices over IEnumerable<T> and IQueryable<T>. Load when writing or reviewing LINQ expressions in any layer. DO NOT load expecting EF Core-specific methods (ToListAsync, AsNoTracking, Include, ExecuteUpdateAsync) — those belong to `backend/dotnet/orms/ef-core/query-best-practices/SKILL.md`.

2026-07-013

dbcontext-usage

Ezefeola/Temper-AI

Canonical rules for using AppDbContext DIRECTLY from application code (use cases / handlers) when the project's data-access pattern is Direct DbContext — no repositories, no UnitOfWork. Load when the chosen pattern is Direct DbContext and a use case reads or writes data. This is the counterpart to repository-usage; never load both for the same task.

2026-07-013

name	backend-config-maintenance
description	How the backend agent keeps the Dependencies section of Docs/Application/Architecture/backend-config.md in sync with the real project. Load only when a task adds, removes, or upgrades a NuGet package. Reconciles the Dependencies list from the actual .csproj PackageReference entries — never touches the architect's decision fields.
requires	["backend-dotnet-csharp"]

Backend Config Maintenance — TemperAI

🚨 NON-NEGOTIABLE RULES — ZERO TOLERANCE

ONLY edit the Dependencies: block of backend-config.md. Every other field (Framework, Language, ORM, Data Access, Architecture, Database, Auth, API Docs, Health Checks, Messaging, Caching, Logging) is owned by the architect and is read-only for you.
RECONCILE from the real .csproj, never from memory. Derive the list from the actual <PackageReference> entries, not from "what I think I added". This self-heals prior drift.
NEVER invent or guess versions. Use the exact Version from the .csproj. If a version is centrally managed (Directory.Packages.props), read it from there.
NEVER touch a decision field even if it looks wrong. If reality contradicts a decision field (e.g. the real ORM package is not the one in ORM:), STOP and ask — do not "fix" it.
ALWAYS preserve the exact template format of the Dependencies block (package name + version, one per line). Do not add justification text — this list is purely technical.

When this skill applies

Which projects count

Include packages referenced by the application/runtime projects (the backend solution's source projects — API, Application, Domain, Infrastructure, etc.).
Exclude test-only projects (anything referenced only by *.Tests/*.UnitTests projects). Test frameworks belong to the test setup, not the runtime config.
Exclude analyzers and build-only PrivateAssets="all" tooling references unless the task added one deliberately as a runtime concern.

Reconciliation procedure

Locate the runtime .csproj files of the backend solution (skip test projects).
Read every <PackageReference Include="..." Version="..." /> across them. If versions are centrally managed, resolve each from Directory.Packages.props.
Build the deduplicated, sorted set of Package Name + version (alphabetical by name).
Open Docs/Application/Architecture/backend-config.md and replace the contents of the Dependencies: block with that set, keeping the exact template shape:
```
Dependencies:
  - MailKit 4.8.0
  - ClosedXML 0.104.1
```
If the runtime projects reference no third-party packages beyond the base stack, write:
```
Dependencies:
  - None beyond base stack
```
Leave every other line of the file byte-for-byte unchanged.
If a decision field clearly contradicts the real packages, do NOT edit it — emit the stop-and-ask report and let the orchestrator route it to the architect.

Completion note

After reconciling, report it in the backend agent's completion summary, e.g.:

🗂️ backend-config.md synced — Dependencies reconciled from .csproj
   Added:   [pkg version, …]
   Removed: [pkg, … or "none"]