---
name: atomic-agent-workflow
description: Use this skill when an AI agent needs to plan or execute work in a project that uses Atomic Bomb, Atomic Resources, Bomber MCP, or Atomic Bomb Templates.
---

# Atomic Agent Workflow

Build maintainable front-end architecture before implementation details. Prefer reusable components, predictable structure, typed contracts, generated support files, and design-token-driven styling.

## Tool Order

1. Use Atomic Resources to establish design foundations.
2. Use Atomic Bomb to generate or preserve component architecture.
3. Use Atomic Bomb Templates when the project needs custom generation output.
4. Use Bomber MCP to automate implementation and maintenance inside the generated architecture.

## Initial Inspection

Before editing, inspect:

- `package.json` for framework, scripts, and available tooling.
- `src/components` for Atomic Design layers.
- `src/resources` for Atomic Resources output.
- `src/domains`, `src/hooks`, `src/lib`, and `src/services` for domain and data boundaries.
- `.atomic-bomb`, `agent.json`, or template config files if present.
- Storybook and test setup.

Do not assume paths. Use the local project shape as the source of truth.

## Architecture Decision Checklist

For every feature request, ask:

- Is there an existing atom, molecule, organism, template, hook, or service that should be reused?
- Is the requested UI a new atom, a composition of atoms, or a larger organism?
- Does behavior belong to a domain, service, hook, or context instead of the component?
- Does content belong in data files instead of JSX?
- Does styling belong in Sass and design tokens instead of inline style?
- Do stories, mocks, interfaces, tests, and barrel exports need updates?

## Atomic Design Boundaries

Atoms are the smallest reusable UI parts. They contain no API calls, business logic, or domain knowledge.

Molecules are small composed units. They arrange atoms and pass simple callbacks.

Organisms are larger page sections. They compose atoms and molecules and receive data from pages.

Templates define layout structure. They should not own business rules.

Pages are route-level views. They select or fetch page data and pass it down.

## Data Flow

Prefer this direction:

```text
page data or hook -> page -> organism -> molecule -> atom
```

Avoid atoms reading global data directly. Avoid deeply nested components importing page data.

## Implementation Steps

1. Inspect existing components and data.
2. Identify the smallest reusable layer to change.
3. Generate missing structure with Atomic Bomb when available.
4. Add or update typed interfaces.
5. Add or update mock data.
6. Add or update Storybook stories.
7. Add or update tests for behavior or rendering.
8. Update Sass and barrels.
9. Run typecheck, build, and relevant tests.

## Anti-Patterns

Do not create massive page components, duplicate UI elements, business logic in atoms, API calls from UI atoms, hard-coded design values when tokens exist, deep relative imports when barrels exist, or components without isolation mocks and stories when Storybook is used.

## Completion Criteria

Work is complete when the requested behavior works, TypeScript passes, the build passes, Storybook isolation remains possible, generated files and barrels are consistent, and the implementation follows existing local project patterns.