@bastani/atomic 0.7.17 → 0.8.0

package/dist/builtin/workflows/skills/research-codebase/SKILL.md

@@ -0,0 +1,226 @@
+---
+name: research-codebase
+description: Document codebase as-is with research directory for historical context.
+---
+
+# Research Codebase
+
+You are tasked with conducting comprehensive research across the codebase to answer user questions by spawning parallel sub-agents and synthesizing their findings.
+
+The user's research question/request is: **$ARGUMENTS**
+
+## Steps to follow after receiving the research query:
+
+<EXTREMELY_IMPORTANT>
+
+- OPTIMIZE the research question using your prompt-engineer skill to refine phrasing and structure for maximum clarity and precision.
+- After research is complete and the research artifact(s) are generated, provide an executive summary of the research and path to the research document(s) to the user, and ask if they have any follow-up questions or need clarification.
+
+</EXTREMELY_IMPORTANT>
+
+1. **Read any directly mentioned files first:**
+    - If the user mentions specific files (tickets, docs, or other notes), read them FULLY first
+    - **IMPORTANT**: Use the `readFile` tool WITHOUT limit/offset parameters to read entire files
+    - **CRITICAL**: Read these files yourself in the main context before spawning any sub-tasks
+    - This ensures you have full context before decomposing the research
+
+2. **Analyze and decompose the research question:**
+    - Break the research question down into composable research areas
+    - Take time to ultrathink about the underlying patterns, connections, and architectural implications the user might be seeking
+    - Identify specific components, patterns, or concepts to investigate
+    - Create a research plan using TodoWrite to track all subtasks
+    - Consider which directories, files, or architectural patterns are relevant
+
+3. **Spawn parallel sub-agent tasks:**
+    - Create multiple Task agents to research different aspects concurrently
+    - We now have specialized agents that know how to do specific research tasks:
+
+    **For codebase research:**
+    - Use the **codebase-locator** agent to find WHERE files and components live
+    - Use the **codebase-analyzer** agent to understand HOW specific code works (without critiquing it)
+    - Use the **codebase-pattern-finder** agent to find examples of existing patterns (without evaluating them)
+    - Output directory: `research/docs/`
+    - Examples:
+        - The database logic is found and can be documented in `research/docs/2024-01-10-database-implementation.md`
+        - The authentication flow is found and can be documented in `research/docs/2024-01-11-authentication-flow.md`
+
+    **IMPORTANT**: All agents are documentarians, not critics. They will describe what exists without suggesting improvements or identifying issues.
+
+    **For research directory:**
+    - Use the **codebase-research-locator** agent to discover what documents exist about the topic
+    - Use the **codebase-research-analyzer** agent to extract key insights from specific documents (only the most relevant ones)
+
+    **For online search:**
+    - VERY IMPORTANT: In case you discover external libraries as dependencies, use the **codebase-online-researcher** agent for external documentation and resources
+        - The agent fetches live web content using the **playwright-cli** skill (or `bunx @playwright/cli` / `curl`). Instruct it to apply the token-efficient fetch order: (1) try `curl https://<site>/llms.txt` for an AI-friendly index (see [llmstxt.org](https://llmstxt.org/llms.txt)), (2) try `curl <url> -H "Accept: text/markdown"` to get pre-converted Markdown (supported on Cloudflare-hosted docs via [Markdown for Agents](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/)), (3) fall back to HTML parsing via `playwright-cli`
+        - Instruct the agent to return LINKS with their findings and INCLUDE those links in the research document
+        - The agent should persist reusable source documents under `research/web/<YYYY-MM-DD>-<kebab-case-topic>.md` (with frontmatter noting `source_url`, `fetched_at`, and `fetch_method`) so future research can reuse them without re-fetching
+        - Output directory for the synthesized research artifact: `research/docs/`
+        - Examples:
+            - If researching `Redis` locks usage, the agent might find relevant usage and create a document `research/docs/2024-01-15-redis-locks-usage.md` with internal links to Redis docs and code references (and cache the fetched Redis docs under `research/web/`)
+            - If researching `OAuth` flows, the agent might find relevant external articles and create a document `research/docs/2024-01-16-oauth-flows.md` with links to those articles
+
+    The key is to use these agents intelligently:
+    - Start with locator agents to find what exists
+    - Then use analyzer agents on the most promising findings to document how they work
+    - Run multiple agents in parallel when they're searching for different things
+    - Each agent knows its job - just tell it what you're looking for
+    - Don't write detailed prompts about HOW to search - the agents already know
+    - Remind agents they are documenting, not evaluating or improving
+
+4. **Wait for all sub-agents to complete and synthesize:**
+    - IMPORTANT: Wait for ALL sub-agent tasks to complete before proceeding
+    - Compile all sub-agent results (both codebase and research findings)
+    - Prioritize live codebase findings as primary source of truth
+    - Use research findings as supplementary historical context
+    - Connect findings across different components
+    - Include specific file paths and line numbers for reference
+    - Highlight patterns, connections, and architectural decisions
+    - Answer the user's research question with concrete evidence
+    - **If findings reveal the original question was misframed** (e.g., the system works differently than assumed, or the components don't exist where expected), flag this to the user before finalizing the document. This is valuable signal — don't bury it.
+
+5. **Generate research document:**
+    - Follow the directory structure for research documents:
+
+```
+research/
+├── tickets/
+│   ├── YYYY-MM-DD-XXXX-description.md
+├── docs/
+│   ├── YYYY-MM-DD-topic.md
+├── notes/
+│   ├── YYYY-MM-DD-meeting.md
+├── ...
+└──
+```
+
+- Naming conventions:
+    - YYYY-MM-DD is today's date
+    - topic is a brief kebab-case description of the research topic
+    - meeting is a brief kebab-case description of the meeting topic
+    - XXXX is the ticket number (omit if no ticket)
+    - description is a brief kebab-case description of the research topic
+    - Examples:
+        - With ticket: `2025-01-08-1478-parent-child-tracking.md`
+        - Without ticket: `2025-01-08-authentication-flow.md`
+- Structure the document with YAML frontmatter followed by content:
+
+    ```markdown
+    ---
+    date: !`date '+%Y-%m-%d %H:%M:%S %Z'`
+    researcher: [Researcher name from thoughts status]
+    git_commit: !`git rev-parse --verify HEAD 2>/dev/null || echo "no-commits"`
+    branch: !`git branch --show-current 2>/dev/null || git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "unborn"`
+    repository: !`basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown-repo"`
+    topic: "[User's Question/Topic]"
+    tags: [research, codebase, relevant-component-names]
+    status: complete
+    last_updated: !`date '+%Y-%m-%d'`
+    last_updated_by: [Researcher name]
+    ---
+
+    # Research
+
+    ## Research Question
+
+    [Original user query]
+
+    ## Summary
+
+    [High-level documentation of what was found, answering the user's question by describing what exists]
+
+    ## Detailed Findings
+
+    ### [Component/Area 1]
+
+    - Description of what exists ([file.ext:line](link))
+    - How it connects to other components
+    - Current implementation details (without evaluation)
+
+    ### [Component/Area 2]
+
+    ...
+
+    ## Code References
+
+    - `path/to/file.py:123` - Description of what's there
+    - `another/file.ts:45-67` - Description of the code block
+
+    ## Architecture Documentation
+
+    [Current patterns, conventions, and design implementations found in the codebase]
+
+    ## Historical Context (from research/)
+
+    [Relevant insights from research/ directory with references]
+
+    - `research/docs/YYYY-MM-DD-topic.md` - Information about module X
+    - `research/notes/YYYY-MM-DD-meeting.md` - Past notes from internal engineering, customer, etc. discussions
+    - ...
+
+    ## Related Research
+
+    [Links to other research documents in research/]
+
+    ## Open Questions
+
+    [Any areas that need further investigation]
+    ```
+
+1. **Add GitHub permalinks (if applicable):**
+    - Check if on main branch or if commit is pushed: `git branch --show-current` and `git status`
+    - If on main/master or pushed, generate GitHub permalinks:
+        - Get repo info: `gh repo view --json owner,name`
+        - Create permalinks: `https://github.com/{owner}/{repo}/blob/{commit}/{file}#L{line}`
+    - Replace local file references with permalinks in the document
+
+2. **Present findings:**
+    - Present a concise summary of findings to the user
+    - Include key file references for easy navigation
+    - Ask if they have follow-up questions or need clarification
+
+3. **Handle follow-up questions:**
+
+- If the user has follow-up questions, append to the same research document
+- Update the frontmatter fields `last_updated` and `last_updated_by` to reflect the update
+- Add `last_updated_note: "Added follow-up research for [brief description]"` to frontmatter
+- Add a new section: `## Follow-up Research [timestamp]`
+- Spawn new sub-agents as needed for additional investigation
+- Continue updating the document and syncing
+
+## Important notes:
+
+- Please DO NOT implement anything in this stage, just create the comprehensive research document
+- Always use parallel Task agents to maximize efficiency and minimize context usage
+- Always run fresh codebase research - never rely solely on existing research documents
+- The `research/` directory provides historical context to supplement live findings
+- Focus on finding concrete file paths and line numbers for developer reference
+- Research documents should be self-contained with all necessary context
+- Each sub-agent prompt should be specific and focused on read-only documentation operations
+- Document cross-component connections and how systems interact
+- Include temporal context (when the research was conducted)
+- Link to GitHub when possible for permanent references
+- Keep the main agent focused on synthesis, not deep file reading
+- Have sub-agents document examples and usage patterns as they exist
+- Explore all of research/ directory, not just research subdirectory
+- **CRITICAL**: You and all sub-agents are documentarians, not evaluators
+- **REMEMBER**: Document what IS, not what SHOULD BE
+- **NO RECOMMENDATIONS**: Only describe the current state of the codebase
+- **File reading**: Always read mentioned files FULLY (no limit/offset) before spawning sub-tasks
+- **Critical ordering**: Follow the numbered steps exactly
+    - ALWAYS read mentioned files first before spawning sub-tasks (step 1)
+    - ALWAYS wait for all sub-agents to complete before synthesizing (step 4)
+    - ALWAYS gather metadata before writing the document (step 5 before step 6)
+    - NEVER write the research document with placeholder values
+
+- **Frontmatter consistency**:
+    - Always include frontmatter at the beginning of research documents
+    - Keep frontmatter fields consistent across all research documents
+    - Update frontmatter when adding follow-up research
+    - Use snake_case for multi-word field names (e.g., `last_updated`, `git_commit`)
+    - Tags should be relevant to the research topic and components studied
+
+## Final Output
+
+- A collection of research files with comprehensive research findings, properly formatted and linked, ready for consumption to create detailed specifications or design documents.
+- IMPORTANT: DO NOT generate any other artifacts or files OUTSIDE of the `research/` directory.

package/dist/builtin/workflows/skills/tdd/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: tdd
+description: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
+---
+
+# Test-Driven Development
+
+## Philosophy
+
+**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
+
+**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
+
+**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
+
+See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
+
+## Anti-Pattern: Horizontal Slices
+
+**DO NOT write all tests first, then all implementation.** This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code."
+
+This produces **crap tests**:
+
+- Tests written in bulk test _imagined_ behavior, not _actual_ behavior
+- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior
+- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine
+- You outrun your headlights, committing to test structure before understanding the implementation
+
+**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.
+
+```
+WRONG (horizontal):
+  RED:   test1, test2, test3, test4, test5
+  GREEN: impl1, impl2, impl3, impl4, impl5
+
+RIGHT (vertical):
+  RED→GREEN: test1→impl1
+  RED→GREEN: test2→impl2
+  RED→GREEN: test3→impl3
+  ...
+```
+
+## Workflow
+
+### 1. Planning
+
+When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.
+
+Before writing any code:
+
+- [ ] Confirm with user what interface changes are needed
+- [ ] Confirm with user which behaviors to test (prioritize)
+- [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)
+- [ ] Design interfaces for [testability](interface-design.md)
+- [ ] List the behaviors to test (not implementation steps)
+- [ ] Get user approval on the plan
+
+Ask: "What should the public interface look like? Which behaviors are most important to test?"
+
+**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.
+
+### 2. Tracer Bullet
+
+Write ONE test that confirms ONE thing about the system:
+
+```
+RED:   Write test for first behavior → test fails
+GREEN: Write minimal code to pass → test passes
+```
+
+This is your tracer bullet - proves the path works end-to-end.
+
+### 3. Incremental Loop
+
+For each remaining behavior:
+
+```
+RED:   Write next test → fails
+GREEN: Minimal code to pass → passes
+```
+
+Rules:
+
+- One test at a time
+- Only enough code to pass current test
+- Don't anticipate future tests
+- Keep tests focused on observable behavior
+
+### 4. Refactor
+
+After all tests pass, look for [refactor candidates](refactoring.md):
+
+- [ ] Extract duplication
+- [ ] Deepen modules (move complexity behind simple interfaces)
+- [ ] Apply SOLID principles where natural
+- [ ] Consider what new code reveals about existing code
+- [ ] Run tests after each refactor step
+
+**Never refactor while RED.** Get to GREEN first.
+
+## Checklist Per Cycle
+
+```
+[ ] Test describes behavior, not implementation
+[ ] Test uses public interface only
+[ ] Test would survive internal refactor
+[ ] Code is minimal for this test
+[ ] No speculative features added
+```

package/dist/builtin/workflows/skills/tdd/deep-modules.md

@@ -0,0 +1,33 @@
+# Deep Modules
+
+From "A Philosophy of Software Design":
+
+**Deep module** = small interface + lots of implementation
+
+```
+┌─────────────────────┐
+│   Small Interface   │  ← Few methods, simple params
+├─────────────────────┤
+│                     │
+│                     │
+│  Deep Implementation│  ← Complex logic hidden
+│                     │
+│                     │
+└─────────────────────┘
+```
+
+**Shallow module** = large interface + little implementation (avoid)
+
+```
+┌─────────────────────────────────┐
+│       Large Interface           │  ← Many methods, complex params
+├─────────────────────────────────┤
+│  Thin Implementation            │  ← Just passes through
+└─────────────────────────────────┘
+```
+
+When designing interfaces, ask:
+
+- Can I reduce the number of methods?
+- Can I simplify the parameters?
+- Can I hide more complexity inside?

package/dist/builtin/workflows/skills/tdd/interface-design.md

@@ -0,0 +1,31 @@
+# Interface Design for Testability
+
+Good interfaces make testing natural:
+
+1. **Accept dependencies, don't create them**
+
+   ```typescript
+   // Testable
+   function processOrder(order, paymentGateway) {}
+
+   // Hard to test
+   function processOrder(order) {
+     const gateway = new StripeGateway();
+   }
+   ```
+
+2. **Return results, don't produce side effects**
+
+   ```typescript
+   // Testable
+   function calculateDiscount(cart): Discount {}
+
+   // Hard to test
+   function applyDiscount(cart): void {
+     cart.total -= discount;
+   }
+   ```
+
+3. **Small surface area**
+   - Fewer methods = fewer tests needed
+   - Fewer params = simpler test setup

package/dist/builtin/workflows/skills/tdd/mocking.md

@@ -0,0 +1,59 @@
+# When to Mock
+
+Mock at **system boundaries** only:
+
+- External APIs (payment, email, etc.)
+- Databases (sometimes - prefer test DB)
+- Time/randomness
+- File system (sometimes)
+
+Don't mock:
+
+- Your own classes/modules
+- Internal collaborators
+- Anything you control
+
+## Designing for Mockability
+
+At system boundaries, design interfaces that are easy to mock:
+
+**1. Use dependency injection**
+
+Pass external dependencies in rather than creating them internally:
+
+```typescript
+// Easy to mock
+function processPayment(order, paymentClient) {
+  return paymentClient.charge(order.total);
+}
+
+// Hard to mock
+function processPayment(order) {
+  const client = new StripeClient(process.env.STRIPE_KEY);
+  return client.charge(order.total);
+}
+```
+
+**2. Prefer SDK-style interfaces over generic fetchers**
+
+Create specific functions for each external operation instead of one generic function with conditional logic:
+
+```typescript
+// GOOD: Each function is independently mockable
+const api = {
+  getUser: (id) => fetch(`/users/${id}`),
+  getOrders: (userId) => fetch(`/users/${userId}/orders`),
+  createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
+};
+
+// BAD: Mocking requires conditional logic inside the mock
+const api = {
+  fetch: (endpoint, options) => fetch(endpoint, options),
+};
+```
+
+The SDK approach means:
+- Each mock returns one specific shape
+- No conditional logic in test setup
+- Easier to see which endpoints a test exercises
+- Type safety per endpoint

package/dist/builtin/workflows/skills/tdd/refactoring.md

@@ -0,0 +1,10 @@
+# Refactor Candidates
+
+After TDD cycle, look for:
+
+- **Duplication** → Extract function/class
+- **Long methods** → Break into private helpers (keep tests on public interface)
+- **Shallow modules** → Combine or deepen
+- **Feature envy** → Move logic to where data lives
+- **Primitive obsession** → Introduce value objects
+- **Existing code** the new code reveals as problematic

package/dist/builtin/workflows/skills/tdd/tests.md

@@ -0,0 +1,61 @@
+# Good and Bad Tests
+
+## Good Tests
+
+**Integration-style**: Test through real interfaces, not mocks of internal parts.
+
+```typescript
+// GOOD: Tests observable behavior
+test("user can checkout with valid cart", async () => {
+  const cart = createCart();
+  cart.add(product);
+  const result = await checkout(cart, paymentMethod);
+  expect(result.status).toBe("confirmed");
+});
+```
+
+Characteristics:
+
+- Tests behavior users/callers care about
+- Uses public API only
+- Survives internal refactors
+- Describes WHAT, not HOW
+- One logical assertion per test
+
+## Bad Tests
+
+**Implementation-detail tests**: Coupled to internal structure.
+
+```typescript
+// BAD: Tests implementation details
+test("checkout calls paymentService.process", async () => {
+  const mockPayment = jest.mock(paymentService);
+  await checkout(cart, payment);
+  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
+});
+```
+
+Red flags:
+
+- Mocking internal collaborators
+- Testing private methods
+- Asserting on call counts/order
+- Test breaks when refactoring without behavior change
+- Test name describes HOW not WHAT
+- Verifying through external means instead of interface
+
+```typescript
+// BAD: Bypasses interface to verify
+test("createUser saves to database", async () => {
+  await createUser({ name: "Alice" });
+  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
+  expect(row).toBeDefined();
+});
+
+// GOOD: Verifies through interface
+test("createUser makes user retrievable", async () => {
+  const user = await createUser({ name: "Alice" });
+  const retrieved = await getUser(user.id);
+  expect(retrieved.name).toBe("Alice");
+});
+```