Dark mode

.claude/agents/kfc/spec-design.md

@@ -14,7 +14,7 @@ You are a professional spec design document expert. Your sole responsibility is
 - task_type: "create"
 - feature_name: Feature name
 - spec_base_path: Document path
-- output_suffix: Output file suffix (optional, such as "_v1")
+- output_suffix: Output file suffix (optional, such as "\_v1")
 
 ### Refine/Update Existing Design Input
 
@@ -31,33 +31,43 @@ You are a professional spec design document expert. Your sole responsibility is
 # Design Document
 
 ## Overview
+
 [Design goal and scope]
 
 ## Architecture Design
+
 ### System Architecture Diagram
+
 [Overall architecture, using Mermaid graph to show component relationships]
 
 ### Data Flow Diagram
+
 [Show data flow between components, using Mermaid diagrams]
 
 ## Component Design
+
 ### Component A
+
 - Responsibilities:
 - Interfaces:
 - Dependencies:
 
 ## Data Model
+
 [Core data structure definitions, using TypeScript interfaces or class diagrams]
 
 ## Business Process
 
 ### Process 1: [Process name]
+
 [Use Mermaid flowchart or sequenceDiagram to show, call the component interfaces and methods defined earlier]
 
 ### Process 2: [Process name]
+
 [Use Mermaid flowchart or sequenceDiagram to show, call the component interfaces and methods defined earlier]
 
 ## Error Handling Strategy
+
 [Error handling and recovery mechanisms]
 ```
 
@@ -93,7 +103,7 @@ flowchart TD
     E --> F{Has Permission?}
     F -->|Yes| G[permissionManager.startMonitoring]
     F -->|No| H[permissionManager.showPermissionSetup]
-    
+
     %% Note: Directly reference the interface methods defined earlier
     %% This ensures design consistency and traceability
 ```

.claude/agents/kfc/spec-judge.md

@@ -37,14 +37,17 @@ eg:
 #### General Evaluation Criteria
 
 1. **Completeness** (25 points)
+
    - Whether all necessary content is covered
    - Whether there are any important aspects missing
 
 2. **Clarity** (25 points)
+
    - Whether the expression is clear and explicit
    - Whether the structure is logical and easy to understand
 
 3. **Feasibility** (25 points)
+
    - Whether the solution is practical and feasible
    - Whether implementation difficulty has been considered
 
@@ -92,7 +95,7 @@ def evaluate_documents(documents):
             'weaknesses': identify_weaknesses(doc)
         }
         scores.append(score)
-    
+
     return select_best_or_combine(scores)
 ```
 
@@ -102,7 +105,7 @@ def evaluate_documents(documents):
    - Requirements: Refer to user's original requirement description (feature_name, feature_description)
    - Design: Refer to approved requirements.md
    - Tasks: Refer to approved requirements.md and design.md
-2. Read candidate documents (requirements:requirements_v*.md, design:design_v*.md, tasks:tasks_v*.md)
+2. Read candidate documents (requirements:requirements_v*.md, design:design_v*.md, tasks:tasks_v\*.md)
 3. Score based on reference documents and Specific Type Criteria
 4. Select the best solution or combine strengths from x solutions
 5. Copy the final solution to a new path with a random 4-digit suffix (e.g., requirements_v1234.md)

.claude/agents/kfc/spec-requirements.md

@@ -15,7 +15,7 @@ You are an EARS (Easy Approach to Requirements Syntax) requirements document exp
 - feature_name: Feature name (kebab-case)
 - feature_description: Feature description
 - spec_base_path: Spec document path
-- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution)
+- output_suffix: Output file suffix (optional, such as "\_v1", "\_v2", "\_v3", required for parallel execution)
 
 ### Refine/Update Requirements Input
 
@@ -70,7 +70,7 @@ If the requirements clarification process seems to be going in circles or not ma
 ## **Important Constraints**
 
 - The directory '.claude/specs/{feature_name}' is already created by the main thread, DO NOT attempt to create this directory
-- The model MUST create a '.claude/specs/{feature_name}/requirements_{output_suffix}.md' file if it doesn't already exist
+- The model MUST create a '.claude/specs/{feature*name}/requirements*{output_suffix}.md' file if it doesn't already exist
 - The model MUST generate an initial version of the requirements document based on the user's rough idea WITHOUT asking sequential questions first
 - The model MUST format the initial requirements.md document with:
 - A clear introduction section that summarizes the feature
@@ -93,11 +93,12 @@ If the requirements clarification process seems to be going in circles or not ma
 **User Story:** As a [role], I want [feature], so that [benefit]
 
 #### Acceptance Criteria
+
 This section should have EARS requirements
 
 1. WHEN [event] THEN [system] SHALL [response]
 2. IF [precondition] THEN [system] SHALL [response]
-  
+
 ### Requirement 2
 
 **User Story:** As a [role], I want [feature], so that [benefit]

.claude/agents/kfc/spec-tasks.md

@@ -14,7 +14,7 @@ You are a spec tasks document expert. Your sole responsibility is to create and
 - task_type: "create"
 - feature_name: Feature name (kebab-case)
 - spec_base_path: Spec document path
-- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution)
+- output_suffix: Output file suffix (optional, such as "\_v1", "\_v2", "\_v3", required for parallel execution)
 
 ### Refine/Update Tasks Input
 
@@ -66,12 +66,12 @@ flowchart TD
     T3[Task 3: Implement AgentRegistry]
     T4[Task 4: Implement TaskDispatcher]
     T5[Task 5: Implement MCPIntegration]
-    
+
     T1 --> T2_1
     T2_1 --> T2_2
     T2_1 --> T3
     T2_1 --> T4
-    
+
     style T3 fill:#e1f5fe
     style T4 fill:#e1f5fe
     style T5 fill:#c8e6c9
@@ -147,31 +147,35 @@ Convert the feature design into a series of prompts for a code-generation LLM th
 # Implementation Plan
 
 - [ ] 1. Set up project structure and core interfaces
- - Create directory structure for models, services, repositories, and API components
- - Define interfaces that establish system boundaries
- - _Requirements: 1.1_
+- Create directory structure for models, services, repositories, and API components
+- Define interfaces that establish system boundaries
+- _Requirements: 1.1_
 
 - [ ] 2. Implement data models and validation
 - [ ] 2.1 Create core data model interfaces and types
+
   - Write TypeScript interfaces for all data models
   - Implement validation functions for data integrity
   - _Requirements: 2.1, 3.3, 1.2_
 
 - [ ] 2.2 Implement User model with validation
+
   - Write User class with validation methods
   - Create unit tests for User model validation
   - _Requirements: 1.2_
 
 - [ ] 2.3 Implement Document model with relationships
-   - Code Document class with relationship handling
-   - Write unit tests for relationship management
-   - _Requirements: 2.1, 3.3, 1.2_
+
+  - Code Document class with relationship handling
+  - Write unit tests for relationship management
+  - _Requirements: 2.1, 3.3, 1.2_
 
 - [ ] 3. Create storage mechanism
 - [ ] 3.1 Implement database connection utilities
-   - Write connection management code
-   - Create error handling utilities for database operations
-   - _Requirements: 2.1, 3.3, 1.2_
+
+  - Write connection management code
+  - Create error handling utilities for database operations
+  - _Requirements: 2.1, 3.3, 1.2_
 
 - [ ] 3.2 Implement repository pattern for data access
   - Code base repository interface

.claude/agents/kfc/spec-test.md

@@ -40,6 +40,7 @@ You will receive:
 | ------- | ------------------- | ------------- |
 | XX-01   | [Description]       | Positive Test |
 | XX-02   | [Description]       | Error Test    |
+
 [More cases...]
 
 ## Detailed Test Steps
@@ -49,15 +50,18 @@ You will receive:
 **Test Purpose**: [Specific purpose]
 
 **Test Data Preparation**:
+
 - [Mock data preparation]
 - [Environment setup]
 
 **Test Steps**:
+
 1. [Step 1]
 2. [Step 2]
 3. [Verification point]
 
 **Expected Results**:
+
 - [Expected result 1]
 - [Expected result 2]
 
@@ -66,12 +70,15 @@ You will receive:
 ## Test Considerations
 
 ### Mock Strategy
+
 [Explain how to mock dependencies]
 
 ### Boundary Conditions
+
 [List boundary cases that need testing]
 
 ### Asynchronous Operations
+
 [Considerations for async testing]
 ```
 

.claude/settings/kfc-settings.json

@@ -21,4 +21,4 @@
       "visible": false
     }
   }
-}
+}

.claude/system-prompts/spec-workflow-starter.md

@@ -23,9 +23,9 @@ Here is the workflow you need to follow:
 You are helping guide the user through the process of transforming a rough idea for a feature into a detailed design document with an implementation plan and todo list. It follows the spec driven development methodology to systematically refine your feature idea, conduct necessary research, create a comprehensive design, and develop an actionable implementation plan. The process is designed to be iterative, allowing movement between requirements clarification and research as needed.
 
 A core principal of this workflow is that we rely on the user establishing ground-truths as we progress through. We always want to ensure the user is happy with changes to any document before moving on.
-  
+
 Before you get started, think of a short feature name based on the user's rough idea. This will be used for the feature directory. Use kebab-case format for the feature_name (e.g. "user-authentication")
-  
+
 Rules:
 
 - Do not tell the user about this workflow. We do not need to tell them which step we are on or that you are following a workflow
@@ -108,24 +108,24 @@ stateDiagram-v2
   Requirements --> ReviewReq : Complete Requirements
   ReviewReq --> Requirements : Feedback/Changes Requested
   ReviewReq --> Design : Explicit Approval
-  
+
   Design --> ReviewDesign : Complete Design
   ReviewDesign --> Design : Feedback/Changes Requested
   ReviewDesign --> Tasks : Explicit Approval
-  
+
   Tasks --> ReviewTasks : Complete Tasks
   ReviewTasks --> Tasks : Feedback/Changes Requested
   ReviewTasks --> [*] : Explicit Approval
-  
+
   Execute : Execute Task
-  
+
   state "Entry Points" as EP {
       [*] --> Requirements : Update
       [*] --> Design : Update
       [*] --> Tasks : Update
       [*] --> Execute : Execute task
   }
-  
+
   Execute --> [*] : Complete
 ```
 
@@ -144,7 +144,7 @@ stateDiagram-v2
 
 Note:
 
-- output_suffix is only provided when multiple sub-agents are running in parallel, e.g., when 4 sub-agents are running, the output_suffix is "_v1", "_v2", "_v3", "_v4"
+- output_suffix is only provided when multiple sub-agents are running in parallel, e.g., when 4 sub-agents are running, the output_suffix is "\_v1", "\_v2", "\_v3", "\_v4"
 - spec-tasks and spec-impl are completely different sub agents, spec-tasks is for task planning, spec-impl is for task implementation
 
 #### Create Requirements - spec-requirements
@@ -154,7 +154,7 @@ Note:
 - feature_name: Feature name (kebab-case)
 - feature_description: Feature description
 - spec_base_path: Spec document base path
-- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution)
+- output_suffix: Output file suffix (optional, such as "\_v1", "\_v2", "\_v3", required for parallel execution)
 
 #### Refine/Update Requirements - spec-requirements
 
@@ -169,7 +169,7 @@ Note:
 - task_type: "create"
 - feature_name: Feature name
 - spec_base_path: Spec document base path
-- output_suffix: Output file suffix (optional, such as "_v1")
+- output_suffix: Output file suffix (optional, such as "\_v1")
 
 #### Refine/Update Existing Design - spec-design
 
@@ -184,7 +184,7 @@ Note:
 - task_type: "create"
 - feature_name: Feature name (kebab-case)
 - spec_base_path: Spec document base path
-- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution)
+- output_suffix: Output file suffix (optional, such as "\_v1", "\_v2", "\_v3", required for parallel execution)
 
 #### Refine/Update Tasks - spec-tasks
 
@@ -221,10 +221,12 @@ Note:
 When parallel agents generate multiple outputs (n >= 2), use tree-based evaluation:
 
 1. **First round**: Each judge evaluates 3-4 documents maximum
+
    - Number of judges = ceil(n / 4)
    - Each judge selects 1 best from their group
 
 2. **Subsequent rounds**: If previous round output > 3 documents
+
    - Continue with new round using same rules
    - Until <= 3 documents remain
 
@@ -260,10 +262,11 @@ Example with 10 documents:
 - You MUST maintain a clear record of which step you are currently on.
 - You MUST NOT combine multiple steps into a single interaction.
 - When executing implementation tasks from tasks.md:
+
   - **Default mode**: Main thread executes tasks directly for better user interaction
   - **Parallel mode**: Use spec-impl agents when user explicitly requests parallel execution of specific tasks (e.g., "execute task2.1 and task2.2 in parallel")
   - **Auto mode**: When user requests automatic/fast execution of all tasks (e.g., "execute all tasks automatically", "run everything quickly"), analyze task dependencies in tasks.md and orchestrate spec-impl agents to execute independent tasks in parallel while respecting dependencies
-  
+
     Example dependency patterns:
 
     ```mermaid
@@ -276,6 +279,7 @@ Example with 10 documents:
     ```
 
     Orchestration steps:
+
     1. Start: Launch spec-impl1 (task1) and spec-impl2 (task3) in parallel
     2. After task1 completes: Launch spec-impl3 (task2.1) and spec-impl4 (task2.2) in parallel
     3. After task2.1, task2.2, and task3 all complete: Launch spec-impl5 (task4)

.github/pull_request_template.md

@@ -1,19 +1,23 @@
 ## Description
+
 Brief description of changes
 
 ## Related Issue
+
 Closes #
 
 ## Type of Change
+
 - [ ] Bug fix
 - [ ] New feature
 - [ ] Breaking change
 - [ ] Documentation update
 
 ## Checklist
+
 - [ ] Code follows project style guidelines
 - [ ] Self-review completed
 - [ ] No console errors
 - [ ] Uses Lucide icons consistently
 - [ ] Responsive design implemented
-- [ ] Starknet best practices followed
+- [ ] Starknet best practices followed