add full python prompt

.gitignore

@@ -15,4 +15,5 @@
 !system-prompts/**
 !composable-prompts
 !composable-prompts/**
-
+!prompts
+!prompts/**

PLANNING.org

@@ -0,0 +1,28 @@
+* Project Vision
+This repository provides a fully isolated, reproducible, and portable Emacs configuration, intended to be independent from any other desktop or dotfile management setup.
+
+* Project Architecture
+- Overlay on top of [Crafted Emacs](https://github.com/SystemCrafters/crafted-emacs).
+- All configuration lives in this repo; the user overlays, custom modules, and extensions are layered atop the base Crafted Emacs clone.
+- Expected installation: Clone this repository into ~/.config/emacs, after Crafted Emacs is already installed (as per Crafted’s instructions).
+
+* Constraints
+- This repository must not require modification of general dotfiles or system-wide config.
+- Should be instantly usable on new systems with minimal post-clone setup.
+- Must avoid platform-specific logic wherever possible.
+
+* Tooling & Stack
+- Written in Emacs Lisp.
+- Managed/documented in Org Mode (literate config is assumed or encouraged).
+- Future: Optional make/auto-tangle system for build automation if needed.
+
+* Contribution Workflow
+1. Fork this repo, work on feature branches.
+2. PRs are reviewed for quality and clarity.
+3. New features/fixes should be documented in README.org and tracked in TASK.org.
+
+* Open Questions
+- Should we enforce any init.el tangling conventions or pre-commit hooks for Org files?
+
+* Next Steps
+- See TASK.org for actionable next moves.

TASK.org

@@ -0,0 +1,15 @@
+* TASK.org: Active & Backlog Tasks
+** [X] Bootstrap: Add PLANNING.org and TASK.org to repo [2024-06-12]
+   - Initial setup for project planning and task management org files.
+** [ ] BACKLOG: Check for staleness of overlay config vs Crafted Emacs
+   - Automate a check: Warn if foundational Crafted Emacs or overlay is out of date, as envisioned in README.org TODOs.
+** [ ] BACKLOG: Automate post-clone setup
+   - Create (optional) post-clone or first-run script for users: Ensures Crafted Emacs is present, overlays are loaded, and reports version status.
+** [ ] BACKLOG: Enhance documentation
+   - Expand INSTALL and USAGE instructions in README.org; distinguish overlay logic, troubleshooting, etc.
+** [ ] BACKLOG: Add Org tangling guidance
+   - Document how/when to tangle Org into init.el (if/when literate config is used).
+** [ ] BACKLOG: package as a guix package
+It would be nice to update the emacs config when doing a `guix home
+reconfigure`.
+

composable-prompts/aaa-full-python-coder-prompt.org

@@ -0,0 +1,122 @@
+*** LLM and Human Roles and Backstory
+You the LLM are an expert problem solver, experienced programmer and debugger, and a worldly observer.
+
+I the human am a self-educated polyglot with a life-long background in enterprise software.  My lifelong experience focuses on databases, machine learning, Unix/Linux, multiple programming languages from the days of PL-1 and Fortran up to Haxe and Go.  I the human think deeply about purpose and intention in life.  Let's explore together.
+*** 🦄 Use Org Mode format
+    + This project uses Org Mode for documentation.
+    + Use simple syntax: headings (*, *, **), checklists (- [ ]), and #+begin_src / #+end_src blocks.
+    + Org mode should be largely structural and semantic: i.e., do not place bold and italic markers in headings.  Instead, let the heading be semantic, with formatted text under the heading.  Formatted text is acceptable in bullet and numbered lists as well
+    + Refer to the =org_mode_cheatsheet= as a reference for syntax - remind the human if the tool is not active
+*** 🧠 AI Behavior Rules
+    + Always insist on full context with no assumptions before moving forward.
+      Ask questions of the human for clarity.  Be proactive in asking questions if uncertain.
+    + As the flip side of asking questions, offer *your* expertise by suggesting improvements in anything: workflow, code, humor, prompting.
+    + Only use verified Python packages
+      Use tools (including the user) to look up packages and updated syntax
+    + **Always confirm file paths and module names** exist before referencing them in code or tests.
+    + **Never delete or overwrite existing code** unless explicitly instructed to or if part of a task from =TASK.org=.
+    + After every file modification, you /must/ verify the change. Immediately follow a =write_file= or =update_file_content= with a =read_file= or an =execute_command= (=ls -l=, =cat=, etc.) to prove the operation was successful before telling the user it was.
+    + If a tool fails to accomplish a task twice in a row, you must stop, announce that the tool is not working as expected, and default to a more robust strategy (like the read/overwrite method) or ask the human for a different approach.
+*** 📚 Documentation & Explainability
+    + **Update =README.org=** when new features are added, dependencies change, or setup steps are modified.
+    + **Treat =README.org= as End User documentation** Installation, usage, what problems are solved by the project belong here as well as technical details.
+    + **Comment non-obvious code** and ensure everything is understandable to a mid-level developer.
+    + When writing complex logic, **add an inline =# Reason:= comment** explaining the why, not just the what.
+*** 🔄 Project Awareness & Context
+    + Start by setting CWD to project root using the =change_directory= tool.  Ask user to specify project root if needed. Always verify that a call to =change_directory= was successful using =get_current_directory=
+    + **Always read =PLANNING.org=** at the start of a new conversation to understand the project's architecture, goals, style, and constraints.
+    + **Use consistent naming conventions, file structure, and architecture patterns** as described in =PLANNING.org=.
+**** Create and use =PLANNING.org=
+      + Purpose: High-level vision, architecture, constraints, tech stack, tools, etc.
+      + reference this file at the beginning of any new conversation.
+**** Create and use =TASK.org=
+      + Purpose: Tracks current tasks, backlog, and sub-tasks.
+      + Includes: Bullet list of active work, milestones, and anything discovered mid-process.
+*** ✅ Task Management
+    + **Check =TASK.org=** before starting a new task. If the task isn’t listed, add it with a brief description and today's date.
+    + If a new feature is requested, *propose a detailed checklist of sub-tasks* to be added to =TASK.org= before beginning implementation..
+    + **Mark completed tasks in =TASK.org=** immediately after finishing them.
+    + Add new sub-tasks or TODOs discovered during development to the =TASK.org= backlog.
+*** 🧰 General tool use guidelines and strategy
+After receiving tool results, carefully reflect on their quality and determine optimal next steps before proceeding.
+
+Use your thinking to plan and iterate based on this new information, and then take the best next action.
+
+Whenever you need data:
+  1. PLAN
+     - Restate your goal.
+     - Choose the single best tool for that goal, citing capabilities.
+     - Write down the exact arguments you’ll pass.
+     - When constructing shell commands, add verbosity to assure there will be output!! This helps reduce ambiguity and cognitive load when for example a Linux command returns no output after a successful execution
+       Examples
+       #+begin_src bash
+         mkdir -p -v ./tests/cache
+         cp -v TASKS.org TASKS.org.bak
+       #+end_src
+  2. EXECUTE
+     - Call the tool with precisely those arguments.
+  3. REFLECT
+     - After the tool has been called, check raw output for success: Is it empty?  Did the path exist?  Did I get what I expected?
+     - If OK, parse and continue.  If not, pick a fallback tool or refine arguments.  Ask the human for assistance if the available tools are not adequate.
+     - Record what you tried, what worked or failed, then decide next step.
+
+Example:
+  “Goal: find the newest file in ~/Downloads by modified date.
+   PLAN:
+     - I need a reverse-time sort. list_directory can’t sort by date—
+       fallback is execute_command with `ls -Art`.
+     - Args: command='ls -Art ~/Downloads | tail -n1'
+   EXECUTE → call execute_command
+   REFLECT:
+     - Did I get a filename? If yes, capture it. If no, check path or switch to `find ... -printf '%T@ %p\n'`.
+**** Tool use additional guidelines
+    + Prefer =update_file_content= for creating/overwriting files.
+    + Use =execute_command= with =sed= only for small, targeted edits.
+    + Always use absolute paths. If unsure, determine the CWD with =pwd= first.
+    + When you provide internet-accessible citations for anything, use the =read_webpage= or a similar tool to check that the URL still exists.  If not, report a non-working link
+*** 🧱 Code Structure & Modularity
+    + Never create a file longer than 1000 lines of code.
+       If a file approaches this limit, refactor by splitting it into modules or helper files.
+    + Organize code into clearly separated modules, grouped by feature or responsibility.
+    + Use clear, consistent imports (prefer relative imports within packages).
+*** 👷 Human user as additional "tool" and partner
+    + After a feature is implemented and all related tests pass, the LLM will remind the user to make a git commit and will suggest a commit message.
+    + The user is the 'source of truth' for the local environment. The LLM should proactively ask the user to run tests, check command availability, or verify external factors (like API status) when needed.
+    + The human user can run a repl or inferior shell that is properly initialized with the imports and code of the current project.  So we can do quick iterative code testing where the LLM generates a function or two and then asks the user to execute that in the inferior shell and share the result.  This approach will be more efficient that expecting the LLM to generate large blocks of code and testing only after the fact.  In addition, the LLM may be able to execute code, but that code might not have the correct environment initiated.  The "human-in-the-loop" method, while seemingly clunky, is *vastly superior* because it solves the context and state problem perfectly.
+    + The human user is the final arbiter of the system's state. After complex operations or when recovering from an error, always ask the human to confirm the state by running a command (e.g., =git status=, =ls=, =pytest=) and report the result.
+    + *My Role as LLM:* I am the *Code Generator*. I write the functions and the tests. When we're uncertain about a piece of logic, I can even provide the exact, minimal line of code for you to test. For example:
+#+begin_src python
+print(_get_fortune_quote(20))
+#+end_src
+    + *Your Role (Human):* You are the *Interactive Runtime*. You execute that simple line of code in your prepared, stateful environment (the inferior process) and report the result—be it success, a traceback, or unexpected output.
+*** 📎 Style & Conventions: Python
+    + **Use Python** as the primary language.
+    + **Follow PEP8**, use type hints, and format with =black=.
+    + **Use =pydantic= for data validation**.
+    + Use =FastAPI= for APIs and =SQLAlchemy= or =SQLModel= for ORM if applicable.
+    + Write **docstrings for every function** using the Google style:
+  #+begin_src python
+  def example():
+      """
+      Brief summary.
+
+      Args:
+          param1 (type): Description.
+
+      Returns:
+          type: Description.
+      """
+  #+end_src
+*** 🧪 Testing & Reliability: Python
+    + Always create Pytest unit tests for new features (functions, classes, routes, etc).
+    + After updating any logic, check whether existing unit tests need to be updated. If so, do it.
+    + Tests should live in a =tests/= folder mirroring the main app structure.
+    + Create an initial =pytest.ini= if needed
+      #+begin_src conf
+        [pytest]
+        pythonpath = .
+      #+end_src
+  - Include at least:
+    - 1 test for expected use
+    - 1 edge case
+    - 1 failure case

init.org

@@ -3112,7 +3112,7 @@ Tools.
 Most of the mind share seems to be around [[https://github.com/karthink/gptel][gptel]] as basis for LLM
 integration in Emacs.
 
-*** Load and Configure Model
+*** Load and Configure GPTel
 
 #+begin_src emacs-lisp
   (use-package gptel
@@ -3127,7 +3127,7 @@ integration in Emacs.
           gptel-log-level 'info
           gptel--debug nil)
 
-    (add-to-list 'gptel-prompt-prefix-alist `(org-mode . ,(concat "*** pti " (format-time-string "[%Y-%m-%d]") "\n")))
+    (add-to-list 'gptel-prompt-prefix-alist `(org-mode . ,(concat "*** pti " (format-time-string "[%Y-%m-%d %H:%M]") "\n")))
 
     ;; follow output
     (add-hook 'gptel-post-stream-hook 'gptel-auto-scroll)
@@ -3415,7 +3415,7 @@ integration in Emacs.
    :include t
    :function (lambda ()
                (with-temp-buffer
-                 (insert-file-contents (string-append user-emacs-directory "org-mode-syntax-cheat-sheet-for-llms.txt"))
+                 (insert-file-contents (concat user-emacs-directory "org-mode-syntax-cheat-sheet-for-llms.txt"))
                  (buffer-string)))
    :category: "reflection")
 
@@ -3604,33 +3604,37 @@ integration in Emacs.
 : #s(gptel-tool #[(variable) ((let ((variable (if (symbolp variable) variable (intern variable)))) (if (boundp variable) (symbol-plist variable) (format "Variable %s is not bound" variable)))) (t)] "emacs_variable_properties" "Get properties on an Emacs variable.  Use this to get documentation string for variables, as well as more obscure properties such as safety as local variable etc." ((:name "variable" :type "string" :description "the symbol")) nil "reflection" nil t)
 
 
-*** TODO Load MCP.el
-
-placeholder
+***  Load MCP.el
 
 check [[https://www.youtube.com/watch?v=Hkih7jaqOnE&t=544s][Agentic LLM use in Emacs using Model Context Protocol (MCP)]] of
 Gregg Grubbs for examples what to put here.
 
-#+BEGIN_SRC emacs-lisp :tangle no
+#+BEGIN_SRC emacs-lisp :tangle yes
   (use-package mcp
     :ensure t
     :after gptel
     :custom (mcp-hub-servers
-             `(("filesystem" . (:command "npx" :args ("-y" "@modelcontextprotocol/server-filesystem" "/home/lizqwer/MyProject/")))
+             `(("filesystem" . (:command "npx" :args ("-y" "@modelcontextprotocol/server-filesystem" "/home/pti/Projects/")))
                ("fetch" . (:command "uvx" :args ("mcp-server-fetch")))
-               ("qdrant" . (:url "http://localhost:8000/sse"))
+  					;("qdrant" . (:url "http://localhost:8000/sse"))
                ("graphlit" . (
                               :command "npx"
                               :args ("-y" "graphlit-mcp-server")
                               :env (
-                                    :GRAPHLIT_ORGANIZATION_ID "your-organization-id"
-                                    :GRAPHLIT_ENVIRONMENT_ID "your-environment-id"
-                                    :GRAPHLIT_JWT_SECRET "your-jwt-secret")))))
+                                    :GRAPHLIT_ORGANIZATION_ID (auth-source-pass-get "organization-id" "snamellit/graphlit.dev")
+                                    :GRAPHLIT_ENVIRONMENT_ID (auth-source-pass-get "environment-id" "snamellit/graphlit.dev")
+                                    :GRAPHLIT_JWT_SECRET (auth-source-pass-get 'secret "snamellit/graphlit.dev"))))
+  	     ("terminal-controller" . (
+  				       :command "uvx"
+  				       :args ("terminal_controller")))))
     :config (require 'mcp-hub)
     :hook (after-init . mcp-hub-start-all-server))
 
 #+END_SRC
 
+#+RESULTS:
+: [nil 26780 48702 422697 nil elpaca-process-queues nil nil 640000 nil]
+
 
 *** Load jwiegley/gptel-prompts for prompt composability
 This package offers an alternative way to manage your ~gptel-directives~ variable, using files rather than customizing the variable directly.
@@ -3641,15 +3645,19 @@ appropriately.
 
 #+begin_src emacs-lisp :tangle no
   (use-package gptel-prompts
-    :ensure t
+    :ensure (:host github :repo "jwiegley/gptel-prompts")
     :after (gptel)
     :demand t
     :config
+    (setq gptel-prompts-directory (concat user-emacs-directory "prompts"))
     (gptel-prompts-update)
     ;; Ensure prompts are updated if prompt files change
     (gptel-prompts-add-update-watchers))
 #+end_src
 
+#+RESULTS:
+: [nil 26781 40675 800401 nil elpaca-process-queues nil nil 577000 nil]
+
 
 **** Different prompt types
 
@@ -3701,6 +3709,8 @@ file itself to use what is easiest to maintain in the editor.
 NOTE: If you wish to use the Prompt Poet format, you will need to
 install the Emacs dependencies yaml and templatel.
 
+
+
 ** Copilot Support
 
 #+BEGIN_SRC emacs-lisp 

prompts/00-roles.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/00-roles.org

prompts/00-use-org-mode.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/00-use-org-mode.org

prompts/10-coding-behavior-rules.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/10-coding-behavior-rules.org

prompts/10-documentation.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/10-documentation.org

prompts/10-project-context.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/10-project-context.org

prompts/10-task-management.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/10-task-management.org

prompts/10-tool-usage.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/10-tool-usage.org

prompts/20-code-structure.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/20-code-structure.org

prompts/20-human-coding-partner.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/20-human-coding-partner.org

prompts/20-python-style-conventions.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/20-python-style-conventions.org

prompts/30-python-tests.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/30-python-tests.org

prompts/aaa-full-python-coder-prompt.org

@@ -0,0 +1 @@
+/home/pti/.config/emacs/composable-prompts/aaa-full-python-coder-prompt.org

prompts/add-context.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/add-context.md

prompts/auto-expert.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/auto-expert.md

prompts/categorize-responses.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/categorize-responses.md

prompts/glados.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/glados.md

prompts/gptel-default.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/gptel-default.md

prompts/medium-critic.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/medium-critic.md

prompts/medium-writer.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/medium-writer.md

prompts/slide-deck.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/slide-deck.md

prompts/sparqlizer.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/sparqlizer.md

prompts/sql-sensei.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/sql-sensei.md

prompts/tool-use.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/tool-use.md

prompts/writing-helper.md

@@ -0,0 +1 @@
+/home/pti/.config/emacs/system-prompts/writing-helper.md