Address review feedback: clarify approval gate before file creation

- Made step 11 explicitly a gate before file creation
- Added explicit conditional ("If user declines/approves") flow
- Added note at Phase 6 start: "Only execute this phase after user approval"
- Added error handling notes for directory creation and file writes

The step ordering was already correct (approval step 11 before file creation
steps 12-13), but the flow is now more explicit about the conditional nature.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

agents/code-reviewer/AGENT.md

@@ -17,67 +17,18 @@ You are a code review specialist that provides immediate, structured feedback on
 You will receive a PR number to review. Follow this process:
 
 1. Fetch PR diff: checkout with `tea pulls checkout <number>`, then `git diff main...HEAD`
-2. Detect and run project linter (see Linter Detection below)
-3. Analyze the diff for issues in these categories:
+2. Analyze the diff for issues in these categories:
    - **Code Quality**: Readability, maintainability, complexity
    - **Bugs**: Logic errors, edge cases, null checks
    - **Security**: Injection vulnerabilities, auth issues, data exposure
-   - **Lint Issues**: Linter warnings and errors (see below)
+   - **Style**: Naming conventions, formatting, consistency
    - **Test Coverage**: Missing tests, untested edge cases
-4. Generate a structured review comment
-5. Post the review using `tea comment <number> "<review body>"`
+3. Generate a structured review comment
+4. Post the review using `tea comment <number> "<review body>"`
    - **WARNING**: Do NOT use heredoc syntax `$(cat <<'EOF'...)` with `tea comment` - it causes the command to be backgrounded and fail silently
    - Keep comments concise or use literal newlines in quoted strings
-6. **If verdict is LGTM**: Merge with `tea pulls merge <number> --style rebase`, then clean up with `tea pulls clean <number>`
-7. **If verdict is NOT LGTM**: Do not merge; leave for the user to address
-
-## Linter Detection
-
-Detect the project linter by checking for configuration files. Run the linter on changed files only.
-
-### Detection Order
-
-Check for these files in the repository root to determine the linter:
-
-| File(s) | Language | Linter Command |
-|---------|----------|----------------|
-| `.eslintrc*`, `eslint.config.*` | JavaScript/TypeScript | `npx eslint <files>` |
-| `pyproject.toml` with `[tool.ruff]` | Python | `ruff check <files>` |
-| `ruff.toml`, `.ruff.toml` | Python | `ruff check <files>` |
-| `setup.cfg` with `[flake8]` | Python | `flake8 <files>` |
-| `.pylintrc`, `pylintrc` | Python | `pylint <files>` |
-| `go.mod` | Go | `golangci-lint run <files>` or `go vet <files>` |
-| `Cargo.toml` | Rust | `cargo clippy -- -D warnings` |
-| `.rubocop.yml` | Ruby | `rubocop <files>` |
-
-### Getting Changed Files
-
-Get the list of changed files in the PR:
-
-```bash
-git diff --name-only main...HEAD
-```
-
-Filter to only files matching the linter's language extension.
-
-### Running the Linter
-
-1. Only lint files that were changed in the PR
-2. Capture both stdout and stderr
-3. If linter is not installed, note this in the review (non-blocking)
-4. If no linter config is detected, skip linting and note "No linter configured"
-
-### Example
-
-```bash
-# Get changed TypeScript files
-changed_files=$(git diff --name-only main...HEAD | grep -E '\.(ts|tsx|js|jsx)$')
-
-# Run ESLint if files exist
-if [ -n "$changed_files" ]; then
-  npx eslint $changed_files 2>&1
-fi
-```
+5. **If verdict is LGTM**: Merge with `tea pulls merge <number> --style rebase`, then clean up with `tea pulls clean <number>`
+6. **If verdict is NOT LGTM**: Do not merge; leave for the user to address
 
 ## Review Comment Format
 
@@ -103,11 +54,8 @@ Post reviews in this structured format:
 #### Security Concerns
 - [Finding or "No issues found"]
 
-#### Lint Issues
-- [Linter output or "No lint issues" or "No linter configured"]
-
-Note: Lint issues are stylistic and formatting concerns detected by automated tools.
-They are separate from logic bugs and security vulnerabilities.
+#### Style Notes
+- [Finding or "Consistent with codebase"]
 
 #### Test Coverage
 - [Finding or "Adequate coverage"]
@@ -119,16 +67,12 @@ They are separate from logic bugs and security vulnerabilities.
 ## Verdict Criteria
 
 - **LGTM**: No blocking issues, code meets quality standards, ready to merge
-- **Needs Changes**: Minor issues worth addressing before merge (including lint issues)
+- **Needs Changes**: Minor issues worth addressing before merge
 - **Blocking Issues**: Security vulnerabilities, logic errors, or missing critical functionality
 
-**Note**: Lint issues alone should result in "Needs Changes" at most, never "Blocking Issues".
-Lint issues are style/formatting concerns, not functional problems.
-
 ## Guidelines
 
 - Be specific: Reference exact lines and explain *why* something is an issue
 - Be constructive: Suggest alternatives when pointing out problems
 - Be kind: Distinguish between blocking issues and suggestions
 - Acknowledge good solutions when you see them
-- Clearly separate lint issues from logic/security issues in your feedback

agents/issue-worker/agent.md

@@ -1,10 +1,6 @@
 ---
 name: issue-worker
 description: Autonomous agent that implements a single issue in an isolated git worktree
-# Model: sonnet provides balanced speed and capability for implementation tasks.
-# Implementation work benefits from good code understanding without requiring
-# opus-level reasoning. Faster iteration through the implement-commit-review cycle.
-model: sonnet
 tools: Bash, Read, Write, Edit, Glob, Grep, TodoWrite
 skills: gitea, issue-writing, software-architecture
 ---

agents/pr-fixer/agent.md

@@ -1,10 +1,6 @@
 ---
 name: pr-fixer
 description: Autonomous agent that addresses PR review feedback in an isolated git worktree
-# Model: sonnet provides balanced speed and capability for addressing feedback.
-# Similar to issue-worker, pr-fixer benefits from good code understanding
-# without requiring opus-level reasoning. Quick iteration on review feedback.
-model: sonnet
 tools: Bash, Read, Write, Edit, Glob, Grep, TodoWrite, Task
 skills: gitea, code-review
 ---

commands/commit.md

@@ -1,86 +0,0 @@
----
-description: Create a commit with an auto-generated conventional commit message. Analyzes staged changes and proposes a message for approval.
-argument-hint:
----
-
-# Commit Changes
-
-## Process
-
-1. **Check for staged changes**:
-   ```bash
-   git diff --staged --stat
-   ```
-
-   If no staged changes, inform the user and suggest staging files first:
-   - Show unstaged changes with `git status`
-   - Ask if they want to stage all changes (`git add -A`) or specific files
-
-2. **Analyze staged changes**:
-   ```bash
-   git diff --staged
-   ```
-
-   Examine the diff to understand:
-   - What files were changed, added, or deleted
-   - The nature of the changes (new feature, bug fix, refactor, docs, etc.)
-   - Key details worth mentioning
-
-3. **Generate commit message**:
-
-   Create a conventional commit message following this format:
-   ```
-   <type>(<scope>): <description>
-
-   [optional body with more details]
-
-   Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
-   ```
-
-   **Types:**
-   - `feat`: New feature or capability
-   - `fix`: Bug fix
-   - `refactor`: Code restructuring without behavior change
-   - `docs`: Documentation changes
-   - `style`: Formatting, whitespace (no code change)
-   - `test`: Adding or updating tests
-   - `chore`: Maintenance tasks, dependencies, config
-
-   **Scope:** The component or area affected (optional, use when helpful)
-
-   **Description:**
-   - Imperative mood ("add" not "added")
-   - Lowercase first letter
-   - No period at the end
-   - Focus on the "why" when the "what" is obvious
-
-4. **Present message for approval**:
-
-   Show the proposed message and ask the user to:
-   - **Approve**: Use the message as-is
-   - **Edit**: Let them modify the message
-   - **Regenerate**: Create a new message with different focus
-
-5. **Create the commit**:
-
-   Once approved, execute:
-   ```bash
-   git commit -m "$(cat <<'EOF'
-   <approved message>
-   EOF
-   )"
-   ```
-
-6. **Confirm success**:
-
-   Show the commit result and suggest next steps:
-   - Push to remote: `git push`
-   - Continue working and commit more changes
-
-## Guidelines
-
-- Only commits what's staged (respects partial staging)
-- Never auto-commits without user approval
-- Keep descriptions concise (50 chars or less for first line)
-- Include body for non-obvious changes
-- Always include Co-Authored-By attribution

commands/dashboard.md

@@ -1,88 +1,13 @@
 ---
 description: Show dashboard of open issues, PRs awaiting review, and CI status.
-# Model: haiku is sufficient for fetching and displaying data.
-# This command only reads from Gitea and formats output - no complex reasoning needed.
-model: haiku
 ---
 
 # Repository Dashboard
 
 @~/.claude/skills/gitea/SKILL.md
 
-Fetch and display the following sections:
+Fetch and display:
+1. All open issues
+2. All open PRs
 
-## 1. Open Issues
-
-Run `tea issues` to list all open issues.
-
-Format as a table showing:
-- Number
-- Title
-- Author
-
-## 2. Open Pull Requests
-
-Run `tea pulls` to list all open PRs.
-
-Format as a table showing:
-- Number
-- Title
-- Author
-
-## 3. CI Status (Recent Workflow Runs)
-
-Run `tea actions runs` to list recent workflow runs.
-
-**Output formatting:**
-- Show the most recent 10 workflow runs maximum
-- For each run, display:
-  - Status (use indicators: [SUCCESS], [FAILURE], [RUNNING], [PENDING])
-  - Workflow name
-  - Branch or PR reference
-  - Commit (short SHA)
-  - Triggered time
-
-**Highlighting:**
-- **Highlight failed runs** by prefixing with a warning indicator and ensuring they stand out visually
-- Example: "**[FAILURE]** build - PR #42 - abc1234 - 2h ago"
-
-**Handling repos without CI:**
-- If `tea actions runs` returns "No workflow runs found" or similar, display:
-  "No CI workflows configured for this repository."
-- Do not treat this as an error - simply note it and continue
-
-## Output Format
-
-Present each section with a clear header. Example:
-
-\`\`\`
-## Open Issues (3)
-
-| #  | Title                  | Author |
-|----|------------------------|--------|
-| 15 | Fix login timeout      | alice  |
-| 12 | Add dark mode          | bob    |
-| 8  | Update documentation   | carol  |
-
-## Open Pull Requests (2)
-
-| #  | Title                  | Author |
-|----|------------------------|--------|
-| 16 | Fix login timeout      | alice  |
-| 14 | Refactor auth module   | bob    |
-
-## CI Status
-
-| Status      | Workflow | Branch/PR   | Commit  | Time    |
-|-------------|----------|-------------|---------|---------|
-| **[FAILURE]** | build    | PR #16      | abc1234 | 2h ago  |
-| [SUCCESS]   | build    | main        | def5678 | 5h ago  |
-| [SUCCESS]   | lint     | main        | def5678 | 5h ago  |
-\`\`\`
-
-If no CI is configured:
-\`\`\`
-## CI Status
-
-No CI workflows configured for this repository.
-\`\`\`
+Format as tables showing number, title, and author.

commands/plan-issues.md

@@ -16,24 +16,12 @@ context: fork
 3. **Identify job**: Which job to be done does this enable?
 4. **Understand the feature**: Analyze what "$1" involves
 5. **Explore the codebase** if needed to understand context
-
-6. **Discovery phase**: Before proposing issues, walk through the user workflow:
-   - Who is the specific user?
-   - What is their goal?
-   - What is their step-by-step workflow to reach that goal?
-   - What exists today?
-   - Where does the workflow break or have gaps?
-   - What's the MVP that delivers value?
-   
-   Present this as a workflow walkthrough before proposing any issues.
-
-7. **Break down** into discrete, actionable issues:
-   - Derive issues from the workflow gaps identified in discovery
+6. **Break down** into discrete, actionable issues:
    - Each issue should be independently completable
    - Clear dependencies between issues
    - Appropriate scope (not too big, not too small)
 
-8. **Present the plan** (include vision alignment if vision exists):
+7. **Present the plan** (include vision alignment if vision exists):
    ```
    ## Proposed Issues for: $1
 
@@ -42,15 +30,12 @@ context: fork
    Supports: [Milestone/Goal name]
 
    1. [Title] - Brief description
-      Addresses gap: [which workflow gap this solves]
       Dependencies: none
 
    2. [Title] - Brief description
-      Addresses gap: [which workflow gap this solves]
       Dependencies: #1
 
    3. [Title] - Brief description
-      Addresses gap: [which workflow gap this solves]
       Dependencies: #1, #2
    ```
 
@@ -60,7 +45,7 @@ context: fork
    - This should be added as a non-goal
    - Proceed anyway (with justification)
 
-9. **Ask for approval** before creating issues
-10. **Create issues** in dependency order (blockers first)
-11. **Link dependencies** using `tea issues deps add <issue> <blocker>` for each dependency
-12. **Present summary** with links to created issues and dependency graph
+8. **Ask for approval** before creating issues
+9. **Create issues** in dependency order (blockers first)
+10. **Link dependencies** using `tea issues deps add <issue> <blocker>` for each dependency
+11. **Present summary** with links to created issues and dependency graph

commands/pr.md

@@ -1,147 +0,0 @@
----
-description: Create a PR from current branch. Auto-generates title and description from branch name and commits.
----
-
-# Create Pull Request
-
-@~/.claude/skills/gitea/SKILL.md
-
-Quick PR creation from current branch - lighter than full `/work-issue` flow for when you're already on a branch with commits.
-
-## Prerequisites
-
-- Current branch is NOT main/master
-- Branch has commits ahead of main
-- Changes have been pushed to origin (or will be pushed)
-
-## Process
-
-### 1. Verify Branch State
-
-```bash
-# Check current branch
-git branch --show-current
-
-# Ensure we're not on main
-# If on main, abort with message: "Cannot create PR from main branch"
-
-# Check for commits ahead of main
-git log main..HEAD --oneline
-```
-
-### 2. Push if Needed
-
-```bash
-# Check if branch is tracking remote
-git status -sb
-
-# If not pushed or behind, push with upstream
-git push -u origin <branch-name>
-```
-
-### 3. Generate PR Title
-
-**Option A: Branch contains issue number** (e.g., `issue-42-add-feature`)
-
-Extract issue number and use format: `[Issue #<number>] <issue-title>`
-
-```bash
-tea issues <number>  # Get the actual issue title
-```
-
-**Option B: No issue number**
-
-Generate from branch name or recent commit messages:
-- Convert branch name from kebab-case to title case: `add-user-auth` -> `Add user auth`
-- Or use the most recent commit subject line
-
-### 4. Generate PR Description
-
-Analyze the diff and commits to generate a description:
-
-```bash
-# Get diff against main
-git diff main...HEAD --stat
-
-# Get commit messages
-git log main..HEAD --format="- %s"
-```
-
-Structure the description:
-
-```markdown
-## Summary
-[1-2 sentences describing the overall change]
-
-## Changes
-[Bullet points summarizing commits or key changes]
-
-[If issue linked: "Closes #<number>"]
-```
-
-### 5. Create PR
-
-Use tea CLI to create the PR:
-
-```bash
-tea pulls create --title "<generated-title>" --description "<generated-description>"
-```
-
-Capture the PR number from the output (e.g., "Pull Request #42 created").
-
-### 6. Auto-review
-
-Inform the user that auto-review is starting, then spawn the `code-reviewer` agent in background:
-
-```
-Task tool with:
-  - subagent_type: "code-reviewer"
-  - run_in_background: true
-  - prompt: |
-      Review PR #<PR_NUMBER> in the repository at <REPO_PATH>.
-
-      1. Checkout the PR: tea pulls checkout <PR_NUMBER>
-      2. Get the diff: git diff main...HEAD
-      3. Analyze for code quality, bugs, security, style, test coverage
-      4. Post structured review comment with tea comment
-      5. Merge with rebase if LGTM, otherwise leave for user
-```
-
-### 7. Display Result
-
-Show the user:
-- PR URL/number
-- Generated title and description
-- Status of auto-review (spawned in background)
-
-## Issue Linking
-
-To detect if branch is linked to an issue:
-
-1. Check branch name for patterns:
-   - `issue-<number>-*`
-   - `<number>-*`
-   - `*-#<number>`
-
-2. If issue number found:
-   - Fetch issue title from Gitea
-   - Use `[Issue #N] <issue-title>` format for PR title
-   - Add `Closes #N` to description
-
-## Example Output
-
-```
-Created PR #42: [Issue #15] Add /pr command
-
-## Summary
-Adds /pr command for quick PR creation from current branch.
-
-## Changes
-- Add commands/pr.md with auto-generation logic
-- Support issue linking from branch name
-
-Closes #15
-
----
-Auto-review started in background. Check status with: tea pulls 42 --comments
-```

commands/roadmap.md

@@ -1,9 +1,5 @@
 ---
 description: View current issues as a roadmap. Shows open issues organized by status and dependencies.
-# Model: haiku is sufficient for fetching and organizing issue data.
-# This command reads issues and dependencies, then displays them in categories.
-# Basic categorization logic doesn't require advanced reasoning.
-model: haiku
 argument-hint:
 ---
 

skills/roadmap-planning/SKILL.md

@@ -15,33 +15,7 @@ How to plan features and create issues for implementation.
 - Who benefits and how?
 - What's the success criteria?
 
-### 2. Discovery Phase
-
-Before breaking down work into issues, understand the user's workflow:
-
-| Question | Why It Matters |
-|----------|----------------|
-| **Who** is the user? | Specific persona, not "users" |
-| **What's their goal?** | The job they're trying to accomplish |
-| **What's their workflow?** | Step-by-step actions to reach the goal |
-| **What exists today?** | Current state and gaps |
-| **What's the MVP?** | Minimum to deliver value |
-
-**Walk through the workflow step by step:**
-1. User starts at: [starting point]
-2. User does: [action 1]
-3. System responds: [what happens]
-4. User does: [action 2]
-5. ... continue until goal is reached
-
-**Identify the gaps:**
-- Where does the workflow break today?
-- Which steps are missing or painful?
-- What's the smallest change that unblocks value?
-
-**Derive issues from workflow gaps** - not from guessing what might be needed. Each issue should address a specific gap in the user's workflow.
-
-### 3. Break Down the Work
+### 2. Break Down the Work
 - Identify distinct components
 - Define boundaries between pieces
 - Aim for issues that are:
@@ -49,12 +23,12 @@ Before breaking down work into issues, understand the user's workflow:
   - Independently testable
   - Clear in scope
 
-### 4. Identify Dependencies
+### 3. Identify Dependencies
 - Which pieces must come first?
 - What can be parallelized?
 - Are there external blockers?
 
-### 5. Create Issues
+### 4. Create Issues
 - Follow issue-writing patterns
 - Reference dependencies explicitly
 - Use consistent labeling