メニュー
Senior CTO review workflow for repository-grounded implementation-plan workstreams used before coding.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Run the canonical build plus all nine per-project test commands from docs/TESTING.md. Never uses solution-level dotnet test.
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.
Apply project EF Core conventions for repositories, DbContext setup, query filters, migrations, and seeded lookup data.
Create a self-contained HTML artifact focused on a high-quality SVG architecture or system diagram with minimal supporting prose.
Create a pragmatic self-contained HTML plan that organizes the user's plan content visually without expanding the scope unnecessarily.
Create a self-contained HTML artifact for reports, explainers, comparisons, prototypes, or decks when no narrower HTML diagram or plan skill applies.
| name | senior-cto-feedback |
| description | Senior CTO review workflow for repository-grounded implementation-plan workstreams used before coding. |
| type | workflow |
| enforcement | suggest |
| priority | high |
Use this skill when the user wants blunt Senior CTO feedback on an implementation plan before coding starts. The primary target is the repository's implementation-plan workflow: dev/active/[task-name]/[task-name]-plan.md, ...-context.md, and ...-tasks.md. The goal is to decide whether the plan is executable, well-sequenced, safe for a self-hostable multi-tenant platform, and strong enough for another implementation agent to follow without rediscovering the problem.
dev/active/... workstream created with the implementation-plan skill.plan.md, context.md, and tasks.md improved before implementation.implementation-plan workstream first.implementation-plan workstream, not just the main plan; plan.md, context.md, and tasks.md must agree.context.md and tasks.md.Review flow:
1. Read plan/context/tasks
2. Compare against the implementation-plan skill and its quality gates
3. Verify referenced files/docs/rules
4. Decide: approve, approve with required changes, split, reject, or defer
5. Return ranked risks, concrete required changes, and a recommended plan rewrite
Typical CTO verdict:
The target architecture is reasonable, but I would not approve this as one workstream. Persistence changes, API contract churn, and Blazor/UI enablement need separate slices, and the current tasks file does not prove tenant-isolation verification or self-hoster recovery steps.
dotnet build --configuration Release --verbosity quietdotnet test --project tests/Event.Architecture.Tests/Event.Architecture.Tests.csproj --configuration Release --verbosity quiet