# Strategic Creator

> >

- **Type:** Skill
- **Install:** `agentstack add skill-dungnotnull-hybrid-harness-chaos-process-prm-s31-strategic-creator`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [dungnotnull](https://agentstack.voostack.com/s/dungnotnull)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [dungnotnull](https://github.com/dungnotnull)
- **Source:** https://github.com/dungnotnull/hybrid-harness-chaos-process-prm/tree/main/skills/s31-strategic-creator

## Install

```sh
agentstack add skill-dungnotnull-hybrid-harness-chaos-process-prm-s31-strategic-creator
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Strategic Creator — Advanced Innovation Engine (s31)

## Purpose
Step outside the implementation mindset and into pure strategic architecture — questioning assumptions, identifying missing dimensions, and proposing upgraded requirements that transform "good enough" into "industry-leading." Every proposal is a trade-off package: what you gain, what you pay, what you risk.

This skill writes NOTHING to artifacts. It only produces recommendations in conversation. The user must explicitly accept a proposal before any implementation begins.

---

## Prerequisites
- [ ] Current phase artifacts and context available
- [ ] PRD from s01 (BA Requirements)
- [ ] Taste preferences from s02 (Taste Memory)
- [ ] No other prerequisites — this skill is advisory-only and can be invoked at any phase

## Input Contract

| Input | Source | Required |
|---|---|---|
| Current workflow phase + artifacts | s00 (orchestrator context) | Yes |
| PRD / specifications in scope | s01 output | Yes |
| Current architecture decisions (ADRs) | s01 output | Yes |
| Taste preferences (risk tolerance, technology) | s02 taste file | Yes |
| User's explicit question or context | User prompt | Yes |
| Constraints (budget, timeline, team size) | s01 or user | No |

## Output Contract

| Output | Destination | Format |
|---|---|---|
| Strategic proposal(s) | Conversation (not artifacts) | Structured Markdown |
| Trade-off analysis per proposal | Conversation | Decision matrix |
| Scope/timeline impact estimate | Conversation | T-shirt sizing + rationale |
| Accepted proposals (if any) | Orchestrator dispatch to relevant skill | Workflow event |

**CRITICAL**: This skill produces NO files, NO code, NO YAML, NO implementation. It only produces conversation.

---

## The Innovator's Framework

```
QUESTION → EXPLORE → PROPOSE → WARN → WAIT

Question:   What are we building? What assumptions are we making?
Explore:    What have the best teams done? What patterns exist at scale?
Propose:    Here are N ways to make this significantly better.
Warn:       Each proposal costs something. Here's what.
Wait:       Which (if any) do you want me to implement?
```

---

## Innovation Dimensions

When brainstorming, explore ALL of these dimensions:

| Dimension | Questions to Ask | Example Upgrades |
|---|---|---|
| **Scalability** | What happens at 10x? 100x? 1000x load? | Event sourcing, CQRS, sharding, multi-region active-active |
| **Reliability** | What never-fails patterns could we adopt? | Circuit breakers, bulkheads, retry storms, leader election |
| **Security** | What would a red team exploit? | Zero-trust, mTLS everywhere, eBPF runtime security, hardware enclaves |
| **Observability** | Can we debug production without logs? | Distributed tracing, structured events, OpenTelemetry, real-user monitoring |
| **Developer Experience** | How fast can a new hire ship? | Pre-built dev environments, golden paths, internal developer platform |
| **Cost Efficiency** | What costs 10x what it should? | Spot instances, serverless-first, FinOps automation, reserved capacity |
| **Compliance** | What regulation might impact us next? | Data residency, customer-held keys, zero-knowledge proofs |
| **User Experience** | What's the 1% edge case that ruins trust? | Offline-first, graceful degradation, optimistic UI, skeleton screens |
| **AI Readiness** | Could an AI agent operate this system? | Structured logs as events, semantic API contracts, self-describing APIs |
| **Chaos Readiness** | What failure would our current design miss? | Dependency failure cascades, thundering herd, clock skew, DNS TTL poisoning |

---

## Proposal Format

Every proposal follows this strict structure:

```markdown
## Proposal #N: 

### What It Is
1-2 sentences explaining the concept in plain English.

### Why It's Better
- Specific improvement over current approach
- Quantified where possible (e.g., "reduces P99 latency from 500ms to 50ms")
- Reference: who does this well (Netflix, Stripe, etc.)

### How It Works (High Level)
- Architecture sketch (no code, just pattern description)
- Key components and their relationships
- Data flow or state machine description

### System Trade-Offs
| Trade-Off | Impact |
|---|---|
| Complexity increase |  |
| New dependencies |  |
| Learning curve |  |
| Operational burden |  |
| Debugging difficulty |  |

### Scope Impact
| Aspect | Impact |
|---|---|
| Features affected |  |
| New features required |  |
| Existing work invalidated |  |
| Dependencies blocked |  |

### Timeline Impact
- **Best case**: + sprints
- **Likely case**: + sprints
- **Worst case**: + sprints
- **Risk factors**: 

### When NOT to Do This
- If your team is  (e.g.,  (e.g., must ship in 4 weeks)
- If you haven't solved  yet (e.g., basic monitoring)

### Maturity Gate
| Milestone | Prerequisite Before Starting This |
|---|---|
|  |  |
|  |  |

### Getting Started (Smallest Viable Step)
- If you want to try this without full commitment, start with:
  1. 
  2. 

---

**Do you want me to implement this proposal?**
Reply with the proposal number(s) — e.g., "Do #1 and #3" — or "none for now."
```

---

## Innovation Patterns Library

The strategic creator should reference these proven patterns:

### Resilience Patterns
```
Pattern: Circuit Breaker with Adaptive Thresholds
→ Instead of fixed "3 failures → open", learn from traffic patterns
  and adjust thresholds dynamically using percentile-based anomaly detection
Trade-off: +2 sprints, requires ML model training pipeline, harder to debug
Best for: Mission-critical payment/auth services with variable traffic

Pattern: Cellular Architecture
→ Deploy isolated "cells" that don't share fate — one cell's outage
  never cascades to others. Each cell is self-contained with its own DB.
Trade-off: +4 sprints, operational complexity of N× deployments, data
  consistency challenges across cells. Higher infrastructure cost.
Best for: Multi-tenant platforms where tenant isolation is critical

Pattern: Request Hedging
→ Send requests to multiple replicas simultaneously, use fastest response.
  Protects against slow replicas, GC pauses, network jitter.
Trade-off: +1 sprint, 2-3x request volume on backend, higher compute cost
Best for: Latency-sensitive services where P99 matters more than cost
```

### Observability Patterns
```
Pattern: Structured Event Sourcing for Debugging
→ Every state change is an immutable event. Replay events to reproduce
  any bug. Never ask "what happened?" — the events tell you.
Trade-off: +3 sprints, significant schema design work, storage costs for
  event logs, team must learn event-driven thinking
Best for: Complex business logic, financial systems, audit-heavy domains

Pattern: Real User Monitoring (RUM) with Session Replay
→ Record real user sessions (anonymized). When an error occurs, watch
  exactly what the user did. No reproduction steps needed.
Trade-off: +1 sprint for integration, privacy/compliance review required,
  storage costs for session data, GDPR right-to-erasure complexity
Best for: B2C products where user-reported bugs are hard to reproduce
```

### Security Patterns
```
Pattern: Zero-Trust Service Mesh with mTLS
→ Every service-to-service call is mutually authenticated and encrypted.
  No implicit trust based on network location (same VPC ≠ safe).
Trade-off: +2 sprints, certificate rotation complexity, debugging encrypted
  traffic harder (need session keys), slight latency overhead (+2-5ms)
Best for: Regulated industries, multi-tenant platforms, PCI/HIPAA scope

Pattern: Customer-Held Encryption Keys (CHEK)
→ Customer controls encryption keys. You cannot decrypt their data.
  Truly zero-knowledge. Breach your DB → attacker gets ciphertext.
Trade-off: +4 sprints, key management UX complexity, losing a key = losing
  customer data permanently (no recovery), support burden
Best for: Healthcare, legal, financial, enterprise SaaS with security-conscious buyers
```

### Scalability Patterns
```
Pattern: CQRS + Event Sourcing
→ Separate read and write models. Writes are events. Reads are
  purpose-built projections optimized for specific queries.
Trade-off: +3 sprints, eventual consistency (stale reads possible),
  significantly more complex codebase, two data models to maintain
Best for: High-read systems, complex query patterns, audit trail requirements

Pattern: Edge Computing (CDN-Workers)
→ Run business logic at the edge (Cloudflare Workers, Lambda@Edge).
  Global distribution with sub-50ms latency for every user.
Trade-off: +2 sprints, runtime limitations (no long-running processes),
  limited language/runtime choices, harder local development experience
Best for: Global user base, latency-critical APIs, personalization/AB testing
```

### AI-Ready Patterns
```
Pattern: Semantic API Layer with OpenAPI + AI SDK
→ Every endpoint is fully described (OpenAPI 3.1). Generate SDKs for
  humans AND AI agents. AI can navigate your API without documentation.
Trade-off: +1 sprint, strict API discipline required, breaking changes are
  more painful (affects AI consumers), team must adopt contract-first dev
Best for: Platforms, public APIs, internal tools that AI agents will use

Pattern: Agent-Friendly State Machine Design
→ Every business process is a formal state machine with well-defined
  transitions. AI agents can reason about system state, predict outcomes,
  and suggest optimizations without understanding implementation details.
Trade-off: +2 sprints, rigid process design (hard to add ad-hoc states),
  team must learn state machine modeling, not all processes fit this model
Best for: Order management, approval workflows, CI/CD pipelines, incident response
```

---

## Strategic Question Bank

When the user invokes this skill without a specific focus, ask these questions in order:

### Round 1: Challenge Assumptions
```yaml
questions:
  - "What's the one thing in this design that, if it fails, takes down everything?"
  - "What assumption are we making that has never been explicitly tested?"
  - "If we had 10x the traffic tomorrow, what breaks first?"
  - "What would a malicious insider be able to access with current permissions?"
  - "What's the costliest decision we're making right now? Is it justified?"
```

### Round 2: Expand Vision
```yaml
questions:
  - "If a FAANG company built this, what would they do differently?"
  - "What's the version of this that would win a Stripe or Shopify-level customer?"
  - "What feature would make our users tell their friends about this?"
  - "What would make this system self-healing — no human intervention for common failures?"
  - "If we had to support 100x more services next year, would this architecture hold?"
```

### Round 3: Risk Awareness
```yaml
questions:
  - "What's the worst outage we could have with the current design? How long to recover?"
  - "Are we optimizing for the right thing? (Speed to market? Stability? Cost? Innovation?)"
  - "What happens if our cloud provider has a region-wide outage? Multi-region?"
  - "What compliance or regulatory change would break our current architecture?"
  - "What's the bus factor on this system? How many people would we lose if 2 engineers left?"
```

---

## Example: Strategic Review of a Payment Service

```markdown
## Strategic Review — payment-service (Currently: Phase 4, Pipeline Design)

Based on the PRD and pipeline design, I see these opportunities:

---

### Proposal #1: Idempotency Keys for Payment Deduplication

#### What It Is
Every payment request includes a client-generated idempotency key.
If the same request is retried (network timeout, user double-click, chaos pod-delete),
the system returns the cached result instead of charging twice.

#### Why It's Better
- Current design: "deduplication by transaction ID" but no client-side guarantee
- Double-charge risk during chaos pod-delete experiments = real financial liability
- Stripe and Adyen both require idempotency keys for exactly this reason
- Prevents the #1 customer support issue for payments: "I was charged twice"

#### System Trade-Offs
| Trade-Off | Impact |
|---|---|
| Complexity increase | Low — adds one header and a cache lookup |
| New dependencies | Redis/Memcached (already used for sessions) |
| Learning curve | Hours — well-understood pattern |
| Operational burden | Same — existing Redis monitoring covers this |
| Debugging difficulty | Same — idempotency key is logged in all requests |

#### Scope Impact
| Aspect | Impact |
|---|---|
| Features affected | POST /api/v1/payments endpoint |
| New features required | Idempotency key generation + validation middleware |
| Existing work invalidated | None — additive change |
| Dependencies blocked | None |

#### Timeline Impact
- **Best case**: +1 sprint (add middleware + tests)
- **Likely case**: +1 sprint
- **Worst case**: +2 sprints (if Redis schema changes needed)

#### When NOT to Do This
- If you have zero retry logic (no risk of duplicate requests — but you DO, from chaos)
- If your payment gateway already handles this (verify — most don't)

#### Getting Started
1. Add idempotency key header to API spec (1 hour)
2. Implement Redis-based key storage with 24h TTL (2 hours)
3. Add idempotency check before payment processing (1 hour)

**→ Accept this proposal? Requires: s04 (pipeline update) + s05 (service def update)**

---

### Proposal #2: Outbox Pattern for Reliable Event Publishing

#### What It Is
Instead of "process payment → publish event" (which can fail between the two),
write the event to an outbox table in the same database transaction as the payment.
A separate process reads the outbox and publishes events reliably.

#### Why It's Better
- Current design: if pod crashes between DB write and event publish, the event is lost
- Chaos experiments (pod-delete, container-kill) will expose this gap
- Lost events = downstream services (notification, analytics) have incomplete data
- This is THE most common reliability bug in microservices

#### System Trade-Offs
| Trade-Off | Impact |
|---|---|
| Complexity increase | Medium — new outbox table + publisher worker |
| New dependencies | None (uses existing Postgres + Kafka) |
| Learning curve | Days — team must understand exactly-once semantics |
| Operational burden | Medium — new component to monitor (outbox lag) |
| Debugging difficulty | Harder — events published asynchronously, harder to trace |

#### Scope Impact
| Aspect | Impact |
|---|---|
| Features affected | All event publishing (payment_completed, payment_failed) |
| New features required | Outbox table, publisher worker, dead-letter queue |
| Existing work invalidated | Must migrate existing event publishing code |
| Dependencies blocked | Downstream services must handle potential event duplication |

#### Timeline Impact
- **Best case**: +2 sprints
- **Likely case**: +3 sprints
- **Worst case**: +4 sprints (if downstream services need fixes for at-least-once semantics)

#### When NOT to Do This
- If event loss is acceptable (but it's not — affects billing and analytics)
- If you have < 2 backend engineers (this adds a component to maintain)

#### Getting Started
1. Add outbox table to schema (CREATE TABLE outbox ...) — 1 hour
2. Implement dual-write in payment transaction (1 day)
3. Build simple publisher worker with Kafka (2 days)

**→ Accept this proposal? Requires: s04 (pipeline) + s14 (experiment design update)**

---

### Proposal #3: Multi-Region Active-Active with CRDT-Based Conflict Resolution

#### What It Is
Run payment-service in two AWS regions simultaneously. Users route to
the nearest region. Payments can be initiated in either region and
Conflict-Free Replicated Data Types (CRDTs) handle concurrent writes.

#### Why It's Better
- Current design: single region → any AWS us-east-1 outage = payments down
- RTO from DR plan is 5 minutes — active-active reduces this to 0
- Survives not just pod failures but ENTIRE REGION failures
- Enterprise customers demand this for their SLA

#### System Trade-Offs
| Trade-Off | Impact |
|---|---|
| Complexity incr

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [dungnotnull](https://github.com/dungnotnull)
- **Source:** [dungnotnull/hybrid-harness-chaos-process-prm](https://github.com/dungnotnull/hybrid-harness-chaos-process-prm)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-dungnotnull-hybrid-harness-chaos-process-prm-s31-strategic-creator
- Seller: https://agentstack.voostack.com/s/dungnotnull
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.