autodoc-agent-kit 1.0.0

package/src/modules/productivity/skills/internal-comms/examples/company-newsletter.md

@@ -0,0 +1,65 @@
+## Instructions
+You are being asked to write a company-wide newsletter update. You are meant to summarize the past week/month of a company in the form of a newsletter that the entire company will read. It should be maybe ~20-25 bullet points long. It will be sent via Slack and email, so make it consumable for that.
+
+Ideally it includes the following attributes:
+- Lots of links: pulling documents from Google Drive that are very relevant, linking to prominent Slack messages in announce channels and from executives, perhgaps referencing emails that went company-wide, highlighting significant things that have happened in the company.
+- Short and to-the-point: each bullet should probably be no longer than ~1-2 sentences
+- Use the "we" tense, as you are part of the company. Many of the bullets should say "we did this" or "we did that"
+
+## Tools to use
+If you have access to the following tools, please try to use them. If not, you can also let the user know directly that their responses would be better if they gave them access.
+
+- Slack: look for messages in channels with lots of people, with lots of reactions or lots of responses within the thread
+- Email: look for things from executives that discuss company-wide announcements
+- Calendar: if there were meetings with large attendee lists, particularly things like All-Hands meetings, big company announcements, etc. If there were documents attached to those meetings, those are great links to include.
+- Documents: if there were new docs published in the last week or two that got a lot of attention, you can link them. These should be things like company-wide vision docs, plans for the upcoming quarter or half, things authored by critical executives, etc.
+- External press: if you see references to articles or press we've received over the past week, that could be really cool too.
+
+If you don't have access to any of these things, you can ask the user for things they want to cover. In this case, you'll mostly just be polishing up and fitting to this format more directly.
+
+## Sections
+The company is pretty big: 1000+ people. There are a variety of different teams and initiatives going on across the company. To make sure the update works well, try breaking it into sections of similar things. You might break into clusters like {product development, go to market, finance} or {recruiting, execution, vision}, or {external news, internal news} etc. Try to make sure the different areas of the company are highlighted well.
+
+## Prioritization
+Focus on:
+- Company-wide impact (not team-specific details)
+- Announcements from leadership
+- Major milestones and achievements
+- Information that affects most employees
+- External recognition or press
+
+Avoid:
+- Overly granular team updates (save those for 3Ps)
+- Information only relevant to small groups
+- Duplicate information already communicated
+
+## Example Formats
+
+:megaphone: Company Announcements
+- Announcement 1
+- Announcement 2
+- Announcement 3
+
+:dart: Progress on Priorities
+- Area 1
+    - Sub-area 1
+    - Sub-area 2
+    - Sub-area 3
+- Area 2
+    - Sub-area 1
+    - Sub-area 2
+    - Sub-area 3
+- Area 3
+    - Sub-area 1
+    - Sub-area 2
+    - Sub-area 3
+
+:pillar: Leadership Updates
+- Post 1
+- Post 2
+- Post 3
+
+:thread: Social Updates
+- Update 1
+- Update 2
+- Update 3

package/src/modules/productivity/skills/internal-comms/examples/faq-answers.md

@@ -0,0 +1,30 @@
+## Instructions
+You are an assistant for answering questions that are being asked across the company. Every week, there are lots of questions that get asked across the company, and your goal is to try to summarize what those questions are. We want our company to be well-informed and on the same page, so your job is to produce a set of frequently asked questions that our employees are asking and attempt to answer them. Your singular job is to do two things:
+
+- Find questions that are big sources of confusion for lots of employees at the company, generally about things that affect a large portion of the employee base
+- Attempt to give a nice summarized answer to that question in order to minimize confusion.
+
+Some examples of areas that may be interesting to folks: recent corporate events (fundraising, new executives, etc.), upcoming launches, hiring progress, changes to vision or focus, etc.
+
+
+## Tools Available
+You should use the company's available tools, where communication and work happens. For most companies, it looks something like this:
+- Slack: questions being asked across the company - it could be questions in response to posts with lots of responses, questions being asked with lots of reactions or thumbs up to show support, or anything else to show that a large number of employees want to ask the same things
+- Email: emails with FAQs written directly in them can be a good source as well
+- Documents: docs in places like Google Drive, linked on calendar events, etc. can also be a good source of FAQs, either directly added or inferred based on the contents of the doc
+
+## Formatting
+The formatting should be pretty basic:
+
+- *Question*: [insert question - 1 sentence]
+- *Answer*: [insert answer - 1-2 sentence]
+
+## Guidance
+Make sure you're being holistic in your questions. Don't focus too much on just the user in question or the team they are a part of, but try to capture the entire company. Try to be as holistic as you can in reading all the tools available, producing responses that are relevant to all at the company.
+
+## Answer Guidelines
+- Base answers on official company communications when possible
+- If information is uncertain, indicate that clearly
+- Link to authoritative sources (docs, announcements, emails)
+- Keep tone professional but approachable
+- Flag if a question requires executive input or official response

package/src/modules/productivity/skills/internal-comms/examples/general-comms.md

@@ -0,0 +1,16 @@
+  ## Instructions
+  You are being asked to write internal company communication that doesn't fit into the standard formats (3P
+  updates, newsletters, or FAQs).
+
+  Before proceeding:
+  1. Ask the user about their target audience
+  2. Understand the communication's purpose
+  3. Clarify the desired tone (formal, casual, urgent, informational)
+  4. Confirm any specific formatting requirements
+
+  Use these general principles:
+  - Be clear and concise
+  - Use active voice
+  - Put the most important information first
+  - Include relevant links and references
+  - Match the company's communication style

package/src/modules/productivity/skills/technical-writing/SKILL.md

@@ -0,0 +1,266 @@
+---
+name: technical-writing
+description: Write clear, scannable technical documentation including READMEs, API docs, architecture docs, runbooks, and onboarding guides. Trigger when writing or improving technical documentation, READMEs, or developer guides.
+---
+
+# Technical Writing Guide
+
+Good technical documentation is precise, scannable, and respects the reader's time. It answers the reader's question in the fewest words possible.
+
+## Core Principles
+
+1. **Lead with the answer** — state the conclusion before the explanation
+2. **One idea per sentence** — if you need a semicolon, consider two sentences
+3. **Active voice** — "Click Save" not "The Save button should be clicked"
+4. **Present tense** — "The function returns" not "The function will return"
+5. **Concrete over abstract** — show an example before explaining the concept
+
+## Document Types
+
+### README
+
+The README is the front door. A developer should understand what the project does in 30 seconds.
+
+```markdown
+# Project Name
+
+One sentence describing what this does and who it's for.
+
+## Quick Start
+
+\`\`\`bash
+npm install my-package
+\`\`\`
+
+\`\`\`ts
+import { doThing } from 'my-package';
+doThing({ input: 'example' });
+// → { result: 'processed' }
+\`\`\`
+
+## Why This Exists
+
+What problem does this solve? What alternatives exist and why did you build this instead?
+
+## Installation
+
+Full installation steps including prerequisites.
+
+## API Reference
+
+...or link to separate docs.
+
+## Contributing
+
+How to run tests, PR process, coding style.
+```
+
+**README Anti-patterns:**
+- Starting with badges (put them at the bottom)
+- Long feature lists before a code example
+- "This project is..." — just say what it does
+- Installation steps before showing what you get
+
+### API Documentation
+
+```markdown
+## POST /api/users
+
+Create a new user account.
+
+**Request**
+
+\`\`\`http
+POST /api/users
+Content-Type: application/json
+Authorization: Bearer <token>
+
+{
+  "name": "Alice Smith",
+  "email": "alice@example.com",
+  "role": "member"
+}
+\`\`\`
+
+**Response** `201 Created`
+
+\`\`\`json
+{
+  "id": "usr_abc123",
+  "name": "Alice Smith",
+  "email": "alice@example.com",
+  "role": "member",
+  "createdAt": "2025-03-12T10:00:00Z"
+}
+\`\`\`
+
+**Errors**
+
+| Status | Code | Description |
+|--------|------|-------------|
+| 400 | `validation_error` | Missing or invalid fields |
+| 409 | `email_taken` | Email already in use |
+| 403 | `insufficient_permissions` | Requires admin role |
+```
+
+### Architecture Document
+
+```markdown
+# [System Name] Architecture
+
+## Overview
+
+One paragraph: what the system does, who uses it, and the key architectural decision.
+
+## Context Diagram
+
+[Diagram showing this system + adjacent systems]
+
+## Key Design Decisions
+
+### Decision 1: Why We Use [Technology X]
+
+**Context**: What problem were we solving?
+**Options considered**: A, B, C
+**Decision**: We chose X because...
+**Consequences**: Trade-offs we accepted
+
+## Component Overview
+
+| Component | Purpose | Technology |
+|-----------|---------|-----------|
+| API Gateway | Request routing, auth | Nginx |
+| App Server | Business logic | Node.js |
+| Database | Persistent storage | PostgreSQL |
+
+## Data Flow
+
+1. Request arrives at Load Balancer
+2. ...
+
+## Failure Modes
+
+What happens when each component fails?
+```
+
+### Runbook
+
+```markdown
+# Runbook: [Incident Type]
+
+**Severity**: P1 / P2 / P3
+**Owner**: Platform Team
+**Last Updated**: 2025-03-12
+
+## Symptoms
+
+- Error rate > 5% on `/api/checkout`
+- Users seeing 500 errors on payment
+
+## Immediate Actions (< 5 minutes)
+
+1. Check error rate: [link to dashboard]
+2. Check recent deploys: `kubectl rollout history deployment/api`
+3. If recent deploy caused this: `kubectl rollout undo deployment/api`
+
+## Diagnosis
+
+### Step 1: Isolate the component
+
+\`\`\`bash
+kubectl logs -l app=api --tail=200 | grep ERROR
+\`\`\`
+
+Look for: database timeouts, memory errors, third-party API failures.
+
+### Step 2: Check dependencies
+
+- Database: [link to RDS dashboard]
+- Payment API: [link to Stripe status page]
+
+## Resolution
+
+**If database issue**: Follow [Database Incident Runbook]
+**If Stripe issue**: Enable fallback payment processor
+**If memory**: Scale up: `kubectl scale deployment api --replicas=8`
+
+## Post-Incident
+
+- [ ] Write incident report (use template)
+- [ ] Fix root cause
+- [ ] Add alert to catch this earlier next time
+```
+
+## Writing Techniques
+
+### The Inverted Pyramid
+
+Lead with the most important information, add details after:
+
+```
+Bad:  "First, open your terminal. Then navigate to the project directory.
+       After that, run the install command. This will install dependencies."
+
+Good: "Install dependencies: `npm install`
+       Run from the project root directory."
+```
+
+### Before/After Examples
+
+Always more useful than abstract descriptions:
+
+```
+Bad:  "The function handles edge cases."
+
+Good: "The function returns `null` for empty inputs:
+       \`\`\`
+       formatDate(null) → null
+       formatDate('') → null
+       formatDate('2025-01-01') → '2025-01-01T00:00:00Z'
+       \`\`\`"
+```
+
+### Admonitions (Use Sparingly)
+
+```markdown
+> **Note**: This only applies when using the SQL adapter.
+
+> **Warning**: This operation is irreversible.
+
+> **Tip**: Run with `--verbose` to see detailed output.
+```
+
+## Style Rules
+
+| Avoid | Prefer |
+|-------|--------|
+| "simply", "just", "easily" | Remove the word |
+| "in order to" | "to" |
+| "utilize" | "use" |
+| "at this point in time" | "now" |
+| "it is important to note that" | Remove, or say it directly |
+| "Please note that" | Remove |
+| Passive voice | Active voice |
+| Future tense ("will return") | Present tense ("returns") |
+
+## Code Examples
+
+- Always use real, working examples (not `foo`, `bar`)
+- Show input and expected output
+- Keep examples short — one concept per example
+- Use syntax highlighting (specify the language in code fences)
+
+```ts
+// Bad: abstract example
+function process(a, b) {
+  return a + b;
+}
+
+// Good: concrete example
+function formatCurrency(amount: number, currency: string): string {
+  return new Intl.NumberFormat('en-US', { style: 'currency', currency }).format(amount);
+}
+
+formatCurrency(29.99, 'USD'); // → "$29.99"
+formatCurrency(1000, 'EUR'); // → "€1,000.00"
+```

package/src/modules/qa/module.yaml

@@ -0,0 +1,9 @@
+code: qa
+name: "QA"
+description: "Quality assurance toolkit — test suite generation, Playwright-based web app testing, and comprehensive testing strategy covering unit, integration, E2E, and contract testing. 3 skills."
+default_selected: false
+skills_count: 3
+skills:
+  - test-writer
+  - webapp-testing
+  - test-strategy

package/src/modules/qa/skills/test-strategy/SKILL.md

@@ -0,0 +1,263 @@
+---
+name: test-strategy
+description: Comprehensive testing strategy covering unit, integration, E2E, and contract testing. Trigger when planning a testing approach, setting up testing infrastructure, deciding what to test, or improving test coverage.
+---
+
+# Testing Strategy
+
+Good tests give you confidence to ship. Bad tests slow you down with false failures. The goal is a fast, reliable suite that catches real bugs.
+
+## The Testing Trophy (Preferred over Pyramid)
+
+```
+        [E2E]           ← few, high-value user journeys
+      [Integration]     ← most tests live here
+    [  Unit Tests  ]    ← fast, isolated logic
+  [Static Analysis]     ← TypeScript, ESLint (always-on)
+```
+
+- **Static**: TypeScript + ESLint. Free bug prevention, no maintenance cost.
+- **Unit**: Test pure logic, utilities, transformers in isolation.
+- **Integration**: Test components, API routes, services with real dependencies (DB, filesystem).
+- **E2E**: Test critical user paths through the actual UI.
+
+## What to Test
+
+### Test this:
+- Business logic with branches (if/else, edge cases)
+- Data transformations and calculations
+- Error handling paths
+- Permissions and access control
+- Integrations between services
+- Critical user journeys (checkout, login, signup)
+
+### Don't test this:
+- Implementation details (internal state, private methods)
+- Third-party library behavior
+- Simple getters/setters with no logic
+- One-line functions with no branches
+
+## Unit Testing
+
+```ts
+// vitest or jest — pure function, no mocks needed
+import { calculateDiscount } from '../pricing';
+
+describe('calculateDiscount', () => {
+  it('applies percentage discount correctly', () => {
+    expect(calculateDiscount(100, { type: 'percent', value: 20 })).toBe(80);
+  });
+
+  it('applies fixed discount correctly', () => {
+    expect(calculateDiscount(100, { type: 'fixed', value: 15 })).toBe(85);
+  });
+
+  it('returns 0 when discount exceeds price', () => {
+    expect(calculateDiscount(10, { type: 'fixed', value: 50 })).toBe(0);
+  });
+
+  it('throws on negative discount value', () => {
+    expect(() => calculateDiscount(100, { type: 'percent', value: -10 }))
+      .toThrow('Discount value cannot be negative');
+  });
+});
+```
+
+### Mocking
+
+```ts
+// Mock at the module level, not function by function
+vi.mock('../lib/email', () => ({
+  sendEmail: vi.fn().mockResolvedValue({ messageId: 'test-123' }),
+}));
+
+// Spy on existing implementation
+const sendSpy = vi.spyOn(emailService, 'sendEmail').mockResolvedValue(null);
+
+// Reset between tests
+afterEach(() => { vi.clearAllMocks(); });
+
+// Verify calls
+expect(sendSpy).toHaveBeenCalledWith({
+  to: 'user@example.com',
+  subject: 'Welcome!',
+});
+```
+
+## Integration Testing
+
+```ts
+// Test with real database (use test DB or transactions)
+import { db } from '../lib/db';
+import { createUser } from '../services/user';
+
+beforeAll(async () => { await db.$connect(); });
+afterAll(async () => { await db.$disconnect(); });
+beforeEach(async () => { await db.$transaction([db.user.deleteMany()]); });
+
+describe('createUser', () => {
+  it('creates a user and sends welcome email', async () => {
+    const user = await createUser({ name: 'Alice', email: 'alice@example.com' });
+
+    // Verify in database
+    const dbUser = await db.user.findUnique({ where: { id: user.id } });
+    expect(dbUser).toMatchObject({ name: 'Alice', email: 'alice@example.com' });
+  });
+
+  it('rejects duplicate email', async () => {
+    await createUser({ name: 'Alice', email: 'alice@example.com' });
+    await expect(
+      createUser({ name: 'Bob', email: 'alice@example.com' })
+    ).rejects.toThrow('Email already in use');
+  });
+});
+```
+
+### API Route Testing
+
+```ts
+// Next.js / Express API testing
+import { createMocks } from 'node-mocks-http';
+import handler from '../pages/api/users/[id]';
+
+it('returns 404 for unknown user', async () => {
+  const { req, res } = createMocks({
+    method: 'GET',
+    query: { id: 'nonexistent-id' },
+  });
+
+  await handler(req, res);
+
+  expect(res._getStatusCode()).toBe(404);
+  expect(JSON.parse(res._getData())).toEqual({ error: 'User not found' });
+});
+```
+
+## Component Testing
+
+```tsx
+// React Testing Library — test behavior, not implementation
+import { render, screen, userEvent } from '@testing-library/react';
+import { LoginForm } from './LoginForm';
+
+describe('LoginForm', () => {
+  it('shows error on empty submit', async () => {
+    render(<LoginForm onSuccess={vi.fn()} />);
+
+    await userEvent.click(screen.getByRole('button', { name: 'Sign in' }));
+
+    expect(screen.getByText('Email is required')).toBeInTheDocument();
+  });
+
+  it('calls onSuccess with credentials on valid submit', async () => {
+    const onSuccess = vi.fn();
+    render(<LoginForm onSuccess={onSuccess} />);
+
+    await userEvent.type(screen.getByLabelText('Email'), 'user@example.com');
+    await userEvent.type(screen.getByLabelText('Password'), 'password123');
+    await userEvent.click(screen.getByRole('button', { name: 'Sign in' }));
+
+    expect(onSuccess).toHaveBeenCalledWith({
+      email: 'user@example.com',
+      password: 'password123',
+    });
+  });
+});
+```
+
+### Queries Priority (RTL)
+
+1. `getByRole` — accessible roles (button, heading, textbox)
+2. `getByLabelText` — form inputs by label
+3. `getByPlaceholderText` — inputs by placeholder
+4. `getByText` — visible text
+5. `getByTestId` — last resort (`data-testid`)
+
+## E2E Testing with Playwright
+
+```ts
+// tests/e2e/checkout.spec.ts
+import { test, expect } from '@playwright/test';
+
+test.describe('Checkout Flow', () => {
+  test.beforeEach(async ({ page }) => {
+    await page.goto('/products');
+  });
+
+  test('user can complete purchase', async ({ page }) => {
+    // Add to cart
+    await page.getByRole('button', { name: 'Add to cart' }).first().click();
+    await page.getByRole('link', { name: 'Cart (1)' }).click();
+
+    // Checkout
+    await page.getByRole('button', { name: 'Checkout' }).click();
+    await page.getByLabel('Card number').fill('4242424242424242');
+    await page.getByLabel('Expiry').fill('12/30');
+    await page.getByLabel('CVC').fill('123');
+    await page.getByRole('button', { name: 'Pay' }).click();
+
+    // Confirm
+    await expect(page.getByText('Order confirmed')).toBeVisible();
+  });
+});
+```
+
+### Playwright Config
+
+```ts
+// playwright.config.ts
+export default {
+  testDir: './tests/e2e',
+  use: {
+    baseURL: process.env.E2E_BASE_URL ?? 'http://localhost:3000',
+    screenshot: 'only-on-failure',
+    video: 'retain-on-failure',
+  },
+  projects: [
+    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
+    { name: 'mobile', use: { ...devices['iPhone 14'] } },
+  ],
+};
+```
+
+## Test Organization
+
+```
+src/
+├── components/
+│   ├── Button.tsx
+│   └── Button.test.tsx     ← co-located unit/component tests
+├── services/
+│   ├── user.ts
+│   └── user.test.ts
+tests/
+├── integration/            ← integration tests (separate)
+│   └── api.test.ts
+└── e2e/                    ← E2E tests (separate)
+    └── checkout.spec.ts
+```
+
+## Coverage Targets
+
+| Layer | Target | Rationale |
+|-------|---------|-----------|
+| Business logic | 90%+ | High value, easy to test |
+| API routes | 80%+ | Integration tested |
+| UI components | 70%+ | Test behavior over structure |
+| E2E | Key paths only | Expensive to maintain |
+
+Run coverage: `vitest --coverage` or `jest --coverage`
+
+## CI Configuration
+
+```yaml
+# .github/workflows/test.yml
+jobs:
+  test:
+    steps:
+      - run: npm run typecheck          # fast, catches most bugs
+      - run: npm run lint               # code quality
+      - run: npm run test:unit          # fast feedback
+      - run: npm run test:integration   # needs DB
+      - run: npm run test:e2e           # slowest, run last
+```