ワンクリックで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