@jhm1909/ag-kit 0.1.0

package/.agent/skills/prompt-engineer/SKILL.md

@@ -0,0 +1,319 @@
+---
+name: prompt-engineer
+description: >
+  prompt-engineer skill for AI-powered development.
+license: MIT
+compatibility: Claude Code, Cursor, Gemini CLI, GitHub Copilot
+metadata:
+  author: jhm1909
+  version: "2.0.0"
+  domain: ai
+  estimated_tokens: 25000
+---
+
+# Prompt Engineer
+
+Designing effective prompts and agent skills for AI-driven development.
+
+## Knowledge Graph
+
+- **extends**: [[ai-engineer]]
+- **suggests**: [[frontend-developer]], [[backend-developer]]
+- **enhances**: [[project-manager]], [[lead-architect]]
+- **moc**: [[ai-development-moc]]
+
+## Sub-capabilities
+
+| Capability | Location | Use For |
+|:-----------|:---------|:--------|
+| Skill Creator | `skill-creator/` | Authoring new skills for the framework |
+| Prompt Templates | `references/prompt-templates.md` | Reusable prompt patterns |
+
+## Using Sub-capabilities
+
+When asked to create a new skill:
+
+1. Load `skill-creator/README.md` from this skill directory
+2. Follow the SKILL.md v2 specification
+3. Use provided templates and examples
+4. Validate against graph requirements
+
+Example workflow:
+```
+User: "Create a skill for Stripe payment integration"
+→ Load prompt-engineer/skill-creator/README.md
+→ Apply SKILL.md v2 template
+→ Define Knowledge Graph relationships
+→ Generate skill files
+```
+
+## Role Definition
+
+You are a **Prompt Engineer** specializing in:
+- Crafting precise, actionable prompts for AI agents
+- Designing SKILL.md files following Anti-Chaotic v2 specification
+- Optimizing context windows through skill graph architecture
+- Creating reusable prompt templates and workflows
+
+## Core Principles
+
+### 1. Clarity Over Cleverness
+- **Be explicit**: State exactly what you want
+- **Use examples**: Show, don't just tell
+- **Avoid ambiguity**: One interpretation only
+
+### 2. Context Budget Awareness
+```
+Total Context Window
+├── System Instructions (skill loading)
+├── Conversation History
+├── Current Request
+└── Output Buffer (leave 20%)
+```
+
+### 3. Progressive Disclosure
+- Load base skills first
+- Add capabilities as needed
+- Suggest enhancements contextually
+
+## SKILL.md v2 Authoring
+
+### Required Structure
+
+```markdown
+---
+name: skill-name
+type: skill | capability | moc
+domain: web | mobile | ai | infra
+status: stable | draft | deprecated
+version: "2.0.0"
+estimated_tokens: 15000
+---
+
+# Skill Title
+
+Clear description of what this skill enables.
+
+## Knowledge Graph
+
+- **extends**: [[parent-skill]] — Why this inheritance
+- **requires**: [[hard-dep]] — Cannot function without
+- **suggests**: [[optional-1]], [[optional-2]] — Nice to have
+- **conflicts**: [[incompatible]] — Mutual exclusion
+- **enhances**: [[base-skill]] — Add-on capability
+- **moc**: [[domain-moc]] — Domain membership
+
+## Triggers (Optional)
+
+Auto-detection patterns:
+- pattern: "regex" → confidence: high/medium/low
+- file: "filename.ext" → confidence: high
+
+## Core Content
+
+### Rules / Guidelines / Patterns
+1. **Bold key terms** — Make them scannable
+2. Use tables for comparisons
+3. Code examples for patterns
+
+## Related Skills
+
+- [[related-skill]] — Why related
+```
+
+### Relationship Design
+
+| Relationship | When to Use | Example |
+|:-------------|:------------|:--------|
+| `extends` | Specialization inherits all patterns | `react-nextjs` extends `frontend-developer` |
+| `requires` | Hard dependency | `ai-engineer` requires `backend-developer` |
+| `suggests` | Optional enhancement | `react-nextjs` suggests `threejs` |
+| `conflicts` | Mutual exclusion | `vue-developer` conflicts `react-nextjs` |
+| `enhances` | Capability add-on | `tailwind-setup` enhances any frontend |
+
+### Common Mistakes
+
+❌ **Vague descriptions**
+```markdown
+## Core Rules
+1. Write clean code
+```
+
+✅ **Specific, actionable rules**
+```markdown
+## Core Rules
+1. **Use Server Components by default** — Only add 'use client' when interactivity required
+2. **File naming**: kebab-case for all files, PascalCase for components
+```
+
+❌ **Missing context estimates**
+```yaml
+# No estimated_tokens
+---
+name: my-skill
+type: skill
+---
+```
+
+✅ **Always include token budget**
+```yaml
+---
+name: my-skill
+type: skill
+estimated_tokens: 12000  # Helps users plan context
+---
+```
+
+❌ **Human learning timelines in MOCs**
+```markdown
+## Learning Path
+Week 1-2: Learn basics
+Week 3-4: Advanced topics
+```
+
+✅ **Agent load orders with context**
+```markdown
+## Load Order
+[[foundation]]          (~2k tokens)
+    ↓ extends
+[[specialization]]      (~1k tokens)
+    ↓ suggests
+[[capability]]          (~0.5k tokens)
+───────────────────────────────
+Total: ~3.5k tokens
+```
+
+## Prompt Patterns
+
+### Pattern 1: Structured Output
+
+```markdown
+## Request Format
+
+**Task**: {clear description}
+
+**Context**:
+- Current state: {what exists}
+- Constraints: {limitations}
+- Goals: {desired outcome}
+
+**Output Format**:
+```yaml
+result:
+  summary: "brief description"
+  files:
+    - path: "relative/path"
+      content: "..."
+  next_steps:
+    - "action item"
+```
+```
+
+### Pattern 2: Chain-of-Thought
+
+```markdown
+## Reasoning Process
+
+Before responding, analyze:
+1. What is the core problem?
+2. What constraints apply?
+3. What patterns are relevant?
+4. What could go wrong?
+5. What is the minimal viable solution?
+
+Then proceed with implementation.
+```
+
+### Pattern 3: Few-Shot Examples
+
+```markdown
+## Examples
+
+### Example 1: Simple Case
+Input: {simple input}
+Output: {expected output}
+
+### Example 2: Edge Case
+Input: {complex input}
+Output: {expected output}
+
+### Example 3: Error Handling
+Input: {invalid input}
+Output: {error message + correction}
+```
+
+## Context Optimization
+
+### Token Budgeting
+
+| Skill Size | Tokens | Use Case |
+|:-----------|:-------|:---------|
+| Minimal | 1-3k | Simple utilities |
+| Standard | 5-10k | Core skills |
+| Comprehensive | 15-25k | Complex domains |
+| Reference | 30k+ | Documentation, API specs |
+
+### Graph Depth Guidelines
+
+```
+Max Recommended Chain Length: 3-4 skills
+
+Good:
+[[frontend]] → [[react]] → [[nextjs]]
+
+Too Deep:
+[[frontend]] → [[react]] → [[nextjs]] → [[app-router]] → [[rsc-patterns]] → [[streaming]]
+```
+
+### Conflict Resolution
+
+When designing `conflicts`:
+1. Must be **bidirectional** (A conflicts B → B conflicts A)
+2. Explain **why** in description
+3. Suggest **alternative** if possible
+
+```markdown
+## Knowledge Graph
+- **conflicts**: [[vue-developer]] — Different component patterns, choose one framework
+  - Alternative: Use [[frontend-developer]] base if undecided
+```
+
+## Skill Testing Checklist
+
+Before publishing a skill:
+
+- [ ] Frontmatter complete (name, type, domain, version, estimated_tokens)
+- [ ] Knowledge Graph section with valid relationships
+- [ ] All wiki-links resolve to existing skills
+- [ ] No circular dependencies in graph
+- [ ] Conflicts are bidirectional
+- [ ] Token estimate is accurate (±20%)
+- [ ] Examples are runnable/testable
+- [ ] No human learning timelines (unless educational skill)
+
+## Anti-Patterns
+
+### 1. Prompt Injection Vulnerabilities
+❌ Don't use: `User input: {{user_input}}` without validation
+✅ Do: Define allowed values, validate patterns
+
+### 2. Context Leaks
+❌ Don't: Load unrelated skills "just in case"
+✅ Do: Use `suggests` for optional capabilities
+
+### 3. Over-Specialization
+❌ Don't: Create skill for every micro-task
+✅ Do: Group related capabilities, use `extends` for variations
+
+### 4. Implicit Assumptions
+❌ Don't: Assume user knows jargon
+✅ Do: Define terms, link to explanations
+
+## Related Skills
+
+- [[ai-engineer]] — LLM integration patterns
+- [[backend-developer]] — API development for AI services
+
+---
+
+*Part of [[ai-development-moc]] | Skill creator guide in `skill-creator/` sub-directory*

package/.agent/skills/prompt-engineer/skill-creator/README.md

@@ -0,0 +1,47 @@
+---
+name: skill-creator
+type: skill
+domain: general
+status: draft
+version: "1.0.0"
+estimated_tokens: 10000
+description: Creating and publishing skills for the Anti-Chaotic Agent Kit.
+---
+
+# Skill Creator
+
+Building and publishing agent skills.
+
+## Knowledge Graph
+
+- **extends**: []
+- **requires": [[prompt-engineer]]
+- **suggests": []
+- **conflicts": []
+- **enhances": [[knowledge-graph]]
+- **moc**: []
+
+## Overview
+
+This skill covers:
+- SKILL.md v2 specification
+- Knowledge graph design
+- Publishing to npm/GitHub
+- Testing and validation
+
+## Creating a Skill
+
+1. Define relationships (extends/requires/suggests)
+2. Write SKILL.md with frontmatter
+3. Add rules/workflows if needed
+4. Test with graph resolver
+5. Publish
+
+## Related
+
+- [[prompt-engineer]] — Prompt design
+- [[knowledge-graph]] — Graph validation
+
+---
+
+*Meta skill for skill development*

package/.agent/skills/qa-tester/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: qa-tester
+description: >
+  Test planning, test cases, bug reporting, automation, and security auditing.
+  Use for Unit/E2E/Security/Performance/Property-Based testing and supply chain audits.
+  Upgraded with Trail of Bits security methodology.
+license: MIT
+compatibility: Claude Code, Cursor, Gemini CLI, GitHub Copilot
+metadata:
+  author: jhm1909
+  version: "3.0.0"
+  domain: qa
+  estimated_tokens: 12000
+  sources:
+    - trailofbits/skills (insecure-defaults, sharp-edges, property-based-testing, supply-chain-risk-auditor, semgrep)
+---
+
+# QA Tester
+
+Comprehensive testing + security auditing for high-quality software delivery.
+
+## Knowledge Graph
+
+- **extends**: []
+- **requires**: []
+- **suggests**: [[frontend-developer]], [[backend-developer]], [[devops-engineer]], [[mobile-developer]]
+- **conflicts**: []
+- **enhances**: [[project-manager]] (quality metrics), [[business-analysis]] (acceptance criteria), [[code-review]] (verification gates)
+- **moc**: [[quality-assurance-moc]]
+
+## Core Philosophy
+
+1. **Docs First** — Base all testing on `docs/` folder requirements
+2. **No Assumptions** — Missing docs? STOP and CONFIRM with user
+3. **Verify Everything** — Happy path, negative path, boundaries, edges
+4. **Trust No Input** — Every input is a potential attack vector
+5. **Pit of Success** — Secure usage should be the path of least resistance
+
+## Decision Tree
+
+```
+What testing is needed?
+│
+├─ Functional testing?
+│  └─ Read: test_case_standards.md, unit_testing.md, e2e_testing.md
+│
+├─ Security audit?
+│  ├─ Insecure defaults/hardcoded secrets? → Read: security_audit.md
+│  ├─ API footgun analysis? → Read: sharp_edges.md
+│  ├─ Dependency risk? → Read: supply_chain_audit.md
+│  └─ Static analysis scan? → Read: static_analysis.md
+│
+├─ Property-based testing?
+│  └─ Read: property_based_testing.md
+│
+└─ Performance testing?
+   └─ Read: performance_testing.md
+```
+
+## Test Types
+
+| Type | Focus | Tool Examples |
+|:-----|:------|:-------------|
+| **Unit** | Logic verification | Jest, Vitest |
+| **Integration** | Module handshake | Supertest, MSW |
+| **E2E** | User flows | Playwright, Cypress |
+| **Security** | Vulnerabilities | Semgrep, OWASP ZAP |
+| **Performance** | Load, responsiveness | k6, Lighthouse |
+| **Property-Based** | Invariants, roundtrips | Hypothesis, fast-check |
+| **Supply Chain** | Dependency risk | gh CLI, npm audit |
+| **Visual** | UI regression | Chromatic, Percy |
+| **Accessibility** | WCAG compliance | axe, Pa11y |
+
+## Test Design Techniques
+
+### Noun-Verb Extraction
+Scan docs for **Nouns** (User, Order) and **Verbs** (Register, Checkout)
+→ Each Action = At least 1 Test Case
+
+### Keyword Permutations
+Look for "MUST", "CANNOT", "ONLY IF"
+→ Test constraint met AND violated
+
+### State Transition Mapping
+Entity states (Pending → Paid → Shipped)
+→ Test valid AND invalid transitions
+
+### Property Detection (PBT)
+| Pattern | Property | Priority |
+|---------|----------|----------|
+| encode/decode pair | Roundtrip | HIGH |
+| Normalization | Idempotence | MEDIUM |
+| Sorting/ordering | Idempotence + ordering | MEDIUM |
+| Pure function | Multiple | HIGH |
+
+## Security Audit Quick Checklist
+
+When auditing code security, check:
+
+- [ ] **Insecure defaults**: `env.get(X) or 'fallback'` — fail-open patterns
+- [ ] **Hardcoded secrets**: `password = "..."`, `API_KEY = "..."`
+- [ ] **Weak crypto**: MD5, SHA1, DES, RC4, ECB in security contexts
+- [ ] **Permissive CORS**: `Access-Control-Allow-Origin: *`
+- [ ] **Debug in prod**: `DEBUG = True`, stack traces exposed
+- [ ] **Sharp edges**: APIs where easy path leads to insecurity
+- [ ] **Supply chain**: Single-maintainer deps, stale packages, CVE history
+
+## Coverage Requirements
+
+- ✅ **Happy Path** — Golden flow
+- ✅ **Negative Path** — Error handling
+- ✅ **Boundary** — Off-by-one (0, 1, Max)
+- ✅ **Edge Cases** — Timeouts, failures, concurrency
+- ✅ **Integration** — Cross-module flows
+- ✅ **Security** — Injection, auth bypass, data leaks
+
+## References
+
+| Reference | Purpose |
+|:----------|:--------|
+| `test_case_standards.md` | "No Ambiguity" philosophy |
+| `unit_testing.md` | "Test Behavior, Not Implementation" |
+| `integration_testing.md` | "Verify the Handshake" |
+| `e2e_testing.md` | "Simulate the Real User" |
+| `security_testing.md` | "Trust No Input" |
+| `performance_testing.md` | "Performance is a Feature" |
+| `security_audit.md` | Insecure defaults detection (Trail of Bits) |
+| `sharp_edges.md` | API footgun analysis (Trail of Bits) |
+| `property_based_testing.md` | PBT methodology (Trail of Bits) |
+| `supply_chain_audit.md` | Dependency risk scoring (Trail of Bits) |
+| `static_analysis.md` | Semgrep scanning workflow (Trail of Bits) |
+
+## Related Skills
+
+- [[frontend-developer]] — Component testing
+- [[backend-developer]] — API testing
+- [[code-review]] — Security-focused PR review
+- [[project-manager]] — Quality metrics, UAT
+
+---
+
+*Quality assurance + Security auditing | Trail of Bits methodology integrated*

package/.agent/skills/qa-tester/assets/README.md

@@ -0,0 +1,8 @@
+# Asset Placeholder
+
+Replace with actual assets (templates, images, fonts, etc.) or delete this file.
+
+Common asset types:
+- Templates: .pptx, .docx, boilerplate directories
+- Images: .png, .jpg, .svg
+- Data: .csv, .json, .yaml

package/.agent/skills/qa-tester/references/accessibility_testing.md

@@ -0,0 +1,35 @@
+# Accessibility (A11y) Testing Guide
+
+> **Optional Module**: Consult this guide when accessibility compliance (WCAG) is required.
+
+## Core Tools
+
+- **axe-core**: The engine for finding accessibility defects.
+- **jest-axe**: For unit/integration level checks.
+- **cypress-axe** / **@axe-core/playwright**: For E2E injection.
+
+## Implementation Pattern (Playwright)
+
+```typescript
+import { test, expect } from "@playwright/test";
+import AxeBuilder from "@axe-core/playwright";
+
+test("landing page should not have any automatically detectable accessibility issues", async ({
+  page,
+}) => {
+  await page.goto("/");
+
+  const accessibilityScanResults = await new AxeBuilder({ page })
+    .withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa"])
+    .analyze();
+
+  expect(accessibilityScanResults.violations).toEqual([]);
+});
+```
+
+## Common Violations to Watch
+
+1. **Color Contrast**: Text vs Background ratio must be at least 4.5:1.
+2. **Alt Text**: All non-decorative images must have `alt` attributes.
+3. **Labels**: Form inputs must have implicit or explicit `<label>` or `aria-label`.
+4. **Interactive Roles**: Divs behaving like buttons must have `role="button"` and keyboard handlers.

package/.agent/skills/qa-tester/references/agent_browser.md

@@ -0,0 +1,38 @@
+# Agent Browser / Human Simulation Guide
+
+The **Browser Subagent** allows you to interact with the web application just like a human user. This is powerful for **Exploratory Testing**, **Visual Verification**, and **Complex Flow Validation** that is hard to script blindly.
+
+## When to Use
+
+| Use Case            | Tool                 | Why?                                            |
+| :------------------ | :------------------- | :---------------------------------------------- |
+| **Regression / CI** | Playwright (Code)    | Fast, deterministic, repeatable.                |
+| **Exploratory**     | **Browser Subagent** | "Try to break this," "See if this feels right." |
+| **Visual Check**    | **Browser Subagent** | "Does the modal overlap the header?"            |
+| **Debugging**       | **Browser Subagent** | "Go to the failed page and inspect the DOM."    |
+
+## How to Use
+
+When you need to "see" or "act" as a human:
+
+1.  **Call the Tool**: Use `browser_subagent` with a clear `Task`.
+2.  **Be Specific**: Give the subagent a persona and a goal.
+
+### Example Prompts
+
+**Scenario: verifying a login flow manually**
+
+> "Open `local.dev:3000/login`, enter username 'admin' and password 'secret', and verify that the dashboard loads and the 'Welcome Admin' toast appears."
+
+**Scenario: Exploratory "Monkey Testing"**
+
+> "Go to the Checkout page. Try clicking on 'Place Order' without filling any fields. Then try filling invalid emails. Report what validation errors you see."
+
+## Best Practices
+
+1.  **State the Goal**: Start with "Navigate to..." and end with "Verify that..."
+2.  **Define Success**: Tell the subagent what "success" looks like (e.g., "URL changes to /dashboard").
+3.  **Capture Evidence**: The subagent records sessions. Use these as proof of verification for your reports.
+4.  **Hybrid Approach**:
+    - Use the Browser Subagent to **learn** the valid selectors and flow.
+    - Use that knowledge to **write** the robust Playwright script.

package/.agent/skills/qa-tester/references/automation/api_testing.md

@@ -0,0 +1,23 @@
+# API Automation Guide (Supertest/Fetch)
+
+Test the contract, status codes, and payload schemas.
+
+## Implementation Pattern
+
+```typescript
+it("POST /api/orders returns 201 and created order", async () => {
+  const response = await request(app)
+    .post("/api/orders")
+    .send({ productId: "123", quantity: 1 });
+
+  expect(response.status).toBe(201);
+  expect(response.body).toHaveProperty("id");
+  expect(response.body.status).toBe("created");
+});
+```
+
+## Checklist
+
+- [ ] **Status Codes**: 2xx for success, 4xx for client error, 5xx for server error.
+- [ ] **Schema Validation**: Ensure response structure matches openapi/swagger spec.
+- [ ] **Auth Checks**: Verify 401/403 for unauthorized/forbidden access.

package/.agent/skills/qa-tester/references/automation/best_practices.md

@@ -0,0 +1,14 @@
+# Automation Best Practices
+
+## Self-Healing & Resilience
+
+- **Dynamic Waiting**: Never use fixed delays like `sleep(1000)`. Use assertion-based waiting (e.g., `findBy`, `waitFor`).
+- **Resilient Selectors**:
+  - ❌ Avoid: `div > div > button.red`
+  - ✅ Prefer: `role="button"` or `data-testid="submit-order"`
+- **TestIDs**: Enforce a strict `data-testid` policy for elements that lack semantic roles.
+
+## Flakiness Prevention
+
+- **Isolation**: Each test must create its own data and clean it up.
+- **Environment**: Do not rely on shared staging environments if possible; mock or use ephemeral DBs.

package/.agent/skills/qa-tester/references/automation/jest_vitest.md

@@ -0,0 +1,26 @@
+# Jest / Vitest Guide
+
+**Core Philosophy**: Isolate logic, integrate flows.
+
+## Implementation Patterns
+
+### Mocking at Boundaries
+
+Mock modules at boundaries (e.g., database clients, mailers) to test logic in isolation.
+
+### Table-Driven Tests
+
+Use `test.each` for covering multiple data inputs efficiently.
+
+```typescript
+// price-calculator.test.ts
+describe("calculateTotal", () => {
+  test.each([
+    [100, 10, 110],
+    [50, 0, 50],
+    [0, 20, 20],
+  ])("given subtotal %i and tax %i, returns %i", (subtotal, tax, expected) => {
+    expect(calculateTotal(subtotal, tax)).toBe(expected);
+  });
+});
+```

package/.agent/skills/qa-tester/references/automation/playwright.md

@@ -0,0 +1,30 @@
+# Playwright Automation Guide
+
+**Golden Rule**: Use resilient locators and the Page Object Model (POM).
+
+## Page Object Model Pattern
+
+```typescript
+// tests/auth.spec.ts
+import { test, expect } from "@playwright/test";
+import { LoginPage } from "./pages/login-page";
+
+test("User can login with valid credentials", async ({ page }) => {
+  const loginPage = new LoginPage(page);
+  await loginPage.goto();
+  await loginPage.login("user@example.com", "password123");
+
+  await expect(page.getByTestId("dashboard-header")).toBeVisible();
+});
+```
+
+## Best Practices
+
+- **Network Boundaries**: Mock external 3rd party APIs (e.g., Stripe, Auth0) during E2E to ensure stability, but keep "Critical User Journey" tests unmocked.
+- **State Setup**: Do not use the UI to seed data. Use API calls in `beforeAll` hooks.
+  ```typescript
+  test.beforeAll(async ({ request }) => {
+    await request.post('/api/seed/user', { data: { ... } });
+  });
+  ```
+- **Dynamic Waiting**: Never use `sleep(1000)`. Use `await expect(...).toBeVisible()` or `waitForResponse()`.