@dzhechkov/p-replicator 1.0.0

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/templates/start-command.md

@@ -0,0 +1,283 @@
+# /start Command Template
+
+Use this template to generate the `/start` bootstrap command for any project.
+Adapt all placeholders to the specific project's architecture, tech stack, and documentation.
+
+---
+
+```markdown
+---
+description: Bootstrap entire {{PROJECT_NAME}} project from documentation. Generates monorepo skeleton, all packages, Docker configs, {{IF_DATABASE: database schema,}} core modules, and basic tests. $ARGUMENTS: optional flags --skip-tests, --skip-seed, --dry-run.
+---
+
+# /start $ARGUMENTS
+
+## Purpose
+
+One-command project generation from documentation → working monorepo with `docker compose up`.
+
+## Prerequisites
+
+- Documentation in `docs/` directory (SPARC or idea2prd-manual output)
+- CC toolkit in project root (CLAUDE.md, .claude/, .mcp.json)
+- {{RUNTIME_PREREQUISITES}}
+- Docker + Docker Compose installed
+- Git initialized
+
+## Process
+
+### Phase 1: Foundation (sequential — everything depends on this)
+
+1. **Read all project docs** to build full context:
+{{DOCS_TO_READ}}
+
+2. **Generate root configs:**
+   - `package.json` {{ROOT_PACKAGE_DETAILS}}
+   - `docker-compose.yml` (from Architecture)
+   - `.env.example` (from Completion/deployment docs)
+   - `.gitignore`
+   - {{ADDITIONAL_ROOT_CONFIGS}}
+
+3. **Git commit:** `chore: project root configuration`
+
+### Phase 2: Packages (parallel via Task tool ⚡)
+
+Launch {{NUM_TASKS}} parallel tasks:
+
+{{FOR_EACH_PACKAGE}}
+#### Task {{LETTER}}: {{PACKAGE_PATH}} ⚡
+
+Read and use as source:
+{{PACKAGE_DOC_REFERENCES}}
+
+Generate:
+{{PACKAGE_FILE_LIST}}
+
+**Commits:** {{PACKAGE_COMMITS}}
+{{/FOR_EACH_PACKAGE}}
+
+### Phase 3: Integration (sequential)
+
+1. **Verify cross-package imports** (shared modules used correctly)
+2. **Docker build:** `docker compose build`
+3. **Start services:** `docker compose up -d`
+{{IF_DATABASE}}
+4. **Database setup:**
+   - `{{MIGRATION_COMMAND}}`
+   - `{{SEED_COMMAND}}`
+{{/IF_DATABASE}}
+{{IF_NO_DATABASE}}
+4. *No database migration needed for this project*
+{{/IF_NO_DATABASE}}
+5. **Health check:** `{{HEALTH_CHECK_COMMAND}}`
+6. **Run tests:** {{TEST_COMMANDS}}
+7. **Git commit:** `chore: verify docker integration`
+
+### Phase 4: Finalize
+
+1. Generate/update `README.md` with quick start instructions
+2. Final git tag: `git tag v0.1.0-scaffold`
+3. Report summary: files generated, services running, what needs manual attention
+
+## Output
+
+After /start completes:
+```
+{{PROJECT_STRUCTURE_AFTER_INIT}}
+```
+
+## Flags
+
+- `--skip-tests` — skip test file generation (faster, not recommended)
+{{IF_DATABASE}}
+- `--skip-seed` — skip database seeding
+{{/IF_DATABASE}}
+- `--dry-run` — show plan without executing
+
+## Estimated Time
+
+- With parallel tasks: {{ESTIMATED_TIME}}
+- Files generated: {{ESTIMATED_FILES}}
+- Commits: {{ESTIMATED_COMMITS}}
+
+## Error Recovery
+
+If a task fails mid-generation:
+- All completed phases are committed to git
+- Re-run `/start` — it detects existing files and skips completed phases
+- Or fix the issue manually and continue
+
+## Swarm Agents Used
+
+| Phase | Agents | Parallelism |
+|-------|--------|-------------|
+| Phase 1 | Main | Sequential |
+| Phase 2 | {{NUM_TASKS}} Task tools | ⚡ Parallel |
+| Phase 3 | Main | Sequential |
+| Phase 4 | Main | Sequential |
+```
+
+---
+
+## Fill Instructions
+
+### DOCS_TO_READ
+
+List ALL documentation files the /start should read.
+
+**For SPARC pipeline:**
+```markdown
+   - `docs/Architecture.md` → monorepo structure, Docker Compose, tech stack
+   - `docs/Specification.md` → data model, API endpoints, NFRs
+   - `docs/Pseudocode.md` → core algorithms, business logic
+   - `docs/Completion.md` → env config, deployment setup
+   - `docs/PRD.md` → features, user personas (for README)
+   - `docs/Refinement.md` → edge cases, testing strategy
+```
+
+**For idea2prd-manual docs, also include:**
+```markdown
+   - `docs/ddd/strategic/` → bounded contexts, context map
+   - `docs/ddd/tactical/` → aggregates, entities, events
+   - `docs/adr/` → technology decisions
+   - `docs/tests/*.feature` → Gherkin test scenarios
+```
+
+### FOR_EACH_PACKAGE
+
+Create one Task block per independent package/service from Architecture.
+Each Task MUST include:
+1. **Doc references** — which docs to read for this package
+2. **File list** — all files to generate (source, configs, tests)
+3. **Commits** — semantic commit messages per logical group
+
+Mark tasks as ⚡ parallel when they have no cross-dependencies.
+Tasks that depend on shared modules should note the dependency.
+
+**For single-app monorepos (e.g. Next.js):**
+Phase 2 may have only 1-2 tasks. This is normal — not all projects are multi-service.
+Example: `⚡ Task A: apps/web` + `⚡ Task B: packages/shared`
+
+**For multi-service monorepos:**
+One task per service. Example: `⚡ Task A: packages/shared`, `⚡ Task B: packages/backend`, `⚡ Task C: packages/frontend`
+
+### IF_DATABASE / IF_NO_DATABASE
+
+Check Architecture.md for database presence:
+- If PostgreSQL/MongoDB/MySQL/Redis mentioned → use `{{IF_DATABASE}}` block
+- Set `{{MIGRATION_COMMAND}}` to correct ORM command:
+  - Prisma: `npx prisma migrate dev --name init`
+  - TypeORM: `npx typeorm migration:run`
+  - Drizzle: `npx drizzle-kit push`
+  - Knex: `npx knex migrate:latest`
+  - Raw SQL: `psql -f init.sql`
+- Set `{{SEED_COMMAND}}` similarly
+- If NO database in Architecture → use `{{IF_NO_DATABASE}}` block, remove --skip-seed flag
+
+### Key Principles
+
+1. **Docs as source of truth** — every Task must reference specific docs, never generate from memory
+2. **Maximize parallelism** — independent packages run as parallel Tasks
+3. **Atomic commits** — one commit per logical change, not one giant commit
+4. **Full integration** — Phase 3 MUST include Docker build + start + health check (+ DB if applicable)
+5. **Error recovery** — git commits after each phase ensure progress is saved
+6. **Project-specific** — adapt ALL placeholders to actual tech stack and architecture
+
+### Adaptation Checklist
+
+- [ ] All packages from Architecture have a Task in Phase 2
+- [ ] All core algorithms from Pseudocode are assigned to correct packages
+- [ ] Database section is conditional (included only if DB exists)
+- [ ] Migration command matches actual ORM (Prisma/TypeORM/Drizzle/Knex/raw SQL)
+- [ ] Docker services match docker-compose.yml from Architecture
+- [ ] Health check endpoint matches actual API
+- [ ] Test commands match actual test framework
+- [ ] Env vars in .env.example match Completion/deployment docs
+- [ ] Single-app monorepo handled correctly (fewer Phase 2 tasks)
+- [ ] If DDD: bounded contexts map to packages/modules
+- [ ] If Gherkin: test stubs generated from .feature files
+- [ ] If external APIs: encrypted storage setup included
+
+---
+
+## Adaptation Rules
+
+The `/start` content MUST be adapted to the specific project:
+
+| Project Aspect | How /start Adapts |
+|---------------|------------------|
+| **Monorepo packages** | One Task per package in Phase 2 |
+| **Single-app monorepo** | May have only 1-2 Tasks (e.g. Next.js + shared) |
+| **Tech stack** | Correct build/start/test commands per framework |
+| **Database present** | Include ORM migration commands (Prisma/TypeORM/Drizzle/etc.) |
+| **No database** | Skip migration/seed in Phase 3, remove {{MIGRATION_COMMAND}} |
+| **Docker services** | All services from docker-compose.yml |
+| **External APIs** | Adapter/client generation + encrypted storage setup |
+| **DDD Bounded Contexts** | One module/package per context if applicable |
+| **Pseudocode algorithms** | Core logic files generated from pseudocode |
+| **Gherkin scenarios** | Test file stubs generated from .feature files |
+| **Security patterns** | Auth middleware, encryption utils if required |
+
+---
+
+## Example: What /start Generated for PredMarket
+
+Real-world reference from a prediction market project (SPARC pipeline):
+
+```
+Phase 1 (Foundation):
+  - docker-compose.yml (3 services: frontend, backend, postgres)
+  - root package.json with workspaces
+  - .env.example with all env vars
+  - tsconfig.base.json
+
+Phase 2 (3 parallel Tasks):
+  ⚡ Task A: packages/shared
+     - LMSR engine (core math from Pseudocode.md)
+     - TypeScript types from data model
+     - Unit tests with invariant checks
+     
+  ⚡ Task B: packages/backend  
+     - Prisma schema from Specification.md data model
+     - 13 API endpoints from Architecture.md
+     - Service layer from Pseudocode.md algorithms
+     - Oracle adapters from Pseudocode.md
+     - Cron scheduler from Completion.md
+     - Zod schemas for all endpoints
+     
+  ⚡ Task C: packages/frontend
+     - React pages from user stories
+     - Components from UI requirements
+     - Hooks (auth, markets, trading, wallet)
+     - API client, router setup
+
+Phase 3 (Integration):
+  - docker compose build
+  - docker compose up -d
+  - npx prisma migrate dev --name init
+  - npx prisma db seed
+  - curl localhost:3001/health → verify
+
+Phase 4 (Finalize):
+  - README.md with quick start
+  - git tag v0.1.0-scaffold
+  - Summary: 70+ files, 15 commits, all services running
+```
+
+---
+
+## Critical: /start MUST Reference Docs, Not Hallucinate
+
+The `/start` command instructions must tell Claude Code to **read the actual docs** in `docs/`
+directory, not generate code from memory. Each Phase 2 Task should include explicit references:
+
+```markdown
+### Task B: packages/backend ⚡
+Read and use as source:
+- `docs/Specification.md` → data model → Prisma schema
+- `docs/Architecture.md` → API endpoints → route files
+- `docs/Pseudocode.md` → algorithms → service implementations
+- `docs/Completion.md` → env config → config.ts
+```
+
+This ensures generated code matches the documentation, not Claude's assumptions.

package/templates/.claude/skills/explore/SKILL.md

@@ -0,0 +1,215 @@
+---
+name: explore
+description: >
+  Adaptive task exploration and clarification skill for transforming vague 
+  requests into actionable specifications. Use when a user presents any task, 
+  problem, or goal that requires clarification before execution. Triggers on 
+  ambiguous requests, complex multi-part tasks, "I want to...", "help me with...", 
+  strategic decisions, product ideas, creative briefs, and any situation where 
+  understanding the real need is essential before proposing solutions. Does NOT 
+  provide solutions until task is fully explored.
+---
+
+# Explore: Adaptive Task Clarification
+
+Transform vague requests into crystal-clear, actionable task specifications through systematic Socratic questioning.
+
+## Core Philosophy
+
+**Never solve before you understand.** Most failed solutions solve the wrong problem. This skill ensures the real problem is understood before any solution is proposed.
+
+Key principles:
+- Questions unlock understanding; answers often hide assumptions
+- The stated goal is rarely the real goal
+- Constraints reveal opportunities
+- Success criteria prevent scope creep
+
+## Task Classification
+
+Before asking questions, classify the task type to select appropriate exploration dimensions:
+
+| Task Type | Indicators | Primary Dimensions |
+|-----------|------------|-------------------|
+| **Product/Feature** | "build", "create app", "develop" | Outcome, Users, Constraints, Success |
+| **Problem Solving** | "fix", "solve", "issue with" | Root Cause, Constraints, Attempted Solutions |
+| **Decision Making** | "should I", "choose between", "evaluate" | Criteria, Tradeoffs, Timeline, Reversibility |
+| **Creative** | "write", "design", "make content" | Audience, Tone, Format, Examples |
+| **Research** | "find out", "analyze", "understand" | Scope, Depth, Sources, Deliverable |
+| **Process/Workflow** | "how to", "improve process" | Current State, Desired State, Blockers |
+
+## Exploration Dimensions
+
+Select 3-5 dimensions based on task type. Each dimension has multiple question variants—choose the most natural for context.
+
+### 1. The Real Objective
+Uncover what success truly looks like, beyond the stated request.
+
+**Questions:**
+- "If this worked perfectly, what would be different in your [work/life/business]?"
+- "What outcome would make you say 'this was absolutely worth it'?"
+- "Is this goal a means to something else, or the end itself?"
+- "If you could wave a magic wand and have any result, what would you choose?"
+
+**Red flags to probe:** Generic goals ("make it better"), proxy metrics, solutions presented as requirements.
+
+### 2. Constraints & Boundaries
+Identify hard limits that shape the solution space.
+
+**Questions:**
+- "What's absolutely off the table—budget, time, technology, or approach-wise?"
+- "What existing systems, processes, or decisions must this work with?"
+- "Who needs to approve this, and what are their non-negotiables?"
+- "What would disqualify a solution, even if it technically works?"
+
+**Red flags to probe:** No constraints mentioned (usually means hidden ones), unrealistic expectations.
+
+### 3. Available Resources
+Understand leverage points and existing assets.
+
+**Questions:**
+- "What do you already have that we could build on—data, tools, people, prior work?"
+- "Who else is involved, and what can they contribute?"
+- "What similar problems have you solved before, and what worked?"
+- "What's your actual capacity to implement this?"
+
+**Red flags to probe:** Overestimated capabilities, unacknowledged dependencies.
+
+### 4. Timeline & Urgency
+Distinguish real deadlines from arbitrary ones.
+
+**Questions:**
+- "What happens if this takes 2x longer than expected?"
+- "Is there a hard deadline, and what's driving it?"
+- "Would you prefer a quick 80% solution or a slower 100% solution?"
+- "What's the cost of delay vs. the cost of getting it wrong?"
+
+**Red flags to probe:** Artificial urgency, no clear driver for deadline.
+
+### 5. Success Criteria
+Define what "done" actually means.
+
+**Questions:**
+- "How will you know this is successful? What will you measure?"
+- "Who decides if this is good enough, and what will they look for?"
+- "What's the minimum viable outcome that would still be valuable?"
+- "In 6 months, what would make you regret the approach we took?"
+
+**Red flags to probe:** Vague criteria ("stakeholders will be happy"), moving targets.
+
+### 6. Attempted Solutions (for problems)
+Learn from what hasn't worked.
+
+**Questions:**
+- "What have you already tried, and why didn't it work?"
+- "What solutions have you considered but rejected?"
+- "What would the obvious solution be, and why isn't that good enough?"
+
+### 7. Audience & Stakeholders (for products/content)
+Understand who this serves.
+
+**Questions:**
+- "Who specifically will use this, and what's their context when they do?"
+- "What does your audience already know or believe about this?"
+- "Who might be negatively affected, and does that matter?"
+
+## Execution Protocol
+
+### Phase 1: Initial Assessment (1 turn)
+
+1. Parse the user's request
+2. Identify what's already clear from context
+3. Classify task type
+4. Select 3-5 most critical dimensions
+5. Note any immediate red flags or assumptions
+
+### Phase 2: Adaptive Questioning (3-7 turns)
+
+**Rules:**
+- Ask ONE question at a time
+- Make questions specific and decision-shaping, not generic
+- Challenge vague answers: "Can you be more specific about...?"
+- Acknowledge answers before next question
+- Skip dimensions already clarified
+- Stop when you have enough to create a clear brief
+
+**Question Sequencing:**
+1. Start with Real Objective (reveals the most)
+2. Follow with Constraints (narrows solution space)
+3. Then Success Criteria (defines done)
+4. Fill gaps with other dimensions as needed
+
+**Adaptive behavior:**
+- If user gives detailed answer → compress follow-ups
+- If user seems frustrated → summarize and ask if they want to continue
+- If contradiction detected → gently probe: "Earlier you mentioned X, but now Y—help me understand?"
+
+### Phase 3: Task Brief Synthesis (1 turn)
+
+After sufficient exploration, synthesize into a **Task Brief**:
+
+```
+## Task Brief
+
+**Objective:** [Clear statement of what we're actually solving]
+
+**Context:** [Relevant background and constraints]
+
+**Success Criteria:**
+- [Measurable criterion 1]
+- [Measurable criterion 2]
+
+**Constraints:**
+- [Hard constraint 1]
+- [Hard constraint 2]
+
+**Resources Available:** [What we can leverage]
+
+**Timeline:** [Deadline and urgency level]
+
+**Key Assumptions:** [Things we're assuming that could change the approach]
+
+**Out of Scope:** [Explicitly excluded items]
+```
+
+Ask user: "Does this capture what you need? Anything to add or correct?"
+
+### Phase 4: Handoff
+
+Once validated, either:
+- Proceed to solution (if user wants immediate help)
+- Export brief for later use
+- Suggest appropriate next steps/skills
+
+## Anti-Patterns to Avoid
+
+❌ **Interrogation mode:** Don't fire questions robotically
+❌ **Assuming context:** Don't skip clarification because you "think" you understand
+❌ **Premature solutions:** Don't hint at solutions before exploration is complete
+❌ **Over-questioning:** Stop when you have enough clarity
+❌ **Generic questions:** Each question should be tailored to this specific task
+❌ **Ignoring signals:** If user provides info proactively, don't re-ask
+
+## Example Flow
+
+**User:** "I want to create a dashboard for my team"
+
+**Claude (Phase 1 assessment):**
+- Task type: Product/Feature
+- Unclear: Who uses it, what data, what decisions it enables, timeline
+- Dimensions needed: Real Objective, Audience, Constraints, Success Criteria
+
+**Claude:** "Before we dive in—what decisions will your team make differently once they have this dashboard? What's the main insight they're missing today?"
+
+*[User answers about tracking project delays]*
+
+**Claude:** "Got it—so the core need is visibility into project health to catch delays early. How do you know a project is delayed today? What's the current process for catching these issues?"
+
+*[Continues adaptively based on answers...]*
+
+## Integration Notes
+
+After exploration, this skill can hand off to:
+- problem-solver-enhanced (for complex problems)
+- goap-research-ed25519 (for research tasks)
+- frontend-design (for UI/product tasks)
+- Any implementation skill with the structured Task Brief

package/templates/.claude/skills/explore/references/questioning-techniques.md

@@ -0,0 +1,151 @@
+# Advanced Questioning Techniques
+
+Reference for sophisticated question patterns when standard approaches don't yield clarity.
+
+## Socratic Techniques
+
+### Clarifying Questions
+When answers are vague or use undefined terms:
+- "What do you mean by [term]?"
+- "Can you give me a specific example of [concept]?"
+- "How would you explain this to someone unfamiliar with your context?"
+
+### Assumption Probing
+When hidden assumptions might be distorting the problem:
+- "What would have to be true for this approach to work?"
+- "What are you taking for granted here that might not be true?"
+- "If you were wrong about [assumption], how would that change things?"
+
+### Consequence Exploration
+When second-order effects matter:
+- "If this succeeds, what problems might it create?"
+- "Who might be affected that we haven't considered?"
+- "What's the worst realistic outcome if this goes wrong?"
+
+### Perspective Shifting
+When stuck in one frame:
+- "How would [competitor/user/skeptic] view this?"
+- "If you had to argue against this approach, what would you say?"
+- "What would you advise someone else in this situation?"
+
+## Techniques for Specific Blockers
+
+### When user presents solution as requirement
+"I need a mobile app for X"
+
+**Approach:** Trace back to underlying need
+- "What problem would the mobile app solve?"
+- "How do users handle this today without the app?"
+- "If a mobile app wasn't an option, how else might you solve this?"
+
+### When user can't articulate success
+"I'll know it when I see it"
+
+**Approach:** Use concrete scenarios
+- "Imagine it's 6 months from now and this was a huge success—describe what's happening"
+- "If you had to bet money on one metric improving, what would it be?"
+- "What would your boss/customer/user say that would prove this worked?"
+
+### When constraints seem impossible
+"We need enterprise features but have startup budget"
+
+**Approach:** Separate hard from soft constraints
+- "If you had to prioritize: which constraint is truly immovable?"
+- "What's the minimum viable version that would still be valuable?"
+- "What could you trade off to make this feasible?"
+
+### When user is emotionally invested
+User seems attached to a specific solution
+
+**Approach:** Validate, then explore
+- "It sounds like you've thought about this a lot. What led you to this approach?"
+- "What would make you reconsider this direction?"
+- "What's the strongest argument against this that you've heard?"
+
+### When multiple stakeholders with conflicting needs
+"My boss wants X but users want Y"
+
+**Approach:** Map the conflict explicitly
+- "Let's map out who wants what. What does your boss's ideal outcome look like?"
+- "Where exactly do these needs conflict?"
+- "Is there a version that gives each party their most important thing?"
+
+## Question Formulation Patterns
+
+### The Magic Wand
+Removes artificial constraints to reveal true desires:
+"If you could wave a magic wand and have any outcome, what would you choose?"
+
+### The Premortem
+Surfaces hidden risks:
+"Imagine this failed spectacularly—what went wrong?"
+
+### The Constraint Inversion
+Challenges assumptions about limitations:
+"What if [constraint] wasn't a factor—would you approach this differently?"
+
+### The Minimum Viable Success
+Defines the essential core:
+"What's the smallest version of this that would still be valuable?"
+
+### The Regret Test
+Clarifies priorities over time:
+"In a year, what would you regret not having done?"
+
+### The Opportunity Cost
+Reveals trade-offs:
+"What else could you do with the time/money/effort this would require?"
+
+### The Outsider View
+Escapes insider bias:
+"How would you explain this problem to someone completely outside your industry?"
+
+## Red Flags and Responses
+
+| Red Flag | What It Might Mean | How to Probe |
+|----------|-------------------|--------------|
+| "Everyone knows..." | Unexamined assumption | "Help me understand—what's the evidence for this?" |
+| "We've always done it this way" | Inertia, not strategy | "What originally drove this approach? Is that still true?" |
+| "It's obvious that..." | Blind spot | "Walk me through why this is obvious—I want to make sure I understand" |
+| "We just need to..." | Oversimplification | "What could go wrong with this approach?" |
+| "ASAP" | Artificial urgency | "What specifically happens if this takes longer?" |
+| No constraints mentioned | Hidden constraints | "What would disqualify a solution even if it technically works?" |
+| Very specific solution stated | Solution fixation | "What problem does this solve? Are there other ways to solve it?" |
+
+## Calibrating Question Depth
+
+### Light Touch (1-2 questions per dimension)
+Use when:
+- User is experienced and already has clarity
+- Task is straightforward
+- Time is genuinely constrained
+- User shows frustration
+
+### Deep Exploration (3-5 questions per dimension)
+Use when:
+- High stakes decision
+- Multiple stakeholders
+- Technical complexity
+- User seems uncertain
+- Contradictions in answers
+
+### Signs to Stop Questioning
+- User is repeating themselves
+- Answers are becoming terse
+- You have enough for a clear brief
+- User explicitly says "that's enough"
+- Remaining questions are nice-to-know, not need-to-know
+
+## Cultural Considerations
+
+Some users may:
+- View detailed questions as distrust
+- Expect to define solutions themselves
+- Be uncomfortable with "why" questions
+- Prefer to give context incrementally
+
+**Adaptive responses:**
+- Frame questions as "helping me help you better"
+- Acknowledge their expertise: "You know this space—help me understand..."
+- Use "what" instead of "why" when appropriate
+- Offer to explain why you're asking