olympus-ai 4.5.13 → 4.5.14

package/resources/rules/inception/workspace-detection.md

@@ -1,82 +1,82 @@
-# Workspace Detection
-
-**Purpose**: Determine workspace state and check for existing AI-DLC projects
-
-## Step 1: Check for Existing AI-DLC Project
-
-Check if any `aidlc-docs/*/aidlc-state.md` exists (glob for workflow subdirectories):
-- **If exists**: Resume the most recent workflow (load context from previous phases)
-- **If not exists**: Continue with new project assessment
-
-## Step 2: Count Source Files
-
-Count source files in the workspace to determine brownfield vs greenfield classification.
-Skip `node_modules`, `.git`, `dist`, `build`, and other common non-source directories.
-
-- **3+ source files** → Brownfield
-- **< 3 source files** → Greenfield
-
-Do NOT analyze languages, build systems, or project structure here — Reverse Engineering handles that in depth for brownfield projects.
-
-## Step 3: Determine Next Phase
-
-**IF workspace is empty (no existing code)**:
-- Set flag: `brownfield = false`
-- Next phase: Requirements Analysis
-
-**IF workspace has existing code**:
-- Set flag: `brownfield = true`
-- Check for existing discovery artifacts in `aidlc-docs/{workflowId}/discovery/`
-- **IF reverse engineering artifacts exist**: Load them, skip to Requirements Analysis
-- **IF no reverse engineering artifacts**: Next phase is Reverse Engineering
-
-## Step 4: Create Initial State File
-
-Create `aidlc-docs/{workflowId}/aidlc-state.md`:
-
-```markdown
-# AI-DLC State Tracking
-
-## Project Information
-- **Project Type**: [Greenfield/Brownfield]
-- **Start Date**: [ISO timestamp]
-- **Current Stage**: INCEPTION - Workspace Detection
-
-## Workspace State
-- **Source File Count**: [Number]
-- **Reverse Engineering Needed**: [Yes/No]
-
-## Code Location Rules
-- **Application Code**: Workspace root (NEVER in aidlc-docs/)
-- **Documentation**: aidlc-docs/ only
-- **Structure patterns**: See code-generation.md Critical Rules
-
-## Stage Progress
-[Will be populated as workflow progresses]
-```
-
-## Step 5: Present Completion Message
-
-**For Brownfield Projects:**
-```markdown
-# 🔍 Workspace Detection Complete
-
-• **Project Type**: Brownfield ([N] source files detected)
-• **Next Step**: Proceeding to **Reverse Engineering** to analyze existing codebase...
-```
-
-**For Greenfield Projects:**
-```markdown
-# 🔍 Workspace Detection Complete
-
-Workspace analysis findings:
-• **Project Type**: Greenfield project
-• **Next Step**: Proceeding to **Requirements Analysis**...
-```
-
-## Step 6: Automatically Proceed
-
-- **No user approval required** - this is informational only
-- Automatically proceed to next phase:
-  - **Brownfield**: Reverse Engineering (if no existing artifacts) or Requirements Analysis (if artifacts exist)
-  - **Greenfield**: Requirements Analysis
+# Workspace Detection
+
+**Purpose**: Determine workspace state and check for existing AI-DLC projects
+
+## Step 1: Check for Existing AI-DLC Project
+
+Check if any `aidlc-docs/*/aidlc-state.md` exists (glob for workflow subdirectories):
+- **If exists**: Resume the most recent workflow (load context from previous phases)
+- **If not exists**: Continue with new project assessment
+
+## Step 2: Count Source Files
+
+Count source files in the workspace to determine brownfield vs greenfield classification.
+Skip `node_modules`, `.git`, `dist`, `build`, and other common non-source directories.
+
+- **3+ source files** → Brownfield
+- **< 3 source files** → Greenfield
+
+Do NOT analyze languages, build systems, or project structure here — Reverse Engineering handles that in depth for brownfield projects.
+
+## Step 3: Determine Next Phase
+
+**IF workspace is empty (no existing code)**:
+- Set flag: `brownfield = false`
+- Next phase: Requirements Analysis
+
+**IF workspace has existing code**:
+- Set flag: `brownfield = true`
+- Check for existing discovery artifacts in `aidlc-docs/{workflowId}/discovery/`
+- **IF reverse engineering artifacts exist**: Load them, skip to Requirements Analysis
+- **IF no reverse engineering artifacts**: Next phase is Reverse Engineering
+
+## Step 4: Create Initial State File
+
+Create `aidlc-docs/{workflowId}/aidlc-state.md`:
+
+```markdown
+# AI-DLC State Tracking
+
+## Project Information
+- **Project Type**: [Greenfield/Brownfield]
+- **Start Date**: [ISO timestamp]
+- **Current Stage**: INCEPTION - Workspace Detection
+
+## Workspace State
+- **Source File Count**: [Number]
+- **Reverse Engineering Needed**: [Yes/No]
+
+## Code Location Rules
+- **Application Code**: Workspace root (NEVER in aidlc-docs/)
+- **Documentation**: aidlc-docs/ only
+- **Structure patterns**: See code-generation.md Critical Rules
+
+## Stage Progress
+[Will be populated as workflow progresses]
+```
+
+## Step 5: Present Completion Message
+
+**For Brownfield Projects:**
+```markdown
+# 🔍 Workspace Detection Complete
+
+• **Project Type**: Brownfield ([N] source files detected)
+• **Next Step**: Proceeding to **Reverse Engineering** to analyze existing codebase...
+```
+
+**For Greenfield Projects:**
+```markdown
+# 🔍 Workspace Detection Complete
+
+Workspace analysis findings:
+• **Project Type**: Greenfield project
+• **Next Step**: Proceeding to **Requirements Analysis**...
+```
+
+## Step 6: Automatically Proceed
+
+- **No user approval required** - this is informational only
+- Automatically proceed to next phase:
+  - **Brownfield**: Reverse Engineering (if no existing artifacts) or Requirements Analysis (if artifacts exist)
+  - **Greenfield**: Requirements Analysis

package/resources/rules/operations/operations.md

@@ -1,19 +1,19 @@
-# Operations
-
-**Purpose**: Placeholder for future operational phases (deployment, monitoring, maintenance)
-
-**Status**: This phase is currently a placeholder and will be expanded in future versions.
-
-## Future Scope
-
-The Operations phase will eventually include:
-- Deployment planning and execution
-- Monitoring and observability setup
-- Incident response procedures
-- Maintenance and support workflows
-- Production readiness checklists
-
-## Current State
-
-All build and test activities have been moved to the CONSTRUCTION phase.
-The AI-DLC workflow currently ends after the Build and Test phase in CONSTRUCTION.
+# Operations
+
+**Purpose**: Placeholder for future operational phases (deployment, monitoring, maintenance)
+
+**Status**: This phase is currently a placeholder and will be expanded in future versions.
+
+## Future Scope
+
+The Operations phase will eventually include:
+- Deployment planning and execution
+- Monitoring and observability setup
+- Incident response procedures
+- Maintenance and support workflows
+- Production readiness checklists
+
+## Current State
+
+All build and test activities have been moved to the CONSTRUCTION phase.
+The AI-DLC workflow currently ends after the Build and Test phase in CONSTRUCTION.

package/resources/skills/brief/templates/ai-dlc-intent-brief-template.md

@@ -1,149 +1,149 @@
-# AI-DLC Intent Brief
-
-**Author:** [Your name]
-**Last Updated:** [Date]
-**Status:** Draft | Ready for Mob Elaboration
-**Project Type:** Greenfield | Brownfield
-
----
-
-## Intent
-
-_A clear, concise statement of what you want to build and why. This is the seed the AI decomposes during Inception. Write it the way you'd pitch the problem to a new team member in 60 seconds._
-
-We need to [what the system should do] so that [who benefits] can [outcome achieved], because today [current pain point or gap].
-
-**Example:** We need to build a consolidated reporting engine so that account managers can generate cross-account summaries in minutes instead of hours, because today they manually pull data from three separate systems and lose ~3 hours/week per person.
-
----
-
-## Business Context
-
-### Who is this for?
-
-| Segment | Role / Persona | Why they care |
-|---------|---------------|---------------|
-| Primary | [e.g., Account managers with 5+ accounts] | [e.g., Directly impacted by manual reporting burden] |
-| Secondary | [e.g., Team leads consuming rolled-up data] | [e.g., Need accurate data for planning decisions] |
-
-### What does success look like?
-
-_Don't over-specify metrics yet — the AI will help refine these during Mob Elaboration. Capture the directional outcomes you care about._
-
-- [e.g., Dramatically reduce time spent on manual data pulls]
-- [e.g., Improve accuracy of cross-account reporting]
-- [e.g., High adoption within the first quarter post-launch]
-
----
-
-## Scope Boundaries
-
-### Explicitly Out of Scope
-
-_This is the most important section for preventing AI over-scoping during Inception. Be specific about what you are NOT building._
-
-- [e.g., Custom report builder — planned for a future phase]
-- [e.g., Real-time streaming / live dashboards]
-- [e.g., Third-party data source integrations]
-- [e.g., Changes to the underlying data models in source systems]
-
-### Scope Signals (In Scope, Directional)
-
-_High-level capabilities you expect. The AI will decompose these into stories and units — don't write detailed requirements here._
-
-- [e.g., Automated aggregation across account types A, B, and C]
-- [e.g., Export functionality (CSV, PDF at minimum)]
-- [e.g., Role-based access control]
-
----
-
-## Constraints
-
-_Realities the AI cannot infer. These shape the solution space before any design work begins._
-
-### Technical Constraints
-- [e.g., Must integrate with existing REST APIs for account types A and B]
-- [e.g., Must work within the current frontend framework — no new UI dependencies]
-- [e.g., Database is PostgreSQL 14; no migration budget in this phase]
-
-### Business / Organizational Constraints
-- [e.g., Engineering capacity: 2 backend + 1 frontend for this initiative]
-- [e.g., Must ship before Q3 planning cycle begins]
-- [e.g., Cannot change the existing billing data schema without Finance approval]
-
-### Compliance / Security Constraints
-- [e.g., Data exports must comply with SOC 2 requirements]
-- [e.g., PII must be masked in any shared or exported reports]
-- [e.g., All API endpoints require authentication via existing SSO]
-
----
-
-## Existing System Context
-
-_Critical for brownfield projects. Give the AI enough to understand what it's working with._
-
-### System Landscape
-- [e.g., Monolithic Rails app with a React frontend, deployed on AWS ECS]
-- [e.g., Account data lives in three microservices: accounts-svc, billing-svc, usage-svc]
-- [e.g., Current reporting is a set of ad-hoc SQL queries run manually against a read replica]
-
-### Key Integration Points
-- [e.g., accounts-svc API (stable, documented)]
-- [e.g., billing-svc API (stable, documented)]
-- [e.g., usage-svc API (undocumented, needs a spike)]
-
-### Known Technical Debt or Risks
-- [e.g., usage-svc has no published API contract — will need reverse engineering]
-- [e.g., Read replica has a 15-minute replication lag]
-
-_For greenfield projects, replace this section with a brief note on target platform/stack if known, or mark as "To be determined during Inception."_
-
----
-
-## Dependencies & Risks
-
-| Item | Type | Owner | Impact if Unresolved |
-|------|------|-------|---------------------|
-| [e.g., usage-svc API contract] | Technical | Backend team | Blocks integration work for account type C |
-| [e.g., Design resource availability] | Organizational | Design lead | Delays UI work; may need async review process |
-| [e.g., Data accuracy in source systems] | Data quality | Data team | Garbage-in/garbage-out for consolidated reports |
-
----
-
-## Non-Functional Requirements (Known)
-
-_Capture NFRs you already know. The AI-DLC workflow will evaluate these and may surface additional ones during Inception._
-
-- **Performance:** [e.g., Report generation must complete within 30 seconds for up to 50 accounts]
-- **Availability:** [e.g., Must meet existing platform SLA of 99.9%]
-- **Scalability:** [e.g., Must support up to 200 concurrent users]
-- **Accessibility:** [e.g., Must meet WCAG 2.1 AA]
-- **Observability:** [e.g., Must integrate with existing Datadog monitoring]
-
----
-
-## Stakeholders for Mob Elaboration
-
-_Who needs to be in the room when Inception kicks off?_
-
-| Name | Role | Why they're needed |
-|------|------|--------------------|
-| [Name] | Product Owner | Owns the intent and prioritization decisions |
-| [Name] | Engineering Lead | Technical feasibility and architecture input |
-| [Name] | QA / Test Lead | Acceptance criteria and edge case identification |
-| [Name] | Security / Compliance | Validates NFRs and compliance constraints |
-| [Name] | Ops / DevOps | Deployment and infrastructure considerations |
-
----
-
-## Open Pre-Inception Questions
-
-_Things you need answered BEFORE Mob Elaboration — not questions for the AI to resolve during Inception._
-
-- [ ] [e.g., Has Finance signed off on the billing schema freeze?]
-- [ ] [e.g., Do we have API credentials for the usage-svc staging environment?]
-- [ ] [e.g., Is the design team available for async review during the build phase?]
-
----
-
-_Once this brief is complete and pre-inception questions are resolved, trigger Mob Elaboration. The AI-DLC Inception phase will decompose the Intent into requirements, stories, and units — with the team validating every step._
+# AI-DLC Intent Brief
+
+**Author:** [Your name]
+**Last Updated:** [Date]
+**Status:** Draft | Ready for Mob Elaboration
+**Project Type:** Greenfield | Brownfield
+
+---
+
+## Intent
+
+_A clear, concise statement of what you want to build and why. This is the seed the AI decomposes during Inception. Write it the way you'd pitch the problem to a new team member in 60 seconds._
+
+We need to [what the system should do] so that [who benefits] can [outcome achieved], because today [current pain point or gap].
+
+**Example:** We need to build a consolidated reporting engine so that account managers can generate cross-account summaries in minutes instead of hours, because today they manually pull data from three separate systems and lose ~3 hours/week per person.
+
+---
+
+## Business Context
+
+### Who is this for?
+
+| Segment | Role / Persona | Why they care |
+|---------|---------------|---------------|
+| Primary | [e.g., Account managers with 5+ accounts] | [e.g., Directly impacted by manual reporting burden] |
+| Secondary | [e.g., Team leads consuming rolled-up data] | [e.g., Need accurate data for planning decisions] |
+
+### What does success look like?
+
+_Don't over-specify metrics yet — the AI will help refine these during Mob Elaboration. Capture the directional outcomes you care about._
+
+- [e.g., Dramatically reduce time spent on manual data pulls]
+- [e.g., Improve accuracy of cross-account reporting]
+- [e.g., High adoption within the first quarter post-launch]
+
+---
+
+## Scope Boundaries
+
+### Explicitly Out of Scope
+
+_This is the most important section for preventing AI over-scoping during Inception. Be specific about what you are NOT building._
+
+- [e.g., Custom report builder — planned for a future phase]
+- [e.g., Real-time streaming / live dashboards]
+- [e.g., Third-party data source integrations]
+- [e.g., Changes to the underlying data models in source systems]
+
+### Scope Signals (In Scope, Directional)
+
+_High-level capabilities you expect. The AI will decompose these into stories and units — don't write detailed requirements here._
+
+- [e.g., Automated aggregation across account types A, B, and C]
+- [e.g., Export functionality (CSV, PDF at minimum)]
+- [e.g., Role-based access control]
+
+---
+
+## Constraints
+
+_Realities the AI cannot infer. These shape the solution space before any design work begins._
+
+### Technical Constraints
+- [e.g., Must integrate with existing REST APIs for account types A and B]
+- [e.g., Must work within the current frontend framework — no new UI dependencies]
+- [e.g., Database is PostgreSQL 14; no migration budget in this phase]
+
+### Business / Organizational Constraints
+- [e.g., Engineering capacity: 2 backend + 1 frontend for this initiative]
+- [e.g., Must ship before Q3 planning cycle begins]
+- [e.g., Cannot change the existing billing data schema without Finance approval]
+
+### Compliance / Security Constraints
+- [e.g., Data exports must comply with SOC 2 requirements]
+- [e.g., PII must be masked in any shared or exported reports]
+- [e.g., All API endpoints require authentication via existing SSO]
+
+---
+
+## Existing System Context
+
+_Critical for brownfield projects. Give the AI enough to understand what it's working with._
+
+### System Landscape
+- [e.g., Monolithic Rails app with a React frontend, deployed on AWS ECS]
+- [e.g., Account data lives in three microservices: accounts-svc, billing-svc, usage-svc]
+- [e.g., Current reporting is a set of ad-hoc SQL queries run manually against a read replica]
+
+### Key Integration Points
+- [e.g., accounts-svc API (stable, documented)]
+- [e.g., billing-svc API (stable, documented)]
+- [e.g., usage-svc API (undocumented, needs a spike)]
+
+### Known Technical Debt or Risks
+- [e.g., usage-svc has no published API contract — will need reverse engineering]
+- [e.g., Read replica has a 15-minute replication lag]
+
+_For greenfield projects, replace this section with a brief note on target platform/stack if known, or mark as "To be determined during Inception."_
+
+---
+
+## Dependencies & Risks
+
+| Item | Type | Owner | Impact if Unresolved |
+|------|------|-------|---------------------|
+| [e.g., usage-svc API contract] | Technical | Backend team | Blocks integration work for account type C |
+| [e.g., Design resource availability] | Organizational | Design lead | Delays UI work; may need async review process |
+| [e.g., Data accuracy in source systems] | Data quality | Data team | Garbage-in/garbage-out for consolidated reports |
+
+---
+
+## Non-Functional Requirements (Known)
+
+_Capture NFRs you already know. The AI-DLC workflow will evaluate these and may surface additional ones during Inception._
+
+- **Performance:** [e.g., Report generation must complete within 30 seconds for up to 50 accounts]
+- **Availability:** [e.g., Must meet existing platform SLA of 99.9%]
+- **Scalability:** [e.g., Must support up to 200 concurrent users]
+- **Accessibility:** [e.g., Must meet WCAG 2.1 AA]
+- **Observability:** [e.g., Must integrate with existing Datadog monitoring]
+
+---
+
+## Stakeholders for Mob Elaboration
+
+_Who needs to be in the room when Inception kicks off?_
+
+| Name | Role | Why they're needed |
+|------|------|--------------------|
+| [Name] | Product Owner | Owns the intent and prioritization decisions |
+| [Name] | Engineering Lead | Technical feasibility and architecture input |
+| [Name] | QA / Test Lead | Acceptance criteria and edge case identification |
+| [Name] | Security / Compliance | Validates NFRs and compliance constraints |
+| [Name] | Ops / DevOps | Deployment and infrastructure considerations |
+
+---
+
+## Open Pre-Inception Questions
+
+_Things you need answered BEFORE Mob Elaboration — not questions for the AI to resolve during Inception._
+
+- [ ] [e.g., Has Finance signed off on the billing schema freeze?]
+- [ ] [e.g., Do we have API credentials for the usage-svc staging environment?]
+- [ ] [e.g., Is the design team available for async review during the build phase?]
+
+---
+
+_Once this brief is complete and pre-inception questions are resolved, trigger Mob Elaboration. The AI-DLC Inception phase will decompose the Intent into requirements, stories, and units — with the team validating every step._

package/resources/skills/getting-started/SKILL.md

@@ -1,79 +1,79 @@
----
-description: Guided introduction to Olympus — capabilities overview and your first /plan workflow
----
-
-# Welcome to Olympus
-
-Olympus is a multi-agent orchestration layer for Claude Code. It gives you 20+ specialized AI agents, a structured development workflow (`/plan`), and a self-learning system that improves with every session.
-
-This guide walks you through the key capabilities and gets you to a real result in your project in under 5 minutes.
-
----
-
-## What Olympus Can Do
-
-**Multi-agent orchestration** — Olympus automatically delegates work to specialist agents (architects, searchers, frontend engineers, QA testers) and routes each task to the right model tier (Haiku/Sonnet/Opus) to balance speed and quality.
-
-**`/plan <task>`** — The AI-DLC structured workflow. Olympus interviews you to clarify requirements, produces a written plan you approve, then delegates construction to the right agents. Best for features, refactors, and anything non-trivial.
-
-**`/ultrawork <task>`** — Maximum performance mode. Runs agents in parallel, doesn't wait for confirmation. Use when you need speed and the task is clear.
-
-**`/ascent <task>`** — Persistence loop. Olympus will not stop until every todo is complete. Use when you need guaranteed completion.
-
-**Self-learning** — Olympus records patterns and preferences across sessions. Future runs benefit from what past runs discovered.
-
----
-
-## Your First Real Task
-
-Let's use `/plan` on your actual project right now.
-
-**Step 1 — Open Claude Code in your project directory** (you're likely already there).
-
-**Step 2 — Pick a real task.** Think of something you've been meaning to do:
-- Add a feature or endpoint
-- Refactor a messy module
-- Write tests for an untested area
-- Fix a known bug or improve error handling
-
-**Step 3 — Start the plan.** Type something like:
-
-```
-/plan add input validation to the user registration flow
-```
-
-or
-
-```
-/plan refactor the database layer to use the repository pattern
-```
-
-**What happens next:**
-1. **Inception** — Olympus interviews you with targeted questions to clarify scope, edge cases, and constraints. Answer honestly; vague answers produce vague plans.
-2. **Plan review** — You'll see a written plan before any code is touched. Request changes or approve it.
-3. **Construction** — Olympus delegates implementation to specialist agents. You can watch progress or step away.
-
-The whole cycle for a medium feature takes 15-30 minutes of AI work, with you approving at key checkpoints.
-
----
-
-## Quick Reference
-
-| Command | When to use |
-|---------|-------------|
-| `/plan <task>` | Features, refactors, anything that needs a plan first |
-| `/ultrawork <task>` | Well-defined tasks where speed matters |
-| `/ascent <task>` | Must-complete work — Olympus won't stop until done |
-| `/deepsearch <query>` | Find anything in the codebase |
-| `/analyze <target>` | Deep investigation of a file, function, or bug |
-| `/olympus-default` | Make Olympus your default mode for every session |
-
----
-
-## Next Steps
-
-- Run `/olympus-default` to activate Olympus automatically in every Claude Code session.
-- Run `/plan` on your first real task.
-- Run `/deepsearch` or `/analyze` to explore unfamiliar parts of your codebase.
-
-For full documentation, see the README or run `olympus info`.
+---
+description: Guided introduction to Olympus — capabilities overview and your first /plan workflow
+---
+
+# Welcome to Olympus
+
+Olympus is a multi-agent orchestration layer for Claude Code. It gives you 20+ specialized AI agents, a structured development workflow (`/plan`), and a self-learning system that improves with every session.
+
+This guide walks you through the key capabilities and gets you to a real result in your project in under 5 minutes.
+
+---
+
+## What Olympus Can Do
+
+**Multi-agent orchestration** — Olympus automatically delegates work to specialist agents (architects, searchers, frontend engineers, QA testers) and routes each task to the right model tier (Haiku/Sonnet/Opus) to balance speed and quality.
+
+**`/plan <task>`** — The AI-DLC structured workflow. Olympus interviews you to clarify requirements, produces a written plan you approve, then delegates construction to the right agents. Best for features, refactors, and anything non-trivial.
+
+**`/ultrawork <task>`** — Maximum performance mode. Runs agents in parallel, doesn't wait for confirmation. Use when you need speed and the task is clear.
+
+**`/ascent <task>`** — Persistence loop. Olympus will not stop until every todo is complete. Use when you need guaranteed completion.
+
+**Self-learning** — Olympus records patterns and preferences across sessions. Future runs benefit from what past runs discovered.
+
+---
+
+## Your First Real Task
+
+Let's use `/plan` on your actual project right now.
+
+**Step 1 — Open Claude Code in your project directory** (you're likely already there).
+
+**Step 2 — Pick a real task.** Think of something you've been meaning to do:
+- Add a feature or endpoint
+- Refactor a messy module
+- Write tests for an untested area
+- Fix a known bug or improve error handling
+
+**Step 3 — Start the plan.** Type something like:
+
+```
+/plan add input validation to the user registration flow
+```
+
+or
+
+```
+/plan refactor the database layer to use the repository pattern
+```
+
+**What happens next:**
+1. **Inception** — Olympus interviews you with targeted questions to clarify scope, edge cases, and constraints. Answer honestly; vague answers produce vague plans.
+2. **Plan review** — You'll see a written plan before any code is touched. Request changes or approve it.
+3. **Construction** — Olympus delegates implementation to specialist agents. You can watch progress or step away.
+
+The whole cycle for a medium feature takes 15-30 minutes of AI work, with you approving at key checkpoints.
+
+---
+
+## Quick Reference
+
+| Command | When to use |
+|---------|-------------|
+| `/plan <task>` | Features, refactors, anything that needs a plan first |
+| `/ultrawork <task>` | Well-defined tasks where speed matters |
+| `/ascent <task>` | Must-complete work — Olympus won't stop until done |
+| `/deepsearch <query>` | Find anything in the codebase |
+| `/analyze <target>` | Deep investigation of a file, function, or bug |
+| `/olympus-default` | Make Olympus your default mode for every session |
+
+---
+
+## Next Steps
+
+- Run `/olympus-default` to activate Olympus automatically in every Claude Code session.
+- Run `/plan` on your first real task.
+- Run `/deepsearch` or `/analyze` to explore unfamiliar parts of your codebase.
+
+For full documentation, see the README or run `olympus info`.