Menú
Force unrelated concepts together to discover emergent properties - "What if we treated X like Y?"
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Build robust backend systems — APIs (REST, GraphQL, gRPC), authentication (OAuth 2.1, JWT), databases, performance optimization, security (OWASP Top 10), scalability patterns (microservices, caching, sharding), and testing. Use when designing APIs, implementing auth, optimizing queries, handling security vulnerabilities, building microservices, or developing production-ready backend systems.
Explore and debate solutions before writing code. Use when the user poses a design question, asks "how should I approach X", wants to think through options before committing, or says anything like "let's brainstorm", "what's the best way to...", "I'm not sure how to tackle this", or "should I use X or Y". Always runs before /ck:plan for novel or ambiguous features. No code is written — only: explore → clarify → spec → report.
Implement a feature phase by phase from a phased JSON master or Markdown plan. Before each phase, confirm whether to create/run unit tests and whether to run ck:quality, unless explicit flags supply those choices. Supports token-budgeted execution, resumable state, and TDD handoff to ck:test.
Fix a bug using Scout → Diagnose → Fix → Review → Finalize. Use when the user pastes an error message, stack trace, or test failure, or says "fix this bug", "something's broken", "tests are failing", "I'm getting an error". Also accepts `--from-quality <report>` or `--from-test <report>` to fix exactly the findings/failures a report lists. Modes (pick one): --fast (trivial errors — lint, type, build — skip scout and review), --hard (mandatory review, no auto-approve).
Create a machine-readable phased JSON plan bundle from a spec or feature description. Produces a compact master manifest plus per-phase step files for resumable ck:cook execution.
Plan a feature or system before implementation. Use when the user says "plan this", "I want to build X", "how do I implement Y", or when /ck:brainstorm produces a spec.md. Always run before /ck:cook. Modes (pick one): --fast (simple, single-file), --hard (research + red-team + validate). Composable flag (combine with any mode): --tdd — propagates into the cook pipeline. Every phase gets Design Constraints and Quality/Testing State; ck:cook confirms optional test and quality checks per phase.
| name | Collision-Zone Thinking |
| description | Force unrelated concepts together to discover emergent properties - "What if we treated X like Y?" |
| when_to_use | when conventional approaches feel inadequate and you need breakthrough innovation by forcing unrelated concepts together |
| version | 1.1.0 |
Revolutionary insights come from forcing unrelated concepts to collide. Treat X like Y and see what emerges.
Core principle: Deliberate metaphor-mixing generates novel solutions.
| Stuck On | Try Treating As | Might Discover |
|---|---|---|
| Code organization | DNA/genetics | Mutation testing, evolutionary algorithms |
| Service architecture | Lego bricks | Composable microservices, plug-and-play |
| Data management | Water flow | Streaming, data lakes, flow-based systems |
| Request handling | Postal mail | Message queues, async processing |
| Error handling | Circuit breakers | Fault isolation, graceful degradation |
| Authorization | Border control | Zero-trust, least privilege, audit logs |
| Caching | Human memory | Forgetting curves, tiered memory (L1/L2/L3) |
Problem: Complex distributed system with cascading failures
Collision: "What if we treated services like electrical circuits?"
Emergent properties:
Where it works: Preventing cascade failures Where it breaks: Circuits don't have retry logic Insight gained: Failure isolation patterns from electrical engineering