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

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

planning

Étoiles3

Forks0

Mis à jour19 juin 2026 à 12:37

Start here to structure a non-trivial change into a high-level, phased plan with dependencies, risks, and an explicit out-of-scope boundary.

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

douglance

douglance/sdlc-plugin

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

Spécialistes en gestion de projetsProfessions des affaires et des opérations financières·SOC 13-1082

SKILL.md

readonly

name	planning
description	Start here to structure a non-trivial change into a high-level, phased plan with dependencies, risks, and an explicit out-of-scope boundary.
context	fork
agent	project-manager

Turn the goal into structure. Gather enough codebase context to understand the terrain, then break the work into a small number of high-level phases.

Stay high-level — leave exact files, signatures, and verify commands out. Ship the plan after the first draft; iterate during execution, not during planning.

What a plan contains

Phases — a handful of ordered steps (aim for ≤5), each a meaningful unit of work.
Dependencies — what each phase needs from the others.
Risks — what could go wrong, what's hard to reverse.
Out-of-scope set — an explicit out_of_scope list. This is a hard constraint, not a suggestion. You own it: every downstream phase inherits it verbatim.

Principles

Prefer the smallest plan that delivers the goal. If the work needs more than ~5 phases, it's two plans, not one.

Plus depuis ce dépôt

même dépôt

api-and-interface-design

douglance/sdlc-plugin

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

2026-06-193

debugging-and-error-recovery

douglance/sdlc-plugin

Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.

2026-06-193

deployment

douglance/sdlc-plugin

Start here to ship built-and-tested code to its target safely — release steps, rollout, smoke checks, and rollback.

2026-06-193

design

douglance/sdlc-plugin

Start here to settle how a non-trivial change will be built — interfaces, contracts, file-level structure, and trade-offs.

2026-06-193

documentation-and-adrs

douglance/sdlc-plugin

Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.

2026-06-193

documentation

douglance/sdlc-plugin

Start here to document what shipped — READMEs, API docs, ADRs, and usage — once a feature lands or an interface changes.

2026-06-193

name	planning
description	Start here to structure a non-trivial change into a high-level, phased plan with dependencies, risks, and an explicit out-of-scope boundary.
context	fork
agent	project-manager

Turn the goal into structure. Gather enough codebase context to understand the terrain, then break the work into a small number of high-level phases.

Stay high-level — leave exact files, signatures, and verify commands out. Ship the plan after the first draft; iterate during execution, not during planning.

What a plan contains

Phases — a handful of ordered steps (aim for ≤5), each a meaningful unit of work.
Dependencies — what each phase needs from the others.
Risks — what could go wrong, what's hard to reverse.
Out-of-scope set — an explicit out_of_scope list. This is a hard constraint, not a suggestion. You own it: every downstream phase inherits it verbatim.

Principles

Prefer the smallest plan that delivers the goal. If the work needs more than ~5 phases, it's two plans, not one.