Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

deb-scripts-service-pattern

Étoiles29

Forks0

Mis à jour31 mars 2026 à 02:40

Use when implementing or refactoring service classes in deb_scripts. Covers the expected public API, private helper structure, idempotent install/uninstall behavior, status design, and how services should interact with CLI and interactive layers.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

thegrayfoxxx

thegrayfoxxx/deb_scripts

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	deb-scripts-service-pattern
description	Use when implementing or refactoring service classes in deb_scripts. Covers the expected public API, private helper structure, idempotent install/uninstall behavior, status design, and how services should interact with CLI and interactive layers.

Service pattern

Use this skill when editing code under app/services/.

Public contract

Services should expose:

install()
uninstall()
is_installed()
get_status()
get_info_lines()

Activatable services should also expose:

activate()
deactivate()
is_active()

Use app/services/protocols.py as the source of truth for the current contracts.

Structure

Public methods provide the stable interface used by CLI and interactive layers.
Private helpers do probing, parsing, file writes, subprocess calls, and retries.
Keep command construction and path constants near the top of the class when they are reused.

Behavioral rules

install() and uninstall() must be idempotent.
A no-op success should still return True.
Catch operational exceptions, log context, and return False on failure.
Prefer one final verification before reporting success.
activate() and deactivate() should be idempotent for activatable services.

Status rules

is_installed() should answer a boolean question cheaply and predictably.
get_status() should provide a short multi-line snapshot for humans.
get_info_lines() should return operator-facing info used by the menu layer.
Do not mix status reads with warning-heavy side effects.
Return user-facing status/info text in a localizable form that works for both default ru and --lang en.

Integration rules

Services should not own menu flow.
Services should not parse CLI args.
Services may emit operator-oriented logs but should avoid duplicating interactive menu output.
Stable user-facing wording should come from app/i18n/messages.py via t(...); localized low-level logs may use tr(...).

Related skills

Use deb-scripts-system-commands when the change adds or alters subprocess behavior.
Use deb-scripts-logging when changing user-visible operational messages.
Use deb-scripts-testing after changing service behavior.

Plus depuis ce dépôt

même dépôt

deb-scripts-commits

thegrayfoxxx/deb_scripts

Use when writing Git commit messages or PR titles for changes in deb_scripts. Covers conventional commits, raw plain-text output, English-only output, and the supported modes single_commit, squash_commit, pr_title, and commit_with_body.

2026-03-3129

deb-scripts-maintainer

thegrayfoxxx/deb_scripts

Use when working in the deb_scripts repository on existing code, bug fixes, refactors, CLI behavior, interactive menus, logging, or documentation updates. Covers the project architecture, service contracts, safety constraints, and the expected testing workflow.

2026-03-3129

deb-scripts-testing

thegrayfoxxx/deb_scripts

Use when adding or changing tests in deb_scripts, or when deciding how to validate a code change. Covers unit, integration, and system test selection, expected smoke checks, and how to verify CLI and interactive behavior without over-testing unrelated paths.

2026-03-3129

deb-scripts-planning

thegrayfoxxx/deb_scripts

Use when the user wants a plan-first workflow in deb_scripts, asks for a clear execution plan before any changes, or expects work to be performed step by step against an explicit plan with checkpoints.

2026-03-3129

deb-scripts-system-commands

thegrayfoxxx/deb_scripts

Use when adding or changing apt, systemctl, ufw, sysctl, curl, rm, or other host-level command execution in deb_scripts. Covers safe subprocess patterns, post-command verification, and what to log versus what to keep in debug output.

2026-03-3129

deb-scripts-cli-ux

thegrayfoxxx/deb_scripts

Use when changing menu text, prompts, status messages, confirmations, or user-facing CLI output in deb_scripts. Covers concise operator-focused messaging, menu consistency, and avoiding duplicate or noisy output across interactive and non-interactive flows.

2026-03-3129

name	deb-scripts-service-pattern
description	Use when implementing or refactoring service classes in deb_scripts. Covers the expected public API, private helper structure, idempotent install/uninstall behavior, status design, and how services should interact with CLI and interactive layers.

Service pattern

Use this skill when editing code under app/services/.

Public contract

Services should expose:

install()
uninstall()
is_installed()
get_status()
get_info_lines()

Activatable services should also expose:

activate()
deactivate()
is_active()

Use app/services/protocols.py as the source of truth for the current contracts.

Structure

Public methods provide the stable interface used by CLI and interactive layers.
Private helpers do probing, parsing, file writes, subprocess calls, and retries.
Keep command construction and path constants near the top of the class when they are reused.

Behavioral rules

install() and uninstall() must be idempotent.
A no-op success should still return True.
Catch operational exceptions, log context, and return False on failure.
Prefer one final verification before reporting success.
activate() and deactivate() should be idempotent for activatable services.

Status rules

is_installed() should answer a boolean question cheaply and predictably.
get_status() should provide a short multi-line snapshot for humans.
get_info_lines() should return operator-facing info used by the menu layer.
Do not mix status reads with warning-heavy side effects.
Return user-facing status/info text in a localizable form that works for both default ru and --lang en.

Integration rules

Services should not own menu flow.
Services should not parse CLI args.
Services may emit operator-oriented logs but should avoid duplicating interactive menu output.
Stable user-facing wording should come from app/i18n/messages.py via t(...); localized low-level logs may use tr(...).

Related skills

Use deb-scripts-system-commands when the change adds or alters subprocess behavior.
Use deb-scripts-logging when changing user-visible operational messages.
Use deb-scripts-testing after changing service behavior.