L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Développement · SKILL.md

repo-development

repo-development

Maintain a gptme checkout: branch policy, style, focused tests, docs, Web UI dev, package validation, and performance guardrails.

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: repo-development description: "Maintain a gptme checkout: branch policy, style, focused tests, docs, Web UI dev, package validation, and performance guardrails." disable-model-invocation: true metadata: disco-role: operating license: MIT

repo-development

Use this sub-skill when the task is about maintaining a gptme checkout: code style, targeted tests, docs, Web UI development, release/package validation, repository policy, or startup/performance constraints.

This sub-skill assumes commands are run from the target gptme checkout unless a command explicitly says otherwise. It does not operate on the generated skill tree itself.

Route away when the task is mainly about:

  • terminal chat usage, prompts, logs, slash commands, or gptme-agent: use cli-and-conversations.
  • config files, credentials, provider/model selection, or auth helpers: use configuration-and-providers.
  • tools, plugins, hooks, MCP, browser, computer-use, skills, or lessons: use tools-and-extensibility.
  • gptme-server, REST/SSE, TUI, ACP, deployment, or hosted runtime behavior: use server-webui-and-protocols.
  • eval suites, benchmark runs, or leaderboard processing: use evals-and-benchmarks.

Read first

Safe helpers

These helpers only inspect local files or built artifacts. They do not run tests, publish releases, or make network calls.

Fast operating checklist

  1. Confirm the task is maintainer work in a target gptme checkout.
  2. Follow repo policy: no direct pushes to master, use feat/, fix/, docs/, or refactor/ branches, write conventional commits, and stage files explicitly.
  3. Keep changes small and scoped; when in doubt, prefer the gptme core / gptme-contrib boundary described in the references.
  4. Pick the smallest useful verification set first: focused pytest commands, cd webui && npm ... commands, or the bundled helper scripts.
  5. Use make test, make lint, make typecheck, make docs, make check-openapi, and the Web UI npm commands as checkout-maintenance commands for the target repo, not as hidden background actions.
  6. For packaging failures, verify that the built archive contains gptme/server/webui-dist/ before chasing runtime regressions.
Skills enregistrées