Atlas Framework

ATLAS Framework - Structured AI-assisted development methodology with GOTCHA 6-layer architecture and 5-step app building workflow. Use when building applica...

Security Scan

This is an instruction-only methodology/framework skill that is internally consistent with its stated purpose; it reads and writes project-local artifacts (memory files, .env, SQLite DBs) which is expected, but you should be careful about placing sensitive credentials in those files or allowing the agent access to non-project secrets.

Purpose & Capability

Name and description describe a development methodology; the SKILL.md contains guidance for architecture, workflow, memory, testing, and file layout. Requested actions (reading/writing memory files, initializing local SQLite DBs, validating integrations) align with a framework for building agentic apps.

Instruction Scope

The instructions explicitly direct the agent to read project-local files (memory/MEMORY.md, memory logs), check .env, validate API keys/OAuth flows, create folders, and initialize SQLite databases. This is coherent for a framework that maintains persistent memory and validates integrations, but it does mean the agent will be instructed to access and modify files in the project workspace. If you don't want the agent touching .env or other sensitive files, restrict those from the project context or sanitize them first.

Install Mechanism

No install spec and no code files are present (instruction-only). This minimizes risk from external downloads or arbitrary code installation.

Credentials

The skill does not declare required environment variables yet the instructions reference checking .env and verifying API keys/OAuth flows. For a framework that manages integrations this is reasonable, but you should confirm which credentials (if any) the agent will be given access to at runtime and avoid exposing unrelated or high-privilege secrets in project .env files.

Persistence & Privilege

always is false and the skill does not request platform-wide persistence or modify other skills. It does instruct creating project-local persistent memory and SQLite databases, which is expected for cross-session continuity and is scoped to the project.

Assessment

This skill is a methodology guide and is coherent with its stated purpose, but it instructs the agent to read and create project-local files (memory logs, .env) and to initialize SQLite DBs. Before installing or invoking it: (1) ensure your project .env does not contain unrelated/high-privilege secrets (move them out or use a dedicated credentials store), (2) run the skill in a sandboxed project directory if you want to limit file writes, (3) back up any existing memory/DB files you care about, and (4) confirm which integration credentials you will provide so the agent only verifies the specific services you intend. If you need more assurance, ask the skill author for an explicit list of exact files/paths it will read/write and the formats it expects.

A structured methodology for AI-assisted development built on the GOTCHA 6-layer architecture.

When to Use This Skill

Use this skill when:

• Building full-stack applications
• Creating agentic workflows
• Setting up AI assistant frameworks
• Designing data systems or databases
• Planning integrations with external services

The GOTCHA Framework (6 Layers)

GOT (The Engine):

• Goals (goals/) — What needs to happen (process definitions)
• Orchestration — The AI manager that coordinates execution
• Tools (tools/) — Deterministic scripts that do the actual work

CHA (The Context):

• Context (context/) — Reference material and domain knowledge
• Hard prompts (hardprompts/) — Reusable instruction templates
• Args (args/) — Behavior settings that shape how the system acts

Why GOTCHA?

LLMs are probabilistic (educated guesses). Business logic is deterministic (must work the same way every time). This structure bridges that gap through separation of concerns:

• Push reliability into deterministic code (tools)
• Push flexibility and reasoning into the LLM (orchestration)
• Push process clarity into goals
• Push behavior settings into args files
• Push domain knowledge into context layer

---

ATLAS Workflow (5 Steps)

Use this when building applications:

Step	Phase	What You Do
A	Architect	Define problem, users, success metrics
T	Trace	Data schema, integrations map, stack proposal
L	Link	Validate ALL connections before building
A	Assemble	Build with layered architecture
S	Stress-test	Test functionality, error handling

For production builds, also add:

• V — Validate (security, input sanitization, edge cases, unit tests)
• M — Monitor (logging, observability, alerts)

A — Architect

Purpose: Know exactly what you're building before touching code.

Answer these questions:

1. What problem does this solve? (One sentence)
2. Who is this for? (Specific user, not "everyone")
3. What does success look like? (Measurable outcome)
4. What are the constraints? (Budget, time, technical requirements)

T — Trace

Purpose: Design before building.

1. Data Schema — Define source of truth BEFORE building
2. Integrations Map — List every external connection (service, purpose, auth type, MCP available?)
3. Technology Stack — Propose database, backend, frontend
4. Edge Cases — Document what could break (rate limits, token expiry, timeouts)

L — Link

Purpose: Validate ALL connections BEFORE building.

[ ] Database connection tested
[ ] All API keys verified
[ ] MCP servers responding
[ ] OAuth flows working
[ ] Environment variables set
[ ] Rate limits understood

A — Assemble

Purpose: Build with proper architecture.

Build order:

1. Database schema first
2. Backend API routes second
3. Frontend UI last

Follow GOTCHA separation:

• Frontend — UI components, user interactions
• Backend — API routes, business logic, validation
• Database — Schema, migrations, indexes

S — Stress-test

Purpose: Test before shipping.

• Functional Testing — All buttons work, data saves/retrieves, navigation works
• Integration Testing — API calls succeed, MCP operations work, auth persists
• Edge Case Testing — Invalid input handled, empty states display, network errors show feedback

---

File Structure

project/
├── goals/          — Process definitions (what to achieve)
├── tools/          — Execution scripts (organized by workflow)
├── args/           — Behavior settings (YAML/JSON)
├── context/        — Domain knowledge and references
├── hardprompts/    — Reusable instruction templates
├── memory/         — Persistent memory system
├── .tmp/           — Temporary work (disposable)
├── .env            — API keys + environment variables
└── CLAUDE.md       — System instruction file

---

Memory System

The framework includes a persistent memory system for cross-session continuity.

Loading Memory

At session start, load memory context:

• Read memory/MEMORY.md for curated long-term facts
• Read today's log: memory/logs/YYYY-MM-DD.md
• Read yesterday's log for continuity

Memory Types

• fact — Objective information
• preference — User preferences
• event — Something that happened
• insight — Learned pattern
• task — Something to do
• relationship — Connection between entities

Search Capabilities

• Keyword search
• Semantic search
• Hybrid search (best results)

---

Anti-Patterns (What NOT To Do)

1. Building before designing — End up rewriting everything
2. Skipping connection validation — Hours wasted on broken integrations
3. No data modeling — Schema changes cascade into UI rewrites
4. No testing — Ship broken code, lose trust
5. Hardcoding everything — No flexibility for changes

---

Guardrails

• Always check tools/manifest.md before writing new scripts
• Verify tool output format before chaining into another tool
• Don't assume APIs support batch operations — check first
• When a workflow fails mid-execution, preserve intermediate outputs before retrying
• Read the full goal before starting a task — don't skim

---

First Run Initialization

On first session in a new environment:

1. Check if memory/MEMORY.md exists
2. If missing, create the folder structure:
   • memory/logs/
   • data/
3. Create MEMORY.md with template
4. Initialize SQLite databases for memory and activity tracking

---

Continuous Improvement Loop

Every failure strengthens the system:

1. Identify what broke and why
2. Fix the tool script
3. Test until it works reliably
4. Update the goal with new knowledge
5. Next time → automatic success