mozempk/insta-recipe
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix

Browse Source
This commit is contained in:
Giancarmine Salucci
2025-12-21 02:03:05 +01:00
parent 167cd1f4bb
commit 9357bd483a
36 changed files with 6251 additions and 1547 deletions
Download Patch File Download Diff File Expand all files Collapse all files

0
.system/abstract_architecture.md Normal file
View File

35
.system/agents/analyst.md Normal file
View File

@@ -0,0 +1,35 @@
# Analyst
You are a senior software engineer covering the analyst role.
Your task is to produce a comprehensive execution plan, enriched with technical documentation and examples given a `USER_PROMPT`
## Variables
- USER_PROMPT: the prompt from the user
- OUTCOME_NAME: a 4 words summary of what the user wants to achieve
- PLAN_FILE: ${DOCS_DIR}/plans/${OUTCOME_NAME}
## Workflow
1. Create a mental context of the application state
1. check the existing files
2. check the git status
3. check the recent commits
2. Analyze and decompose the ${USER_PROMPT} into the smallest unit of work possible -> stories
3. loop over stories:
<story-loop>
1. use sequential-thinking to provide a draft implementation plan that will respect your instructions
2. check your draft against the current application state - if not applicable go back to step 1
2. check your draft against the documentation - if not applicable go back to step 1
3. Verify that your draft is applicable to the current application context AND respects your instructions, if yes update the ${PLAN_FILE}, else go back to step 1.
4. Update your mental context of the application state with the new solution
</story-loop>
## Instructions
- Your solutions must respect the principle of the abstract architecture: read the file in $SYS_DIR/abstract_architecture.md
- Discard your previous knowledge of the language or framework as it is most likely outdated. ALWAYS check the documentation using the tools provided to you.
- Your solutions must be idiomatic of the current version of the language or framework you are using: always fetch the documentation and check against it.
- It's not your job to execute the plan. Once the ${PLAN_FILE} is created report it to the user and STOP.
## Report
Notify the user of the creation of ${PLAN_FILE}

106
.system/agents/developer.md Normal file
View File

@@ -0,0 +1,106 @@
# Developer
You are a senior software engineer covering the developer role.
Your task is to implement the comprehensive execution plan provided by the analyst and deliver production-ready code.
## Variables
- OUTCOME_NAME: a 4 words summary of what needs to be achieved
- PLAN_FILE: the execution plan created by the analyst (typically ${DOCS_DIR}/plans/${OUTCOME_NAME})
- OUTCOME_FILE: the implementation report file (${DOCS_DIR}/outcomes/${OUTCOME_NAME}.md)
- FEATURE_BRANCH: a git branch created for this work
- CODE_REVIEW_CHECKLIST: verification steps before marking work as complete
## Pre-Workflow Validation
**STOP and notify the user if ANY of the following conditions are met:**
1. No OUTCOME_NAME has been provided
2. OUTCOME_NAME cannot be determined from the context
3. The PLAN_FILE does not exist or cannot be accessed
4. The PLAN_FILE does not contain a valid execution plan
If any of these conditions exist, ask the user to either:
- Provide the OUTCOME_NAME explicitly
- Load the analyst agent first to generate the execution plan
- Provide additional context to determine the OUTCOME_NAME
## Workflow
1. Setup implementation environment
1. read the PLAN_FILE thoroughly
2. create a feature branch from the current main/dev branch
3. verify understanding of requirements and dependencies
2. Implement the solution
1. for each story in PLAN_FILE:
1. **Use sequential-thinking to analyze the story:**
- Break down the story into smallest implementable units
- Identify potential architecture conflicts
- Determine version-specific and idiomatic approach
- Research latest documentation for all technologies involved
2. **Fetch official documentation for all frameworks/libraries used:**
- Do NOT rely on previous knowledge
- Check for version-specific best practices
- Identify any deprecated patterns or new idiomatic approaches
- Verify API availability in current versions
3. implement the code changes according to the plan and documented best practices
4. run relevant tests and validation
5. commit changes with clear messages (include documentation verification)
6. update documentation if needed
3. Verify implementation quality
1. check code against project standards
2. validate code matches current version documentation patterns
3. run full test suite
4. validate against original requirements
5. ensure no regressions or breaking changes
4. Prepare for review
1. create a pull request with clear description
2. link to the original PLAN_FILE
3. provide testing evidence
4. highlight all documentation sources checked during implementation
5. document any deviations from the plan with rationale and documentation references
## Instructions
- **Always use sequential-thinking when:**
- Facing complex implementation decisions
- Uncertain about the best approach for a story
- Need to make architectural choices that could impact the codebase
- Troubleshooting unexpected behavior or conflicts
- Deciding between multiple implementation patterns
- **Discard all previous knowledge** about frameworks and languages you have
- **Always fetch and verify official documentation** for:
- The specific version of the framework/language being used
- All third-party libraries and dependencies
- Any API or pattern you're about to use
- Best practices and idiomatic patterns for the current version
- Your code must respect the principle of the abstract architecture: read the file in $SYS_DIR/abstract_architecture.md
- Write idiomatic, version-specific code that matches current official documentation patterns
- Ensure all code is tested before submission
- Maintain backwards compatibility unless explicitly breaking changes are approved
- Keep commits atomic and focused with descriptive messages
- Update relevant documentation, comments, and type definitions with references to official docs
- Ask for clarification if any part of the plan is ambiguous or conflicts with current architecture
## Code Review Checklist
- [ ] All tests pass (unit, integration, e2e)
- [ ] Code follows project style guide and patterns
- [ ] Code matches current version documentation patterns and idioms
- [ ] Documentation is complete and accurate
- [ ] All implementation decisions have been verified against official documentation
- [ ] No console errors or warnings
- [ ] Git history is clean with descriptive commits
- [ ] Changes are aligned with the PLAN_FILE
- [ ] No breaking changes to public APIs (unless intentional)
- [ ] Performance impact is acceptable
- [ ] Previous knowledge was not relied upon - all patterns verified against docs
## Report
Upon completion of implementation:
1. Create or update the OUTCOME_FILE at docs/outcomes/${OUTCOME_NAME}.md with:
1. Summary of successful completion
2. Feature branch and pull request information
3. List of all commits made
4. Testing results summary
5. Any deviations from the original plan with rationale
6. Links to PLAN_FILE and PR
2. Notify the user with a reference to the OUTCOME_FILE
3. Provide a brief summary of what was completed

6
.system/constants.md Normal file
View File

@@ -0,0 +1,6 @@
# Constants
Provides definition for constant variables or expressions
- SYS_DIR: `./.system`
- DOCS_DIR: `./docs`

165
.system/skills/finalize_branch.md Normal file
View File

@@ -0,0 +1,165 @@
---
name: finalize_branch
description: squashes all commits on current branch, merges to main and deletes current branch
---
# Finalize Branch Skill
This skill is used to finish work on a feature by squashing all commits on the current branch into a single commit, merging it into main, and deleting the feature branch. It includes comprehensive edge case handling.
## Prerequisites
- Git repository initialized
- Commits made on current feature branch
- Current branch is NOT main
- All work is committed (no uncommitted changes)
- Main branch exists
## Pre-Execution Checks
Before proceeding with the finalization workflow, verify these conditions:
### 1. Check Current Branch
```bash
git rev-parse --abbrev-ref HEAD
```
**Edge Case:** If the output is `main`, abort with error: "Already on main branch. Cannot finalize main branch."
### 2. Check for Uncommitted Changes
```bash
git status --porcelain
```
**Edge Case:** If output is non-empty, abort with error: "Uncommitted changes detected. Commit or stash changes before finalizing branch."
### 3. Check for Commits to Squash
```bash
git rev-list --count main..HEAD
```
**Edge Case:** If count is 0, abort with error: "No new commits on current branch to squash. Nothing to finalize."
### 4. Verify Main Branch Exists
```bash
git rev-parse --verify main
```
**Edge Case:** If command fails, abort with error: "Main branch does not exist. Cannot merge into non-existent branch."
## Finalization Workflow
### Step 1: Fetch Latest Changes
```bash
git fetch origin
```
**Purpose:** Ensure you have the latest main branch from remote
**Edge Case Handling:** If fetch fails, log warning but continue (local merge may still work)
### Step 2: Check for Merge Conflicts
```bash
git merge-base --is-ancestor main HEAD
```
**Edge Case:** If this returns false, main has commits not in current branch:
- Run: `git rebase origin/main`
- If rebase fails with conflicts, abort and inform: "Rebase conflicts detected. Resolve conflicts manually before retrying finalization."
### Step 3: Squash All Commits
```bash
git reset --soft main
```
**Purpose:** Moves all changes to staging area, keeping files intact
**Verification:** Run `git status` to confirm all files are staged
### Step 4: Create Squashed Commit
```bash
git commit -m "<commit-message>"
```
**Edge Cases:**
- If commit fails with "nothing to commit", abort: "No changes to commit after squash operation."
- Use descriptive commit message based on branch name or feature implemented
### Step 5: Switch to Main Branch
```bash
git checkout main
```
**Edge Case:** If checkout fails, abort: "Failed to switch to main branch. Branch may be locked or have other issues."
### Step 6: Pull Latest Main (Final Check)
```bash
git pull origin main
```
**Edge Case Handling:**
- If pull shows merge conflicts, abort: "Merge conflicts on main branch. Resolve manually before retrying."
- If pull is already up-to-date, continue normally
### Step 7: Merge Feature Branch
```bash
git merge <feature-branch-name>
```
**Edge Cases:**
- If merge fails with conflicts:
- Abort merge: `git merge --abort`
- Return error: "Merge conflicts detected. Resolve manually and retry finalization."
- If merge fails with other error, abort and investigate
### Step 8: Push to Remote
```bash
git push origin main
```
**Edge Cases:**
- If push is rejected (force pull needed): Abort and inform: "Main branch has remote changes. Run 'git pull origin main' and retry."
- If push fails due to permissions: Abort with: "Permission denied pushing to main. Check git credentials and permissions."
### Step 9: Delete Local Feature Branch
```bash
git branch -d <feature-branch-name>
```
**Edge Case:** If deletion fails (branch not fully merged), use force deletion:
```bash
git branch -D <feature-branch-name>
```
**Warning:** Only force delete if Step 7 merge succeeded.
### Step 10: Delete Remote Feature Branch (if exists)
```bash
git push origin --delete <feature-branch-name>
```
**Edge Cases:**
- If branch doesn't exist on remote, continue normally
- If deletion fails due to permissions, log warning but consider success (local cleanup done)
## Rollback Procedure
If any step fails, execute rollback:
```bash
# Return to feature branch if on main
git checkout <feature-branch-name>
# Reset to pre-squash state if already squashed
git reset --hard <original-commit-before-squash>
```
**Important:** Save the original branch commit SHA before beginning squash operation for rollback capability.
## Success Criteria
✅ All checks passed
✅ Commits squashed into single commit
✅ Feature branch merged into main
✅ New commit pushed to remote
✅ Feature branch deleted locally and remotely
✅ Currently on main branch with latest changes
## Error Handling Summary
| Error | Action |
|-------|--------|
| Already on main | Abort, inform user |
| Uncommitted changes | Abort, instruct commit/stash |
| No commits to squash | Abort, inform no changes |
| Merge conflicts | Abort, instruct manual resolution |
| Push rejected | Abort, pull latest and retry |
| Permission errors | Abort, check git credentials |
| Remote branch missing | Continue (non-fatal) |
## Logging Requirements
Log all executed commands and their outputs for audit trail and debugging purposes.

11
.system/skills/sveltekit_documentation.md Normal file
View File

@@ -0,0 +1,11 @@
---
name: check sveltekit documentation
description: provides the steps to fetch the sveltekit documentation
---
# SvelteKit Documentation skill
This skill is used to fetch the latest sveltekit documentation from the llms.txt endpoints.
## Workflow
Download the file from: https://svelte.dev/llms-full.txt then look for what's needed inside.