Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问clear审计通过

sparc-pseudocodesparc 伪代码

Agent Skill

sparc-pseudocode 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

451

周安装

19

GitHub Stars

8

下载量

158
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:sparc-pseudocode(sparc 伪代码)
来源仓库:https://github.com/vamseeachanta/workspace-hub
仓库路径:skills/sparc-pseudocode
安装命令:
npx skills add https://github.com/vamseeachanta/workspace-hub --skill sparc-pseudocode
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/vamseeachanta/workspace-hub --skill sparc-pseudocode

简介

sparc-pseudocode 用于查找、检索和筛选相关信息。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词、任务场景或来源线索快速定位候选结果。
  • 通过 npx skills add 命令从指定 GitHub 仓库安装,需结合原始 README 核验具体用法。
  • 安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写操作。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

SPARC Pseudocode Agent

Algorithm design specialist focused on translating specifications into clear, efficient algorithmic logic for the SPARC methodology.

Quick Start

# Invoke SPARC Pseudocode phase

# Or directly in Claude Code
# "Use SPARC pseudocode to design the login flow algorithm"

When to Use

  • Translating specifications into algorithmic solutions
  • Designing data structures for optimal performance
  • Analyzing time and space complexity
  • Selecting appropriate design patterns
  • Creating implementation roadmaps for developers

Prerequisites

  • Completed specification phase with clear requirements
  • Understanding of data structure trade-offs
  • Knowledge of common algorithm patterns
  • Familiarity with complexity analysis

Core Concepts

SPARC Pseudocode Phase

The Pseudocode phase bridges specifications and implementation:

  1. Design algorithmic solutions - Language-agnostic logic
  2. Select optimal data structures - Based on access patterns
  3. Analyze complexity - Time and space requirements
  4. Identify design patterns - Reusable solutions
  5. Create implementation roadmap - Guide for developers

Complexity Classes

ClassDescriptionExample
O(1)ConstantHash lookup
O(log n)LogarithmicBinary search
O(n)LinearArray scan
O(n log n)LinearithmicMerge sort
O(n^2)QuadraticNested loops

Implementation Pattern

Algorithm Structure

ALGORITHM: AuthenticateUser
INPUT: email (string), password (string)
OUTPUT: user (User object) or error

BEGIN
    // Validate inputs
    IF email is empty OR password is empty THEN
        RETURN error("Invalid credentials")
    END IF

    // Retrieve user from database
    user <- Database.findUserByEmail(email)

    IF user is null THEN
        RETURN error("User not found")
    END IF

    // Verify password
    isValid <- PasswordHasher.verify(password, user.passwordHash)

    IF NOT isValid THEN
        // Log failed attempt
        SecurityLog.logFailedLogin(email)
        RETURN error("Invalid credentials")
    END IF

    // Create session
    session <- CreateUserSession(user)

    RETURN {user: user, session: session}
END

Data Structure Selection

DATA STRUCTURES:

UserCache:
    Type: LRU Cache with TTL
    Size: 10,000 entries
    TTL: 5 minutes
    Purpose: Reduce database queries for active users

    Operations:
        - get(userId): O(1)
        - set(userId, userData): O(1)
        - evict(): O(1)

PermissionTree:
    Type: Trie (Prefix Tree)
    Purpose: Efficient permission checking

    Structure:
        root
        +-- users
        |   +-- read
        |   +-- write
        |   +-- delete
        +-- admin
            +-- system
            +-- users

    Operations:
        - hasPermission(path): O(m) where m = path length
        - addPermission(path): O(m)
        - removePermission(path): O(m)

Algorithm Patterns

PATTERN: Rate Limiting (Token Bucket)

ALGORITHM: CheckRateLimit
INPUT: userId (string), action (string)
OUTPUT: allowed (boolean)

CONSTANTS:
    BUCKET_SIZE = 100
    REFILL_RATE = 10 per second

BEGIN
    bucket <- RateLimitBuckets.get(userId + action)

    IF bucket is null THEN
        bucket <- CreateNewBucket(BUCKET_SIZE)
        RateLimitBuckets.set(userId + action, bucket)
    END IF

    // Refill tokens based on time elapsed
    currentTime <- GetCurrentTime()
    elapsed <- currentTime - bucket.lastRefill
    tokensToAdd <- elapsed * REFILL_RATE

    bucket.tokens <- MIN(bucket.tokens + tokensToAdd, BUCKET_SIZE)
    bucket.lastRefill <- currentTime

    // Check if request allowed
    IF bucket.tokens >= 1 THEN
        bucket.tokens <- bucket.tokens - 1
        RETURN true
    ELSE
        RETURN false
    END IF
END

Configuration

# sparc-pseudocode-config.yaml
pseudocode_settings:
  syntax_style: "structured"  # structured, functional, mixed
  include_complexity: true
  include_subroutines: true

complexity_analysis:
  report_time: true
  report_space: true
  include_best_case: false
  include_worst_case: true
  include_average_case: true

patterns:
  catalog: ["strategy", "observer", "factory", "singleton", "decorator"]
  document_rationale: true

Usage Examples

Example 1: Search Algorithm

ALGORITHM: OptimizedSearch
INPUT: query (string), filters (object), limit (integer)
OUTPUT: results (array of items)

SUBROUTINES:
    BuildSearchIndex()
    ScoreResult(item, query)
    ApplyFilters(items, filters)

BEGIN
    // Phase 1: Query preprocessing
    normalizedQuery <- NormalizeText(query)
    queryTokens <- Tokenize(normalizedQuery)

    // Phase 2: Index lookup
    candidates <- SET()
    FOR EACH token IN queryTokens DO
        matches <- SearchIndex.get(token)
        candidates <- candidates UNION matches
    END FOR

    // Phase 3: Scoring and ranking
    scoredResults <- []
    FOR EACH item IN candidates DO
        IF PassesPrefilter(item, filters) THEN
            score <- ScoreResult(item, queryTokens)
            scoredResults.append({item: item, score: score})
        END IF
    END FOR

    // Phase 4: Sort and filter
    scoredResults.sortByDescending(score)
    finalResults <- ApplyFilters(scoredResults, filters)

    // Phase 5: Pagination
    RETURN finalResults.slice(0, limit)
END

SUBROUTINE: ScoreResult
INPUT: item, queryTokens
OUTPUT: score (float)

BEGIN
    score <- 0

    // Title match (highest weight)
    titleMatches <- CountTokenMatches(item.title, queryTokens)
    score <- score + (titleMatches * 10)

    // Description match (medium weight)
    descMatches <- CountTokenMatches(item.description, queryTokens)
    score <- score + (descMatches * 5)

    // Tag match (lower weight)
    tagMatches <- CountTokenMatches(item.tags, queryTokens)
    score <- score + (tagMatches * 2)

    // Boost by recency
    daysSinceUpdate <- (CurrentDate - item.updatedAt).days
    recencyBoost <- 1 / (1 + daysSinceUpdate * 0.1)
    score <- score * recencyBoost

    RETURN score
END

Example 2: Design Patterns

PATTERN: Strategy Pattern

INTERFACE: AuthenticationStrategy
    authenticate(credentials): User or Error

CLASS: EmailPasswordStrategy IMPLEMENTS AuthenticationStrategy
    authenticate(credentials):
        // Email/password logic

CLASS: OAuthStrategy IMPLEMENTS AuthenticationStrategy
    authenticate(credentials):
        // OAuth logic

CLASS: AuthenticationContext
    strategy: AuthenticationStrategy

    executeAuthentication(credentials):
        RETURN strategy.authenticate(credentials)

---

PATTERN: Observer Pattern

CLASS: EventEmitter
    listeners: Map<eventName, List<callback>>

    on(eventName, callback):
        IF NOT listeners.has(eventName) THEN
            listeners.set(eventName, [])
        END IF
        listeners.get(eventName).append(callback)

    emit(eventName, data):
        IF listeners.has(eventName) THEN
            FOR EACH callback IN listeners.get(eventName) DO
                callback(data)
            END FOR
        END IF

Example 3: Complexity Analysis

ANALYSIS: User Authentication Flow

Time Complexity:
    - Email validation: O(1)
    - Database lookup: O(log n) with index
    - Password verification: O(1) - fixed bcrypt rounds
    - Session creation: O(1)
    - Total: O(log n)

Space Complexity:
    - Input storage: O(1)
    - User object: O(1)
    - Session data: O(1)
    - Total: O(1)

ANALYSIS: Search Algorithm

Time Complexity:
    - Query preprocessing: O(m) where m = query length
    - Index lookup: O(k * log n) where k = token count
    - Scoring: O(p) where p = candidate count
    - Sorting: O(p log p)
    - Filtering: O(p)
    - Total: O(p log p) dominated by sorting

Space Complexity:
    - Token storage: O(k)
    - Candidate set: O(p)
    - Scored results: O(p)
    - Total: O(p)

Optimization Notes:
    - Use inverted index for O(1) token lookup
    - Implement early termination for large result sets
    - Consider approximate algorithms for >10k results

Execution Checklist

  • Read and understand specifications
  • Design main algorithm with clear INPUT/OUTPUT
  • Identify subroutines and helper functions
  • Select appropriate data structures
  • Write complexity analysis (time and space)
  • Identify applicable design patterns
  • Document optimization opportunities
  • Review for edge cases
  • Validate against specifications

Best Practices

  1. Language Agnostic: Don't use language-specific syntax
  2. Clear Logic: Focus on algorithm flow, not implementation details
  3. Handle Edge Cases: Include error handling in pseudocode
  4. Document Complexity: Always analyze time/space complexity
  5. Use Meaningful Names: Variable names should explain purpose
  6. Modular Design: Break complex algorithms into subroutines

Error Handling

IssueResolution
Unclear complexityBreak down into primitive operations
Missing edge casesReview input validation and error paths
Overly complexDecompose into smaller subroutines
No data structure justificationDocument access patterns and requirements

Metrics & Success Criteria

  • All algorithms have documented complexity
  • Subroutines are clearly defined
  • Data structures are justified with operations
  • Design patterns are identified where applicable
  • Pseudocode is language-agnostic

Integration Points

MCP Tools

// Store pseudocode phase completion
  action: "store",
  key: "sparc/pseudocode/algorithms",
  namespace: "coordination",
  value: JSON.stringify({
    algorithms: ["AuthenticateUser", "CheckRateLimit"],
    patterns: ["strategy", "observer"],
    complexity: "O(log n)",
    timestamp: Date.now()
  })
}

Hooks

# Pre-pseudocode hook

# Post-pseudocode hook

Related Skills

References

Version History

  • 1.0.0 (2026-01-02): Initial release - converted from agent to skill format

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

29.03%
按下载量换算46

windsurf

22.72%
按下载量换算36

trae

18.1%
按下载量换算29

OpenCode

11.09%
按下载量换算18

Cursor

6.91%
按下载量换算11

Codex

3.5%
按下载量换算6

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

来源信息

继续浏览同类 Skills