mcp-tools-py 0.1.3__tar.gz

mcp_tools_py-0.1.3/.claude/Claude.md

@@ -0,0 +1,195 @@
+--- This file is used by Claude Code - similar to a system prompt. ---
+
+# ⚠️ MANDATORY INSTRUCTIONS - MUST BE FOLLOWED ⚠️
+
+**THESE INSTRUCTIONS OVERRIDE ALL DEFAULT BEHAVIORS - NO EXCEPTIONS**
+
+## 🔴 CRITICAL: ALWAYS Use MCP Tools
+
+**MANDATORY**: You MUST use MCP tools for ALL operations when available. DO NOT use standard Claude tools.
+
+**BEFORE EVERY TOOL USE, ASK: "Does an MCP version exist?"**
+
+### Tool Mapping Reference
+
+| Task | ❌ NEVER USE | ✅ USE MCP TOOL |
+|------|--------------|------------------|
+| Read file | `Read()` | `mcp__filesystem__read_file()` |
+| Edit file | `Edit()` | `mcp__filesystem__edit_file()` |
+| Write file | `Write()` | `mcp__filesystem__save_file()` |
+| Run pytest | `Bash("pytest ...")` | `mcp__tools-py__run_pytest_check()` |
+| Run pylint | `Bash("pylint ...")` | `mcp__tools-py__run_pylint_check()` |
+| Run mypy | `Bash("mypy ...")` | `mcp__tools-py__run_mypy_check()` |
+| Git operations | ✅ `Bash("git ...")` | ✅ `Bash("git ...")` (allowed) |
+
+## 🔴 CRITICAL: Code Quality Requirements
+
+**MANDATORY**: After making ANY code changes (after EACH edit), you MUST run ALL THREE code quality checks using the EXACT MCP tool names below:
+
+```
+mcp__tools-py__run_pylint_check
+mcp__tools-py__run_pytest_check
+mcp__tools-py__run_mypy_check
+```
+
+This runs:
+
+- **Pylint** - Code quality and style analysis
+- **Pytest** - All unit and integration tests
+- **Mypy** - Static type checking
+
+**⚠️ ALL CHECKS MUST PASS** - If ANY issues are found, you MUST fix them immediately before proceeding.
+
+### 📋 Pytest Execution Requirements
+
+**MANDATORY pytest parameters:**
+- ALWAYS use `extra_args: ["-n", "auto"]` for parallel execution
+
+**Available markers in pyproject.toml:**
+- `integration`: Integration tests requiring external resources
+
+**RECOMMENDED USAGE:**
+- **Fast unit tests (recommended)**: Use `-m` with `not` expressions to exclude slow integration tests
+- **All tests**: Run without markers to include everything (slow!)
+- **Specific integration tests**: Use specific `markers` parameter when testing integration functionality
+
+**Examples:**
+
+```python
+# RECOMMENDED: Fast unit tests (excludes integration tests)
+mcp__tools-py__run_pytest_check(extra_args=["-n", "auto", "-m", "not integration"])
+
+# All tests including slow integration tests (not recommended for regular development)
+mcp__tools-py__run_pytest_check(extra_args=["-n", "auto"])
+
+# Specific integration tests (only when needed)
+mcp__tools-py__run_pytest_check(extra_args=["-n", "auto"], markers=["integration"])
+```
+
+**Important:** Without the `-m "not integration"` exclusions, pytest runs ALL tests including slow integration tests that may require external resources. For regular development, always use the exclusion pattern as shown in the first example above.
+
+## 📁 MANDATORY: File Access Tools
+
+**YOU MUST USE THESE MCP TOOLS** for all file operations:
+
+```
+mcp__filesystem__get_reference_projects
+mcp__filesystem__list_reference_directory
+mcp__filesystem__read_reference_file
+mcp__filesystem__list_directory
+mcp__filesystem__read_file
+mcp__filesystem__save_file
+mcp__filesystem__append_file
+mcp__filesystem__delete_this_file
+mcp__filesystem__move_file
+mcp__filesystem__edit_file
+```
+
+**⚠️ ABSOLUTELY FORBIDDEN:** Using `Read`, `Write`, `Edit`, `MultiEdit` tools when MCP filesystem tools are available.
+
+### Quick Examples
+
+```python
+# ❌ WRONG - Standard tools
+Read(file_path="src/example.py")
+Edit(file_path="src/example.py", old_string="...", new_string="...")
+Write(file_path="src/new.py", content="...")
+Bash("pytest tests/")
+
+# ✅ CORRECT - MCP tools
+mcp__filesystem__read_file(file_path="src/example.py")
+mcp__filesystem__edit_file(file_path="src/example.py", edits=[...])
+mcp__filesystem__save_file(file_path="src/new.py", content="...")
+mcp__tools-py__run_pytest_check(extra_args=["-n", "auto"])
+```
+
+**WHY MCP TOOLS ARE MANDATORY:**
+
+- Proper security and access control
+- Consistent error handling
+- Better integration with the development environment
+- Required for this project's architecture
+
+## ✍️ Writing Style
+
+**Be concise.** Keep code comments, commit messages, documentation changes, and prompt additions short and direct. If one line works, don't use three.
+
+## 🚨 COMPLIANCE VERIFICATION
+
+**Before completing ANY task, you MUST:**
+
+1. ✅ Confirm all code quality checks passed using MCP tools
+2. ✅ Verify you used MCP tools exclusively (NO `Bash` for code checks, NO `Read`/`Write`/`Edit` for files)
+3. ✅ Ensure no issues remain unresolved
+4. ✅ State explicitly: "All CLAUDE.md requirements followed"
+
+## 🔧 DEBUGGING AND TROUBLESHOOTING
+
+**When tests fail or skip:**
+- Use MCP pytest tool with verbose flags: `extra_args: ["-v", "-s", "--tb=short"]`
+- For integration tests, check if they require external configuration (tokens, URLs)
+- Never fall back to `Bash` commands - always investigate within MCP tools
+- If MCP tools don't provide enough detail, ask user for guidance rather than using alternative tools
+
+## 🔧 MCP Server Issues
+
+**IMMEDIATELY ALERT** if MCP tools are not accessible - this blocks all work until resolved.
+
+## 🔄 Git Operations
+
+**MANDATORY: Before ANY commit:**
+
+```bash
+# ALWAYS run format_all before committing
+./tools/format_all.sh   # Linux/macOS
+tools\format_all.bat    # Windows
+
+# Then verify formatting worked
+git diff  # Should show formatting changes if any
+```
+
+**Format all code before committing:**
+
+- Run `./tools/format_all.sh` (or `tools\format_all.bat` on Windows) to format with black and isort
+- Review the changes to ensure they're formatting-only
+- Stage the formatted files
+- Then commit
+
+**ALLOWED git operations via Bash tool:**
+
+```
+git status
+git diff
+git log
+git fetch
+git ls-tree
+```
+
+**⚠️ Bash discipline (applies to subagents too):**
+
+- No `cd` prefix, no `git -C` — the working directory is already correct. Just `git status`, never `git -C "/some/path" status`.
+- Stick to approved commands above. Avoid unapproved bash commands — they trigger user authorization prompts and interrupt the workflow.
+- Do not chain approved commands with unapproved ones (e.g. `git status && echo "---" && git diff`). The `echo` makes the whole command unapproved. Run approved commands separately instead.
+
+**Git commit message format:**
+
+- Use standard commit message format without advertising footers
+- Focus on clear, descriptive commit messages
+- No Claude Code attribution or links
+
+**Pull Request format:**
+
+- No "Generated with Claude Code" footer or similar attribution
+- Focus on clear summary and test plan
+- Keep PR descriptions concise and professional
+
+## 📏 File Size Check
+
+Check for large files (>750 lines) that may impact LLM context:
+
+```bash
+mcp-coder check file-size --max-lines 750
+mcp-coder check branch-status --llm-truncate
+```
+
+For guidance on splitting large files, consider breaking them into smaller, focused modules.

mcp_tools_py-0.1.3/.claude/agents/commit-pusher.md

@@ -0,0 +1,26 @@
+---
+name: commit-pusher
+description: Commits and pushes code changes with pre-approved git operations
+tools:
+  - Bash
+  - Skill
+permissionMode: bypassPermissions
+---
+
+# Commit-Pusher Agent
+
+You are a commit and push specialist. Invoke the /commit_push skill.
+
+Before committing, verify that only the expected files (as listed in your launch prompt) are modified. If unexpected files are changed, stop and report back.
+
+The working directory is already correct — do not use `cd` or `git -C`.
+
+## Why `bypassPermissions`?
+
+This agent uses `bypassPermissions` so that git add/commit/push commands are auto-approved
+without adding them to the global permissions allow list. This is intentional:
+
+- The **main conversation** must NOT have git add/commit/push permissions
+- Only this agent (reachable via `/commit_push` skill) should be able to commit
+- `acceptEdits` only auto-approves file edit tools (Edit/Write), not Bash commands
+- `bypassPermissions` auto-approves all tool calls within this agent's scope

mcp_tools_py-0.1.3/.claude/commands/check_branch_status.md

@@ -0,0 +1,57 @@
+---
+allowed-tools: Bash(mcp-coder check branch-status *)
+workflow-stage: quality-check
+suggested-next: commit_push, rebase
+---
+
+# Check Branch Status
+
+Check comprehensive branch readiness including CI status, rebase requirements, task completion, and GitHub labels.
+
+## Usage
+
+Call the underlying CLI command with LLM-optimized output and CI waiting:
+
+```bash
+mcp-coder check branch-status --ci-timeout 300 --llm-truncate
+```
+
+## What This Command Does
+
+1. **CI Status Check**: Analyzes latest workflow run and retrieves error logs
+2. **Rebase Detection**: Checks if branch needs rebasing onto main
+3. **Task Validation**: Verifies all implementation tasks are complete
+4. **GitHub Labels**: Reports current workflow status label
+5. **Recommendations**: Provides actionable next steps
+
+## Follow-Up Actions
+
+Based on the status report, use these commands for next steps:
+
+| Status | Action |
+|--------|--------|
+| CI failures | Fix the issues shown in the CI error details |
+| Rebase needed | Run `/rebase` to rebase onto base branch with conflict resolution |
+| Tasks incomplete | Complete remaining tasks manually |
+| CI green + tasks done | Run `/commit_push` to commit and push changes |
+| Ready to merge | Create PR or merge via GitHub |
+
+## Output Format
+
+LLM-optimized output with:
+- CI error logs for failed jobs (truncated to ~300 lines total)
+- Complete status information for all other components
+- Clear status indicators
+- Actionable recommendations
+
+## Integration
+
+This slash command enables interactive workflow management:
+- Check readiness before creating PRs
+- Diagnose CI failures
+- Validate task completion
+- Identify when rebase is needed (then use `/rebase`)
+
+## Rationale
+
+**Rationale**: LLM-driven context benefits from waiting for complete results. The 300-second timeout provides a balance between responsiveness and allowing typical CI runs to complete. No `--fix` by default to let LLM analyze failures and suggest targeted fixes.

mcp_tools_py-0.1.3/.claude/commands/commit_push.md

@@ -0,0 +1,44 @@
+---
+allowed-tools: Bash(git status), Bash(git status *), Bash(git diff *), Bash(git add *), Bash(git commit *), Bash(git push *), Bash(git push), Bash(git log *), Bash(./tools/format_all.sh), Bash(tools/format_all.bat), Read, Glob, Grep
+workflow-stage: utility
+suggested-next: (context-dependent)
+---
+
+# Commit and Push Changes
+
+Follow this process to commit and push your changes:
+
+## 1. Format Code
+```bash
+# Linux/macOS
+./tools/format_all.sh
+
+# Windows
+tools/format_all.bat
+```
+
+## 2. Review Changes
+```bash
+git status
+git diff
+```
+
+## 3. Stage Changes
+Stage all relevant changes (exclude any files that shouldn't be committed).
+
+## 4. Commit
+Create a commit with a clear, conventional commit message:
+- Use format: `type(scope): description`
+- Types: feat, fix, docs, style, refactor, test, chore
+- Keep summary under 50 characters
+- **No Claude Code footer or attribution in commit message**
+
+## 5. Push
+```bash
+git push
+```
+
+If the branch doesn't exist on remote yet:
+```bash
+git push -u origin HEAD
+```

mcp_tools_py-0.1.3/.claude/commands/discuss.md

@@ -0,0 +1,16 @@
+---
+workflow-stage: utility
+suggested-next: (context-dependent)
+---
+
+# Step-by-step Discussion
+
+Interactively walk through all open suggestions, questions, and proposed changes one by one.
+
+Can we go through all open suggested changes and questions step by step?
+You explain, ask and I answer until we discussed all topics?
+Please offer, whenever possible, simple options like
+- A
+- B
+- C
+Always just ask ONE question

mcp_tools_py-0.1.3/.claude/commands/implementation_approve.md

@@ -0,0 +1,20 @@
+---
+allowed-tools: Bash(mcp-coder set-status *)
+workflow-stage: code-review
+suggested-next: (bot runs create_pr) -> merge in GitHub
+---
+
+# Approve Implementation
+
+Approve the implementation and transition the issue to PR-ready state.
+
+**Instructions:**
+1. Run the set-status command to update the issue label:
+```bash
+mcp-coder set-status status-08:ready-pr
+```
+
+2. Confirm the status change was successful.
+**Note:** If the command fails, report the error to the user. Do not use `--force` unless explicitly asked.
+
+**Effect:** Changes issue status from `status-07:code-review` to `status-08:ready-pr`.

mcp_tools_py-0.1.3/.claude/commands/implementation_finalise.md

@@ -0,0 +1,52 @@
+---
+workflow-stage: utility
+suggested-next: implementation_review or implementation_review_supervisor
+---
+
+# Implementation Finalise
+
+Complete any remaining unchecked tasks in the task tracker before transitioning to code review.
+
+## Process
+
+### 1. Read Task Tracker
+
+Read `pr_info/TASK_TRACKER.md` and identify all unchecked tasks (`- [ ]`).
+
+If all tasks are already checked (`- [x]`), report that no finalisation is needed and exit.
+
+### 2. Process Each Unchecked Task
+
+For each unchecked task:
+
+#### Commit Message Tasks
+
+If the task contains "commit message" (case-insensitive):
+
+- if the tasks before are already done, ignore this task by marking it as done `[x]`
+
+#### Other Tasks
+
+- Check `pr_info/steps/` for related step files that provide context
+- If step files don't exist, analyse based on task name and codebase
+- Verify if the task is already complete
+- If not complete: implement the required work
+- If complete or successfully implemented: mark as `[x]`
+- If unable to complete: DO NOT mark as done - explain the issue
+
+### 3. Quality Checks (If Code Changed)
+
+If any code changes were made during this process:
+
+- Run pylint checks using the MCP server (fix all errors)
+- Run pytest checks using the MCP server (fix all failures)
+- Run mypy checks using the MCP server (fix all type errors)
+
+## Output
+
+Report:
+
+1. Which tasks were processed
+2. Which tasks were marked complete
+3. Any issues encountered
+4. Summarize the changes in a commit message and report it

mcp_tools_py-0.1.3/.claude/commands/implementation_needs_rework.md

@@ -0,0 +1,34 @@
+---
+allowed-tools: Bash(mcp-coder set-status *)
+workflow-stage: code-review
+suggested-next: (bot runs implement) -> /clear -> implementation_review or implementation_review_supervisor
+---
+
+# Return to plan-ready after major review issues
+
+Transitions the issue back to `plan-ready` status for re-implementation when code review identifies major issues that cannot be fixed with minor changes.
+
+## When to Use
+
+| Situation | Action |
+|-----------|--------|
+| Minor fixes | Fix directly, re-run `/implementation_review` or `/implementation_review_supervisor` |
+| **Major issues** | **This command** (after `/implementation_new_tasks` + `/commit_push`) |
+| Approved | `/implementation_approve` |
+
+## Prerequisites
+
+- New implementation steps created (`/implementation_new_tasks`)
+- Changes committed and pushed (`/commit_push`)
+
+## Instructions
+
+```bash
+mcp-coder set-status status-05:plan-ready
+```
+
+Confirm the status change was successful. If it fails, report the error. Do not use `--force` unless explicitly asked.
+
+## Next Steps
+
+Run `mcp-coder implement` to process the new steps, then `/implementation_review` or `/implementation_review_supervisor`.

mcp_tools_py-0.1.3/.claude/commands/implementation_new_tasks.md

@@ -0,0 +1,31 @@
+---
+workflow-stage: code-review
+suggested-next: commit_push -> implementation_needs_rework
+---
+
+# Create Further Implementation Tasks
+
+Append new implementation tasks to the project plan after code review identified areas needing additional work.
+
+## Instructions
+
+Please expand the **implementation plan** stored under `pr_info/steps`
+Update the `pr_info/steps/Decisions.md` with the decisions we took.
+Please create additional self-contained steps (`pr_info/steps/step_1.md`, `pr_info/steps/step_2.md`, etc.).
+Please update the **summary** (`pr_info/steps/summary.md`).
+
+### Requirements for the new implementation steps:
+- Follow **Test-Driven Development** where applicable.
+  Each step should have its own test implementation followed by related functionality implementation.
+- Each step must include a **clear LLM prompt** that references the summary and that specific step
+- Apply **KISS principle** - minimize complexity, maximize maintainability
+- Keep code changes minimal and follow best practices
+
+### Each Step Must Specify:
+- **WHERE**: File paths and module structure
+- **WHAT**: Main functions with signatures
+- **HOW**: Integration points (decorators, imports, etc.)
+- **ALGORITHM**: 5-6 line pseudocode for core logic (if any)
+- **DATA**: Return values and data structures
+
+Please also update the task tracker (`pr_info/TASK_TRACKER.md`).

mcp_tools_py-0.1.3/.claude/commands/implementation_review.md

@@ -0,0 +1,45 @@
+---
+allowed-tools: Bash(git fetch *), Bash(git fetch), Bash(git status), Bash(git diff *), Read, Glob, Grep
+workflow-stage: code-review
+suggested-next:
+  - discuss -> commit_push -> implementation_approve
+  - discuss -> implementation_new_tasks -> commit_push -> implementation_needs_rework
+---
+
+# Implementation Review (Code Review)
+
+**First, ensure we're up to date:**
+```bash
+git fetch
+git status
+```
+
+Confirm and display the current feature branch name.
+
+---
+
+**Then run the code review:**
+
+## Code Review Request
+
+Run this command to get the changes to review:
+```bash
+git diff --unified=5 --no-prefix main...HEAD -- . ":(exclude)pr_info/.conversations/**"
+```
+
+No need to run all checks; do not use pylint warnings. Feel free to further analyse any mentioned files and/or the file structure.
+
+### Focus Areas:
+- Logic errors or bugs
+- Tests for `__main__` functions should be removed (not needed)
+- Unnecessary debug code or print statements
+- Code that could break existing functionality
+- Compliance with existing architecture principles, see `docs/architecture/architecture.md`
+
+### Output Format:
+1. **Summary** - What changed (1-2 sentences)
+2. **Critical Issues** - Must fix before merging
+3. **Suggestions** - Nice to have improvements
+4. **Good** - What works well
+
+Do not perform any action. Just present the code review.

mcp_tools_py-0.1.3/.claude/commands/implementation_review_supervisor.md

@@ -0,0 +1,54 @@
+---
+workflow-stage: code-review
+suggested-next: implementation_approve or implementation_needs_rework
+---
+
+# Automated Implementation Review (Code Review) / using a supervisor agent
+
+You are a technical lead supervising a software engineer (subagent). You do not write code or use development tools yourself — you delegate all implementation work to the engineer.
+
+**Setup:**
+
+1. Read the knowledge base files:
+   - `.claude/knowledge_base/principles.md`
+   - `.claude/knowledge_base/python.md`
+2. Check for existing `pr_info/implementation_review_log_*.md` files to determine the next run number `{n}`.
+3. Create `pr_info/implementation_review_log_{n}.md` with a header.
+
+**Your Role:**
+
+- **Delegate**: Launch subagents to do the work. Do not execute code, read files, or run tests yourself.
+- **Triage**: Assess each review finding against the knowledge base. Skip items that are out of scope, cosmetic, or speculative. Only escalate to the user when you're unsure or a major refactoring is needed.
+- **Guide**: For each accepted finding, give the engineer a clear, specific instruction. For rejected findings, briefly state why (referencing the relevant principle).
+- **Scope**: Stay close to the relevant issue. Don't let the review drift into unrelated improvements.
+
+**Prerequisites:**
+
+- **Code must exist.** If the review subagent reports there is no implementation diff (only plan files, docs, or pr_info/), stop immediately and tell the user there is nothing to review yet.
+
+**Workflow:**
+
+1. Launch a new engineer subagent → `/implementation_review`
+2. `/discuss` the findings — triage each item, decide accept/skip
+3. Tell the engineer to implement the accepted changes. If a major refactoring is needed, stop and talk to the user.
+4. Update `pr_info/implementation_review_log_{n}.md` with this round's findings, decisions, and changes.
+5. Collect from the engineer: which files were changed, what was done, and a suggested commit message. Then launch the **commit agent** with this context. The commit agent should verify only the expected files are modified before committing.
+6. Launch the engineer → `/check_branch_status`
+7. **If no code was changed this round, go to step 8.** Otherwise, launch a fresh engineer subagent (new context) and repeat from step 1.
+8. Add a `## Final Status` section to the log. Commit and push the log via the **commit agent**.
+9. Launch the engineer → `/check_branch_status` to verify CI, rebase need, and overall readiness. Include the result in the completion message.
+10. Notify the user with a short completion message: rounds run, commits produced, whether any issues remain, and branch status (CI, rebase needed).
+
+**Review Log Format** (each round appended to `pr_info/implementation_review_log_{n}.md`):
+
+```
+## Round {r} — {date}
+**Findings**: {bulleted list of items from review}
+**Decisions**: {accept/skip with brief reason for each}
+**Changes**: {what was implemented}
+**Status**: {committed / no changes needed}
+```
+
+**Subagent instructions:** Remind subagents to follow CLAUDE.md (MCP tools, no `cd` prefix, approved commands only).
+
+**Escalation:** If you have questions or are unsure about a significant technical decision, ask the user. For borderline Accept/Skip findings, default to better code quality rather than asking — only escalate when the fix has meaningful scope or risk, not for trivial changes in either direction.

mcp_tools_py-0.1.3/.claude/commands/issue_analyse.md

@@ -0,0 +1,30 @@
+---
+workflow-stage: issue-discussion
+suggested-next: discuss -> issue_update -> issue_approve
+---
+
+# Analyse GitHub Issue
+
+Fetch a GitHub issue and analyze its requirements, feasibility, and potential implementation approaches.
+
+## Instructions
+
+First, fetch the issue details:
+```bash
+gh issue view $ARGUMENTS
+```
+
+Then analyze the issue:
+
+Can we discuss this requirement / implementation idea and its feasibility?
+Please also look at the code base to understand the context (using the different tools with access to the project directory).
+Do not provide code yet!
+
+At the end of our discussion, I want to have an even better issue description.
+
+**Focus on:**
+- Understanding the problem/feature request
+- Technical feasibility
+- Potential implementation approaches
+- Questions that need clarification
+- Impact on existing code

mcp_tools_py-0.1.3/.claude/commands/issue_approve.md

@@ -0,0 +1,26 @@
+---
+allowed-tools: Bash(gh issue comment *), Read, Bash(MSYS_NO_PATHCONV=1 gh issue comment *)
+workflow-stage: issue-discussion
+suggested-next: (bot runs create_plan) -> /clear -> plan_review
+---
+
+# Approve Issue
+
+Approve the current issue to transition it to the next status in the workflow.
+
+**Instructions:**
+
+1. If no issue context is found from prior `/issue_analyse` or `/issue_create`, respond: "No issue context found. Please run `/issue_analyse <number>` or `/issue_create` first."
+
+2. Validate that the issue is ready for approval:
+   - Issue has been analyzed/discussed
+   - Requirements are clear
+   - No blocking questions remain
+
+3. Comment `/approve` on the issue (use MSYS_NO_PATHCONV to prevent Windows Git Bash path conversion):
+
+```bash
+MSYS_NO_PATHCONV=1 gh issue comment <issue_number> --body "/approve"
+```
+
+This triggers the GitHub Action to promote the issue status (e.g., `status-01:created` → `status-02:awaiting-planning`).

mcp_tools_py-0.1.3/.claude/commands/issue_create.md

@@ -0,0 +1,22 @@
+---
+allowed-tools: Bash(gh issue create *)
+workflow-stage: issue-discussion
+suggested-next: discuss -> issue_update -> issue_approve
+---
+
+# Create GitHub Issue
+
+Based on our prior discussion, create a GitHub issue.
+
+**Instructions:**
+1. Extract the issue title and body from the conversation context
+2. Use a clear, descriptive title
+3. Include relevant details from our discussion in the body
+4. Use markdown formatting for better readability
+
+**Create the issue using:**
+```bash
+gh issue create --title "TITLE" --body "BODY"
+```
+
+If no prior discussion context is found, respond: "No discussion context found. Please discuss the feature or bug first before creating an issue."