@adityaaria/spark 6.0.16 → 6.0.18

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -23,10 +23,11 @@ readonly LOCK_FILE_NAME=".spark-lock.json"
23
23
  if [ -t 1 ]; then
24
24
  readonly C_RESET='\033[0m'
25
25
  readonly C_BOLD='\033[1m'
26
- readonly C_GREEN='\033[0;32m'
27
- readonly C_YELLOW='\033[0;33m'
28
- readonly C_RED='\033[0;31m'
29
- readonly C_CYAN='\033[0;36m'
26
+ readonly C_GREEN='\033[38;5;46m' # 8-bit neon green
27
+ readonly C_YELLOW='\033[38;5;226m' # 8-bit bright yellow
28
+ readonly C_RED='\033[38;5;196m' # 8-bit bright red
29
+ readonly C_CYAN='\033[38;5;51m' # 8-bit cyan
30
+ readonly C_MAGENTA='\033[38;5;201m' # 8-bit magenta
30
31
  readonly C_DIM='\033[2m'
31
32
  else
32
33
  readonly C_RESET=''
@@ -35,6 +36,7 @@ else
35
36
  readonly C_YELLOW=''
36
37
  readonly C_RED=''
37
38
  readonly C_CYAN=''
39
+ readonly C_MAGENTA=''
38
40
  readonly C_DIM=''
39
41
  fi
40
42
 
@@ -46,15 +48,19 @@ readonly EXIT_NO_REPO=3
46
48
  readonly EXIT_INSTALL_FAILED=4
47
49
 
48
50
  # =============================================================================
49
- # Output helpers
51
+ # Output helpers (8-Bit Theme)
50
52
  # =============================================================================
51
53
 
52
- info() { printf "${C_CYAN}▸${C_RESET} %s\n" "$*"; }
53
- success() { printf "${C_GREEN}✔${C_RESET} %s\n" "$*"; }
54
- warn() { printf "${C_YELLOW}⚠${C_RESET} %s\n" "$*" >&2; }
55
- error() { printf "${C_RED}✖${C_RESET} %s\n" "$*" >&2; }
56
- step() { printf "${C_BOLD}[%s/%s]${C_RESET} %s\n" "$1" "$2" "$3"; }
57
- header() { printf "\n${C_BOLD}═══ %s ═══${C_RESET}\n\n" "$*"; }
54
+ info() { printf "${C_CYAN}►${C_RESET} %s\n" "$*"; }
55
+ success() { printf "${C_GREEN}★${C_RESET} %s\n" "$*"; }
56
+ warn() { printf "${C_YELLOW}▲${C_RESET} %s\n" "$*" >&2; }
57
+ error() { printf "${C_RED}[X]${C_RESET} %s\n" "$*" >&2; }
58
+ step() { printf "${C_MAGENTA}[LVL %s/%s]${C_RESET} %s\n" "$1" "$2" "$3"; }
59
+ header() {
60
+ printf "\n${C_MAGENTA}▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄${C_RESET}\n"
61
+ printf "${C_MAGENTA}█${C_RESET} ${C_BOLD}%-35s${C_RESET} ${C_MAGENTA}█${C_RESET}\n" " $1 "
62
+ printf "${C_MAGENTA}▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀${C_RESET}\n\n"
63
+ }
58
64
 
59
65
  # =============================================================================
60
66
  # Argument parsing
@@ -310,7 +316,7 @@ detect_agents() {
310
316
  info "Detected $detected_count agent(s):"
311
317
  for i in "${!AGENT_IDS[@]}"; do
312
318
  if [ "${AGENT_DETECTED[$i]}" = "true" ]; then
313
- printf " ${C_GREEN}●${C_RESET} %-15s ${C_DIM}(%s)${C_RESET}\n" "${AGENT_LABELS[$i]}" "${AGENT_REASONS[$i]}"
319
+ printf " ${C_GREEN}■${C_RESET} %-15s ${C_DIM}(%s)${C_RESET}\n" "${AGENT_LABELS[$i]}" "${AGENT_REASONS[$i]}"
314
320
  fi
315
321
  done
316
322
  fi
@@ -765,7 +771,7 @@ print_summary() {
765
771
  method="$(echo "$entry" | cut -d: -f2)"
766
772
  local target_dir
767
773
  target_dir="$(get_target_dir "$agent_id")"
768
- printf " ${C_GREEN}●${C_RESET} %-15s → %s ${C_DIM}(%s)${C_RESET}\n" "$agent_id" "$target_dir" "$method"
774
+ printf " ${C_GREEN}■${C_RESET} %-15s → %s ${C_DIM}(%s)${C_RESET}\n" "$agent_id" "$target_dir" "$method"
769
775
  done
770
776
  fi
771
777
 
@@ -773,7 +779,7 @@ print_summary() {
773
779
  echo ""
774
780
  echo " Errors:"
775
781
  for entry in "${INSTALL_ERRORS[@]}"; do
776
- printf " ${C_RED}●${C_RESET} %s\n" "$entry"
782
+ printf " ${C_RED}■${C_RESET} %s\n" "$entry"
777
783
  done
778
784
  fi
779
785
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@adityaaria/spark",
3
- "version": "6.0.16",
3
+ "version": "6.0.18",
4
4
  "description": "SPARK skills and runtime bootstrap for coding agents",
5
5
  "type": "module",
6
6
  "publishConfig": {
@@ -0,0 +1,30 @@
1
+ ---
2
+ name: audit
3
+ description: Use to audit code quality, architecture, and security against the project's documented anti-patterns and standards.
4
+ ---
5
+
6
+ # Audit (Meta-Skill)
7
+
8
+ ## Overview
9
+
10
+ Use this skill to orchestrate a rigorous code review or architecture audit. You must NOT evaluate the code based on generic AI preferences or external "best practices" unless they align with the project's established rules. Your sole source of truth for the audit is the local knowledge base.
11
+
12
+ **Announce at start:** "spark detection 💥 Using audit meta-skill to enforce project standards"
13
+
14
+ ## Standard Operating Procedure (SOP)
15
+
16
+ You MUST execute this checklist strictly in order. Do not skip steps.
17
+
18
+ ### Phase 1: Context Grounding
19
+ - `[ ]` **Step 1:** Read the local knowledge base located in `.docs/` (generated by the `project-scanner` skill). Focus heavily on `STANDARDS.md`, API contracts, and the list of Legacy Traps / Anti-patterns.
20
+ - `[ ]` **Step 2:** Identify the exact boundaries of the code to be audited (e.g., a specific Pull Request, a newly written module, or a suspected legacy file).
21
+
22
+ ### Phase 2: Tactical Delegation (Review)
23
+ - `[ ]` **Step 3:** Invoke the `receiving-code-review` (or `requesting-code-review` depending on your role) skill to structure your feedback.
24
+ - `[ ]` **Step 4:** Compare the target code strictly against the Legacy Traps found in Phase 1. Actively flag any re-introduction of:
25
+ - Business logic leaks.
26
+ - Raw SQL/ORM mixing or N+1 queries.
27
+ - Undocumented bypass comments (`@ts-ignore`, `// HACK`).
28
+
29
+ ### Phase 3: Reporting
30
+ - `[ ]` **Step 5:** Output an Audit Report summarizing the violations. If the code is clean, explicitly state that it complies with the `.docs/` standards.
@@ -0,0 +1,30 @@
1
+ ---
2
+ name: bug-fix
3
+ description: Use to fix a bug while adhering strictly to the project's established standards and debugging protocols.
4
+ ---
5
+
6
+ # Bug Fix (Meta-Skill)
7
+
8
+ ## Overview
9
+
10
+ Use this skill to orchestrate a safe, standard-compliant bug fix. You are not allowed to blindly modify code based on assumptions. You must first ground yourself in the project's context, trace the bug systematically, and execute the fix using disciplined test-driven practices.
11
+
12
+ **Announce at start:** "spark detection 💥 Using bug-fix meta-skill to coordinate this investigation"
13
+
14
+ ## Standard Operating Procedure (SOP)
15
+
16
+ You MUST execute this checklist strictly in order. Do not skip steps.
17
+
18
+ ### Phase 1: Context Grounding
19
+ Before touching any code, you must understand the rules of this repository.
20
+ - `[ ]` **Step 1:** Read the local knowledge base located in `.docs/` (generated by the `project-scanner` skill). Specifically, look for `PROJECT_SCAN.md`, `STANDARDS.md`, and `API_CONTRACT.md`.
21
+ - `[ ]` **Step 2:** Identify any Legacy Traps or Anti-Patterns documented in `.docs/`. You must NOT re-introduce these patterns while fixing the bug.
22
+
23
+ ### Phase 2: Tactical Delegation (Investigation)
24
+ Do not guess the root cause. Delegate the investigation.
25
+ - `[ ]` **Step 3:** Invoke the `systematic-debugging` skill. Follow its rigorous condition-based waiting and root-cause tracing protocols to find exactly what is broken.
26
+ - `[ ]` *(Optional)*: If the bug spans multiple independent services, invoke `dispatching-parallel-agents` to investigate them concurrently.
27
+
28
+ ### Phase 3: Execution
29
+ Once the root cause is proven (not guessed), fix it safely.
30
+ - `[ ]` **Step 4:** Invoke the `test-driven-development` skill. Write a failing test that reproduces the bug, then implement the minimal code required to make it pass. Ensure your fix aligns with the architecture rules read in Phase 1.
@@ -0,0 +1,28 @@
1
+ ---
2
+ name: enhancement
3
+ description: Use to build a new feature or enhancement by aligning strictly with the project's existing business flow and domain architecture.
4
+ ---
5
+
6
+ # Enhancement (Meta-Skill)
7
+
8
+ ## Overview
9
+
10
+ Use this skill to orchestrate the safe addition of new features. Do not inject your own architectural preferences. You must ground yourself in the project's reality, scope the feature thoughtfully, plan it out, and execute it using the project's established conventions.
11
+
12
+ **Announce at start:** "spark detection 💥 Using enhancement meta-skill to coordinate feature development"
13
+
14
+ ## Standard Operating Procedure (SOP)
15
+
16
+ You MUST execute this checklist strictly in order. Do not skip steps.
17
+
18
+ ### Phase 1: Context Grounding
19
+ - `[ ]` **Step 1:** Read the local knowledge base located in `.docs/` (generated by the `project-scanner` skill). Focus heavily on `BUSINESS_FLOW.md` and `DOMAINS/`.
20
+ - `[ ]` **Step 2:** Determine which existing Domain will own this new feature, or if a completely new Domain is justified. Ensure your design respects the existing boundaries.
21
+
22
+ ### Phase 2: Tactical Delegation (Scoping & Planning)
23
+ - `[ ]` **Step 3:** Invoke the `brainstorming` skill to map out edge cases, UX flows, and failure modes for this enhancement.
24
+ - `[ ]` **Step 4:** Invoke the `writing-plans` skill to create a step-by-step implementation plan (saving to `docs/spark/plans/`). The plan MUST adhere to the standards found in Phase 1.
25
+
26
+ ### Phase 3: Execution
27
+ - `[ ]` **Step 5:** Invoke the `executing-plans` skill to write the code.
28
+ - `[ ]` *(Optional)*: If the enhancement is massive (e.g., touching frontend UI, backend API, and database migrations simultaneously), invoke `dispatching-parallel-agents` to delegate the sub-tasks to specialized subagents.
@@ -0,0 +1,59 @@
1
+ ---
2
+ name: project-scanner
3
+ description: Use when analyzing an undocumented, legacy, or new project repository to extract its architectural and operational DNA.
4
+ ---
5
+
6
+ # Project Scanner
7
+
8
+ ## Overview
9
+
10
+ Use this skill to scan and document a codebase's architecture, operational rules, and hidden legacy traps. You must rely on file reading and listing tools rather than making assumptions. Traverse the root directory and key source directories to extract the project's DNA. This skill is polyglot—it applies to any tech stack (e.g., TypeScript, Go, Python, Java, PHP, Rust).
11
+
12
+ **Announce at start:** "spark detection 💥 Using project-scanner to analyze repository DNA"
13
+
14
+ **Save findings to:** The `.docs/` directory. Create it if it does not exist. For large projects, break down the documentation logically (e.g., `.docs/PROJECT_SCAN.md`, `.docs/API_CONTRACT.md`, `.docs/DOMAINS/`) instead of creating one massive monolithic file.
15
+
16
+ ## Handling Massive Codebases (Subagent Delegation)
17
+ If the repository is extremely large and analyzing all four pillars sequentially risks exceeding context limits or taking too long:
18
+ - Invoke the `dispatching-parallel-agents` skill.
19
+ - Delegate specific analytical tasks to specialized subagents in parallel (e.g., Subagent A extracts the API Contract, Subagent B extracts the Business Flow).
20
+ - Compile their findings into the final `.docs/` reports.
21
+
22
+ ## Target Extraction Artifacts
23
+
24
+ Your final analysis must thoroughly document these four pillars:
25
+
26
+ ### 1. API CONTRACT
27
+ Identify how the application communicates internally and externally.
28
+ - **Priority Target:** Actively search for Swagger (`swagger.yaml`, `swagger.json`) or OpenAPI specifications. These are the single source of truth for the API contract.
29
+ - **Secondary Targets:** Discover REST/GraphQL endpoints, gRPC protos, ORM schemas, Data Transfer Objects (DTOs), and core data models.
30
+ - **Legacy Traps:** Flag any endpoints that violate current conventions or bypass standard authentication/validation layers.
31
+
32
+ ### 2. WORKFLOW
33
+ Identify how the project is built, run, tested, and deployed.
34
+ - **Targets:** CI/CD pipelines (e.g., `.github/workflows`, `.gitlab-ci.yml`), build scripts (Makefiles, Gradle, NPM scripts), Dockerfiles, and deployment scripts.
35
+ - **Testing:** Identify the test framework, strategy (Unit, Integration, E2E), and explicitly highlight critical areas that lack test coverage.
36
+
37
+ ### 3. BUSINESS FLOW & DOMAINS
38
+ Identify the core business logic and user journeys.
39
+ - **Targets:** Core domains, domain services, use cases, and state machines.
40
+ - **Domain Mapping:** Draft a list of business domains (e.g., Auth, Checkout, Inventory). Note their complexity, risk level, and the specific modules/packages that own them. Avoid forcing a domain split if the project is small.
41
+
42
+ ### 4. STANDARDS & ANTI-PATTERNS
43
+ Identify conventions, rules, and technical debt enforced or found in the codebase.
44
+ - **Targets:** Code styling conventions, linting rules, architectural patterns (e.g., MVC, Hexagonal, Clean Architecture).
45
+ - **Anti-Pattern Detection (CRITICAL):** Actively search for and document legacy traps:
46
+ - Business logic leaked into controllers, presentation, or routing layers.
47
+ - Inconsistent database queries (e.g., raw queries mixed with ORM) or N+1 query problems.
48
+ - Misleading naming (e.g., `Utils` files containing heavy domain logic).
49
+ - Hardcoded external URLs, API keys, or magic numbers.
50
+ - Bypass comments (e.g., `@ts-ignore`, `// HACK`, `// FIXME`, `#nosec`) without explanations.
51
+ - Duplicated logic across modules.
52
+
53
+ ## Execution Checklist
54
+
55
+ - `[ ]` **Step 1:** Announce skill usage exactly as required.
56
+ - `[ ]` **Step 2:** Scan root configuration files and prioritize searching for Swagger/OpenAPI specifications.
57
+ - `[ ]` **Step 3:** Scan source directory structures to infer the language, framework, and architectural patterns.
58
+ - `[ ]` **Step 4:** Analyze testing frameworks, CI/CD workflows, and actively hunt for anti-patterns and legacy traps.
59
+ - `[ ]` **Step 5:** Write the comprehensive report(s) into the `.docs/` directory.
@@ -49,6 +49,10 @@ Skills speak in actions ("dispatch a subagent", "create a todo", "read a file")
49
49
 
50
50
  **Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.
51
51
 
52
+ ## Announcement Format
53
+ When you invoke a skill, you MUST announce it to the developer using exactly this format as the very first thing you say:
54
+ `spark detection 💥 Using [skill] to [purpose]`
55
+
52
56
  ```dot
53
57
  digraph skill_flow {
54
58
  "User message received" [shape=doublecircle];
@@ -57,7 +61,7 @@ digraph skill_flow {
57
61
  "Invoke brainstorming skill" [shape=box];
58
62
  "Might any skill apply?" [shape=diamond];
59
63
  "Invoke the skill" [shape=box];
60
- "Announce: 'Using [skill] to [purpose]'" [shape=box];
64
+ "Announce: 'spark detection 💥 Using [skill]...'" [shape=box];
61
65
  "Has checklist?" [shape=diamond];
62
66
  "Create a todo per item" [shape=box];
63
67
  "Follow skill exactly" [shape=box];
@@ -71,8 +75,8 @@ digraph skill_flow {
71
75
  "User message received" -> "Might any skill apply?";
72
76
  "Might any skill apply?" -> "Invoke the skill" [label="yes, even 1%"];
73
77
  "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
74
- "Invoke the skill" -> "Announce: 'Using [skill] to [purpose]'";
75
- "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
78
+ "Invoke the skill" -> "Announce: 'spark detection 💥 Using [skill]...'";
79
+ "Announce: 'spark detection 💥 Using [skill]...'" -> "Has checklist?";
76
80
  "Has checklist?" -> "Create a todo per item" [label="yes"];
77
81
  "Has checklist?" -> "Follow skill exactly" [label="no"];
78
82
  "Create a todo per item" -> "Follow skill exactly";