Skip to content
cccskills
FreePublished on GitHub

sparc-implement

Turn an approved specification into pseudocode, a plain outline of program logic, and an architecture defining module responsibilities and API inputs and outputs. After user confirmation, proceed with implementation and unit tests based on those designs.

OriginalShow the original description

Run the SPARC Pseudocode and Architecture phases (2 and 3) — write algorithm pseudocode, design module boundaries and API contracts, then implement

See how to install

Good for

  • Turning an approved specification into pseudocode
  • Defining module boundaries and dependency rules
  • Designing API inputs, outputs, and error responses
  • Implementing code and unit tests from an agreed design

Files included (1)

  • SKILL.md5.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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

  1. 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.

  2. Retrieve phase state — call mcp__plugin_ruflo-core_ruflo__memory_retrieve with namespace sparc-state and exact key current-phase-{feature-slug} to confirm we are in Phase 2 or 3.

  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

  4. 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: {...} }
  5. 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: {...} }
  6. Update phase state — call mcp__plugin_ruflo-core_ruflo__memory_store with namespace sparc-state, exact key current-phase-{feature-slug}; preserve existing state fields, update current phase to 3 (Architecture) with both artifacts recorded, and set updatedAt to the current ISO timestamp

  7. Record trajectory step — call mcp__plugin_ruflo-core_ruflo__hooks_intelligence_trajectory-step with architecture summary

  8. 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

  9. Present architecture — display the architecture decision record and suggest running /ruflo-sparc:ruflo-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 /ruflo-sparc:ruflo-sparc advance to pass the gate check.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Compare models available through the HuggingFace router with chat-ui configuration, research missing models, and write short English descriptions of their architecture and capabilities. Add entries to both production and development configuration files and commit the changes.

  • Adding newly available router models to chat-ui
  • Writing concise descriptions of model capabilities
  • Updating production and development model entries together
ruvnet/ruflo77KUpdated Oct 19, 2026

adr-create

FreeSummary

Create an Architecture Decision Record, a document for recording important design choices, with the next sequential number. It generates a Markdown template, registers the record in AgentDB, and links related decisions found through search.

  • Record the reasoning behind adopting a technology
  • Start an ADR for an API or data model change
  • Document an infrastructure decision
ruvnet/ruflo77KUpdated Oct 19, 2026

adr-index

FreeSummary

Build a searchable index and relationship graph from ADRs, records of architectural decisions. Import two supported document formats, refresh existing metadata without duplicate relationships, and review summaries of statuses, missing references, and inconsistencies.

  • Index ADRs imported from another project
  • Refresh a graph that differs from files on disk
  • Set up ADR tracking in an existing codebase
ruvnet/ruflo77KUpdated Oct 19, 2026

adr-reindex

FreeSummary

Rebuild the index of ADRs, records of architectural decisions, after files or relationship lines are deleted. It clears stored records and relationships, indexes the files still present, and checks that the final record count matches.

  • Rebuild the index after deleting an ADR file
  • Remove stale relationships after editing an ADR
  • Reconcile the ADR index on a schedule
ruvnet/ruflo77KUpdated Oct 19, 2026

adr-review

FreeSummary

Review code changes against accepted Architecture Decision Records, documents that capture agreed design choices. Report violations, outdated references, compliant changes, and areas without ADR coverage, then suggest code fixes or a new decision record where appropriate.

  • Check a pull request before merging
  • Review major code changes against agreed design decisions
  • Find references to superseded ADRs
ruvnet/ruflo77KUpdated Oct 19, 2026

adr-verify

FreeSummary

Check saved architecture decision records (ADRs) for broken references, circular replacement relationships, and inconsistent statuses. Use the results to verify imported records or stop a CI check when selected integrity rules fail.

  • Checking ADR integrity after import
  • Blocking CI when ADR issues are found
  • Reviewing ADR data before a release
ruvnet/ruflo77KUpdated Oct 19, 2026

See all skills by ruvnet

Report a problem with this skill