john/prompts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

initial server

Browse Source
This commit is contained in:
John Lancaster
2026-06-18 19:16:06 -05:00
parent 9b02007216
commit dbaaad8df8
21 changed files with 1886 additions and 286 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/nicegui/SKILL.md
+21 -5
View File
@@ -41,9 +41,10 @@ Produce:
1. Frame the baseline architecture.
2. Choose optional extensions (DB, AI, docs) using decision points below.
3. Map modules, dependencies, and key boundaries.
4. Define key functions/classes and configuration surfaces.
5. Produce phased checklist with rollout or migration notes when relevant.
6. Run completion checks before returning.
4. Define async behavior and UI responsiveness expectations.
5. Define key functions/classes and configuration surfaces.
6. Produce phased checklist with rollout or migration notes when relevant.
7. Run completion checks before returning.
### 1) Baseline architecture
@@ -131,15 +132,27 @@ Prefer:
Avoid reverse imports from services into API or UI modules.
### 5) Testing minimums
### 5) Async and UI responsiveness rules
- Prefer `async def` for page handlers, service methods, and integrations when the call path includes I/O.
- Use non-blocking clients/libraries where possible so long-running I/O does not freeze UI updates.
- Do not run blocking calls (`time.sleep`, blocking HTTP/database clients) in UI event handlers.
- For heavy CPU work, offload to worker/background execution and keep the UI loop free.
- Show progress states for long actions (disable action button, show spinner/progress text, re-enable on completion).
- Stream or chunk incremental results to the UI when workflows are multi-step or long-running.
- Keep cancellation and timeout behavior explicit for user-triggered long tasks.
- Ensure exceptions from async tasks are surfaced with user-friendly feedback and logged for diagnostics.
### 6) Testing minimums
- Test FastAPI health route behavior.
- Test page registration wiring.
- If DB enabled: session lifecycle and rollback behavior tests.
- If AI enabled: graph happy path and interrupt/resume coverage.
- If docs enabled: mounted docs route returns index page.
- For async flows: test long-running actions preserve UI responsiveness (loading state, completion state, and error state).
### 6) Styling architecture
### 7) Styling architecture
- Keep structure and layout in Python modules using NiceGUI class composition.
- Keep visual polish in shared CSS files, loaded once at startup.
@@ -151,6 +164,7 @@ Avoid reverse imports from services into API or UI modules.
- Pages are modularized (not single-file UI).
- Health endpoint exists on FastAPI side.
- Dependency direction is clean and one-way.
- Async-first guidance is applied where I/O exists, with explicit non-blocking UX states.
- Optional DB/AI/docs decisions are explicit and reflected in structure.
- Output includes architecture summary and package-organized checklist.
@@ -171,6 +185,8 @@ Return:
- Do not collapse all pages into one file.
- Do not use globals or implicit global side effects.
- Do not block UI event handlers with synchronous I/O or long CPU tasks.
- Always define loading/progress/error states for long user-triggered actions.
- Keep code minimal but production-minded.
- Prefer clarity and maintainability over clever abstractions.
skills/python-logging-dictconfig/SKILL.md
+97
View File
@@ -0,0 +1,97 @@
---
name: python-logging-dictconfig
description: 'Set up idiomatic Python logging with logging.config.dictConfig. Use when creating or refactoring logging setup, standardizing handlers/formatters, and enforcing centralized config.'
argument-hint: 'Target context (single script, package, FastAPI app, or CLI) and desired log destinations'
---
# Idiomatic Python Logging with dictConfig
Use this skill to produce a minimal, centralized logging setup using `logging.config.dictConfig`.
Load references only when needed:
- Python logging overview and hierarchy: [./references/python-logging-docs.md](./references/python-logging-docs.md)
## When to Use
- A project configures logging ad hoc with `basicConfig` across multiple modules.
- You need one canonical logging configuration for app startup.
- You need consistent formatting and levels across console/file handlers.
- You want library modules to use named loggers without configuring logging themselves.
## Inputs To Collect
1. Runtime type: script, library, web app, worker, CLI.
2. Destinations: stdout only, file only, or both.
3. Desired default level: `INFO`, `DEBUG`, etc.
4. Whether third-party loggers should be tuned (for example `uvicorn`, `sqlalchemy`).
If missing, assume:
- stdout handler
- human-readable formatter
- root level `INFO`
- `disable_existing_loggers: False`
## Procedure
1. Define a single `LOGGING` dictionary in one startup-oriented module (for example `logging_config.py`).
2. Include `version: 1` and set `disable_existing_loggers: False` unless there is a specific reason to silence existing loggers.
3. Define formatters first, then handlers, then logger routing (`root` and optional named `loggers`).
4. Use `logging.config.dictConfig(LOGGING)` exactly once during application startup.
5. In all modules, get loggers via `logger = logging.getLogger(__name__)` and never call `basicConfig`.
6. Keep libraries configuration-free: libraries should emit logs, applications decide routing.
7. Verify behavior with a quick smoke check at multiple levels (`DEBUG`, `INFO`, `WARNING`, `ERROR`).
## Minimal Baseline Template
```python
# logging_config.py
from logging.config import dictConfig
LOGGING = {
"version": 1,
"disable_existing_loggers": False,
"formatters": {
"standard": {
"format": "%(asctime)s %(levelname)s %(name)s: %(message)s"
}
},
"handlers": {
"console": {
"class": "logging.StreamHandler",
"level": "INFO",
"formatter": "standard",
"stream": "ext://sys.stdout",
}
},
"root": {
"level": "INFO",
"handlers": ["console"],
},
}
def configure_logging() -> None:
dictConfig(LOGGING)
```
```python
# app startup
from .logging_config import configure_logging
configure_logging()
```
```python
# any module
import logging
logger = logging.getLogger(__name__)
logger.info("module initialized")
```
## Completion Checks
1. `dictConfig` is called once at startup, not per module.
2. No `basicConfig` calls remain.
3. Modules use `getLogger(__name__)`.
4. Logs appear at expected level and destination.
5. Third-party logger noise is intentionally configured or left at defaults.
## Branching Guidance
- If structured logs are required: switch formatter output to JSON while keeping `dictConfig` topology unchanged.
- If both console and file output are needed: add a file handler and attach it to `root`.
- If a specific framework logger is too noisy: add a named logger override under `loggers`.
skills/python-logging-dictconfig/references/python-logging-docs.md
+18
View File
@@ -0,0 +1,18 @@
# Python Logging References
Use these official Python docs when applying this skill.
## Core Documentation
- Logging HOWTO: https://docs.python.org/3/howto/logging.html
- Logging Cookbook: https://docs.python.org/3/howto/logging-cookbook.html
- logging API reference: https://docs.python.org/3/library/logging.html
- logging.config reference: https://docs.python.org/3/library/logging.config.html
## dictConfig-Specific
- Dictionary schema details (`version`, formatters, handlers, loggers, root): https://docs.python.org/3/library/logging.config.html#logging-config-dictschema
- `logging.config.dictConfig` function: https://docs.python.org/3/library/logging.config.html#logging.config.dictConfig
## Practical Notes
- Prefer app-level centralized config with one startup call to `dictConfig`.
- In modules, use `logging.getLogger(__name__)`.
- Avoid calling `basicConfig` in libraries or scattered modules.