G
gjelal-bjrm/structured-software-lifecycle
Claude Code skill: structured, technology-agnostic method to run a software project end to end — scoping,…
no SECURITY.md
View on GitHub ↗Link checked 2026-11-12 · HTTP 200 · opens the vendor's own site
- Star count
- 0 ★ · gjelal-bjrm/structured-software-lifecycle · read from the GitHub search API · (checked 2026-11-13 20:00:50)
- Source
- read directly from its GitHub page · type: open-source project
- Harvest history
- first seen 2026-10-21 · last seen 2026-11-14 · seen 28× · listed by 1 sources
- Score
- score 103 · 1 sources · repo
FAQ (answers come from our records)
Who is it for?
We filed it under these tags: 开源项目. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository
gjelal-bjrm/structured-software-lifecycle;first catalogued 2026-10-21;last seen 2026-11-14。There is no official certification or quality rating here — we record sources and dates only.# Structured Software Lifecycle
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
Un skill pour Claude Code qui applique une méthode de développement structurée, du besoin jusqu'à la livraison : cadrage, spécification, modèle de données, API, architecture, planification, analyse des risques et développement par itérations, avec une documentation tenue à jour à chaque étape.
La méthode ne dépend d'aucune technologie : elle convient aussi bien à un site web, une application mobile ou tablette, un programme desktop qu'à un outil interne.
A Claude Code skill for running a software project end to end with a structured, technology-agnostic method. The skill content is written in French; Claude writes the project documentation in the user's language.
## La méthode
| Phase | Ce qu'on fait | Livrables |
| 1. Documentation | Comprendre le problème, les utilisateurs, les technologies, l'architecture | Problématique, user personas, choix techniques, architecture, modèle de données, définition des API |
| 2. Spécification | Décider quoi construire | User stories classées MoSCoW et estimées (Fibonacci), product backlog, cas d'utilisation avec flots alternatifs |
| 3. Planification | Décider dans quel ordre et anticiper les problèmes | Planning par semaine, analyse des risques (impact × probabilité, mitigation, risque résiduel) |
| 4. Itérations | Développer une story à la fois | Analyse et conception → Implémentation → Test → Évaluation, puis « problèmes rencontrés » |
Les phases 1 à 3 ont lieu une fois au début du projet ; la phase 4 se répète pour chaque story.
La documentation produite est rangée dans un dossier docs/ du projet, à partir des modèles fournis dans templates/.
## Quand l'utiliser
Le skill donne une colonne vertébrale à un projet : comprendre le besoin, décider quoi construire, l'organiser, puis le développer morceau par morceau en laissant une documentation claire. Son but n'est pas de coder plus vite, mais d'éviter de construire la mauvaise chose, de se perdre en route, ou d'avoir un projet que plus personne ne comprend quelques mois plus tard.
| Situation | Utile ? | Ce qui se passe |
| Nouveau projet conséquent (application, logiciel, plateforme) | Oui, c'est son cas idéal | Les 4 phases complètes : cadrage, backlog, données et API, planning et risques, puis les itérations |
| Grosse fonctionnalité dans un projet existant (paiement, espace d'administration…) | Oui | Version courte : personas et stories concernés, cas d'utilisation, impact sur les données et les API, puis une ou plusieurs itérations |
| Fonctionnalité moyenne dans un projet déjà cadré | Oui, en version légère | Directement une itération : analyse, implémentation, test, évaluation, avec sa fiche dans docs/iterations/ |
| Petite tâche (corriger un bug, changer un texte, ajuster un style, petit script) | Non | Le skill ne se déclenche pas, volontairement : un cadrage complet serait une perte de temps |
| Prototype rapide ou idée à tester | Plutôt non | La méthode est faite pour durer. Si le prototype devient un vrai projet, appliquez-la à ce moment-là |
| Projet déjà bien avancé, sans documentation | Partiellement | Voir la limite ci-dessous |
Pour déclencher la méthode explicitement, demandez par exemple : « applique la méthode structured-software-lifecycle à ce projet ».
La méthode ne dépend d'aucune technologie : elle convient aussi bien à un site web, une application mobile ou tablette, un programme desktop qu'à un outil interne.
A Claude Code skill for running a software project end to end with a structured, technology-agnostic method. The skill content is written in French; Claude writes the project documentation in the user's language.
## La méthode
| Phase | Ce qu'on fait | Livrables |
| 1. Documentation | Comprendre le problème, les utilisateurs, les technologies, l'architecture | Problématique, user personas, choix techniques, architecture, modèle de données, définition des API |
| 2. Spécification | Décider quoi construire | User stories classées MoSCoW et estimées (Fibonacci), product backlog, cas d'utilisation avec flots alternatifs |
| 3. Planification | Décider dans quel ordre et anticiper les problèmes | Planning par semaine, analyse des risques (impact × probabilité, mitigation, risque résiduel) |
| 4. Itérations | Développer une story à la fois | Analyse et conception → Implémentation → Test → Évaluation, puis « problèmes rencontrés » |
Les phases 1 à 3 ont lieu une fois au début du projet ; la phase 4 se répète pour chaque story.
La documentation produite est rangée dans un dossier docs/ du projet, à partir des modèles fournis dans templates/.
## Quand l'utiliser
Le skill donne une colonne vertébrale à un projet : comprendre le besoin, décider quoi construire, l'organiser, puis le développer morceau par morceau en laissant une documentation claire. Son but n'est pas de coder plus vite, mais d'éviter de construire la mauvaise chose, de se perdre en route, ou d'avoir un projet que plus personne ne comprend quelques mois plus tard.
| Situation | Utile ? | Ce qui se passe |
| Nouveau projet conséquent (application, logiciel, plateforme) | Oui, c'est son cas idéal | Les 4 phases complètes : cadrage, backlog, données et API, planning et risques, puis les itérations |
| Grosse fonctionnalité dans un projet existant (paiement, espace d'administration…) | Oui | Version courte : personas et stories concernés, cas d'utilisation, impact sur les données et les API, puis une ou plusieurs itérations |
| Fonctionnalité moyenne dans un projet déjà cadré | Oui, en version légère | Directement une itération : analyse, implémentation, test, évaluation, avec sa fiche dans docs/iterations/ |
| Petite tâche (corriger un bug, changer un texte, ajuster un style, petit script) | Non | Le skill ne se déclenche pas, volontairement : un cadrage complet serait une perte de temps |
| Prototype rapide ou idée à tester | Plutôt non | La méthode est faite pour durer. Si le prototype devient un vrai projet, appliquez-la à ce moment-là |
| Projet déjà bien avancé, sans documentation | Partiellement | Voir la limite ci-dessous |
Pour déclencher la méthode explicitement, demandez par exemple : « applique la méthode structured-software-lifecycle à ce projet ».
Listed badge (optional)
Copy this line into the README if you want the listing mark. Optional, and it does not affect being listed.
[](https://anclum.com/en/s/gjelal-bjrm-structured-software-lifecycle/)
- Source
- github · https://github.com/gjelal-bjrm/structured-software-lifecycle
- Browse by field
- Open source
- added
- today
- Security policy
- no
SECURITY.mdat the repository root (which does not mean it is unsafe)
More like this
Filed under
Every tag opens the full list for that filter. Counts are the live catalogue figures.