feat: Enhance project setup and add prompt style matching

.athignore

@@ -340,7 +340,9 @@ docs/_site/
 ###############################################################################
 # ATHANOR PROJECT FILES
 ###############################################################################
+!/.ath_materials/**/*
 /.ath_materials/project_graph.json
+/.ath_materials/project_settings.json
 
 ###############################################################################
 # PROJECT FILES

.gitignore

@@ -30,4 +30,12 @@ Thumbs.db
 codebase.md
 
 # Temporary folder
-/temp-folder
+/temp-folder
+
+###############################################################################
+# ATHANOR PROJECT FILES
+###############################################################################
+/.ath_materials/**/*
+!/.ath_materials/prompts/
+!/.ath_materials/prompts/**/*
+!/.ath_materials/project_settings.json

CHANGELOG.md

@@ -9,6 +9,22 @@ and this project aims to adhere to [Semantic Versioning](https://semver.org/spec
 
 _(Future changes will go here)_
 
+## [0.7.5] - 2025-06-28
+
+### Added
+
+- An option is now available in the project creation dialog to append default Athanor ignore rules to the project's `.gitignore` file. ([81b0a65](https://github.com/lacerbi/athanor/commit/81b0a65))
+- Style matching has been introduced to writing prompts to improve the consistency of AI-generated content. ([456ed28](https://github.com/lacerbi/athanor/commit/456ed28))
+
+### Changed
+
+- Updated and expanded the main `PROJECT.md` documentation. ([1f5ceac](https://github.com/lacerbi/athanor/commit/1f5ceac))
+- Created a new `docs/design` directory to better organize design specification documents. ([bb0d6a4](https://github.com/lacerbi/athanor/commit/bb0d6a4))
+
+### Fixed
+
+- Corrected various style comments in the codebase. ([16a92a8](https://github.com/lacerbi/athanor/commit/16a92a8))
+
 ## [0.7.4] - 2025-06-24
 
 ### Added

package.json

@@ -1,6 +1,6 @@
 {
   "name": "athanor",
-  "version": "0.7.4",
+  "version": "0.7.5",
   "bugs": {
     "url": "https://github.com/lacerbi/athanor/issues"
   },

resources/files/default_athignore

@@ -369,7 +369,11 @@ docs/_site/
 ###############################################################################
 # ATHANOR PROJECT FILES
 ###############################################################################
-# Athanor system files
+# Athanor materials folder is visible (as a separate node in the file manager)
+!/.ath_materials/**/*
+
+# Athanor configuration files are hidden
 /.ath_materials/project_graph.json
+/.ath_materials/project_settings.json
 
 # Put other files or folders below

resources/files/default_gitignore_extras

@@ -0,0 +1,7 @@
+###############################################################################
+# ATHANOR PROJECT FILES
+###############################################################################
+/.ath_materials/**/*
+!/.ath_materials/prompts/
+!/.ath_materials/prompts/**/*
+!/.ath_materials/project_settings.json

resources/prompts/prompt_writer.xml

@@ -27,6 +27,44 @@ Use the included project instructions as a general guide.
 
 # Instructions
 
+## Writing Style Matching
+
+When editing existing text or when the user provides a sample/excerpt:
+
+**Carefully analyze and match the writing style**, including:
+
+- **Register**: Match the level of formality (casual, conversational, professional, academic)
+- **Tone & Voice**: Match perspective (first/second/third person), authorial stance, and emotional coloring
+- **Humor & Personality**: 
+  - Preserve any wit, sarcasm, or playfulness
+  - Match the use of jokes, puns, or cultural references
+  - Maintain the same level of seriousness or levity
+- **Sentence Structure**: Replicate patterns of sentence length, complexity, and rhythm
+- **Vocabulary**: Use similar word choices, idioms, colloquialisms, and technical terminology level
+- **Paragraph Structure**: Match typical paragraph lengths and organizational patterns
+- **Stylistic Elements**: Preserve any distinctive features like:
+  - Use of rhetorical questions or exclamations
+  - Metaphors, similes, or analogies
+  - Lists vs. prose
+  - Transition phrases and connectives
+  - Punctuation habits (e.g., em dashes, semicolons, Oxford commas, ellipses)
+  - Parenthetical asides or footnote style
+- **Cultural & Regional Language**: Match any specific dialect, spelling conventions (US/UK), or cultural expressions
+- **Formatting Conventions**: Follow existing patterns for headings, emphasis, spacing, capitalization
+- **Markup & Environment Usage**: Match the document's formatting approach:
+  - Plain text (no markup)
+  - Markdown (and which flavor - CommonMark, GFM, etc.)
+  - HTML tags and attributes
+  - reStructuredText
+  - AsciiDoc
+  - Wiki markup
+  - Mixed environments (e.g., Markdown with HTML)
+  - Code block languages and formatting
+
+**Note**: The above are examples of stylistic elements to consider. The goal is to **match the writing style holistically** - capturing not just individual elements but the overall feel, flow, and character of the text. Pay attention to subtle patterns and combinations that create the unique voice of the existing content.
+
+If no sample is provided but you're editing existing text, analyze the surrounding content to maintain consistency throughout the document.
+
 ## Response Formats
 
 You will respond with 2 sections: A summary section and one or more XML section(s).
@@ -206,6 +244,41 @@ Use the included project instructions as a general guide.
 
 # Instructions
 
+## Writing Style Matching
+
+When editing existing LaTeX documents or when the user provides a sample/excerpt:
+
+**Carefully analyze and match the writing style**, including:
+
+- **Register & Academic Tone**: Match the level of formality (conversational academic, formal academic, technical report)
+- **Authorial Voice**: 
+  - Preserve any personality or humor in explanations
+  - Match the use of "we" vs passive voice vs imperative mood
+  - Maintain pedagogical style (if teaching) or research style (if presenting findings)
+- **Mathematical Presentation**: Follow existing patterns for:
+  - Inline vs. display equations
+  - Notation conventions and variable naming
+  - Theorem/proof formatting and numbering
+  - Definition and example styles
+  - Level of mathematical rigor and detail
+- **Citation Style**: Match existing citation patterns (parenthetical, narrative, etc.)
+- **Document Structure**: Preserve sectioning conventions, numbering schemes, and organizational patterns
+- **LaTeX-Specific Style**:
+  - Macro usage patterns
+  - Spacing commands (e.g., `\,` vs `~` vs `\ `)
+  - Environment choices (e.g., `align` vs `equation` vs `gather`)
+  - Label naming conventions
+  - Comment style, frequency, and language
+  - Use of packages and custom commands
+- **Prose Elements**: 
+  - Match sentence structure and complexity
+  - Preserve any colloquialisms or field-specific jargon
+  - Maintain transitions between mathematical and prose sections
+  - Match explanation depth and pedagogical approach
+- **Cultural & Field Conventions**: Respect discipline-specific writing norms (e.g., physics vs pure mathematics vs computer science)
+
+If no sample is provided but you're editing existing text, analyze the surrounding content to maintain consistency throughout the document.
+
 ## LaTeX formatting
 
 ### Math conventions
@@ -373,161 +446,4 @@ instructing them to select the files from the Athanor file manager.
 </current_task>
 </ath_prompt_variant>
 
-<ath_prompt_variant 
-    id="full-update"
-    label="Full file updates"
-    tooltip="Writing prompt asking models to provide full files (no diffs)">
-<system_prompt>
-You are an expert software engineer.
-
-You are tasked with following my instructions.
-
-Use the project instructions included below as a general guide.
-
-# Instructions
-
-## Tracking File State During Edits
-
-To prevent errors, you must correctly track the "current state" of each file as it's edited during our conversation.
-
-Your edits are considered **proposals**. The user's feedback determines if your proposal becomes the new official state.
-
--   **Implicit Acceptance is the Default:** If the user continues with a new instruction without rejecting your proposal, you MUST assume your changes were accepted. The new official state is now your last proposed version.
--   **Handling Rejection:** If the user explicitly rejects your proposal (e.g., "no, that's wrong," "undo that"), you MUST discard your proposal and revert to the state *before* you made the change.
--   **User Input is Final:** If the user provides a new file themselves, that version immediately becomes the official state, overriding any of your proposals.
-
-**In short: Your last edit becomes the new baseline, UNLESS the user rejects it or provides a new version.**
-
-## Response Formats
-
-You will respond with 2 sections: A summary section and one or more XML section(s).
-
-### Summary section
-
-- Provide a brief overall summary
-- Provide a 1-sentence summary for each file changed and why
-- Provide a 1-sentence summary for each file deleted and why
-- Format this section as markdown
-
-### XML sections
-
-- Respond with the XML block(s) and nothing else
-- Include all of the changed files
-- Specify each file operation with CREATE, UPDATE_FULL, or DELETE
-- Each file should include a brief change summary
-- Include the full file path
-- Put the XML block inside markdown codeblocks
-- Make sure to enclose the file content with ![CDATA[__FILE CONTENT HERE__]]
-- **Regarding file content within `CDATA` blocks:**
-    - By default use standard space characters (U+0020)
-    - Avoid introducing non-breaking spaces (U+00A0) and other non-standard whitespace, unless there is a reason (e.g., within a string literal)
-- You can write multiple `file` blocks in the same `ath` command
-- Ensure to write valid XML by opening and closing all tags as appropriate
-
-### File operations
-
-You will provide changes as follows:
-
-For CREATE and UPDATE_FULL, report the full file content:
-```xml
-<ath command="apply changes">
-<file>
-<file_message>Brief change description</file_message>
-<file_operation>CREATE|UPDATE_FULL</file_operation>
-<file_path>path/to/file</file_path>
-<file_code><![CDATA[
-[Full file content here]
-]]></file_code>
-</file>
-
-[keep adding files here if any]
-</ath>
-```
-
-For DELETE operations, leave the file content empty
-```
-<file_code><![CDATA[]]></file_code>
-```
-
-{{
-  include_ai_summaries ? 
-`## AI Summary
-
-Brief file-level comments that capture essential purpose and behavior
-
-Place them at the start of new/updated files and include:
-
-1. Core purpose
-2. Key functions/interfaces (if not obvious from filename)
-3. Important dependencies and system interactions
-4. Non-obvious behaviors or gotchas
-
-### Rules
-
-- Keep to 1-5 lines
-- Use file-appropriate comment syntax
-- Do not leave empty lines before of after the summary
-- Skip for files without comment support
-- Update when file content changes meaningfully
-
-### Example
-
-\`\`\`typescript
-// AI Summary: Handles JWT authentication, session management, and role-based access.
-// Requires secret key initialization. Core functions: generateToken(), validateSession().
-\`\`\`` 
-}}
-
-## Comments
-
-For code, add comments as needed to explain parts of the code and make it readable.
-
-Do NOT remove existing comments, unless they are wrong or misleading.
-
-## File Contents Availability
-
-Check that the file contents of ALL files which you are planning to update are 
-available in the `file_contents` section included below.
-
-If a file content:
-- is not provided below
-- is only provided partially with `... (content truncated)`
-
-then it is NOT fully available.
-
-If you are missing the contents of a file that you are planning to update, 
-you may be missing crucial information to write valid code!
-
-If that is the case, do NOT write any code for any file.
-
-Instead, STOP and list ALL the additional files that you require from the user, 
-instructing them to select the files from the Athanor file manager.
-</system_prompt>
-
-<project>
-# Documentation `{{project_name}}`
-
-{{project_info}}
-<file_contents>
-{{file_contents}}
-</file_contents>
-
-{{file_tree}}
-{{codebase_legend}}
-</project>
-
-<current_task>
-<task_description>
-{{task_description}}
-{{task_context}}
-</task_description>
-
-- Efficiently implement the feature or change described above according to best writing practices
-- Think carefully of ALL the files that would need to be modified
-- Only change what necessary
-- Carefully follow the writing instructions in `system_prompt`
-</current_task>
-</prompt_content>
-</ath_prompt_variant>
-
 </ath_prompt>

src/components/AthanorApp.tsx

@@ -63,6 +63,7 @@ const AthanorApp: React.FC = () => {
     refreshFileSystem,
     showProjectDialog,
     pendingDirectory,
+    pendingGitignoreExists,
     handleCreateProject,
     handleProjectDialogClose,
   } = useFileSystemLifecycle();
@@ -236,6 +237,7 @@ const AthanorApp: React.FC = () => {
         onClose={handleProjectDialogClose}
         onCreateProject={handleCreateProject}
         folderName={pendingDirectory ? getBaseName(pendingDirectory) : ''}
+        gitignoreExists={pendingGitignoreExists}
       />
       {filesData && currentDirectory && (
         <MainLayout