@funnycode/myclaude 0.1.75 → 0.1.77

package/seed/marketplaces/ecc/skills/angular-developer/references/testing-fundamentals.md

@@ -1,65 +1,65 @@
-# Testing Fundamentals
-
-This guide covers the fundamental principles and practices for writing Angular unit and component tests. Use the runner already configured in the project.
-
-## Core Philosophy: Async-First
-
-Modern Angular applications often schedule state changes asynchronously, especially when using signals or zoneless change detection. Tests should account for this.
-
-Prefer the "Act, Wait, Assert" pattern:
-
-1. **Act:** Update state or perform an action (e.g., set a component input, click a button).
-2. **Wait:** Use `await fixture.whenStable()` to allow the framework to process the scheduled update and render the changes.
-3. **Assert:** Verify the outcome.
-
-### Basic Test Structure Example
-
-```ts
-import {ComponentFixture, TestBed} from '@angular/core/testing';
-import {MyComponent} from './my.component';
-
-describe('MyComponent', () => {
-  let component: MyComponent;
-  let fixture: ComponentFixture<MyComponent>;
-  let h1: HTMLElement;
-
-  beforeEach(async () => {
-    // 1. Configure the test module
-    await TestBed.configureTestingModule({
-      imports: [MyComponent],
-    }).compileComponents();
-
-    // 2. Create the component fixture
-    fixture = TestBed.createComponent(MyComponent);
-    component = fixture.componentInstance;
-    h1 = fixture.nativeElement.querySelector('h1');
-  });
-
-  it('should display the default title', async () => {
-    // ACT: (Implicit) Component is created with default state.
-    // WAIT for initial data binding.
-    await fixture.whenStable();
-    // ASSERT the initial state.
-    expect(h1.textContent).toContain('Default Title');
-  });
-
-  it('should display a different title after a change', async () => {
-    // ACT: Change the component's title property.
-    component.title.set('New Test Title');
-
-    // WAIT for the asynchronous update to complete.
-    await fixture.whenStable();
-
-    // ASSERT the DOM has been updated.
-    expect(h1.textContent).toContain('New Test Title');
-  });
-});
-```
-
-## TestBed and ComponentFixture
-
-- **`TestBed`**: The primary utility for creating a test-specific Angular module. Use `TestBed.configureTestingModule({...})` in your `beforeEach` to declare components, provide services, and set up imports needed for your test.
-- **`ComponentFixture`**: A handle on the created component instance and its environment.
-  - `fixture.componentInstance`: Access the component's class instance.
-  - `fixture.nativeElement`: Access the component's root DOM element.
-  - `fixture.debugElement`: An Angular-specific wrapper around the `nativeElement` that provides safer, platform-agnostic ways to query the DOM (e.g., `debugElement.query(By.css('p'))`).
+# Testing Fundamentals
+
+This guide covers the fundamental principles and practices for writing Angular unit and component tests. Use the runner already configured in the project.
+
+## Core Philosophy: Async-First
+
+Modern Angular applications often schedule state changes asynchronously, especially when using signals or zoneless change detection. Tests should account for this.
+
+Prefer the "Act, Wait, Assert" pattern:
+
+1. **Act:** Update state or perform an action (e.g., set a component input, click a button).
+2. **Wait:** Use `await fixture.whenStable()` to allow the framework to process the scheduled update and render the changes.
+3. **Assert:** Verify the outcome.
+
+### Basic Test Structure Example
+
+```ts
+import {ComponentFixture, TestBed} from '@angular/core/testing';
+import {MyComponent} from './my.component';
+
+describe('MyComponent', () => {
+  let component: MyComponent;
+  let fixture: ComponentFixture<MyComponent>;
+  let h1: HTMLElement;
+
+  beforeEach(async () => {
+    // 1. Configure the test module
+    await TestBed.configureTestingModule({
+      imports: [MyComponent],
+    }).compileComponents();
+
+    // 2. Create the component fixture
+    fixture = TestBed.createComponent(MyComponent);
+    component = fixture.componentInstance;
+    h1 = fixture.nativeElement.querySelector('h1');
+  });
+
+  it('should display the default title', async () => {
+    // ACT: (Implicit) Component is created with default state.
+    // WAIT for initial data binding.
+    await fixture.whenStable();
+    // ASSERT the initial state.
+    expect(h1.textContent).toContain('Default Title');
+  });
+
+  it('should display a different title after a change', async () => {
+    // ACT: Change the component's title property.
+    component.title.set('New Test Title');
+
+    // WAIT for the asynchronous update to complete.
+    await fixture.whenStable();
+
+    // ASSERT the DOM has been updated.
+    expect(h1.textContent).toContain('New Test Title');
+  });
+});
+```
+
+## TestBed and ComponentFixture
+
+- **`TestBed`**: The primary utility for creating a test-specific Angular module. Use `TestBed.configureTestingModule({...})` in your `beforeEach` to declare components, provide services, and set up imports needed for your test.
+- **`ComponentFixture`**: A handle on the created component instance and its environment.
+  - `fixture.componentInstance`: Access the component's class instance.
+  - `fixture.nativeElement`: Access the component's root DOM element.
+  - `fixture.debugElement`: An Angular-specific wrapper around the `nativeElement` that provides safer, platform-agnostic ways to query the DOM (e.g., `debugElement.query(By.css('p'))`).

package/seed/marketplaces/ecc/skills/api-connector-builder/SKILL.md

@@ -1,120 +1,120 @@
----
-name: api-connector-builder
-description: Build a new API connector or provider by matching the target repo's existing integration pattern exactly. Use when adding one more integration without inventing a second architecture.
-origin: ECC direct-port adaptation
-version: "1.0.0"
----
-
-# API Connector Builder
-
-Use this when the job is to add a repo-native integration surface, not just a generic HTTP client.
-
-The point is to match the host repository's pattern:
-
-- connector layout
-- config schema
-- auth model
-- error handling
-- test style
-- registration/discovery wiring
-
-## When to Use
-
-- "Build a Jira connector for this project"
-- "Add a Slack provider following the existing pattern"
-- "Create a new integration for this API"
-- "Build a plugin that matches the repo's connector style"
-
-## Guardrails
-
-- do not invent a new integration architecture when the repo already has one
-- do not start from vendor docs alone; start from existing in-repo connectors first
-- do not stop at transport code if the repo expects registry wiring, tests, and docs
-- do not cargo-cult old connectors if the repo has a newer current pattern
-
-## Workflow
-
-### 1. Learn the house style
-
-Inspect at least 2 existing connectors/providers and map:
-
-- file layout
-- abstraction boundaries
-- config model
-- retry / pagination conventions
-- registry hooks
-- test fixtures and naming
-
-### 2. Narrow the target integration
-
-Define only the surface the repo actually needs:
-
-- auth flow
-- key entities
-- core read/write operations
-- pagination and rate limits
-- webhook or polling model
-
-### 3. Build in repo-native layers
-
-Typical slices:
-
-- config/schema
-- client/transport
-- mapping layer
-- connector/provider entrypoint
-- registration
-- tests
-
-### 4. Validate against the source pattern
-
-The new connector should look obvious in the codebase, not imported from a different ecosystem.
-
-## Reference Shapes
-
-### Provider-style
-
-```text
-providers/
-  existing_provider/
-    __init__.py
-    provider.py
-    config.py
-```
-
-### Connector-style
-
-```text
-integrations/
-  existing/
-    client.py
-    models.py
-    connector.py
-```
-
-### TypeScript plugin-style
-
-```text
-src/integrations/
-  existing/
-    index.ts
-    client.ts
-    types.ts
-    test.ts
-```
-
-## Quality Checklist
-
-- [ ] matches an existing in-repo integration pattern
-- [ ] config validation exists
-- [ ] auth and error handling are explicit
-- [ ] pagination/retry behavior follows repo norms
-- [ ] registry/discovery wiring is complete
-- [ ] tests mirror the host repo's style
-- [ ] docs/examples are updated if expected by the repo
-
-## Related Skills
-
-- `backend-patterns`
-- `mcp-server-patterns`
-- `github-ops`
+---
+name: api-connector-builder
+description: Build a new API connector or provider by matching the target repo's existing integration pattern exactly. Use when adding one more integration without inventing a second architecture.
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# API Connector Builder
+
+Use this when the job is to add a repo-native integration surface, not just a generic HTTP client.
+
+The point is to match the host repository's pattern:
+
+- connector layout
+- config schema
+- auth model
+- error handling
+- test style
+- registration/discovery wiring
+
+## When to Use
+
+- "Build a Jira connector for this project"
+- "Add a Slack provider following the existing pattern"
+- "Create a new integration for this API"
+- "Build a plugin that matches the repo's connector style"
+
+## Guardrails
+
+- do not invent a new integration architecture when the repo already has one
+- do not start from vendor docs alone; start from existing in-repo connectors first
+- do not stop at transport code if the repo expects registry wiring, tests, and docs
+- do not cargo-cult old connectors if the repo has a newer current pattern
+
+## Workflow
+
+### 1. Learn the house style
+
+Inspect at least 2 existing connectors/providers and map:
+
+- file layout
+- abstraction boundaries
+- config model
+- retry / pagination conventions
+- registry hooks
+- test fixtures and naming
+
+### 2. Narrow the target integration
+
+Define only the surface the repo actually needs:
+
+- auth flow
+- key entities
+- core read/write operations
+- pagination and rate limits
+- webhook or polling model
+
+### 3. Build in repo-native layers
+
+Typical slices:
+
+- config/schema
+- client/transport
+- mapping layer
+- connector/provider entrypoint
+- registration
+- tests
+
+### 4. Validate against the source pattern
+
+The new connector should look obvious in the codebase, not imported from a different ecosystem.
+
+## Reference Shapes
+
+### Provider-style
+
+```text
+providers/
+  existing_provider/
+    __init__.py
+    provider.py
+    config.py
+```
+
+### Connector-style
+
+```text
+integrations/
+  existing/
+    client.py
+    models.py
+    connector.py
+```
+
+### TypeScript plugin-style
+
+```text
+src/integrations/
+  existing/
+    index.ts
+    client.ts
+    types.ts
+    test.ts
+```
+
+## Quality Checklist
+
+- [ ] matches an existing in-repo integration pattern
+- [ ] config validation exists
+- [ ] auth and error handling are explicit
+- [ ] pagination/retry behavior follows repo norms
+- [ ] registry/discovery wiring is complete
+- [ ] tests mirror the host repo's style
+- [ ] docs/examples are updated if expected by the repo
+
+## Related Skills
+
+- `backend-patterns`
+- `mcp-server-patterns`
+- `github-ops`