agentleFS
open-edge-platformopen-edge-platform/training_extensions/skills/application/geti-backend-dev/SKILL.md

geti-backend-dev

Skill1.4k starsChanged 17 days agoApache-2.0View on GitHub

Develop and validate changes in `application/backend/` for the FastAPI `geti` service. Use when changing backend source or tests as well as packaging and configuration. This includes API routers and schemas; services and repositories; database code; UI-facing backend contracts. Covers environment setup; targeted tests; OpenAPI generation; local server workflows.

1 other project uses a version of this.

Trending

More talk lately.about the whole repository

Dec 2025: 1 mentionJan 2026: 4 mentionsFeb 2026: 2 mentionsMar 2026: 2 mentionsApr 2026: 7 mentionsMay 2026: 2 mentionsJun 2026: 3 mentionsJul 2026: 2 mentionsAug 2026: 3 mentionsSep 2026: 4 mentionsOct 2026: 9 mentionsNov 2026: 5 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the open-edge-platform/training_extensions repository that our weekly crawl found. There is no adoption data for this file yet.

Most recently taken up by

Who's talking about open-edge-platform/training_extensions

The biggest 5 of 50 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 50

Talked about on GitHub (50 times).

On GitHub · 50

45 more on GitHub

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 1 is distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Create or refresh the environment with just venv --accelerator cpu for normal local work.

    line 15
  2. Very specific:

    Start with just lint, then run the narrowest relevant test target.

    line 17
  3. Very specific:

    Keep the change inside the existing backend boundaries unless the task explicitly crosses into libraries/getitune/ or application/ui/.

    line 21
  4. Distinctive:

    Keep routers thin and move business logic into services or repositories that match the existing package structure.

    line 22
  5. Very specific:

    Keep app.api.routers above app.api.schemas, and app.api.schemas above app.api.dependencies.

    line 30
  6. Very specific:

    Treat run-server --clean and _clean_data as destructive helpers.

    line 39
  7. Very specific:

    Use just lint for Ruff, import-linter, and pyrefly checks.

    line 43
  8. Very specific:

    Use just test-unit -- tests/unit/...

    line 44
  9. Very specific:

    Use just test-integration -- <pytest args> when the change crosses service, persistence, or API boundaries.

    line 45
  10. Very specific:

    Use just test-bdd -- <behave args> when behavior is covered by BDD specs.

    line 46
  11. Very specific:

    Use just gen-api-spec --output-path openapi-spec.json after intentional API contract changes.

    line 47
  12. Very specific:

    Prefer project just targets over custom shell commands so local work matches CI.

    line 52

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Geti Backend Development

For the full architecture reference (layered design, app/ layout, adding an endpoint end-to-end, library integration and job execution) read application/backend/AGENTS.md.

Quick Start

  • Work from application/backend/.
  • Create or refresh the environment with just venv --accelerator cpu for normal local work.
  • Switch to cuda or xpu only when the task depends on accelerator-specific behavior.
  • Start with just lint, then run the narrowest relevant test target.

Workflow

  1. Keep the change inside the existing backend boundaries unless the task explicitly crosses into libraries/getitune/ or application/ui/.
  2. Keep routers thin and move business logic into services or repositories that match the existing package structure.
  3. Generate a fresh OpenAPI spec when router or schema changes affect the API contract.
  4. Hand off to the $geti-openapi-sync skill after backend contract changes so the UI types stay aligned.

Architecture Reminders

  • The request flow is layered: app.api → app.services → app.repositories → app.db. Respect the import-linter contracts in pyproject.toml.
  • Keep app.api.routers above app.api.schemas, and app.api.schemas above app.api.dependencies.
  • Pydantic API schemas (app/api/schemas/), domain models (app/models/), and SQLAlchemy ORM models (app/db/schema.py) are separate layers — never return raw ORM models from a router.
  • Schema changes require an Alembic migration under app/alembic/versions/.
  • Long-running work (training, quantization, dataset import/export) runs out-of-process via app/core/jobs/ and lazily-imported builders in app/execution/; training calls into the getitune library.
  • Treat run-server --clean and _clean_data as destructive helpers.

Verification

  • Use just lint for Ruff, import-linter, and pyrefly checks.
  • Use just test-unit -- tests/unit/... or just test-unit -- -k <expr> for routine backend changes.
  • Use just test-integration -- <pytest args> when the change crosses service, persistence, or API boundaries.
  • Use just test-bdd -- <behave args> when behavior is covered by BDD specs.
  • Use just gen-api-spec --output-path openapi-spec.json after intentional API contract changes.

Coordination Notes

  • application/backend depends on the local editable ../../libraries/getitune. Validate libraries/getitune/ too when shared model or training behavior changes.
  • Prefer project just targets over custom shell commands so local work matches CI.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.