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

Phase 1: Make Change  → Locate, change, verify
Phase 2: Deploy       → Test + deploy via quality script

---

Phase 1: Make Change

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

Steps:

1. Locate the code

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

2. Make the change

   • Update the single value/line
   • Keep it simple - if it's getting complex, escalate to Iterative or Standard

3. 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

StackMap-Specific Considerations:

Even for quick changes, follow conventions:

Field naming:

// ✅ CORRECT
activity.text = "New text"
activity.icon = "🏃"

// ❌ WRONG (even for quick changes)
activity.name = "New text"
activity.emoji = "🏃"

Colors:

// ✅ CORRECT (accessibility)
color: '#000000'  // Black text

// ❌ WRONG (gray text not allowed)
color: '#666666'

Typography:

// ✅ CORRECT
<Typography>Hello</Typography>

// ⚠️ OK for quick change (but Typography preferred)
<Text style={{ fontFamily: 'Comic Relief' }}>Hello</Text>

Examples:

Example 1: Fix typo

// Before
<Text>Wellcome to StackMap</Text>

// After
<Text>Welcome to StackMap</Text>

Example 2: Change color

// Before
backgroundColor: '#0000FF'  // Blue

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

Example 3: Update timeout

// Before
const SYNC_TIMEOUT = 30000  // 30 seconds

// After
const SYNC_TIMEOUT = 60000  // 60 seconds

---

Phase 2: Deploy

Goal: Run tests and deploy via quality script.

Steps:

1. Update PENDING_CHANGES.md

   ## Title: Fix welcome message typo
   ### Changes Made:
   - Fixed typo: "Wellcome" → "Welcome"
   

2. Run quick validation

   # Type checking (fast)
   npm run typecheck
   
   # If tests are fast enough, run them
   npm test
   

3. Deploy to QUAL

   ./scripts/deploy.sh qual --all
   

Deployment Checklist:

Pre-deployment:

• PENDING_CHANGES.md updated
• Type checking passes (if applicable)
• Change verified locally

Deployment:

• Use deployment script (not manual commit)
• Deploy to QUAL first
• Check deployment output

Post-deployment:

• No errors in deployment
• Change visible in QUAL environment

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: Deployment script will run tests regardless. If they fail, you'll need to fix them.

---

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:

"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:

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

# Change it
# (Update in editor)

# Verify
# (Visual check in app)

# Deploy
./scripts/deploy.sh qual --all

Time: 5-10 minutes

---

2. Color Changes

Use case: Update colors, adjust styles

Pattern:

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

# Change it
backgroundColor: '#007AFF'

# Verify colors are accessible (no gray text)
# Deploy
./scripts/deploy.sh qual --all

Time: 5-10 minutes

---

3. Config Updates

Use case: Change timeouts, URLs, feature flags

Pattern:

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

# Change value
const SYNC_TIMEOUT = 60000

# Verify value makes sense
# Deploy
./scripts/deploy.sh qual --all

Time: 5 minutes

---

4. Documentation Updates

Use case: Update README, comments, docs

Pattern:

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

# Deploy
./scripts/deploy.sh qual --all

Time: 5 minutes

---

Anti-Patterns (Don't Do This)

❌ Anti-Pattern 1: Making Multiple Changes

"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

"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

"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

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
• StackMap conventions followed (field names, colors, etc.)

Phase 2: Deploy

• PENDING_CHANGES.md updated
• Type checking passes (if ran)
• Deployed to QUAL using 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 sync error message"

Phase 1: Make Change (3 minutes)

Step 1: Locate

grep -r "Sync faild" src/
# Found: src/services/sync/syncService.js:142

Step 2: Change

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

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

Step 3: Verify

# Quick type check
npm run typecheck
# ✅ Pass

Phase 2: Deploy (2 minutes)

Step 1: Update PENDING_CHANGES.md

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

Step 2: Deploy

./scripts/deploy.sh qual --all

# Output:
# ✅ Type checking: Pass
# ✅ Tests: Pass (15/15)
# ✅ Build: Success
# ✅ Deployed: qual-api.stackmap.app

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:

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

# Verify
npm run typecheck

# Deploy
./scripts/deploy.sh qual --all

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

---

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.