Run any Skill in Manus with one click

deb-scripts-service-pattern

Stars29

Forks0

UpdatedMarch 31, 2026 at 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

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

thegrayfoxxx

thegrayfoxxx/deb_scripts

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·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.

More from this repository

same repository

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.