SPARC Architecture + Implementation
Run Phases 2 and 3 of the SPARC methodology: design algorithms with pseudocode, then establish architecture with module boundaries and API contracts.
When to use
After the Specification phase is complete and its gate has been passed. This skill covers both the Pseudocode and Architecture phases as they are tightly coupled — algorithm design informs module boundaries and vice versa.
Steps
Retrieve specification — call mcp__plugin_ruflo-core_ruflo__memory_search with namespace sparc-phases and query for the feature's spec. Extract requirements, acceptance criteria, constraints, and edge cases.
Retrieve phase state — call mcp__plugin_ruflo-core_ruflo__memory_search with namespace sparc-state and query for the feature to confirm we are in Phase 2 or 3.
Search for architectural patterns — call mcp__plugin_ruflo-core_ruflo__neural_predict with the feature description to find relevant architectural decisions from past projects
Phase 2 — Pseudocode Design:
a. For each acceptance criterion, write language-agnostic pseudocode that satisfies it
b. Define core data structures with type annotations
c. Map control flow including:
- Happy path
- Error/exception paths for each edge case
- Concurrent access handling if applicable
d. Annotate algorithmic complexity (time and space) for critical paths
e. Store pseudocode artifact:
- Call
mcp__plugin_ruflo-core_ruflo__memory_store with namespace sparc-phases, key pseudo-{feature-slug}
- Value:
{ status: "complete", algorithms: [...], dataStructures: [...], controlFlow: [...], complexity: {...} }
Phase 3 — Architecture Design:
a. Define bounded contexts and aggregate roots following DDD patterns:
- Identify entity boundaries and value objects
- Define aggregate invariants
- Map domain events
b. Design API contracts:
- Request/response schemas with TypeScript interfaces
- Error response codes and formats
- Versioning strategy if applicable
c. Plan module boundaries:
- Directory structure
- Dependency direction rules (no circular dependencies)
- Public vs internal interfaces
d. Specify infrastructure concerns:
- Persistence strategy (database, cache, file)
- Messaging patterns (sync, async, event-driven)
- Configuration and environment requirements
e. Store architecture artifact:
- Call
mcp__plugin_ruflo-core_ruflo__memory_store with namespace sparc-phases, key arch-{feature-slug}
- Value:
{ status: "complete", boundedContexts: [...], apiContracts: [...], moduleBoundaries: {...}, infrastructure: {...} }
Update phase state — call mcp__plugin_ruflo-core_ruflo__memory_store with namespace sparc-state, updating current phase to 3 (Architecture) with both artifacts recorded
Record trajectory step — call mcp__plugin_ruflo-core_ruflo__hooks_intelligence_trajectory-step with architecture summary
Begin implementation — if the user confirms, proceed to write production code:
a. Create files following the defined module boundaries
b. Implement interfaces and types first
c. Implement core logic following the pseudocode
d. Write unit tests alongside implementation (TDD when possible)
e. Run tests to verify acceptance criteria
Present architecture — display the architecture decision record and suggest running /sparc advance to pass the Phase 3 gate
Output format
# Pseudocode: {Feature Name}
## Core Algorithms
### Algorithm 1: {name}
```pseudocode
FUNCTION processRequest(input):
VALIDATE input against schema
IF invalid THEN THROW ValidationError
result <- TRANSFORM input
STORE result
RETURN result
Complexity: O(n) time, O(1) space
Data Structures
- {StructName}: { field1: type, field2: type }
Architecture: {Feature Name}
Bounded Contexts
- {ContextName}: {description}
- Aggregates: {list}
- Events: {list}
API Contracts
POST /api/{resource}
- Request: { field1: string, field2: number }
- Response: { id: string, ...fields }
- Errors: 400 (validation), 409 (conflict), 500 (internal)
Module Structure
src/{feature}/
{feature}.types.ts # Interfaces and types
{feature}.service.ts # Business logic
{feature}.controller.ts # HTTP handling
{feature}.repository.ts # Data access
{feature}.test.ts # Tests
Infrastructure
- Persistence: {strategy}
- Caching: {strategy}
- Events: {strategy}
Phases 2-3 complete. Run /sparc advance to pass the gate check.
1---2name: sparc-implement3description: Run the SPARC Pseudocode and Architecture phases (2 and 3) — write algorithm pseudocode, design module boundaries and API contracts, then implement4---5
6# SPARC Architecture + Implementation
7
8Run Phases 2 and 3 of the SPARC methodology: design algorithms with pseudocode, then establish architecture with module boundaries and API contracts.
9
10## When to use
11
12After the Specification phase is complete and its gate has been passed. This skill covers both the Pseudocode and Architecture phases as they are tightly coupled — algorithm design informs module boundaries and vice versa.
13
14## Steps
15
161. **Retrieve specification** — call `mcp__plugin_ruflo-core_ruflo__memory_search` with namespace `sparc-phases` and query for the feature's spec. Extract requirements, acceptance criteria, constraints, and edge cases.
17
182. **Retrieve phase state** — call `mcp__plugin_ruflo-core_ruflo__memory_search` with namespace `sparc-state` and query for the feature to confirm we are in Phase 2 or 3.
19
203. **Search for architectural patterns** — call `mcp__plugin_ruflo-core_ruflo__neural_predict` with the feature description to find relevant architectural decisions from past projects
21
224. **Phase 2 — Pseudocode Design**:
23 a. For each acceptance criterion, write language-agnostic pseudocode that satisfies it
24 b. Define core data structures with type annotations
25 c. Map control flow including:
26 - Happy path
27 - Error/exception paths for each edge case
28 - Concurrent access handling if applicable
29 d. Annotate algorithmic complexity (time and space) for critical paths
30 e. Store pseudocode artifact:
31 - Call `mcp__plugin_ruflo-core_ruflo__memory_store` with namespace `sparc-phases`, key `pseudo-{feature-slug}`
32 - Value: `{ status: "complete", algorithms: [...], dataStructures: [...], controlFlow: [...], complexity: {...} }`
33
345. **Phase 3 — Architecture Design**:
35 a. Define bounded contexts and aggregate roots following DDD patterns:
36 - Identify entity boundaries and value objects
37 - Define aggregate invariants
38 - Map domain events
39 b. Design API contracts:
40 - Request/response schemas with TypeScript interfaces
41 - Error response codes and formats
42 - Versioning strategy if applicable
43 c. Plan module boundaries:
44 - Directory structure
45 - Dependency direction rules (no circular dependencies)
46 - Public vs internal interfaces
47 d. Specify infrastructure concerns:
48 - Persistence strategy (database, cache, file)
49 - Messaging patterns (sync, async, event-driven)
50 - Configuration and environment requirements
51 e. Store architecture artifact:
52 - Call `mcp__plugin_ruflo-core_ruflo__memory_store` with namespace `sparc-phases`, key `arch-{feature-slug}`
53 - Value: `{ status: "complete", boundedContexts: [...], apiContracts: [...], moduleBoundaries: {...}, infrastructure: {...} }`
54
556. **Update phase state** — call `mcp__plugin_ruflo-core_ruflo__memory_store` with namespace `sparc-state`, updating current phase to 3 (Architecture) with both artifacts recorded
56
577. **Record trajectory step** — call `mcp__plugin_ruflo-core_ruflo__hooks_intelligence_trajectory-step` with architecture summary
58
598. **Begin implementation** — if the user confirms, proceed to write production code:
60 a. Create files following the defined module boundaries
61 b. Implement interfaces and types first
62 c. Implement core logic following the pseudocode
63 d. Write unit tests alongside implementation (TDD when possible)
64 e. Run tests to verify acceptance criteria
65
669. **Present architecture** — display the architecture decision record and suggest running `/sparc advance` to pass the Phase 3 gate
67
68## Output format
69
70```
71# Pseudocode: {Feature Name}
72
73## Core Algorithms
74### Algorithm 1: {name}
75```pseudocode
76FUNCTION processRequest(input):
77 VALIDATE input against schema
78 IF invalid THEN THROW ValidationError
79 result <- TRANSFORM input
80 STORE result
81 RETURN result
82```
83Complexity: O(n) time, O(1) space
84
85## Data Structures
86- {StructName}: { field1: type, field2: type }
87
88---
89
90# Architecture: {Feature Name}
91
92## Bounded Contexts
93- {ContextName}: {description}
94 - Aggregates: {list}
95 - Events: {list}
96
97## API Contracts
98### POST /api/{resource}
99- Request: { field1: string, field2: number }
100- Response: { id: string, ...fields }
101- Errors: 400 (validation), 409 (conflict), 500 (internal)
102
103## Module Structure
104```
105src/{feature}/
106 {feature}.types.ts # Interfaces and types
107 {feature}.service.ts # Business logic
108 {feature}.controller.ts # HTTP handling
109 {feature}.repository.ts # Data access
110 {feature}.test.ts # Tests
111```
112
113## Infrastructure
114- Persistence: {strategy}
115- Caching: {strategy}
116- Events: {strategy}
117
118---
119Phases 2-3 complete. Run `/sparc advance` to pass the gate check.
120```