factory-factory 0.4.8 → 0.4.9

package/prompts/workflows/ci-fix.md

@@ -1,52 +0,0 @@
----
-name: CI Fix
-description: Investigate and fix CI failures
-expectsPR: false
----
-
-# CI Failure Resolution
-
-You are investigating and fixing CI failures for this workspace's pull request. Your goal is to get the CI checks passing.
-
-## Workflow Steps
-
-### 1. Understand the Failures
-- Review the CI failure information provided in the initial message
-- Use `gh pr checks <pr-number>` to see current check status
-- Use `gh run view <run-id> --log-failed` to see detailed failure logs
-
-### 2. Diagnose Root Cause
-- Identify which specific tests or checks are failing
-- Understand why each is failing (test logic, code bug, environment issue, flaky test)
-- Prioritize fixes based on impact
-
-### 3. Implement Fixes
-- Fix the underlying issues causing the failures
-- Run failing tests locally to verify your fix works: `pnpm test <test-file>`
-- Keep changes focused on fixing CI - avoid unrelated improvements
-
-### 4. Verify Locally
-- Run the full test suite: `pnpm test`
-- Run type checking: `pnpm typecheck`
-- Run linting: `pnpm check:fix`
-
-### 5. Commit and Push
-- Commit your fixes with clear messages explaining what was fixed
-- Push to the branch: `git push`
-- The CI will automatically re-run
-
-## Guidelines
-
-- **Focus on CI failures only**: Don't refactor or improve unrelated code
-- **One fix at a time**: Commit each logical fix separately for easier review
-- **Verify locally first**: Run tests locally before pushing to avoid CI cycles
-- **Handle flaky tests**: If a test is flaky, fix the flakiness rather than just re-running
-- **Communicate blockers**: If you cannot determine the cause of a failure, explain what you've tried
-
-## Common CI Failure Patterns
-
-- **Type errors**: Run `pnpm typecheck` and fix any issues
-- **Lint errors**: Run `pnpm check:fix` to auto-fix, then review remaining issues
-- **Test failures**: Read the test output carefully, reproduce locally, fix the code or test
-- **Build failures**: Check for missing dependencies or syntax errors
-- **Timeout issues**: Look for infinite loops or very slow operations

package/prompts/workflows/explore.md

@@ -1,54 +0,0 @@
----
-name: Explore
-description: Understand codebase structure and answer questions
-expectsPR: false
----
-
-# Exploration Workflow
-
-You are exploring the codebase to understand how things work or answer questions.
-
-## When to Use This Workflow
-
-- Learning how a feature is implemented
-- Understanding code architecture
-- Researching before implementing a feature
-- Answering questions about the codebase
-- Finding relevant code for a task
-
-## Exploration Techniques
-
-### 1. Start with Entry Points
-- Find main files, routers, or handlers
-- Trace the code path from user action to implementation
-- Identify key modules and their responsibilities
-
-### 2. Use Search Effectively
-- `Grep` for specific function or variable names
-- `Glob` for file patterns (e.g., `**/*.test.ts`)
-- Read file headers and exports first
-
-### 3. Build Mental Models
-- Map out module dependencies
-- Identify core abstractions and patterns
-- Note important files and their purposes
-
-### 4. Document Findings
-- Summarize what you learned
-- Note important files and code locations
-- Explain patterns and conventions used
-
-## Guidelines
-
-- **Use Task tool for deep dives**: Spawn exploration agents to protect context
-- **Be systematic**: Start broad, then narrow down
-- **Read before searching**: Sometimes reading related code is faster
-- **Share knowledge**: Document findings clearly for future reference
-
-## Output Format
-
-When answering questions, include:
-- Direct answer to the question
-- Relevant file paths with line numbers
-- Brief explanation of how the code works
-- Any caveats or edge cases to be aware of

package/prompts/workflows/feature.md

@@ -1,80 +0,0 @@
----
-name: Feature
-description: End-to-end feature implementation with PR creation
-expectsPR: true
----
-
-# Feature Implementation Workflow
-
-You are implementing a new feature. Follow this workflow to deliver high-quality, production-ready code.
-
-## Workflow Steps
-
-### 1. Understand Requirements
-- Read any linked issues, PRs, or documentation
-- Clarify ambiguous requirements before starting implementation
-- Identify affected areas of the codebase
-
-### 2. Plan the Implementation
-- Use the TodoWrite tool to create a task list
-- Break down the work into logical commits
-- Consider edge cases and error handling upfront
-
-### 3. Implement the Feature
-- Write clean, well-structured code
-- Follow existing patterns in the codebase
-- Add appropriate type definitions
-- Keep commits focused and atomic
-
-### 4. Test Your Changes
-- Run the existing test suite (`pnpm test`)
-- Add new tests for your feature
-- Test edge cases and error scenarios
-- Verify the feature works end-to-end
-
-### 5. Verify Build and Lint
-- Run `pnpm typecheck` to catch type errors
-- Run `pnpm check:fix` to fix linting issues
-- Ensure the build passes (`pnpm build:all`)
-
-### 6. Capture UI Screenshots (if applicable)
-
-If your changes affect the UI:
-
-1. Read `factory-factory.json` for the `scripts.run` command, pick a free port, replace `{port}`, and start it in the background.
-2. Use `browser_navigate` to visit the dev server URL
-3. Determine the most relevant screen showing your changes and capture a screenshot
-4. Save screenshots to `.factory-factory/screenshots/` with descriptive names
-5. Commit the screenshots
-6. Reference them in the PR body using raw GitHub URLs:
-   `![Description](https://raw.githubusercontent.com/{owner}/{repo}/{branch}/.factory-factory/screenshots/filename.png)`
-
-### 7. Create Pull Request
-- Commit all changes with descriptive messages
-- Push your branch: `git push -u origin HEAD`
-- Create the PR using the GitHub CLI with a body file to preserve formatting:
-  ```bash
-  cat > /tmp/pr-body.md << 'EOF'
-  ## Summary
-  [Clear description of what this PR accomplishes]
-
-  ## Changes
-  - [List of key changes]
-
-  ## Testing
-  - [How to test the changes]
-  EOF
-  gh pr create --title "Your PR title" --body-file /tmp/pr-body.md
-  ```
-- **IMPORTANT**: Always append the following signature as the very last lines of the PR body, after a horizontal rule:
-  ```
-  ---
-  🏭 Forged in [Factory Factory](https://factoryfactory.ai)
-  ```
-
-## Guidelines
-
-- **Protect context**: For complex sub-tasks, use the Task tool to spawn specialized agents
-- **Commit early, commit often**: Make atomic commits as you complete each logical unit
-- **Test-driven when appropriate**: Write tests before or alongside implementation
-- **Ask questions**: If requirements are unclear, ask before making assumptions

package/prompts/workflows/followup.md

@@ -1,32 +0,0 @@
----
-name: Follow-up
-description: Continue previous work or handle ad-hoc tasks
-expectsPR: false
----
-
-# Follow-up Session
-
-This is a follow-up session. Continue where the previous session left off.
-
-## Context Recovery
-
-If you're resuming previous work:
-1. Review the conversation history
-2. Check git status for uncommitted changes
-3. Look at the TodoWrite list for pending tasks
-4. Identify what was completed and what remains
-
-## Ad-hoc Tasks
-
-For new tasks in this session:
-1. Understand the request
-2. Create a plan if needed (use TodoWrite)
-3. Execute the task
-4. Verify the result
-
-## Guidelines
-
-- **Resume gracefully**: Don't repeat work that's already done
-- **Check state**: Review git status, test results, and build state
-- **Ask for clarification**: If the previous context is unclear, ask
-- **Commit frequently**: Don't let work pile up uncommitted

package/prompts/workflows/pr-review-fix.md

@@ -1,50 +0,0 @@
----
-name: PR Review Fix
-description: Address PR review comments and feedback
-expectsPR: false
----
-
-# PR Review Comment Resolution
-
-You are addressing PR review comments for this workspace's pull request. Your goal is to implement the requested changes and satisfy the reviewers.
-
-**CRITICAL: Execute autonomously. Do not ask the user for input, confirmation, or clarification. Analyze comments, implement fixes, push changes, and request re-review without waiting.**
-
-## Workflow
-
-### 1. Analyze Comments
-- Review all comments in the initial message
-- Categorize each as **actionable** (requires code changes) or **informational** (no action needed)
-- Informational comments include: automated coverage reports, CI status notifications, or comments that just acknowledge/thank without requesting changes
-- For actionable comments, determine what changes are needed
-
-### 2. Implement Fixes
-- Address each actionable comment systematically
-- Make focused changes that directly address the feedback
-- If a request is unclear, make a reasonable interpretation and proceed
-- Do not ask for clarification - make your best judgment
-
-### 3. Verify Changes
-\`\`\`bash
-pnpm test && pnpm typecheck && pnpm check:fix
-\`\`\`
-
-### 4. Commit and Push
-\`\`\`bash
-git add -A && git commit -m "Address review comments" && git push
-\`\`\`
-
-### 5. Request Re-review
-CRITICAL: You MUST post a comment mentioning ALL reviewers whose comments you addressed, asking them to re-review. This is MANDATORY whenever you make code changes in response to review comments, even if you've already responded to their comments in previous sessions. Use `gh pr list --head $(git branch --show-current)` to find the PR number if not already known:
-\`\`\`bash
-gh pr comment $(gh pr list --head $(git branch --show-current) --json number --jq '.[0].number') --body "@reviewer1 @reviewer2 I've addressed the review comments. Please re-review when you have a chance."
-\`\`\`
-Do NOT skip this step based on whether you've previously commented. New code changes always require a new re-review request.
-
-## Guidelines
-
-- **Operate autonomously**: Never ask the user what to do. Analyze, decide, implement, push.
-- **Address all actionable comments**: Skip only truly informational comments
-- **Keep changes focused**: Only change what was requested
-- **Test before pushing**: Always run local checks first
-- **Handle bot comments**: Analyze bot comments (coverage, CI) for actionable items. If purely informational, move on without code changes.