shotgun-sh 0.1.0.dev14__py3-none-any.whl → 0.1.0.dev16__py3-none-any.whl

shotgun/artifacts/templates/research/sdk_comparison.yaml

@@ -15,16 +15,16 @@ sections:
         instructions: |
             # What is a good research.overview section?
 
-            •	Clarifies the technical need
-            •	Establishes scope and constraints
-            •	Aligns the team on evaluation criteria
-            •	Sets realistic timeline for decision
+            * Clarifies the technical need
+            * Establishes scope and constraints
+            * Aligns the team on evaluation criteria
+            * Sets realistic timeline for decision
 
             # Questions to ask yourself:
-            •	What problem are we trying to solve with this SDK/library?
-            •	What happens if we make the wrong choice?
-            •	What are our non-negotiable requirements?
-            •	Is there anything specific to our tech stack that constrains choices?
+            * What problem are we trying to solve with this SDK/library?
+            * What happens if we make the wrong choice?
+            * What are our non-negotiable requirements?
+            * Is there anything specific to our tech stack that constrains choices?
 
             # Includes:
               Research Objective: [One clear sentence stating what SDK/library type we need and why]
@@ -50,36 +50,36 @@ sections:
 
             Define technical and business requirements that will guide the evaluation.
 
-            •	Separates must-haves from nice-to-haves
-            •	Includes both functional and non-functional requirements
-            •	Considers team capabilities and constraints
+            * Separates must-haves from nice-to-haves
+            * Includes both functional and non-functional requirements
+            * Considers team capabilities and constraints
 
             # Questions to ask yourself:
-            •	What features are absolutely essential vs. "would be nice"?
-            •	What are our technical constraints (language, platform, licenses)?
-            •	What are our resource constraints (budget, team expertise)?
+            * What features are absolutely essential vs. "would be nice"?
+            * What are our technical constraints (language, platform, licenses)?
+            * What are our resource constraints (budget, team expertise)?
 
             # Includes:
               ## Functional Requirements
               Essential Features:
-                - [Core functionality needed]
-                - [Integration requirements]
-                - [Performance benchmarks]
+                * [Core functionality needed]
+                * [Integration requirements]
+                * [Performance benchmarks]
               
               Nice-to-Have Features:
-                - [Additional capabilities]
-                - [Future-proofing considerations]
+                * [Additional capabilities]
+                * [Future-proofing considerations]
               
               ## Non-Functional Requirements
               Technical Constraints:
-                - Language/Platform: [e.g., Must support TypeScript]
-                - Architecture: [e.g., Must work in serverless environment]
-                - Performance: [e.g., < 50ms latency for operations]
+                * Language/Platform: [e.g., Must support TypeScript]
+                * Architecture: [e.g., Must work in serverless environment]
+                * Performance: [e.g., < 50ms latency for operations]
               
               Business Constraints:
-                - License: [e.g., MIT or Apache 2.0 preferred]
-                - Cost: [e.g., Free for commercial use or < $X/month]
-                - Support: [e.g., Active community or paid support available]
+                * License: [e.g., MIT or Apache 2.0 preferred]
+                * Cost: [e.g., Free for commercial use or < $X/month]
+                * Support: [e.g., Active community or paid support available]
         depends_on:
             - "research.overview"
 
@@ -89,21 +89,21 @@ sections:
 
             Document the process and results of finding available options.
 
-            •	Shows comprehensive search methodology
-            •	Lists all viable candidates with brief descriptions
-            •	Explains why certain options were excluded early
+            * Shows comprehensive search methodology
+            * Lists all viable candidates with brief descriptions
+            * Explains why certain options were excluded early
 
             # Questions to ask yourself:
-            •	Where did we search? (GitHub, npm, package managers, forums)
-            •	What keywords and criteria did we use?
-            •	Are there any industry-standard or popular choices we're missing?
+            * Where did we search? (GitHub, npm, package managers, forums)
+            * What keywords and criteria did we use?
+            * Are there any industry-standard or popular choices we're missing?
 
             # Includes:
               ## Search Methodology
               Sources Consulted:
-                - [Package registries searched]
-                - [Community recommendations]
-                - [Industry reports/comparisons referenced]
+                * [Package registries searched]
+                * [Community recommendations]
+                * [Industry reports/comparisons referenced]
               
               ## Initial Candidates
 
@@ -115,8 +115,8 @@ sections:
 
               ## Early Eliminations
               Excluded Options:
-                - **[Library Name]**: [Reason for exclusion]
-                - **[Library Name]**: [Critical missing feature or constraint violation]
+                * **[Library Name]**: [Reason for exclusion]
+                * **[Library Name]**: [Critical missing feature or constraint violation]
 
         depends_on:
             - "research.requirements"
@@ -127,23 +127,23 @@ sections:
 
             Deep technical analysis of the top candidates.
 
-            •	Provides objective, measurable comparisons
-            •	Includes code examples and API comparisons
-            •	Evaluates developer experience and learning curve
+            * Provides objective, measurable comparisons
+            * Includes code examples and API comparisons
+            * Evaluates developer experience and learning curve
 
             # Questions to ask yourself:
-            •	How easy is it to implement our use case in each option?
-            •	What are the performance characteristics under our expected load?
-            •	How well does each option integrate with our existing stack?
+            * How easy is it to implement our use case in each option?
+            * What are the performance characteristics under our expected load?
+            * How well does each option integrate with our existing stack?
 
             # Includes:
               ## Evaluated Options (Top 3-5 candidates)
 
               ### **Option A: [Name]**
               Technical Architecture:
-                - Core design philosophy
-                - Key abstractions and patterns
-                - Dependencies and size
+                * Core design philosophy
+                * Key abstractions and patterns
+                * Dependencies and size
               
               Code Example:
               ```[language]
@@ -151,15 +151,15 @@ sections:
               ```
               
               Performance Metrics:
-                - Benchmark results
-                - Memory footprint
-                - Bundle size impact
+                * Benchmark results
+                * Memory footprint
+                * Bundle size impact
               
               Developer Experience:
-                - Setup complexity: [Rating]
-                - Documentation quality: [Rating]
-                - API design: [Rating]
-                - Debugging tools: [Rating]
+                * Setup complexity: [Rating]
+                * Documentation quality: [Rating]
+                * API design: [Rating]
+                * Debugging tools: [Rating]
 
               [Repeat for each candidate]
 
@@ -172,21 +172,21 @@ sections:
 
             Side-by-side comparison of all evaluation criteria.
 
-            •	Enables quick visual comparison
-            •	Uses consistent scoring methodology
-            •	Weights criteria by importance
+            * Enables quick visual comparison
+            * Uses consistent scoring methodology
+            * Weights criteria by importance
 
             # Questions to ask yourself:
-            •	Are we comparing apples to apples?
-            •	Is our scoring methodology clear and reproducible?
-            •	Have we weighted criteria appropriately for our use case?
+            * Are we comparing apples to apples?
+            * Is our scoring methodology clear and reproducible?
+            * Have we weighted criteria appropriately for our use case?
 
             # Includes:
               ## Scoring Methodology
-              - 🟢 Excellent (3 points): Exceeds requirements
-              - 🟡 Good (2 points): Meets requirements
-              - 🔴 Poor (1 point): Below requirements
-              - ❌ Missing (0 points): Doesn't support
+              * 🟢 Excellent (3 points): Exceeds requirements
+              * 🟡 Good (2 points): Meets requirements
+              * 🔴 Poor (1 point): Below requirements
+              * ❌ Missing (0 points): Doesn't support
 
               ## Feature Comparison
 
@@ -215,14 +215,14 @@ sections:
 
             Clear recommendation with thorough justification.
 
-            •	States the recommendation unambiguously
-            •	Provides clear rationale tied to requirements
-            •	Addresses concerns and mitigation strategies
+            * States the recommendation unambiguously
+            * Provides clear rationale tied to requirements
+            * Addresses concerns and mitigation strategies
 
             # Questions to ask yourself:
-            •	Will stakeholders understand why we chose this option?
-            •	Have we addressed all major concerns about our choice?
-            •	Is our decision reversible if needed?
+            * Will stakeholders understand why we chose this option?
+            * Have we addressed all major concerns about our choice?
+            * Is our decision reversible if needed?
 
             # Includes:
               ## Recommendation
@@ -236,12 +236,12 @@ sections:
               ## Detailed Justification
               
               ### Why [Selected] Over [Alternative A]
-              - [Specific technical advantage]
-              - [Business consideration]
-              - [Risk mitigation]
+              * [Specific technical advantage]
+              * [Business consideration]
+              * [Risk mitigation]
 
               ### Why [Selected] Over [Alternative B]
-              - [Comparison points]
+              * [Comparison points]
 
               ## Risk Mitigation Plan
 
@@ -250,7 +250,7 @@ sections:
               | [Specific risk] | [How we'll address it] | [Team/Person] |
 
               ## Dissenting Opinions
-              - [Any team concerns and how they were addressed]
+              * [Any team concerns and how they were addressed]
 
         depends_on:
             - "research.comparison_matrix"

shotgun/prompts/agents/partials/interactive_mode.j2

@@ -1,6 +1,13 @@
+
+
+
+!!! CRITICALLY IMPORTANT !!!
+
 {% if interactive_mode -%}
 IMPORTANT: USER INTERACTION IS ENABLED (interactive mode).
 
+- BEFORE GETTING TO WORK, ALWAYS THINK WHAT YOU'RE GOING TO DO AND ask_user() TO ACCEPT WHAT YOU'RE GOING TO DO.
+- ALWAYS USE ask_user TO REVIEW AND ACCEPT THE ARTIFACT SECTION YOU'VE WORKED ON BEFORE PROCEEDING TO THE NEXT SECTION.
 - Don't assume - ask for confirmation of your understanding
 - When in doubt about any aspect of the goal, ASK before proceeding
 
@@ -13,4 +20,6 @@ IMPORTANT: USER INTERACTION IS DISABLED (non-interactive mode).
 - Make reasonable assumptions based on industry best practices
 - Use sensible defaults when specific details are not provided
 - When in doubt, make reasonable assumptions and proceed with best practices
-{% endif %}
+{% endif %}
+
+

shotgun/prompts/agents/plan.j2

@@ -6,18 +6,15 @@ Your job is to help create comprehensive, actionable plans for software projects
 
 ## PLANNING WORKFLOW
 
-For planning tasks:
-1. **Check existing work**: Use `list_artifacts("plan")` to see what plans already exist and create a new one if needed
-2. **Review specifications**: Use `list_artifacts("specify")` and read relevant specifications artifacts
-3. **Consider research**: Use `list_artifacts("research")` and read relevant research artifacts (but specifications drive the plan)
-IF NO SUITABLE ARTIFACT EXISTS:
-  4. **Look for suitable artifact template**: Use `list_artifact_templates("plan")` to see what templates are available.
-  5. **Create new artifact**: Use `create_artifact()` to create a new artifact with the appropriate template or without if you can't find any relevant enough.
-6. **Review specifications**: Use `list_artifacts("specify")` and read relevant specifications artifacts
-   7. **Consider research**: Use `list_artifacts("research")` and read relevant research artifacts (but specifications drive the plan)
-8. **Analyze context**: Understand the current situation and user's goals
-9. **Create structured plans**: Use `write_artifact_section()` to organize planning output
-10. **Build iteratively**: Update and refine plans based on new information
+For PLANNING tasks:
+0. **Check specify**, if any - Consider Existing Artifacts available in specify mode.
+1. **Check existing work**: Consider Existing Artifacts available in plan mode already.
+IF NO SUITABLE ARTIFACT ALREADY EXISTS:
+  2. **Look for suitable artifact template**: Consider Available Artifact Templates available in plan mode.
+  3. **Create new artifact**: Use `create_artifact()` to create a new artifact with the appropriate template or without if you can't find any relevant enough.
+4. **Analyze requirements**: Consider Existing Artifacts available in specify and research modes already.
+5. **Define specifications**: Create detailed technical and functional plans
+6. **Structure documentation**: Use `write_artifact_section()` to organize plans
 
 Use meaningful artifact IDs like: "mvp-roadmap", "migration-strategy", "product-launch"
 

shotgun/prompts/agents/research.j2

@@ -7,11 +7,11 @@ Your job is to help the user research various subjects related to their software
 ## RESEARCH WORKFLOW
 
 For research tasks:
-1. **Check existing work**: ALWAYS first use `list_artifacts("research")` to see what research already exists and read it if it exists and is relevant, not to repeat the work that was already done.
+1. **Check existing work**: Consider "Existing Artifacts" available in research mode already.
 IF NO SUITABLE ARTIFACT ALREADY EXISTS:
-  2. **Look for suitable artifact template**: Use `list_artifact_templates("research")` to see what templates are available.
+  2. **Look for suitable artifact template**: Consider "Available Artifact Templates" available in research mode.
   3. **Create new artifact**: Use `create_artifact()` to create a new artifact with the appropriate template or without if you can't find any relevant enough.
-4. **Analyze previous work**: Use `read_artifact()` to understand what has been done
+4. **Analyze previous work**: Consider "Existing Artifacts" available in research mode already.
 5. **Identify gaps**: Determine what additional research is needed
 6. DO NOT ASSUME YOU KNOW THE ANSWER TO THE QUERY. ALWAYS START WITH GENERIC SEARCHES FIRST, NOT USING NAMES OF THINGS SUGGESTIVE OF THE ANSWER.
 7. **Search strategically**: Use web search to fill knowledge gaps (max 3 searches per session)
@@ -22,6 +22,9 @@ Use meaningful artifact IDs like: "api-design-patterns", "microservices-study",
 
 ## RESEARCH PRINCIPLES
 
+{% if interactive_mode -%}
+- CRITICAL: BEFORE RUNNING ANY SEARCH TOOL, ASK THE USER FOR CONFIRMATION USING ask_user().
+{% endif -%}
 - Build upon existing research rather than starting from scratch
 - Focus on practical, actionable information over theoretical concepts
 - Include specific examples, tools, and implementation details

shotgun/prompts/agents/specify.j2

@@ -9,15 +9,14 @@ Transform requirements into detailed, actionable specifications that development
 ## SPECIFICATION WORKFLOW
 
 For specification tasks:
-1. **Check existing work**: Use `list_artifacts("specify")` to see what specifications already exist
-2. **Review research**: Use `list_artifacts("research")` to see what research already exists.
-IF NO SUITABLE ARTIFACT EXISTS:
-  3. **Look for suitable artifact template**: Use `list_artifact_templates("specify")` to see what templates are available.
-  4. **Create new artifact**: Use `create_artifact()` to create a new artifact with the appropriate template or without if you can't find any relevant enough.
-5. **Analyze requirements**: Understand the functional and non-functional requirements
-6. **Review existing artifacts**: Check research outputs if any with list_artifacts("research")
-7. **Define specifications**: Create detailed technical and functional specifications
-8. **Structure documentation**: Use `write_artifact_section()` to organize specifications
+0. **Check research**, if any - Consider Existing Artifacts available in research mode already.
+1. **Check existing work**: Consider Existing Artifacts available in specify mode already.
+IF NO SUITABLE ARTIFACT ALREADY EXISTS:
+  2. **Look for suitable artifact template**: Consider Available Artifact Templates available in specify mode.
+  3. **Create new artifact**: Use `create_artifact()` to create a new artifact with the appropriate template or without if you can't find any relevant enough.
+4. **Analyze requirements**: Understand the functional and non-functional requirements
+5. **Define specifications**: Create detailed technical and functional specifications
+6. **Structure documentation**: Use `write_artifact_section()` to organize specifications
 
 Use meaningful artifact IDs like: "user-auth-spec", "api-gateway-spec", "data-model-spec"
 

shotgun/prompts/agents/state/artifact_templates_available.j2

@@ -1,6 +1,8 @@
 {% if available_templates %}
 
-## Available Artifact Templates
+## Available Artifact Templates (up to date, no need to check again)
+
+### Below if the current output of list_artifact_templates()
 
 You have access to these pre-built templates for creating structured artifacts:
 

shotgun/prompts/agents/state/existing_artifacts_available.j2

@@ -2,6 +2,8 @@
 
 ## Existing Artifacts (All Modes)
 
+### Below if the current output of list_artifacts()
+
 Work already completed across all agent modes:
 
 {% for mode, artifacts in existing_artifacts.items() %}

shotgun/prompts/agents/tasks.j2

@@ -8,7 +8,7 @@ Your job is to help create and manage actionable tasks for software projects.
 
 For task management:
 1. **Check existing work**: Use `list_artifacts("tasks")` to see what tasks already exist
-2. **Review context**: Use `list_artifacts("plan")` and `list_artifacts("research")` to understand project context
+2. **Review context**: Use `list_artifacts("plan")` and `list_artifacts("specify")` to understand project context
 3. **Analyze requirements**: Understand the current situation and user's task requirements
 4. **Create structured tasks**: Use `write_artifact_section()` to organize task output
 5. **Build incrementally**: Update and refine tasks based on new information

shotgun/prompts/codebase/cypher_query_patterns.j2

@@ -1,3 +1,5 @@
+# FOLLOW THESE PATTERNS TO GENERATE THE CORRECT CYPHER QUERY:
+
 **Pattern: Finding All Classes**
 ```cypher
 // "Find all Python classes" or "list all classes" or "show me all classes"

shotgun/prompts/codebase/partials/graph_schema.j2

@@ -1,7 +1,9 @@
-**1. Graph Schema Definition**
+
+# Codebase Graph Schema Definition
 The database contains information about a codebase, structured with the following nodes and relationships.
 
-Node Labels and Their Key Properties:
+THE ONLY PROPERTIES THAT ARE AVAILABLE ARE THE ONES LISTED BELOW. DO NOT MAKE UP ANY OTHER PROPERTIES.
+PAY ATTENTION TO THE PROPERTY TYPES.
 - Project: {name: string}
 - Package: {qualified_name: string, name: string, path: string}
 - Folder: {path: string, name: string}

shotgun/tui/app.py

@@ -1,5 +1,9 @@
-from textual.app import App
+from collections.abc import Iterable
+from typing import Any
+
+from textual.app import App, SystemCommand
 from textual.binding import Binding
+from textual.screen import Screen
 
 from shotgun.agents.config import ConfigManager, get_config_manager
 from shotgun.logging_config import get_logger
@@ -41,6 +45,7 @@ class ShotgunApp(App[None]):
         logger.debug(f"Update notification received: {notification}")
 
     def on_mount(self) -> None:
+        self.theme = "gruvbox"
         # Track TUI startup
         from shotgun.posthog_telemetry import track_event
 
@@ -88,6 +93,9 @@ class ShotgunApp(App[None]):
             console.print(f"\n[cyan]{self.update_notification}[/cyan]", style="bold")
         self.exit()
 
+    def get_system_commands(self, screen: Screen[Any]) -> Iterable[SystemCommand]:
+        return []  # we don't want any system commands
+
 
 def run(no_update_check: bool = False) -> None:
     """Run the TUI application.

shotgun/tui/commands/__init__.py

@@ -0,0 +1,73 @@
+"""Command handling for the TUI chat interface."""
+
+from collections.abc import Callable
+
+
+class CommandHandler:
+    """Handles slash commands in the TUI chat interface."""
+
+    def __init__(self) -> None:
+        """Initialize the command handler with available commands."""
+        self.commands: dict[str, Callable[[], str]] = {
+            "help": self.get_help_text,
+        }
+
+    def is_command(self, text: str) -> bool:
+        """Check if the text is a command (starts with /)."""
+        return text.strip().startswith("/")
+
+    def parse_command(self, text: str) -> str:
+        """Extract the command name from the text."""
+        text = text.strip()
+        if not text.startswith("/"):
+            return ""
+
+        # Split on whitespace and get the command part
+        parts = text[1:].split()
+        return parts[0] if parts else ""
+
+    def handle_command(self, text: str) -> tuple[bool, str]:
+        """
+        Handle a command and return success status and response text.
+
+        Args:
+            text: The full command text including the leading /
+
+        Returns:
+            Tuple of (success, response_text)
+        """
+        if not self.is_command(text):
+            return False, ""
+
+        command = self.parse_command(text)
+
+        if command in self.commands:
+            response = self.commands[command]()
+            return True, response
+        else:
+            return False, self.get_error_message(command)
+
+    def get_help_text(self) -> str:
+        """Return the help text for the /help command."""
+        return """📚 **Shotgun Help**
+
+**Commands:**
+• `/help` - Show this help message
+
+**Keyboard Shortcuts:**
+• `Enter` - Send message
+• `Ctrl+P` - Open command palette
+• `Shift+Tab` - Cycle agent modes
+• `Ctrl+C` - Quit application
+
+**Agent Modes:**
+• **Research** - Research topics with web search and synthesize findings
+• **Planning** - Create comprehensive, actionable plans with milestones
+• **Tasks** - Generate specific, actionable tasks from research and plans
+
+**Usage:**
+Type your message and press Enter to chat with the AI. The AI will respond based on the current mode."""
+
+    def get_error_message(self, command: str) -> str:
+        """Return a polite error message for unknown commands."""
+        return f"⚠️ Sorry, `/{command}` is not a recognized command. Type `/help` to see available commands."