원클릭으로 Manus에서 모든 스킬 실행

sdlc-plan

스타1

포크0

업데이트2026년 6월 1일 21:32

Phase 2 of the SDLC. Use this to decide HOW a specified feature will be built — architecture, tech choices, data model, API contracts, and trade-offs. Triggers after a spec exists and the user wants a technical plan or design decisions. Produces specs/<feature>/plan.md plus Architecture Decision Records (ADRs). Must read spec.md and memory/constitution.md and respect their constraints.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

AZANIR

AZANIR/sdlc-kit

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Phase 2 — Plan (HOW)

Translate the spec into a technical approach that obeys the constitution.

Preconditions

specs/<feature>/spec.md exists. If not, route to /specify.

Process

Read spec.md and memory/constitution.md. List the constraints they impose.
Recall prior architecture decisions via memory-manager for consistency.
For every significant choice (datastore, framework, boundary, protocol), record an ADR from templates/adr.template.md in specs/<feature>/adr/. ADR prose in Ukrainian.
Write specs/<feature>/plan.md from templates/plan.template.md:
- architecture overview + component boundaries,
- data model / contracts,
- dependencies & versions,
- risks and mitigations,
- test strategy (aligned with constitution's TDD rule).

Discipline

Invoke superpowers-core brainstorming before committing to an approach — generate 2–3 options and justify the pick. Single-option plans are a red flag.
For large/unfamiliar codebases, you may invoke code-graph to map dependencies first.

Exit

Update .sdlc/state.json (phase=plan). Persist memory checkpoint. Say: "Plan + ADRs ready. Next: /tasks."

Примітка (UK)

План перетворює специфікацію на технічний підхід. Кожне суттєве рішення фіксуємо як ADR українською мовою, щоб згодом було зрозуміло, ЧОМУ обрали саме так.

이 저장소의 다른 Skills

같은 저장소

code-graph

AZANIR/sdlc-kit

Optional code-navigation aid for large or unfamiliar codebases. Use during the plan or implement phases to map module dependencies, find where a symbol is defined and used, and orient before making changes. This is a navigation helper only — it is NOT the memory layer. Skip for small projects.

2026-06-011

memory-manager

AZANIR/sdlc-kit

Persistent memory layer across sessions. Use to recall prior context at the start of work, to store checkpoints at phase boundaries, and to answer "what did we decide / do before" questions. Backed by the agentmemory server (local SQLite + vector embeddings) on port 3111, with an MCP-only fallback. Every phase skill calls this to survive /clear and compaction boundaries.

2026-06-011

sdlc-design

AZANIR/sdlc-kit

Phase 4 of the SDLC, used ONLY for user-facing features. Use this to produce UI/UX design documentation and a persistent design system before implementation. Triggers when tasks.md exists and the spec marked a UI surface. Coordinates with the ui-ux-pro-max skill to generate design-system/MASTER.md and per-page specs. Skip entirely for CLI tools, libraries, or backend-only work.

2026-06-011

sdlc-implement

AZANIR/sdlc-kit

Phase 5 of the SDLC. Use this to write code that satisfies the tasks, strictly test-first (TDD). Triggers when tasks.md exists and design is done or not needed. Implements one task at a time, writing a failing test before code, then making it pass, then refactoring. Persists progress to memory after each task so work survives session boundaries.

2026-06-011

sdlc-orchestrator

AZANIR/sdlc-kit

Master coordinator for the full software development lifecycle. Use this when starting a new feature or project, when the user is unsure which phase to run, when resuming work after a break, or to establish/edit the project constitution. Routes to specify, plan, tasks, design, implement, review, and ship phases in the correct order and enforces that no phase is skipped. ALWAYS consider this skill first at the start of any development work.

2026-06-011

sdlc-review

AZANIR/sdlc-kit

Phase 6 of the SDLC. Use this to verify the implementation against the spec's acceptance criteria and the project constitution before shipping. Triggers when implementation is complete. Produces specs/<feature>/review.md — a filled acceptance checklist with pass/fail per criterion and required fixes. Does not ship; gates whether ship is allowed.

2026-06-011

name	sdlc-plan
description	Phase 2 of the SDLC. Use this to decide HOW a specified feature will be built — architecture, tech choices, data model, API contracts, and trade-offs. Triggers after a spec exists and the user wants a technical plan or design decisions. Produces specs/<feature>/plan.md plus Architecture Decision Records (ADRs). Must read spec.md and memory/constitution.md and respect their constraints.

Phase 2 — Plan (HOW)

Translate the spec into a technical approach that obeys the constitution.

Preconditions

specs/<feature>/spec.md exists. If not, route to /specify.

Process

Read spec.md and memory/constitution.md. List the constraints they impose.
Recall prior architecture decisions via memory-manager for consistency.
For every significant choice (datastore, framework, boundary, protocol), record an ADR from templates/adr.template.md in specs/<feature>/adr/. ADR prose in Ukrainian.
Write specs/<feature>/plan.md from templates/plan.template.md:
- architecture overview + component boundaries,
- data model / contracts,
- dependencies & versions,
- risks and mitigations,
- test strategy (aligned with constitution's TDD rule).

Discipline

Invoke superpowers-core brainstorming before committing to an approach — generate 2–3 options and justify the pick. Single-option plans are a red flag.
For large/unfamiliar codebases, you may invoke code-graph to map dependencies first.

Exit

Update .sdlc/state.json (phase=plan). Persist memory checkpoint. Say: "Plan + ADRs ready. Next: /tasks."