Ctxarchitect

CTX:Architect - Structured Design Workflow

Senior architect workflow: Understand → Research → Specify → Decompose → Plan

Core Workflow

1. Understand the Problem

Extract essentials:

• Core problem (what's the real need?)
• Constraints (time, budget, skills, existing systems)
• Success criteria (what does "done" look like?)
• Assumptions (make implicit explicit)

If unclear, ask:

• "What problem does this solve?"
• "What systems must it integrate with?"
• "Expected scale/volume?"
• "Must-haves vs. nice-to-haves?"

2. Research Existing Solutions

Use WebSearch to find:

• Existing tools/libraries: "best [tech] for [problem] 2025"
• Implementation patterns: "[problem] implementation examples"
• Known challenges: "[problem] pitfalls"
• Comparisons: "[tool A] vs [tool B]"

Evaluate each solution:

• Maturity (active? community?)
• Fit (solves 80%+?)
• Integration (works with stack?)
• Cost (license, hosting)
• Risk (lock-in, learning curve)

Output: Comparison table with pros/cons

3. Develop Specifications

Structure:

## Problem Statement
[1-2 sentences]

## Requirements
- [ ] Functional (High/Med/Low priority)
- [ ] Performance (metrics, scale)
- [ ] Security (requirements)

## Constraints
- Technical: [stack, systems]
- Resources: [time, budget, team]

## Success Criteria
- [Measurable outcomes]

If specs missing, ask:

• Functional: "What must it do?" "Inputs/outputs?" "Edge cases?"
• Non-functional: "How many users?" "Response time?" "Uptime?"
• Technical: "Current stack?" "Team skills?" "Deployment constraints?"

4. Decompose into Tasks

Process:

1. Identify major components
2. Break into 1-3 day tasks
3. Classify: Independent | Sequential | Parallel-ready
4. Map dependencies

Dependency mapping:

Task A (indep) ────┐
Task B (indep) ────┼──> Task D (needs A,B,C)
Task C (indep) ────┘
Task E (needs D) ──> Task F (needs E)

For each task:

• Prerequisites (what must exist first?)
• Outputs (what does it produce?)
• Downstream (what depends on it?)
• Parallelizable? (can run with others?)

5. Create Execution Plan

Phase structure:

## Phase 1: Foundation (Parallel)
- [ ] Task A - Infrastructure
- [ ] Task B - Data models
- [ ] Task C - CI/CD

## Phase 2: Core (Sequential after Phase 1)
- [ ] Task D - Auth (needs A,B)
- [ ] Task E - API (needs B)

## Phase 3: Features (Mixed)
- [ ] Task F - Feature 1 (needs D,E)
- [ ] Task G - Feature 2 (needs D,E) ← Parallel with F

Per task include:

• Description (what to build)
• Dependencies (prerequisites)
• Effort (S/M/L)
• Owner (who can execute)
• Done criteria (how to verify)
• Risks (what could fail)

Build vs. Buy Decision

Hybrid: Buy infrastructure/common features, build differentiation

Critical Success Factors

✅ Research first (don't reinvent) ✅ Make dependencies explicit (enable parallel work) ✅ Ask direct questions (get clarity fast) ✅ Document trade-offs (explain decisions) ✅ Think in phases (iterative delivery) ✅ Consider team (match to capabilities)

Activation Triggers

• "Design a system for..."
• "How should I architect..."
• "Break down this project..."
• "What's the best approach..."
• "Help me plan..."
• "Should I build or buy..."

Integration with Contextune

This skill is invoked automatically when Contextune detects /ctx:design command.

Workflow:

1. User types: "design a caching system"
2. Contextune detects: /ctx:design
3. Hook augments: "You can use your ctx:architect skill..."
4. Claude should ask: "I detected this is a design task. Would you like me to use the ctx:architect skill (structured workflow) or proceed directly?"
5. User chooses, workflow proceeds

Output: Structured specifications, researched alternatives, executable plan with dependencies

Converted and distributed by TomeVault — claim your Tome and manage your conversions.