backend-engineering

Implements Go backend changes with thin handlers, sqlc migrations, and typed evidence outputs.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/vovanostm-public/multica --skill backend-engineering-vovanostm-public
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: backend-engineering
Source: https://github.com/vovanostm-public/multica/tree/main/workflow-bundles/multica-specops-v5/codex_skills/.agents/skills/backend-engineering
Command: npx skills add https://github.com/vovanostm-public/multica --skill backend-engineering-vovanostm-public

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Backend changes in a Go codebase often drift into fat handlers, ad-hoc SQL, and undocumented API changes. This Skill enforces a disciplined implementation workflow so handlers stay thin, business logic lives in services, database changes go through migrations and sqlc, and every change produces typed, auditable evidence. ## Core Features & Use Cases - Structured Go Implementation: Keeps handlers as transport boundaries, extracts business logic into services/usecases, and scopes transactions correctly. - Database Change Workflow: Adds migrations and sqlc queries for any SQL change, then regenerates code with make sqlc. - Typed Evidence Outputs: Produces implementation.backend, api.contract_changes, db.migration_notes, backend.tests, and backend.handoff artifacts with evidence, assumptions, blockers, and confidence fields. - Use Case: When assigned a stage in a multi-agent workflow to add a new API endpoint backed by a new table, the Skill follows the existing package pattern, writes the migration and sqlc query, implements the service and thin handler, runs focused Go tests, and hands off typed evidence to the next stage. ## Quick Start Implement the assigned backend stage for this Go service, keeping handlers thin, adding a migration and sqlc query for any schema change, and returning the typed evidence envelope with test results.

Frequently Asked Questions about backend-engineering

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure Go API handlers with business logic separated?▼

Keep handlers as thin transport boundaries that only parse requests and write responses. Place business logic in a service or usecase layer, and extract a service whenever a handler grows complex.

How to add a database change with sqlc in a Go project?▼

Write a SQL migration for the schema change, add the corresponding sqlc query, then run `make sqlc` to regenerate typed query code. Follow up with focused Go tests covering the new query path.

When should a Go handler be refactored into a service layer?▼

Refactor when the handler starts containing business rules, orchestration, or data transformation beyond request parsing. The decision matrix in this workflow directs extraction into a service/usecase as soon as handler complexity grows.

What evidence should a backend implementation stage produce?▼

Produce typed outputs: implementation.backend, api.contract_changes, db.migration_notes, backend.tests, and backend.handoff. Each must include used_evidence, assumptions, blockers, confidence, and a handoff when applicable.

What are the boundaries of this backend workflow stage?▼

It does not perform unrelated stages, overwrite evidence owned by other stages, execute privileged actions directly, or write outside the assigned worktree. Policy-sensitive actions must go through the approved action pipeline.