cto-challenge-stress-test

CTO Challenge Stress Test

Use this skill when the user wants to evaluate an AI CTO (or a CTO operating manual) against a list of real-world CTO challenges.

Trigger conditions

• User asks to stress-test a CTO approach, rubric, or agent against common CTO problems.
• User wants challenge-by-challenge comparison against proposed solutions.
• User wants a compact evaluation of how well an agentic CTO would handle inherited systems, delivery, risk, scale, security, talent, governance, or business alignment.

Core output shape

Prefer a compact table or numbered list with one row per challenge. For each challenge, include:

1. Challenge name
2. AI CTO response
3. Proposed/expected solution from the governing manual or source context
4. Quality rating: strong / partial / weak
5. One short reason for the rating

Keep the format concise and easy to scan. Default to the user's preferred cheat-sheet style.

If the exact historic question bank is not available in the live context, explicitly say that and reconstruct an equivalent class-level set rather than pretending to remember the exact wording.

Operating steps

1. Identify the source challenge list.
   • If the user gives a specific article or source, extract the challenge titles first and ignore marketing copy, ads, and “how to buy” sections.
   • For question-bank articles, pull the actual prompts verbatim when possible, then normalize duplicates and near-duplicates.
   • If the source is a challenge article, prefer one challenge per row; if it is a question list, cluster near-identical questions into a single test family.
   • If not, generate a representative class-level list covering strategy, delivery, risk, talent, cost, governance, security, data, and scaling.
   • If the primary source is blocked or partially inaccessible (for example, Reddit), use alternate retrieval paths first; if the exact thread text still cannot be recovered, answer at the theme level and say so explicitly.
2. Ground the evaluation in the governing operating manual or attached context.
   • Use the company CTO principles as the baseline.
   • Do not invent solutions when the manual already states a preferred response.
   • If the user asked to ignore a domain (for example, politics), exclude it from the evaluation rather than discussing it.
   • If the source article mixes challenges with vendor advice or product pitches, strip the pitch first and evaluate only the underlying CTO problem.
   • If the source review reveals durable gaps in the company guide, convert them into a short delta list and patch the guide artifacts together when appropriate.
3. Normalize and dedupe question sources before scoring.
   • Prefer one canonical question per theme when two prompts test the same CTO behavior.
   • Cluster exact duplicates and near-duplicates into one row unless the user explicitly wants every source question preserved.
   • If the exact historic question bank is unavailable in live context, say so and reconstruct an equivalent theme-level set rather than pretending exact recall.
   • Maintain a canonical theme bank in a reference file when multiple sources converge on the same CTO behaviors.
4. Score each response.
   • Strong: directly matches the manual and answers the practical issue.
   • Partial: directionally correct, but missing a key operational step, mitigation, ownership, or verification.
   • Weak: misses the root issue, over-indexes on theory, or avoids the decision.
5. Highlight systemic gaps only after the row-by-row evaluation.
   • Examples: first-90-days onboarding, change management, hiring cadence, or executive translation.
6. When evaluating many questions, batch them in groups of 3 or fewer if using delegation tools.
   • This avoids tool concurrency limits and keeps the scoring output easy to compare.