autology-tutorial

Overview

Interactive tutorial in a live git branch. Create real config files, commit them, and watch autology skills trigger naturally.

Duration: ~15 minutes across 3 acts.

Arguments

• /autology:autology-tutorial → Start from Act 1
• /autology:autology-tutorial <1-3> → Jump to specific act
• /autology:autology-tutorial reset → Cleanup (return to original branch, delete tutorial branch, remove tutorial docs)

---

Setup: Create Tutorial Branch

Check for uncommitted changes first:

git status --short

If clean, create the tutorial branch:

ORIGINAL_BRANCH=$(git rev-parse --abbrev-ref HEAD)
git checkout -b tutorial/autology-demo
echo "Saved original branch: $ORIGINAL_BRANCH"

Tell the user: "We're now on tutorial/autology-demo. All tutorial commits happen here. When we're done, we'll return to $ORIGINAL_BRANCH and delete this branch."

Wait for confirmation before Act 1.

---

Act 1: Capture — Decision + Code

The scenario: Design a URL shortener. First architectural decision: storage.

Present the technical analysis to the user:

"We're building a URL shortener. The core operation is mapping short codes to original URLs — pure key-value lookups. Here are the options:

• Redis: O(1) GET/SET, built-in key expiry (TTL), designed for exactly this pattern
• PostgreSQL: relational, flexible — but a full SQL engine for what's essentially a hashmap
• In-memory: fastest, but no persistence — data lost on restart"

Use AskUserQuestion:

question: "Which storage would you choose for the URL shortener?"
options:
  - Redis (Recommended) — O(1) lookups, native TTL, built for key-value
  - PostgreSQL — familiar, flexible, but heavier than needed
  - In-memory — fast but no persistence

When user selects Redis, create docker-compose.yml:

services:
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data

volumes:
  redis_data:

Commit: