| name | senior-cto-feedback |
| description | Senior CTO review workflow for repository-grounded implementation-plan workstreams used before coding. |
| type | workflow |
| enforcement | suggest |
| priority | high |
Purpose
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.
When to Load
- The user asks for CTO feedback, plan critique, approval/rejection, or plan rewrite.
- The input is a
dev/active/... workstream created with the implementation-plan skill.
- The user wants stronger architecture, sequencing, security, multi-tenancy, operations, or verification expectations in a plan.
- Breaking changes are acceptable, and the main question is whether the proposed direction is worth implementing.
- The user wants the existing
plan.md, context.md, and tasks.md improved before implementation.
When NOT to Load
- Not for direct production implementation unless the user separately asks to implement.
- Not for a vague product idea with no implementation plan; recommend creating an
implementation-plan workstream first.
- Not for narrow syntax or framework-doc questions where official docs are the primary need.
- Not for a pure PRD or discovery artifact that is intentionally pre-implementation.
- Not for generic praise; this skill is for decisive critique and correction.
Must-Read Docs
Top 5 Invariants
- Review the entire
implementation-plan workstream, not just the main plan; plan.md, context.md, and tasks.md must agree.
- Distinguish verified codebase reality from plan aspiration. Do not approve claims you did not verify.
- Favor simpler, more operable, better-tested, more explicit designs over compatibility with weak pre-v1 architecture.
- Protect tenant isolation, authorization boundaries, and self-hosting/operator clarity before convenience or UI polish.
- If the plan is directionally right but too large or mixed, require a sharper sequence or PR split instead of giving a soft approval.
Top 5 Anti-Patterns
- Reviewing only the narrative architecture while ignoring stale or vague
context.md and tasks.md.
- Treating missing migration, tenant-isolation, or operator-recovery detail as a minor documentation issue.
- Accepting UI/BFF-local authorization or affordance logic instead of API/HAL-authoritative behavior.
- Preserving duplicate contracts, compatibility shims, or obsolete routes “for now” without a named migration reason.
- Producing generic best-practice feedback that does not name files, plan sections, risks, or required corrections.
Minimal Examples
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.
Verification Hooks
dotnet build --configuration Release --verbosity quietdotnet test --project tests/Event.Architecture.Tests/Event.Architecture.Tests.csproj --configuration Release --verbosity quiet
Related Skills
