@adityaaria/spark 6.0.17 → 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.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@adityaaria/spark",
3
- "version": "6.0.17",
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.