Atlas Quick Workflow

When to Use This Skill

Perfect for:

•UI text changes (typos, copy updates)
•Color/style tweaks (single value changes)
•Simple configuration updates
•Documentation fixes
•Single-line bug fixes

Time estimate: 5-15 minutes

Success criteria:

•Change deployed in < 15 minutes
•Tests pass
•No rollbacks

The 2 Phases

code

Phase 1: Make Change  → Locate, change, verify
Phase 2: Deploy       → Test + deploy via your deployment process

Phase 1: Make Change

Goal: Locate the code, make the change, verify locally.

Steps:

•

Locate the code

bash

# Find file by name
find src/ -name "*filename*"

# Find file by content
grep -r "text to find" src/

•
Make the change
- •Update the single value/line
- •Keep it simple - if it's getting complex, escalate to Iterative or Standard
•
Verify locally
- •If UI change: Check visually
- •If config: Verify value makes sense
- •If text: Check for typos

Quick Workflow Rules:

DO:

•✅ Make ONE focused change
•✅ Verify change is visible/working
•✅ Keep it under 5 minutes

DON'T:

•❌ Change multiple unrelated things
•❌ Add new logic
•❌ Modify multiple files
•❌ Skip verification

Project-Specific Considerations:

Even for quick changes, follow your project conventions:

Check for .atlas/conventions.md: If your project has this file, review relevant sections:

•Field naming conventions
•Code style requirements
•Design system rules
•Platform-specific gotchas

Common conventions to verify:

javascript

// Example: Field naming (customize for your project)
// ✅ Use project's standard field names
user.displayName = "John"

// ❌ Don't use deprecated field names
user.username = "John"  // If your project prefers displayName

// Example: Colors (customize for your project)
// ✅ Use project's color system
color: theme.colors.primary

// ❌ Don't use hard-coded colors if project has theme system
color: '#007AFF'

// Example: Typography (customize for your project)
// ✅ Use project's typography component
<Typography variant="body">Hello</Typography>

// ⚠️ Acceptable for quick change if no typography system
<Text style={{ fontFamily: 'System' }}>Hello</Text>

Examples:

Example 1: Fix typo

javascript

// Before
<Text>Wellcome to our app</Text>

// After
<Text>Welcome to our app</Text>

Example 2: Change color

javascript

// Before
backgroundColor: '#0000FF'  // Bright blue

// After
backgroundColor: '#007AFF'  // iOS blue

Example 3: Update timeout

javascript

// Before
const API_TIMEOUT = 30000  // 30 seconds

// After
const API_TIMEOUT = 60000  // 60 seconds

Phase 2: Deploy

Goal: Run tests and deploy via your deployment process.

Steps:

•
Update your changelog/release notes

If your project uses a changelog file (e.g., CHANGELOG.md, PENDING_CHANGES.md):
markdown
```
## Title: Fix welcome message typo
### Changes Made:
- Fixed typo: "Wellcome" → "Welcome"
```

•

Run quick validation

Adjust commands based on your project:

bash

# Type checking (if using TypeScript)
npm run typecheck
# OR
tsc --noEmit

# Linting (if configured)
npm run lint
# OR
eslint src/

# If tests are fast enough, run them
npm test

•

Deploy using your project's deployment script

Replace with your actual deployment command:

bash

# Examples (use your project's command):
npm run deploy:dev
# OR
./scripts/deploy.sh dev
# OR
make deploy-dev
# OR
git push origin develop

Deployment Checklist:

Pre-deployment:

• Changelog/release notes updated (if applicable)
• Type checking passes (if applicable)
• Linting passes (if applicable)
• Change verified locally

Deployment:

• Use your project's deployment script (not manual commit)
• Deploy to dev/staging environment first
• Check deployment output for errors

Post-deployment:

• No errors in deployment output
• Change visible in deployed environment
• Tests pass (if run by deployment script)

When to Skip Tests:

For truly trivial changes (typos, doc updates), you MAY skip running tests locally if:

•✅ Change is pure text/documentation
•✅ No code logic affected
•✅ Deployment script will run tests anyway

However: If your deployment script runs tests, they'll catch any issues regardless.

Escalation Criteria

Escalate to Iterative workflow if:

•Change works but you want peer validation
•Making multiple related changes
•Want quality review cycle

Escalate to Standard workflow if:

•Change affects multiple files
•Tests fail (need to add new tests)
•Edge cases emerge during implementation
•Not sure if change is correct

How to Escalate:

code

"Escalating to [Iterative|Standard] workflow. [REASON]"

Then restart from Phase 1 of new tier.

Common Quick Workflow Tasks

1. Text Changes

Use case: Fix typos, update copy, change labels

Pattern:

bash

# Find the text
grep -r "old text" src/

# Change it
# (Update in editor)

# Verify
# (Visual check in app)

# Deploy
[your deployment command]

Time: 5-10 minutes

2. Color Changes

Use case: Update colors, adjust styles

Pattern:

bash

# Find color usage
grep -r "#0000FF" src/

# Change it
backgroundColor: '#007AFF'

# Verify colors follow design system
# Deploy
[your deployment command]

Time: 5-10 minutes

3. Config Updates

Use case: Change timeouts, URLs, feature flags

Pattern:

bash

# Find config
grep -r "TIMEOUT" src/config/

# Change value
const API_TIMEOUT = 60000

# Verify value makes sense
# Deploy
[your deployment command]

Time: 5 minutes

4. Documentation Updates

Use case: Update README, comments, docs

Pattern:

bash

# Update documentation file directly
# No tests needed for pure docs

# Deploy
[your deployment command]

Time: 5 minutes

Anti-Patterns (Don't Do This)

❌ Anti-Pattern 1: Making Multiple Changes

code

"Fix typo in welcome text AND update button color AND adjust padding"

Problem: No longer a quick change. Each change has different risk.

Solution: Escalate to Iterative or make separate Quick changes.

❌ Anti-Pattern 2: Adding Logic

code

"Change timeout from 30s to 60s AND add retry logic"

Problem: "Add retry logic" is not trivial.

Solution: Escalate to Standard workflow.

❌ Anti-Pattern 3: Modifying Multiple Files

code

"Update button text in 5 components"

Problem: Multiple files = higher risk, needs review.

Solution: Escalate to Standard workflow (or make 5 separate Quick changes if truly independent).

❌ Anti-Pattern 4: Skipping Verification

code

Make change → Deploy immediately without checking

Problem: Might deploy broken change.

Solution: Always verify locally first.

Quick Workflow Checklist

Use this checklist for every Quick workflow:

Phase 1: Make Change

• Found the file quickly (< 2 minutes)
• Change is ONE focused thing
• No logic changes
• No new files created
• Verified change locally
• Project conventions followed (check .atlas/conventions.md)

Phase 2: Deploy

• Changelog/release notes updated (if applicable)
• Type checking passes (if ran)
• Deployed using project's deployment script
• No deployment errors
• Change visible in environment

Red Flags (Escalate if ANY are true):

•⚠️ Took > 5 minutes to locate code
•⚠️ Need to modify multiple files
•⚠️ Tests failing
•⚠️ Not sure if change is correct
•⚠️ Need to add new logic
•⚠️ Cross-platform implications

Example: Complete Quick Workflow

Task: "Fix typo in error message"

Phase 1: Make Change (3 minutes)

Step 1: Locate

bash

grep -r "Opertaion faild" src/
# Found: src/services/api/apiClient.js:142

Step 2: Change

javascript

// Before (line 142)
throw new Error('Opertaion faild due to network error')

// After
throw new Error('Operation failed due to network error')

Step 3: Verify

bash

# Quick type check (if applicable)
npm run typecheck
# ✅ Pass

Phase 2: Deploy (2 minutes)

Step 1: Update changelog (if applicable)

markdown

## Title: Fix typo in API error message
### Changes Made:
- Fixed typo: "Opertaion faild" → "Operation failed"

Step 2: Deploy

bash

npm run deploy:dev

# Output:
# ✅ Linting: Pass
# ✅ Type checking: Pass
# ✅ Tests: Pass (15/15)
# ✅ Build: Success
# ✅ Deployed: dev.example.com

Total time: 5 minutes ✅

When NOT to Use Quick Workflow

Don't use Quick if:

•Change affects > 1 file → Use Iterative or Standard
•Need to add tests → Use Standard
•Not sure about impact → Use Standard
•Security-related → Use Standard or Full
•Cross-platform concerns → Use Standard
•Need review/validation → Use Iterative

Default rule: When in doubt, use Standard workflow instead.

Success Indicators

You've succeeded when:

•✅ Deployed in < 15 minutes
•✅ Tests pass (if ran)
•✅ No rollbacks needed
•✅ Change works as expected
•✅ No side effects

You should have escalated if:

•⚠️ Took > 15 minutes
•⚠️ Found edge cases
•⚠️ Tests failed
•⚠️ Needed to change multiple files
•⚠️ Uncertain about correctness

Quick Reference

Quick Workflow Commands:

bash

# Find code
grep -r "search term" src/
find src/ -name "*filename*"

# Verify (adjust for your project)
npm run typecheck    # Type checking
npm run lint         # Linting
npm test             # Tests

# Deploy (use your project's command)
[your deployment command]

Time Allocation:

•Phase 1: 3-10 minutes (locate + change + verify)
•Phase 2: 2-5 minutes (deploy)
•Total: 5-15 minutes

Decision:

•1 file, trivial, no logic → Quick ✅
•2+ files, validation needed → Iterative
•Logic changes, tests needed → Standard

Customization for Your Project

To customize this workflow for your project:

•Create .atlas/conventions.md with your standards
•Update deployment commands in Phase 2 to match your scripts
•Adjust validation commands to match your tooling
•Define your changelog format (if using one)
•Document platform-specific rules (if applicable)

Example .atlas/conventions.md section for Quick workflow:

markdown

## Quick Workflow Conventions

### Deployment
- Command: `./deploy.sh dev`
- Always update: `CHANGELOG.md`
- Pre-deployment: Run `npm run lint && npm test`

### Code Style
- Use ESLint config (no manual formatting)
- Field naming: camelCase for JS, snake_case for DB
- Colors: Only use values from `src/theme/colors.js`

### When to Escalate
- If touching > 1 file
- If tests fail
- If change affects API contracts

Summary

The Quick workflow is for trivial changes only. It's fast because:

•No research phase (you know where the code is)
•No planning phase (change is obvious)
•No review phase (tests cover it)

Use it often for small fixes, but escalate quickly if anything feels non-trivial.

Remember: It's better to start with Quick and escalate than to skip phases in Standard workflow.