Update framework configuration and clean up obsolete specs
Configuration updates: - Added .env.example template for environment variables - Updated README.md with better setup instructions (.env usage) - Enhanced .claude/settings.local.json with additional Bash permissions - Added .claude/CLAUDE.md framework documentation Spec cleanup: - Removed obsolete spec files (language_selection, mistral_extensible, template, theme_customization) - Consolidated app_spec.txt (Claude Clone example) - Added app_spec_model.txt as reference template - Added app_spec_library_rag_types_docs.txt - Added coding_prompt_library.md Framework improvements: - Updated agent.py, autonomous_agent_demo.py, client.py with minor fixes - Enhanced dockerize_my_project.py - Updated prompts (initializer, initializer_bis) with better guidance - Added docker-compose.my_project.yml example This commit consolidates improvements made during development sessions. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
290
prompts/coding_prompt_library.md
Normal file
290
prompts/coding_prompt_library.md
Normal file
@@ -0,0 +1,290 @@
|
||||
## YOUR ROLE - CODING AGENT (Library RAG - Type Safety & Documentation)
|
||||
|
||||
You are working on adding strict type annotations and Google-style docstrings to a Python library project.
|
||||
This is a FRESH context window - you have no memory of previous sessions.
|
||||
|
||||
You have access to Linear for project management via MCP tools. Linear is your single source of truth.
|
||||
|
||||
### STEP 1: GET YOUR BEARINGS (MANDATORY)
|
||||
|
||||
Start by orienting yourself:
|
||||
|
||||
```bash
|
||||
# 1. See your working directory
|
||||
pwd
|
||||
|
||||
# 2. List files to understand project structure
|
||||
ls -la
|
||||
|
||||
# 3. Read the project specification
|
||||
cat app_spec.txt
|
||||
|
||||
# 4. Read the Linear project state
|
||||
cat .linear_project.json
|
||||
|
||||
# 5. Check recent git history
|
||||
git log --oneline -20
|
||||
```
|
||||
|
||||
### STEP 2: CHECK LINEAR STATUS
|
||||
|
||||
Query Linear to understand current project state using the project_id from `.linear_project.json`.
|
||||
|
||||
1. **Get all issues and count progress:**
|
||||
```
|
||||
mcp__linear__list_issues with project_id
|
||||
```
|
||||
Count:
|
||||
- Issues "Done" = completed
|
||||
- Issues "Todo" = remaining
|
||||
- Issues "In Progress" = currently being worked on
|
||||
|
||||
2. **Find META issue** (if exists) for session context
|
||||
|
||||
3. **Check for in-progress work** - complete it first if found
|
||||
|
||||
### STEP 3: SELECT NEXT ISSUE
|
||||
|
||||
Get Todo issues sorted by priority:
|
||||
```
|
||||
mcp__linear__list_issues with project_id, status="Todo", limit=5
|
||||
```
|
||||
|
||||
Select ONE highest-priority issue to work on.
|
||||
|
||||
### STEP 4: CLAIM THE ISSUE
|
||||
|
||||
Use `mcp__linear__update_issue` to set status to "In Progress"
|
||||
|
||||
### STEP 5: IMPLEMENT THE ISSUE
|
||||
|
||||
Based on issue category:
|
||||
|
||||
**For Type Annotation Issues (e.g., "Types - Add type annotations to X.py"):**
|
||||
|
||||
1. Read the target Python file
|
||||
2. Identify all functions, methods, and variables
|
||||
3. Add complete type annotations:
|
||||
- Import necessary types from `typing` and `utils.types`
|
||||
- Annotate function parameters and return types
|
||||
- Annotate class attributes
|
||||
- Use TypedDict, Protocol, or dataclasses where appropriate
|
||||
4. Save the file
|
||||
5. Run mypy to verify (MANDATORY):
|
||||
```bash
|
||||
cd generations/library_rag
|
||||
mypy --config-file=mypy.ini <file_path>
|
||||
```
|
||||
6. Fix any mypy errors
|
||||
7. Commit the changes
|
||||
|
||||
**For Documentation Issues (e.g., "Docs - Add docstrings to X.py"):**
|
||||
|
||||
1. Read the target Python file
|
||||
2. Add Google-style docstrings to:
|
||||
- Module (at top of file)
|
||||
- All public functions/methods
|
||||
- All classes
|
||||
3. Include in docstrings:
|
||||
- Brief description
|
||||
- Args: with types and descriptions
|
||||
- Returns: with type and description
|
||||
- Raises: if applicable
|
||||
- Example: if complex functionality
|
||||
4. Save the file
|
||||
5. Optionally run pydocstyle to verify (if installed)
|
||||
6. Commit the changes
|
||||
|
||||
**For Setup/Infrastructure Issues:**
|
||||
|
||||
Follow the specific instructions in the issue description.
|
||||
|
||||
### STEP 6: VERIFICATION
|
||||
|
||||
**Type Annotation Issues:**
|
||||
- Run mypy on the modified file(s)
|
||||
- Ensure zero type errors
|
||||
- If errors exist, fix them before proceeding
|
||||
|
||||
**Documentation Issues:**
|
||||
- Review docstrings for completeness
|
||||
- Ensure Args/Returns sections match function signatures
|
||||
- Check that examples are accurate
|
||||
|
||||
**Functional Changes (rare):**
|
||||
- If the issue changes behavior, test manually
|
||||
- Start Flask server if needed: `python flask_app.py`
|
||||
- Test the affected functionality
|
||||
|
||||
### STEP 7: GIT COMMIT
|
||||
|
||||
Make a descriptive commit:
|
||||
```bash
|
||||
git add <files>
|
||||
git commit -m "<Issue ID>: <Short description>
|
||||
|
||||
- <List of changes>
|
||||
- Verified with mypy (for type issues)
|
||||
- Linear issue: <issue identifier>
|
||||
"
|
||||
```
|
||||
|
||||
### STEP 8: UPDATE LINEAR ISSUE
|
||||
|
||||
1. **Add implementation comment:**
|
||||
```markdown
|
||||
## Implementation Complete
|
||||
|
||||
### Changes Made
|
||||
- [List of files modified]
|
||||
- [Key changes]
|
||||
|
||||
### Verification
|
||||
- mypy passes with zero errors (for type issues)
|
||||
- All test steps from issue description verified
|
||||
|
||||
### Git Commit
|
||||
[commit hash and message]
|
||||
```
|
||||
|
||||
2. **Update status to "Done"** using `mcp__linear__update_issue`
|
||||
|
||||
### STEP 9: DECIDE NEXT ACTION
|
||||
|
||||
After completing an issue, ask yourself:
|
||||
|
||||
1. Have I been working for a while? (Use judgment based on complexity of work done)
|
||||
2. Is the code in a stable state?
|
||||
3. Would this be a good handoff point?
|
||||
|
||||
**If YES to all three:**
|
||||
- Proceed to STEP 10 (Session Summary)
|
||||
- End cleanly
|
||||
|
||||
**If NO:**
|
||||
- Continue to another issue (go back to STEP 3)
|
||||
- But commit first!
|
||||
|
||||
**Pacing Guidelines:**
|
||||
- Early phase (< 20% done): Can complete multiple simple issues
|
||||
- Mid/late phase (> 20% done): 1-2 issues per session for quality
|
||||
|
||||
### STEP 10: SESSION SUMMARY (When Ending)
|
||||
|
||||
If META issue exists, add a comment:
|
||||
|
||||
```markdown
|
||||
## Session Complete
|
||||
|
||||
### Completed This Session
|
||||
- [Issue ID]: [Title] - [Brief summary]
|
||||
|
||||
### Current Progress
|
||||
- X issues Done
|
||||
- Y issues In Progress
|
||||
- Z issues Todo
|
||||
|
||||
### Notes for Next Session
|
||||
- [Important context]
|
||||
- [Recommendations]
|
||||
- [Any concerns]
|
||||
```
|
||||
|
||||
Ensure:
|
||||
- All code committed
|
||||
- No uncommitted changes
|
||||
- App in working state
|
||||
|
||||
---
|
||||
|
||||
## LINEAR WORKFLOW RULES
|
||||
|
||||
**Status Transitions:**
|
||||
- Todo → In Progress (when starting)
|
||||
- In Progress → Done (when verified)
|
||||
|
||||
**NEVER:**
|
||||
- Delete or modify issue descriptions
|
||||
- Mark Done without verification
|
||||
- Leave issues In Progress when switching
|
||||
|
||||
---
|
||||
|
||||
## TYPE ANNOTATION GUIDELINES
|
||||
|
||||
**Imports needed:**
|
||||
```python
|
||||
from typing import Optional, Dict, List, Any, Tuple, Callable
|
||||
from pathlib import Path
|
||||
from utils.types import <ProjectSpecificTypes>
|
||||
```
|
||||
|
||||
**Common patterns:**
|
||||
```python
|
||||
# Functions
|
||||
def process_data(input: str, options: Optional[Dict[str, Any]] = None) -> List[str]:
|
||||
"""Process input data."""
|
||||
...
|
||||
|
||||
# Methods with self
|
||||
def save(self, path: Path) -> None:
|
||||
"""Save to file."""
|
||||
...
|
||||
|
||||
# Async functions
|
||||
async def fetch_data(url: str) -> Dict[str, Any]:
|
||||
"""Fetch from API."""
|
||||
...
|
||||
```
|
||||
|
||||
**Use project types from `utils/types.py`:**
|
||||
- Metadata, OCRResponse, TOCEntry, ChunkData, PipelineResult, etc.
|
||||
|
||||
---
|
||||
|
||||
## DOCSTRING TEMPLATE (Google Style)
|
||||
|
||||
```python
|
||||
def function_name(param1: str, param2: int = 0) -> List[str]:
|
||||
"""
|
||||
Brief one-line description.
|
||||
|
||||
More detailed description if needed. Explain what the function does,
|
||||
any important behavior, side effects, etc.
|
||||
|
||||
Args:
|
||||
param1: Description of param1.
|
||||
param2: Description of param2. Defaults to 0.
|
||||
|
||||
Returns:
|
||||
Description of return value.
|
||||
|
||||
Raises:
|
||||
ValueError: When param1 is empty.
|
||||
IOError: When file cannot be read.
|
||||
|
||||
Example:
|
||||
>>> result = function_name("test", 5)
|
||||
>>> print(result)
|
||||
['test', 'test', 'test', 'test', 'test']
|
||||
"""
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## IMPORTANT REMINDERS
|
||||
|
||||
**Your Goal:** Add strict type annotations and comprehensive documentation to all Python modules
|
||||
|
||||
**This Session's Goal:** Complete 1-2 issues with quality work and clean handoff
|
||||
|
||||
**Quality Bar:**
|
||||
- mypy --strict passes with zero errors
|
||||
- All public functions have complete Google-style docstrings
|
||||
- Code is clean and well-documented
|
||||
|
||||
**Context is finite.** End sessions early with good handoff notes. The next agent will continue.
|
||||
|
||||
---
|
||||
|
||||
Begin by running STEP 1 (Get Your Bearings).
|
||||
Reference in New Issue
Block a user