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

implementation-plan

스타6

포크3

업데이트2026년 7월 16일 15:55

Create or re-baseline lean, repository-grounded implementation plans and persistent dev docs when users ask for an implementation plan, technical plan, feature plan, refactor plan, or dev-docs workstream.

설치

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

Manus에서 실행

출처

islamu-ngo

islamu-ngo/Event

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

다운로드

Manus에서 실행

Purpose

Create the operational source of truth that future implementation agents use before editing code. The skill investigates current repository reality, designs executable slices, and writes a resumable three-file workstream under dev/active/ that implementation agents maintain progressively without repeated full rereads.

When to Load

Keywords: implementation plan, technical plan, plan this feature, refactor plan, create dev docs, dev-docs workstream.
A complex change needs repository investigation and executable sequencing before implementation.
Work is likely to span layers, multiple sessions, multiple contributors, or more than two hours.
An existing dev/active/<task-name>/ workstream needs re-baselining after scope or repository changes.
A handoff requests persistent planning artifacts for future implementation agents.

When NOT to Load

Not for a simple bug fix, single-file edit, quick update, or other atomic task that can be safely implemented now.
Not for product discovery or requirements elicitation without an implementation focus; use the PRD workflow instead.
Not for reviewing an existing completed plan; use senior-cto-feedback for critique and approval readiness.
Not for executing an approved plan; load the plan's implementation skills and rules instead.
Not for claiming implementation has started or runtime behavior has changed.

Must-Read Docs

Top 5 Invariants

Investigate and plan only; do not edit runtime code or claim implementation has started.
Verify every claimed existing path, symbol, test, contract, and configuration key from repository evidence before naming it as current state.
Classify the requested implementation work against every relevant intent and carry its docs, skills, rules, scope, tests, acceptance criteria, and forbidden moves into the plan.
Treat tasks.md as the hot progress ledger by checking substantial tasks immediately and all remaining completed tasks by phase end, while updating context only for meaningful state changes and the plan only for strategy changes.
Run verification once at each phase end using exactly one Release dotnet build command and at most one dotnet test --project command for the fastest relevant non-browser test project.

Top 5 Anti-Patterns

Memory-based planning, which turns assumptions about the repository into false implementation facts.
Future-state-first planning, which designs changes before reporting what exists, what is missing, and what evidence supports those conclusions.
Verification sprawl, which wastes implementation time on per-task checks, multiple test commands, app startup, browser automation, Playwright, Chrome DevTools MCP, Aspire, Docker, or live-service smoke tests.
Stale checkbox debt, which postpones task updates until a separate refresh command and leaves completed implementation appearing unfinished.
Repetitive rereading, which reloads unchanged plan/context files after every task instead of using tasks.md as the current execution ledger.

Minimal Examples

Request: "Create an implementation plan for event RSVP."
Output:
dev/active/event-rsvp/event-rsvp-plan.md
dev/active/event-rsvp/event-rsvp-context.md
dev/active/event-rsvp/event-rsvp-tasks.md

Planning sequence:
classify intents -> load rules/skills/docs -> inspect related work ->
verify code/tests/contracts -> report current state -> design slices ->
write and cross-check plan/context/tasks

Phase-end verification only:
dotnet build --configuration Release --verbosity quiet
dotnet test --project <one-relevant-project>.csproj --configuration Release --verbosity quiet

Progress cadence:
start/resume -> read once
substantial task done -> check it immediately
small tasks done -> reconcile no later than phase end
strategy changed -> update plan
decision/blocker/handoff -> update context

Verification Hooks

dotnet test --project tests/Event.Architecture.Tests/Event.Architecture.Tests.csproj --configuration Release --verbosity quiet
git diff --check -- .agents/skills/implementation-plan dev/active

Related Skills

이 저장소의 다른 Skills

같은 저장소

source-command-check

islamu-ngo/Event

Run the canonical build plus all nine per-project test commands from docs/TESTING.md. Never uses solution-level dotnet test.

2026-07-176

senior-cto-feedback

islamu-ngo/Event

Senior CTO review workflow for repository-grounded implementation-plan workstreams used before coding.

2026-07-166

dotnet-efcore-guidelines

islamu-ngo/Event

Apply project EF Core conventions for repositories, DbContext setup, query filters, migrations, and seeded lookup data.

2026-07-166

html-diagram

islamu-ngo/Event

Create a self-contained HTML artifact focused on a high-quality SVG architecture or system diagram with minimal supporting prose.

2026-07-076

html-plan

islamu-ngo/Event

Create a pragmatic self-contained HTML plan that organizes the user's plan content visually without expanding the scope unnecessarily.

2026-07-076

html

islamu-ngo/Event

Create a self-contained HTML artifact for reports, explainers, comparisons, prototypes, or decks when no narrower HTML diagram or plan skill applies.

2026-07-076

name	implementation-plan
description	Create or re-baseline lean, repository-grounded implementation plans and persistent dev docs when users ask for an implementation plan, technical plan, feature plan, refactor plan, or dev-docs workstream.
type	workflow
enforcement	block
priority	high

Purpose

When to Load

Keywords: implementation plan, technical plan, plan this feature, refactor plan, create dev docs, dev-docs workstream.
A complex change needs repository investigation and executable sequencing before implementation.
Work is likely to span layers, multiple sessions, multiple contributors, or more than two hours.
An existing dev/active/<task-name>/ workstream needs re-baselining after scope or repository changes.
A handoff requests persistent planning artifacts for future implementation agents.

When NOT to Load

Not for a simple bug fix, single-file edit, quick update, or other atomic task that can be safely implemented now.
Not for product discovery or requirements elicitation without an implementation focus; use the PRD workflow instead.
Not for reviewing an existing completed plan; use senior-cto-feedback for critique and approval readiness.
Not for executing an approved plan; load the plan's implementation skills and rules instead.
Not for claiming implementation has started or runtime behavior has changed.

Must-Read Docs

Top 5 Invariants

Investigate and plan only; do not edit runtime code or claim implementation has started.
Verify every claimed existing path, symbol, test, contract, and configuration key from repository evidence before naming it as current state.
Classify the requested implementation work against every relevant intent and carry its docs, skills, rules, scope, tests, acceptance criteria, and forbidden moves into the plan.
Treat tasks.md as the hot progress ledger by checking substantial tasks immediately and all remaining completed tasks by phase end, while updating context only for meaningful state changes and the plan only for strategy changes.
Run verification once at each phase end using exactly one Release dotnet build command and at most one dotnet test --project command for the fastest relevant non-browser test project.

Top 5 Anti-Patterns

Memory-based planning, which turns assumptions about the repository into false implementation facts.
Future-state-first planning, which designs changes before reporting what exists, what is missing, and what evidence supports those conclusions.
Verification sprawl, which wastes implementation time on per-task checks, multiple test commands, app startup, browser automation, Playwright, Chrome DevTools MCP, Aspire, Docker, or live-service smoke tests.
Stale checkbox debt, which postpones task updates until a separate refresh command and leaves completed implementation appearing unfinished.
Repetitive rereading, which reloads unchanged plan/context files after every task instead of using tasks.md as the current execution ledger.

Minimal Examples

Request: "Create an implementation plan for event RSVP."
Output:
dev/active/event-rsvp/event-rsvp-plan.md
dev/active/event-rsvp/event-rsvp-context.md
dev/active/event-rsvp/event-rsvp-tasks.md

Planning sequence:
classify intents -> load rules/skills/docs -> inspect related work ->
verify code/tests/contracts -> report current state -> design slices ->
write and cross-check plan/context/tasks

Phase-end verification only:
dotnet build --configuration Release --verbosity quiet
dotnet test --project <one-relevant-project>.csproj --configuration Release --verbosity quiet

Progress cadence:
start/resume -> read once
substantial task done -> check it immediately
small tasks done -> reconcile no later than phase end
strategy changed -> update plan
decision/blocker/handoff -> update context

Verification Hooks

dotnet test --project tests/Event.Architecture.Tests/Event.Architecture.Tests.csproj --configuration Release --verbosity quiet
git diff --check -- .agents/skills/implementation-plan dev/active