### Installing Frontend Node.js Dependencies Source: https://github.com/glebkudr/shotgun_code/blob/main/design/launch.md These commands navigate into the `frontend` directory and then use npm to install all project dependencies defined in `package.json`. After the installation is complete, the terminal navigates back to the project's root directory. ```bash cd frontend npm install cd .. ``` -------------------------------- ### Installing Go Module Dependencies Source: https://github.com/glebkudr/shotgun_code/blob/main/design/launch.md This command cleans up and synchronizes the Go module dependencies listed in the `go.mod` file. It ensures all required modules are downloaded and unused ones are removed, preparing the Go backend for compilation and execution. ```bash go mod tidy ``` -------------------------------- ### Installing Wails CLI with Go Source: https://github.com/glebkudr/shotgun_code/blob/main/design/launch.md This command installs the Wails command-line interface globally using the Go toolchain. It fetches the latest version of the Wails v2 CLI from GitHub and compiles it, making it available in your Go binary path for system-wide use. ```bash go install github.com/wailsapp/wails/v2/cmd/wails@latest ``` -------------------------------- ### Running Shotgun App in Development Mode with Wails Source: https://github.com/glebkudr/shotgun_code/blob/main/design/launch.md This Wails command starts the application in development mode. It builds the Go backend, launches the Vite development server for the frontend, and opens the application window, providing live reloading for frontend changes. ```bash wails dev ``` -------------------------------- ### Installing Wails CLI for Go Development Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command installs the Wails CLI tool, which is essential for developing applications with the Wails framework. It fetches the latest version of the Wails command-line interface from GitHub and installs it into your Go binary path, enabling Wails-specific commands. ```bash go install github.com/wailsapp/wails/v2/cmd/wails@latest ``` -------------------------------- ### Building Shotgun App for Production with Wails Source: https://github.com/glebkudr/shotgun_code/blob/main/design/launch.md This Wails command compiles the application for production. It bundles frontend assets, compiles the Go backend, and creates a standalone executable file (e.g., .exe, .app, or binary) in the `build/bin/` directory, ready for distribution. ```bash wails build ``` -------------------------------- ### Installing Vue Frontend Dependencies Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command installs all required Node.js packages for the Vue.js frontend of the Shotgun application. It reads the `package.json` file in the 'frontend' directory and downloads all listed dependencies, preparing the frontend for development or build. ```bash npm install ``` -------------------------------- ### Navigating to Project Root Directory Source: https://github.com/glebkudr/shotgun_code/blob/main/design/launch.md This command changes the current directory in the terminal to the root of the `shotgun-app` project. It is a necessary step to ensure that subsequent Go and Wails commands are executed from the correct project context. ```bash cd path/to/shotgun-app ``` -------------------------------- ### Shotgun Output Structure Example Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This snippet illustrates the typical directory and file structure of a Shotgun project's output, including core Go application files and frontend Vue components. It also shows the XML-like `` block format used to represent file contents, which is designed for easy parsing by Large Language Models. ```text app/ ├── main.go ├── app.go └── frontend/ ├── App.vue └── components/ └── FileTree.vue (example) package main ... ``` -------------------------------- ### Navigating to Frontend Directory Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command changes the current working directory to the 'frontend' subdirectory within the Shotgun project. This is required to install Node.js dependencies specific to the Vue.js frontend application. ```bash cd frontend ``` -------------------------------- ### Defining AI Prompt Template - JavaScript Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/old_gitDiffPrompt.md This snippet defines a multi-line string constant, `PROMPT_TEMPLATE`, which serves as a detailed prompt for an AI assistant. It outlines the AI's role, primary goal, guiding principles for analysis and code generation, user-defined rules, and the expected file structure for processing user tasks. The template uses placeholders like `{TASK}`, `{RULES}`, and `{FILE_STRUCTURE}` to be dynamically filled. ```JavaScript const PROMPT_TEMPLATE = `## ROLE & PRIMARY GOAL: You are a "Robotic Senior Software Engineer AI". Your mission is to meticulously analyze the user's coding request (\`User Task\`), strictly adhere to \`Guiding Principles\` and \`User Rules\`, comprehend the existing \`File Structure\`, and then generate a precise set of code changes. Your *sole and exclusive output* must be a single patch file. Zero tolerance for any deviation from the specified output format. --- ## 1. User Task {TASK} --- ## 2. Guiding Principles (Your Senior Developer Logic) ### A. Analysis & Planning (Internal Thought Process - Do NOT output this part): 1. **Deconstruct Request:** Deeply understand the \`User Task\` – its explicit requirements, implicit goals, and success criteria. 2. **Identify Impact Zone:** Determine precisely which files/modules/functions will be affected. 3. **Risk Assessment:** Anticipate edge cases, potential errors, performance impacts, and security considerations. 4. **Assume with Reason:** If ambiguities exist in \`User Task\`, make well-founded assumptions based on best practices and existing code context. Document these assumptions internally if complex. 5. **Optimal Solution Path:** Briefly evaluate alternative solutions, selecting the one that best balances simplicity, maintainability, readability, and consistency with existing project patterns. 6. **Plan Changes:** Before generating diffs, mentally (or internally) outline the specific changes needed for each affected file. ### B. Code Generation & Standards: * **Simplicity & Idiomatic Code:** Prioritize the simplest, most direct solution. Write code that is idiomatic for the language and aligns with project conventions (inferred from \`File Structure\`). Avoid over-engineering. * **Respect Existing Architecture:** Strictly follow the established project structure, naming conventions, and coding style. * **Type Safety:** Employ type hints/annotations as appropriate for the language. * **Modularity:** Design changes to be modular and reusable where sensible. * **Documentation:** * Add concise docstrings/comments for new public APIs, complex logic, or non-obvious decisions. * Update existing documentation if changes render it inaccurate. * **Logging:** Introduce logging for critical operations or error states if consistent with the project\'s logging strategy. * **No New Dependencies:** Do NOT introduce external libraries/dependencies unless explicitly stated in \`User Task\` or \`User Rules\`. * **Atomicity of patch contents:** Each patch should represent a small, logically coherent change. * **Testability:** Design changes to be testable. If a testing framework is evident in \`File Structure\` or mentioned in \`User Rules\`, ensure new code is compatible. --- ## 3. User Rules {RULES} --- ## 6. File Structure {FILE_STRUCTURE} `; ``` -------------------------------- ### Example Git Unified Diff Block Structure Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_projectManager.md This snippet illustrates the mandatory structure of a Git unified diff block used for documenting file changes. It demonstrates how to represent context lines, lines to be removed, and lines to be added, along with the necessary header information for file paths, index hashes, and hunk headers specifying line numbers and counts for both old and new file states. ```Git Diff diff --git a/path/to/doc/file.md b/path/to/doc/file.md index .. --- a/path/to/doc/file.md +++ b/path/to/doc/file.md @@ -START_OLD,LINES_OLD +START_NEW,LINES_NEW @@ context line (unchanged) -old line to be removed +new line to be added another context line (unchanged) ``` -------------------------------- ### Diff Structure for Newly Created Files (Diff) Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_makeDiffGitFormat.md This diff snippet demonstrates the format for a newly created file. Key characteristics include `--- /dev/null` for the original file, indicating no prior version, and a hunk header starting with `@@ -0,0 +1,LINES_IN_NEW_FILE @@`. It also includes the `new file mode` and `index` lines, with placeholders for hashes if actual values are not computable. ```Diff diff --git a/relative/path/to/new_file.ext b/relative/path/to/new_file.ext new file mode 100644 index 0000000.. --- /dev/null +++ b/relative/path/to/new_file.ext @@ -0,0 +1,LINES_IN_NEW_FILE @@ +line 1 of new file +line 2 of new file ... ``` -------------------------------- ### Running Shotgun in Development Mode Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command starts the Shotgun application in development mode using the Wails CLI. It enables hot-reloading for Vue.js frontend changes, allowing for rapid iteration. For Go backend code changes, the command needs to be restarted to apply updates. ```bash wails dev ``` -------------------------------- ### Pseudocode Example for Input Data Validation Hypothesis Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_analyzeBug.md This pseudocode snippet demonstrates a conditional check that could be a source of error, specifically related to incorrect input data validation. It highlights how a misconfigured `MAX_VALUE` or an improper comparison could lead to unexpected behavior or bugs, supporting a hypothesis about data validation issues. ```Pseudocode // Example of relevant code if (data.value > MAX_VALUE) { // Possibly, MAX_VALUE is incorrectly defined // ... } ``` -------------------------------- ### Building Shotgun Release Binaries Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command compiles the Shotgun application into release binaries using the Wails CLI. The generated executable files are placed in the `build/bin/` directory, ready for distribution. This process optimizes the application for performance and size. ```bash wails build ``` -------------------------------- ### Managing Go Backend Dependencies Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command synchronizes the Go module dependencies for the backend of the Shotgun application. It adds missing module requirements and removes unused ones, ensuring that all necessary Go packages are available and the `go.mod` and `go.sum` files are clean and up-to-date. ```bash go mod tidy ``` -------------------------------- ### Returning to Project Root Directory Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command navigates back up one directory level from the 'frontend' directory to the root of the 'shotgun_code' project. This is often done to execute commands that affect the entire project or to prepare for running the application from the root. ```bash cd .. ``` -------------------------------- ### Documenting New File Creation - Git Diff - Diff Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_projectManager.md This snippet illustrates the Git diff output for a newly created documentation file. It shows the 'new file mode' and the addition of content, including the required YAML front matter with fields like 'id', 'title', 'created', and 'updated', followed by the document's context. ```diff diff --git a/architecture/path/to/new_ARCH-doc-v1.md b/architecture/path/to/new_ARCH-doc-v1.md new file mode 100644 index 0000000..abcdef0 --- /dev/null +++ b/architecture/path/to/new_ARCH-doc-v1.md @@ -0,0 +1,LINES_IN_NEW_FILE @@ +--- +id: ARCH-... +title: "..." +created: {CURRENT_DATE} # Example: 2024-07-28 +updated: {CURRENT_DATE} # Example: 2024-07-28 +# ... other YAML fields ... +--- +## Context +... ``` -------------------------------- ### Markdown Sections for Task Documents Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_projectManager.md Defines the standard Markdown sections for task documentation files (`TASK-*.md`). These sections include a detailed description of the task, clear acceptance criteria, a definition of done, and a notes section for additional important details. ```Markdown ## Description Brief description of the task from a business or technical necessity perspective. If the task reflects work already done, describe what was done. ## Acceptance Criteria Clear criteria by which task completion can be judged. For tasks reflecting work already done, this is a description of how the functionality works. ## Definition of Done Conditions under which the task is considered fully completed (e.g., code written, tests passed, documentation updated). For "done" tasks, this must be fulfilled. ## Notes Any important details, discussions, links to PRs (if applicable), conclusions. ``` -------------------------------- ### Navigating to Shotgun Project Directory Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command changes the current working directory to the newly cloned 'shotgun_code' repository. It is a necessary step before executing further project-specific commands like dependency management or running the application. ```bash cd shotgun_code ``` -------------------------------- ### YAML Frontmatter for Architecture Documents Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_projectManager.md Defines the metadata structure for architecture documentation files (`ARCH-*.md`). It includes unique identifiers, titles, types, layers, ownership, versioning, status, creation/update dates, tags, and dependencies on other architecture documents. ```YAML --- id: ARCH-UI-print-receipt # Unique identifier without version title: "UI. Print Receipt Button" type: feature # feature | component | service | data_model | etc. layer: presentation # presentation | application | domain | infrastructure | etc. owner: @team-or-person version: v1 # v1, v2, etc. status: current # current | planned | deprecated created: YYYY-MM-DD # File creation date. For new files - {CURRENT_DATE}. For existing files - do not change. updated: {CURRENT_DATE} # Date of last file update (use the provided {CURRENT_DATE}) tags: [ui, pdf] depends_on: [ARCH-service-pdf] # List of IDs of other ARCH documents (without version) referenced_by: [] # DO NOT FILL. This field is managed by an external script, unless otherwise specified in User Rules. --- ``` -------------------------------- ### Cloning Shotgun Code Repository Source: https://github.com/glebkudr/shotgun_code/blob/main/README.md This command clones the Shotgun application's source code repository from GitHub to your local machine. It creates a new directory named 'shotgun_code' containing all project files, serving as the initial step for setting up the development environment. ```bash git clone https://github.com/glebkudr/shotgun_code ``` -------------------------------- ### YAML Frontmatter for Task Documents Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_projectManager.md Specifies the metadata structure for task documentation files (`TASK-*.md`). It includes unique task IDs, titles, status, priority, type, estimates, assignees, dates, parent/child relationships, links to architecture documents, risk, benefit, and an audit log for tracking changes. ```YAML --- id: TASK-2025-001 # Unique task ID title: "Print PDF Receipts" status: in_progress # backlog | ready | in_progress | review | done | blocked priority: high # low | medium | high type: feature # feature | bug | tech_debt | spike | question | chore estimate: 5h # Approximate estimate assignee: @username created: YYYY-MM-DD # Keep the existing creation date if the file already exists. For new files - {CURRENT_DATE}. due: YYYY-MM-DD # (optional) updated: {CURRENT_DATE} # Date of last task file update (use the provided {CURRENT_DATE}) parents: [TASK-ID-parent] # (optional) children: [TASK-ID-child] # (optional) arch_refs: [ARCH-UI-print-receipt, ARCH-service-pdf] # Links to IDs of architecture documents (without version) risk: medium # (optional) benefit: "Will reduce manual time by 80%" # (optional) audit_log: - {date: YYYY-MM-DD, user: "@some-user", action: "created with status backlog"} # Example of an existing entry - {date: {CURRENT_DATE}, user: "@AI-DocArchitect", action: "status → in_progress"} # LLM must add an entry to audit_log when `status` changes. # Also add an entry for significant changes: `assignee`, `priority`, `due_date`, `estimate`, `arch_refs`. # For new task files, the first entry must be: {date: {CURRENT_DATE}, user: "@AI-DocArchitect", action: "created with status "}. # Example: {date: {CURRENT_DATE}, user: "@AI-DocArchitect", action: "priority: low → high"} --- ``` -------------------------------- ### Mermaid.js Sequence Diagram for User Profile Update Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_analyzeBug.md This Mermaid.js sequence diagram illustrates a typical user profile update flow, from a user clicking 'Save' on the frontend to data persistence in the database. It details interactions between the user, frontend, backend controller, service layer, and database, including success and error paths for data saving. ```Mermaid sequenceDiagram participant User participant Frontend participant BackendController participant ServiceLayer participant Database User->>Frontend: Clicks "Save" with data X Frontend->>BackendController: POST /api/profile (data: X) BackendController->>ServiceLayer: updateUser(userId, X) ServiceLayer->>Database: UPDATE users SET ... WHERE id = userId alt Successful save Database-->>ServiceLayer: Rows affected: 1 ServiceLayer-->>BackendController: {success: true} BackendController-->>Frontend: HTTP 200 {success: true} else Error or data not changed Database-->>ServiceLayer: Rows affected: 0 / Error ServiceLayer-->>BackendController: {success: false, error: "..."} BackendController-->>Frontend: HTTP 500 or HTTP 200 {success: false} end ``` -------------------------------- ### Markdown Sections for Architecture Documents Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_projectManager.md Outlines the standard Markdown sections for architecture documentation files (`ARCH-*.md`). These sections cover context, internal structure, behavior, and evolution (planned and historical changes) of the architectural component. ```Markdown ## Context Brief description of the purpose and role of this architectural component in the system. ## Structure Description of the component's internal structure: subcomponents, classes, modules, main code files to which it relates. ## Behavior Main usage scenarios, interactions with other components (`depends_on`), key algorithms, limitations. ## Evolution ### Planned — What is planned to be changed (if applicable, otherwise can be omitted or left empty). ### Historical — Brief chronology of significant version changes (e.g., "v1: Initial design"). ``` -------------------------------- ### Documenting File Deletion - Git Diff - Diff Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_projectManager.md This snippet demonstrates the Git diff output for a deleted documentation file. It indicates the 'deleted file mode' and the removal of the file's entire content, showing the transition from the old file path to /dev/null. ```diff diff --git a/tasks/some-quarter/TASK-ID-old.md b/tasks/some-quarter/TASK-ID-old.md deleted file mode 100644 index abcdef0..0000000 --- a/tasks/some-quarter/TASK-ID-old.md +++ /dev/null @@ -1,LINES_IN_OLD_FILE +0,0 @@ -... old content ... ``` -------------------------------- ### Diff Structure for Deleted Files (Diff) Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_makeDiffGitFormat.md This snippet illustrates the diff format for a file that has been deleted. It features `+++ /dev/null` for the new file, signifying its removal, and a hunk header with `@@ -1,LINES_IN_OLD_FILE +0,0 @@`. The diff also includes `deleted file mode` and `index` lines, using placeholders for mode and hash if the exact values are unknown. ```Diff diff --git a/relative/path/to/deleted_file.ext b/relative/path/to/deleted_file.ext deleted file mode index ..0000000 --- a/relative/path/to/deleted_file.ext +++ /dev/null @@ -1,LINES_IN_OLD_FILE +0,0 @@ -line 1 of old file -line 2 of old file ... ``` -------------------------------- ### Typical File Modification Diff Structure (Diff) Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/prompt_makeDiffGitFormat.md This snippet illustrates the standard unified diff format for a file that has been modified. It shows how context lines, removed lines (prefixed with '-'), and added lines (prefixed with '+') are represented within a hunk. The diff header specifies the original and new file paths, and the hunk header indicates the line ranges affected in both versions. ```Diff diff --git a/relative/path/to/file.ext b/relative/path/to/file.ext index .. --- a/relative/path/to/file.ext +++ b/relative/path/to/file.ext @@ -START_OLD,LINES_OLD +START_NEW,LINES_NEW @@ context line (unchanged) -old line to be removed +new line to be added another context line (unchanged) ``` -------------------------------- ### Defining a File Modification Hunk in Shotgun Diff XML Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/old_prompt_makeDiff5.md This XML snippet defines how a single modified or newly created file, along with its changes, is represented within the Shotgun Diff XML format. It includes a element with a 'path' attribute and one or more elements. Each contains a 'range' attribute specifying original line numbers and a CDATA section holding the unified diff content for the changes. ```XML ``` -------------------------------- ### Representing No Changes in Shotgun Diff XML Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/old_prompt_makeDiff5.md This XML snippet represents the case where no file changes are required. It consists of an empty root element with the specified namespace, indicating that no modifications or new files need to be applied. ```XML ``` -------------------------------- ### Defining File Changes with XML Hunks (XML) Source: https://github.com/glebkudr/shotgun_code/blob/main/design/prompts/old_prompt_makeDiff6.md This XML snippet defines the structure for representing file modifications within a `shotgunDiff` document. It uses a `` element to specify the `path` of the modified file and contains one or more `` elements. Each `` details a specific change range via its `range` attribute and embeds the actual unified diff content within a CDATA section, allowing for precise, non-contiguous updates to a file. ```xml ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.