olympus-ai 4.4.5 → 4.4.6

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "olympus-ai",
-  "version": "4.4.5",
+  "version": "4.4.6",
   "description": "Olympus: Multi-agent orchestration for Claude Code. Summon the gods of code.",
   "author": {
     "name": "mikev10",

package/dist/installer/index.d.ts

@@ -24,7 +24,7 @@ export declare const HOOKS_DIR: string;
 export declare const SETTINGS_FILE: string;
 export declare const VERSION_FILE: string;
 /** Current version - MUST match package.json */
-export declare const VERSION = "4.4.5";
+export declare const VERSION = "4.4.6";
 /** Installation result */
 export interface InstallResult {
     success: boolean;

package/dist/installer/index.js

@@ -40,7 +40,7 @@ export const HOOKS_DIR = join(CLAUDE_CONFIG_DIR, 'hooks');
 export const SETTINGS_FILE = join(CLAUDE_CONFIG_DIR, 'settings.json');
 export const VERSION_FILE = join(CLAUDE_CONFIG_DIR, '.olympus-version.json');
 /** Current version - MUST match package.json */
-export const VERSION = '4.4.5';
+export const VERSION = '4.4.6';
 /**
  * Read a content file from the resources/ directory.
  *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "olympus-ai",
-  "version": "4.4.5",
+  "version": "4.4.6",
   "description": "Olympus: Multi-agent orchestration for Claude Code. Summon the gods of code.",
   "type": "module",
   "main": "dist/index.js",

package/resources/skills/brief/SKILL.md

@@ -23,6 +23,16 @@ Determine which mode to run based on the input:
 
 If the input already contains substantial context (e.g., the user pasted a feature description, a ticket, or a problem statement), extract what you can from it and confirm rather than re-asking. The goal is a conversation, not a questionnaire.
 
+### Thin-Context Handling
+
+When the input is vague or minimal (e.g., "we need password reset" with no further detail), don't generate a brief full of assumptions. Instead:
+
+1. **Generate the brief anyway** — a brief with "Unknown" sections is better than no brief. Fill in what you can reasonably infer from the request itself.
+2. **Mark unknowns explicitly** — for each unknown section, include the specific questions you would have asked. This turns the brief into a structured interview guide for the next conversation. Example: "Unknown — Who is requesting this? What is the business impact? Is there a deadline?"
+3. **Invest in Notes for Elaboration** — when context is thin, this section becomes the most valuable part of the brief. List the open questions, risks, and decisions the elaboration team needs to resolve.
+
+The goal is that even a thin-context brief is useful — it captures what is known, makes the unknowns visible, and gives the team a structured starting point for discussion.
+
 ---
 
 ## Single Mode
@@ -57,7 +67,7 @@ Have a natural conversation to understand the user's intent. You're trying to fi
 
 ### Generating the Brief
 
-Once you have enough context, generate the brief. Don't wait for perfect information — a brief with a few "TBD" sections is better than no brief.
+Once you have enough context, generate the brief. Don't wait for perfect information — a brief with a few "Unknown" sections is better than no brief.
 
 Create the directory if needed, then write the brief:
 
@@ -69,7 +79,7 @@ Create the directory if needed, then write the brief:
 # Intent Brief: [Name]
 
 **Date:** [ISO date]
-**Author:** [who created it — ask if not obvious]
+**Author:** [who created it — ask if not obvious, default to "Unknown" if not provided]
 **Status:** Draft
 
 ## Problem
@@ -143,6 +153,8 @@ Help the user sequence the items. Ask about:
 
 If the user already has a priority order, confirm it rather than re-deriving it.
 
+**Partial priority ordering:** When some items have an explicit priority (e.g., "Mario requested the first 3") but others don't, preserve the explicit ordering for those items and sequence the remaining items using dependency analysis and risk assessment. Explain your reasoning for the inferred positions — the user should understand why item 4 comes before item 5.
+
 ### Step 4: Generate All Briefs
 
 Write each brief to `.olympus/briefs/{kebab-case-name}.md` using the same template as single mode. Include the priority position in each brief's metadata.
@@ -176,7 +188,19 @@ Write the priority-sequenced index:
 [How this collection should be used — e.g., "Feed into March 30th Mob Elaboration session" or "Input for /plan runs on the EZFacility codebase"]
 ```
 
-After generating all briefs and the index, summarize what was created and offer next steps.
+### Step 6: Identify Cross-Brief Dependencies
+
+After generating all briefs, review the full set and identify items that share components, data models, or user flows. Document these in the index under a dedicated section:
+
+```markdown
+## Cross-Brief Dependencies
+
+- **[Brief A] ↔ [Brief B]** — Share [component/data model/user flow]. Elaborate together or sequence A before B.
+```
+
+This prevents the team from elaborating overlapping items in isolation, which leads to conflicting designs and rework during construction.
+
+After generating all briefs, the index, and cross-brief dependencies, summarize what was created and offer next steps.
 
 ---
 
@@ -193,7 +217,7 @@ This integration point will be formalized in a future update to the `/plan` skil
 ## Principles
 
 - **Capture intent, not design.** Briefs describe problems and outcomes. Solutions, architecture, and implementation details belong to `/plan` and Mob Elaboration.
-- **Good enough beats perfect.** A brief with a "TBD" section is better than no brief. The elaboration team will fill gaps — that's their job.
+- **Good enough beats perfect.** A brief with an "Unknown" section is better than no brief. The elaboration team will fill gaps — that's their job.
 - **Respect the user's time.** In batch mode especially, don't ask questions you can infer the answers to. Template similar items. Be efficient.
 - **Standalone value.** A brief should be useful even if `/plan` is never run — it's a communication artifact that helps teams align on what needs to be built and why.
 - **No codebase analysis.** Briefs are business-context documents. Technical discovery, reverse engineering, and architecture decisions happen in `/plan`. Don't read source code or suggest implementations.