Build backend systems with ak:backend-development

Use ak:backend-development to make a backend decision or carry a scoped backend change through API design, implementation, security checks, testing, and operational readiness. Its bundled guidance covers Node.js, Python, Go, and Rust; REST, GraphQL, and gRPC; authentication; databases; caching; distributed systems; observability; and deployment patterns.

Choose ak:backend-development for the backend surface

Use ak:backend-development when

• The main outcome is an API, service, authentication flow, data-access layer, queue consumer, cache, or backend performance correction.
• You need to compare backend languages, frameworks, databases, API styles, or architecture patterns against concrete constraints.
• The work must include backend-focused security, integration, migration, contract, load, or observability evidence.

Choose another workflow when

• The task is primarily schema design or migration safety. Use ak:databases.
• The task is primarily infrastructure, CI/CD, containers, or deployment. Use ak:devops.
• You already have an approved cross-stack plan and mainly need coordinated implementation. Use ak:cook and name this Skill as relevant guidance.
• You only need to diagnose a failure. Use ak:fix before changing code.

Prepare the project and dependencies

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the current runtime and scope.
• Open the backend project, read its instructions, and identify its package manager, framework, runtime version, test commands, and deployment boundary.
• State the API or service outcome, existing contracts, expected load, data ownership, security requirements, and non-goals.
• Make required framework CLIs, language toolchains, databases, containers, or provider credentials available only when the requested work needs them.
• Define whether file edits, dependency installation, local services, schema migration, external API calls, or deployment are authorized.

The Skill does not install NestJS, FastAPI, Django, Express, Gin, databases, Docker, Kubernetes, or cloud tooling for you as a prerequisite. It works from what the project and runtime session make available.

See Runtime adapters before assuming that the same implementation or approval surface exists in every runtime.

Run the Skill

The declared argument shape is [framework] [task]. It defines no flags, named modes, or default framework. Give the current stack when it matters; if you want a comparison, say so instead of implying that a framework is chosen.

/ak:backend-development nestjs "Add an idempotent POST /v1/webhooks/orders endpoint using the existing auth and persistence patterns. Add focused integration tests; do not run migrations or deploy."

/ak:backend-development nestjs "Add an idempotent POST /v1/webhooks/orders endpoint using the existing auth and persistence patterns. Add focused integration tests; do not run migrations or deploy."

$ak:backend-development nestjs "Add an idempotent POST /v1/webhooks/orders endpoint using the existing auth and persistence patterns. Add focused integration tests; do not run migrations or deploy."

Useful inputs identify the contract rather than only the technology:

Observe an evidence-led run

The source packages a reference library, not a fixed orchestration sequence. For implementation work, keep these stages visible:

1. The run confirms the contract. It identifies the existing stack, API and data owners, acceptance criteria, and authority boundary.
2. The run selects relevant guidance. It narrows the bundled references to API design, authentication, security, performance, architecture, testing, code quality, debugging, operations, or technology selection as needed.
3. The run inspects current patterns. It verifies routes, schemas, service boundaries, dependencies, tests, and repository instructions before edits.
4. The run proposes or implements the smallest change. A comparison can end in a recommendation; an authorized implementation can edit code and tests.
5. The run verifies observable behavior. It reports focused unit, integration, contract, migration, load, or security checks appropriate to the change rather than claiming generic production readiness.
6. The run reports remaining authority. Migrations, provider changes, release operations, and deployment stay explicit next steps unless approved.

Keep data and production control with you

• Review schema changes for forward and rollback safety before any migration.
• Do not expose secrets, tokens, personal data, request bodies, or production snapshots to logs, prompts, test fixtures, or external tools.
• Dependency installation, container pulls, API calls, scanners, APM services, message brokers, and cloud resources can use network access and incur compute, storage, or provider charges. The Skill declares no required paid provider.
• Starting servers, databases, containers, profilers, load tests, or scanners creates local processes and can consume ports, CPU, memory, and disk.
• Commit, push, publication, infrastructure mutation, traffic switching, and deployment require separate authority.

Verify the result

A complete advisory result gives you a recommendation tied to constraints, trade-offs, and rejected alternatives. A complete implementation result should instead provide:

• The API or service contract implemented and the exact files changed.
• Focused test commands and results, including failure and authorization cases.
• Data and migration impact, security checks, and compatibility evidence.
• Operational evidence such as health behavior, structured logs, metrics, or traces when the scope requires it.
• Skipped checks, unresolved risks, and every production-affecting action still awaiting approval.

Troubleshoot or continue

Continue with Projects, artifacts, and checkpoints for recovery boundaries or the Engineer Kit overview for the broader workflow.

Know the current limits

• The bundled references are broad point-in-time guidance, not a substitute for the installed framework, provider, protocol, or security documentation.
• Performance ratios and adoption figures in the source references are not a guarantee for your workload; require project-specific measurement.
• The source defines no deterministic plan, provider integration, runtime estimate, or Skill-specific automated test suite. Duration ranges from a short design answer to a multi-stage implementation and depends on project size, validation, and external services.
• Stable and beta contain identical Skill content and bundled references for this release pair.