القائمة
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