siftcode 0.3.0__py3-none-any.whl

siftcode/core/prompts.py

@@ -0,0 +1,215 @@
+"""
+Prompt templates for Siftcode.
+
+All LLM prompts live here so they can be iterated independently of
+the analysis logic. Templates use Python's str.format() syntax.
+"""
+
+from __future__ import annotations
+
+
+# ---------------------------------------------------------------------------
+# System prompts — the "persona" for each analysis stage
+# ---------------------------------------------------------------------------
+
+SYSTEM_ROOT = (
+    "You are a senior software engineer who summarizes projects from their "
+    "directory structure and file names. Be factual and concise.\n\n"
+    "CRITICAL: Only report what you can actually see in the directory "
+    "listing. Do NOT invent common files like setup.py, requirements.txt, "
+    "config.yaml, or Dockerfile unless they appear in the listing. If a "
+    "typical file is missing, say so explicitly rather than assuming it "
+    "exists."
+)
+
+SYSTEM_FILE = (
+    "You are a senior software engineer who analyzes source code files. "
+    "Be precise and factual.\n\n"
+    "CRITICAL: Report only what is literally present in the code. Do NOT "
+    "invent functions, classes, parameters, or interfaces that are not "
+    "shown. If a file imports a module, report the import — do not "
+    "speculate about what that module contains. If you cannot determine "
+    "something from the code, say 'not shown in this file' rather than "
+    "guessing."
+)
+
+SYSTEM_DIRECTORY = (
+    "You are a senior software engineer who summarizes the purpose of a "
+    "directory based on its files. Be concise and factual. Base your "
+    "summary only on the file summaries provided."
+)
+
+SYSTEM_GUIDE = (
+    "You are a technical writer who creates clear, well-organized developer "
+    "guides in Markdown. Write for a developer who is new to the project.\n\n"
+    "CRITICAL RULES:\n"
+    "1. Base every statement on the project analysis provided below. "
+    "Never invent files, functions, or configuration that is not in the "
+    "analysis.\n"
+    "2. If the analysis does not mention a common file (e.g. setup.py, "
+    "requirements.txt), do not assume it exists.\n"
+    "3. If you cannot determine something, write 'Not documented' rather "
+    "than guessing.\n"
+    "4. Report only issues that are directly supported by the analysis. "
+    "If no significant issues are found, write 'No significant issues "
+    "detected.'\n"
+)
+
+
+# ---------------------------------------------------------------------------
+# Root summary
+# ---------------------------------------------------------------------------
+
+ROOT_SUMMARY = """Project directory: {project_dir}
+
+Directory contents (excluding common noise):
+{contents}
+
+Answer these questions in order:
+
+1. **Main language(s)**: What programming language(s) does this project use?
+2. **Project purpose**: What does this project do? Infer from file and directory names.
+3. **Architecture layers**: What are the main layers or components?
+4. **Notable technologies**: What frameworks, libraries, or tools are indicated by config files?
+
+IMPORTANT:
+- List ONLY files that appear in the directory contents above.
+- Do NOT list common file names (setup.py, requirements.txt, config.yaml) unless they are actually in the listing.
+- If a file typically found in this kind of project is MISSING, note it explicitly as missing.
+
+Keep the answer under 300 words.
+"""
+
+
+# ---------------------------------------------------------------------------
+# File analysis
+# ---------------------------------------------------------------------------
+
+FILE_ANALYSIS = """{context}Analyze this file: {path}
+
+Content:
+{content}
+
+Provide:
+
+1. **Purpose** (1-2 sentences)
+2. **Fields/variables**: name and purpose of each
+3. **Functions**: name, inputs, outputs, purpose
+4. **Classes/structs**: name and significance
+5. **Integration**: how this file fits into the project
+
+IMPORTANT:
+- Report only what is literally in this file.
+- Do NOT invent classes, interfaces, or functions that are not shown.
+- If a section has nothing to report, write "none".
+"""
+
+
+# ---------------------------------------------------------------------------
+# Directory summary
+# ---------------------------------------------------------------------------
+
+DIRECTORY_SUMMARY = """Directory: {path}
+
+Files in this directory:
+{file_summaries}
+
+Provide a short summary (2-4 sentences) of:
+1. The purpose of this directory
+2. How the files work together
+3. What a developer should know when working here
+"""
+
+
+# ---------------------------------------------------------------------------
+# Developer guide
+# ---------------------------------------------------------------------------
+
+DEVELOPER_GUIDE = """Based on the project analysis below, create a comprehensive developer guide in Markdown.
+
+{context}
+
+---
+
+# Project analysis
+
+## Root summary
+
+{root_summary}
+
+## Directory summaries
+
+{directory_summaries}
+
+## File summaries
+
+{file_summaries}
+
+---
+
+Create the developer guide with the following structure:
+
+## 1. Executive Summary
+- Project purpose
+- Main technologies
+- Key features
+
+## 2. Architecture
+- High-level overview
+- Key components and their relationships
+- Design patterns observed
+
+## 3. Setup & Installation
+- Prerequisites
+- Installation steps
+- Configuration
+
+## 4. Code Organization
+- Directory structure
+- Purpose of each major directory
+- Key files
+
+## 5. Core Concepts
+- Main abstractions
+- Data models
+- Important interfaces
+
+## 6. Development Workflow
+- Building
+- Testing
+- Running
+
+## 7. API Reference
+- Key functions with signatures and purposes
+- Important classes
+
+## 8. Common Tasks
+- Example workflows
+- Code snippets
+
+STRICT RULES:
+- Use ONLY information from the analysis above. Do not invent files, commands, or APIs.
+- If a section has no useful information from the analysis, write "Not documented" and move on.
+- For the "Setup & Installation" section: report exactly what the analysis shows about dependencies and build tooling. If the project uses pyproject.toml, say so. Do NOT mention requirements.txt or setup.py unless they appear in the analysis.
+- For the "Notable Issues" section: report only issues that are directly visible in the analysis (missing files that are referenced but not present, typos visible in file names, inconsistencies in the analysis data). If you find no significant issues, write exactly: "No significant issues detected."
+- Do NOT invent typos, missing files, or inconsistencies. Only report what the analysis actually shows.
+- Write in Markdown with clear headings and code blocks.
+"""
+
+
+# ---------------------------------------------------------------------------
+# Guide language
+# ---------------------------------------------------------------------------
+
+GUIDE_LANGUAGES = {
+    "en": "English",
+    "fi": "Finnish (suomi)",
+}
+
+
+def guide_language_instruction(language_code: str) -> str:
+    """Return a sentence telling the LLM which language to write in."""
+    if language_code == "en" or language_code not in GUIDE_LANGUAGES:
+        return ""
+    lang = GUIDE_LANGUAGES[language_code]
+    return f"\n\nWrite the entire guide in {lang}."

siftcode/gui/__init__.py

@@ -0,0 +1,9 @@
+"""GTK4 front-end for Siftcode.
+
+All identifiers are re-exported from siftcode._version, which is the
+single source of truth for the application's metadata.
+"""
+
+from siftcode._version import APP_ID, APP_NAME, APP_TAGLINE
+
+__all__ = ["APP_ID", "APP_NAME", "APP_TAGLINE"]