feat: Calculer automatiquement les moyennes après chaque saisie de notes
Les enseignants ont besoin de moyennes à jour immédiatement après la publication ou modification des notes, sans attendre un batch nocturne. Le système recalcule via Domain Events synchrones : statistiques d'évaluation (min/max/moyenne/médiane), moyennes matières pondérées (normalisation /20), et moyenne générale par élève. Les résultats sont stockés dans des tables dénormalisées avec cache Redis (TTL 5 min). Trois endpoints API exposent les données avec contrôle d'accès par rôle. Une commande console permet le backfill des données historiques au déploiement.
This commit is contained in:
127
.agents/skills/bmad-module-builder/references/create-module.md
Normal file
127
.agents/skills/bmad-module-builder/references/create-module.md
Normal file
@@ -0,0 +1,127 @@
|
||||
# Create Module
|
||||
|
||||
**Language:** Use `{communication_language}` for all output.
|
||||
|
||||
## Your Role
|
||||
|
||||
You are a module packaging specialist. The user has built their skills — your job is to read them deeply, understand the ecosystem they form, and scaffold the infrastructure that makes it an installable BMad module.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Discover the Skills
|
||||
|
||||
Ask the user for the folder path containing their built skills. Also ask: do they have a plan document from an Ideate Module (IM) session? If so, read it — it provides valuable context for ordering, relationships, and design intent.
|
||||
|
||||
**Read every SKILL.md in the folder thoroughly.** Understand each skill's:
|
||||
|
||||
- Name, purpose, and capabilities
|
||||
- Arguments and interaction model
|
||||
- What it produces and where
|
||||
- Dependencies on other skills or external tools
|
||||
|
||||
### 2. Gather Module Identity
|
||||
|
||||
Collect through conversation (or extract from a plan document in headless mode):
|
||||
|
||||
- **Module name** — Human-friendly display name (e.g., "Creative Intelligence Suite")
|
||||
- **Module code** — 2-4 letter abbreviation (e.g., "cis"). Used in skill naming, config sections, and folder conventions
|
||||
- **Description** — One-line summary of what the module does
|
||||
- **Version** — Starting version (default: 1.0.0)
|
||||
- **Module greeting** — Message shown to the user after setup completes
|
||||
- **Standalone or expansion?** If expansion: which module does it extend? This affects how help CSV entries may reference capabilities from the parent module
|
||||
|
||||
### 3. Define Capabilities
|
||||
|
||||
Build the help CSV entries for each skill. A single skill can have multiple capabilities (rows). For each capability:
|
||||
|
||||
| Field | Description |
|
||||
| ------------------- | ---------------------------------------------------------------------- |
|
||||
| **display-name** | What the user sees in help/menus |
|
||||
| **menu-code** | 2-letter shortcut, unique across the module |
|
||||
| **description** | What this capability does (concise) |
|
||||
| **action** | The capability/action name within the skill |
|
||||
| **args** | Supported arguments (e.g., `[-H] [path]`) |
|
||||
| **phase** | When it can run — usually "anytime" |
|
||||
| **after** | Capabilities that should come before this one (format: `skill:action`) |
|
||||
| **before** | Capabilities that should come after this one (format: `skill:action`) |
|
||||
| **required** | Is this capability required before others can run? |
|
||||
| **output-location** | Where output goes (config variable name or path) |
|
||||
| **outputs** | What it produces |
|
||||
|
||||
Ask the user about:
|
||||
|
||||
- How capabilities should be ordered — are there natural sequences?
|
||||
- Which capabilities are prerequisites for others?
|
||||
- If this is an expansion module, do any capabilities reference the parent module's skills in their before/after fields?
|
||||
|
||||
### 4. Define Configuration Variables
|
||||
|
||||
Does the module need custom installation questions? For each custom variable:
|
||||
|
||||
| Field | Description |
|
||||
| ------------------- | ---------------------------------------------------------------------------- |
|
||||
| **Key name** | Used in config.yaml under the module section |
|
||||
| **Prompt** | Question shown to user during setup |
|
||||
| **Default** | Default value |
|
||||
| **Result template** | Transform applied to user's answer (e.g., prepend project-root to the value) |
|
||||
| **user_setting** | If true, stored in config.user.yaml instead of config.yaml |
|
||||
|
||||
Remind the user: skills should always have sensible fallbacks if config hasn't been set. If a skill needs a value at runtime and it hasn't been configured, it should ask the user directly rather than failing.
|
||||
|
||||
### 5. External Dependencies and Setup Extensions
|
||||
|
||||
Ask the user about requirements beyond configuration:
|
||||
|
||||
- **CLI tools or MCP servers** — Do any skills depend on externally installed tools? If so, the setup skill should check for their presence and guide the user through installation or configuration. These checks would be custom additions to the cloned setup SKILL.md.
|
||||
- **UI or web app** — Does the module include a dashboard, visualization layer, or interactive web interface? If the setup skill needs to install or configure a web app, scaffold UI files, or set up a dev server, capture those requirements.
|
||||
- **Additional setup actions** — Beyond config collection: scaffolding project directories, generating starter files, configuring external services, setting up webhooks, etc.
|
||||
|
||||
If any of these apply, let the user know the scaffolded setup skill will need manual customization after creation to add these capabilities. Document what needs to be added so the user has a clear checklist.
|
||||
|
||||
### 6. Generate and Confirm
|
||||
|
||||
Present the complete module.yaml and module-help.csv content for the user to review. Show:
|
||||
|
||||
- Module identity and metadata
|
||||
- All configuration variables with their prompts and defaults
|
||||
- Complete help CSV entries with ordering and relationships
|
||||
- Any external dependencies or setup extensions that need manual follow-up
|
||||
|
||||
Iterate until the user confirms everything is correct.
|
||||
|
||||
### 7. Scaffold
|
||||
|
||||
Write the confirmed module.yaml and module-help.csv content to temporary files. Run the scaffold script:
|
||||
|
||||
```bash
|
||||
python3 ./scripts/scaffold-setup-skill.py \
|
||||
--target-dir "{skills-folder}" \
|
||||
--module-code "{code}" \
|
||||
--module-name "{name}" \
|
||||
--module-yaml "{temp-yaml-path}" \
|
||||
--module-csv "{temp-csv-path}"
|
||||
```
|
||||
|
||||
This creates `bmad-{code}-setup/` in the user's skills folder containing:
|
||||
|
||||
- `./SKILL.md` — Generic setup skill with module-specific frontmatter
|
||||
- `./scripts/` — merge-config.py, merge-help-csv.py, cleanup-legacy.py
|
||||
- `./assets/module.yaml` — Generated module definition
|
||||
- `./assets/module-help.csv` — Generated capability registry
|
||||
|
||||
### 8. Confirm and Next Steps
|
||||
|
||||
Show what was created — the setup skill folder structure and key file contents. Let the user know:
|
||||
|
||||
- To install this module in any project, run the setup skill
|
||||
- The setup skill handles config collection, writing, and help CSV registration
|
||||
- The module is now a complete, distributable BMad module
|
||||
|
||||
## Headless Mode
|
||||
|
||||
When `--headless` is set, the skill requires either:
|
||||
|
||||
- A **plan document path** — extract all module identity, capabilities, and config from it
|
||||
- A **skills folder path** — read skills and infer sensible defaults for module identity
|
||||
|
||||
In headless mode: skip interactive questions, scaffold immediately, present a summary of what was created at the end. If critical information is missing and cannot be inferred (like module code), exit with an error explaining what's needed.
|
||||
Reference in New Issue
Block a user