rafcode 1.0.0

package/RAF/012-name-picker-buffet/outcomes/006-update-execution-prompt-for-commits.md

@@ -0,0 +1,47 @@
+# Outcome: Update Execution Prompt for Commit Workflow
+
+## Summary
+
+Updated Claude's execution prompt to clearly instruct it to commit code changes and outcome file together when a task succeeds, and to NOT commit when a task fails (preserving changes for debugging).
+
+## Key Changes
+
+### Modified Files
+
+- **src/prompts/execution.ts**:
+  - Added failure commit instruction in the Git Instructions section: "On Failure: do NOT commit. Just write the outcome file with the `<promise>FAILED</promise>` marker and stop. Uncommitted changes will be preserved for debugging."
+  - Added two new Important Rules (7 and 8):
+    - Rule 7: "On SUCCESS: Commit code changes AND outcome file together BEFORE you finish"
+    - Rule 8: "On FAILURE: Do NOT commit - just write the outcome file with FAILED marker"
+
+- **tests/unit/execution-prompt.test.ts**:
+  - Added test: "should include instruction not to commit on failure"
+  - Added test: "should not include failure commit instruction when autoCommit is false"
+  - Added new test suite "Commit Workflow Rules" with 3 tests:
+    - "should include rule to commit code and outcome together on success"
+    - "should include rule not to commit on failure"
+    - "should specify that changes are preserved for debugging on failure"
+
+## Acceptance Criteria Met
+
+- [x] Execution prompt includes commit instructions (with failure handling)
+- [x] Outcome file path is explicitly provided (already present)
+- [x] Commit message format is specified: `RAF[NNN:task] description` (already present)
+- [x] Instructions specify: write outcome → commit → marker appears
+- [x] Failed tasks: write outcome with FAILED marker, no commit
+- [x] Claude commits code + outcome in single commit during execution
+- [x] All tests pass (605 total, 5 new tests added)
+
+## Notes
+
+The prompt already had the outcome file path and commit message format. The main additions were:
+1. Clear instruction about not committing on failure
+2. Important Rules 7 and 8 that explicitly state the commit workflow for success/failure cases
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 1
+- Elapsed time: 2m 24s
+- Completed at: 2026-01-31T14:16:17.299Z

package/RAF/012-name-picker-buffet/outcomes/007-fix-plan-mode-user-prompt.md

@@ -0,0 +1,83 @@
+# Outcome: Fix Plan Mode User Prompt
+
+## Summary
+
+Fixed the issue where Claude would get stuck waiting for user input in plan mode by splitting the prompt into a system prompt (via `--append-system-prompt`) and a user message (via `-p` flag). This triggers Claude to immediately start the planning interview process instead of waiting.
+
+## Key Changes
+
+### Modified Files
+
+- **src/core/claude-runner.ts**:
+  - Updated `runInteractive()` method signature to accept both `systemPrompt` and `userMessage` parameters
+  - Changed args to include both `--append-system-prompt` for system instructions and `-p` for user message
+  - Added JSDoc comments explaining the parameters
+
+- **src/prompts/planning.ts**:
+  - Added `PlanningPromptResult` interface with `systemPrompt` and `userMessage` fields
+  - Updated `getPlanningPrompt()` to return an object with both prompts
+  - System prompt contains planning instructions, project location, and rules
+  - User message contains the project description to trigger Claude to start
+
+- **src/prompts/amend.ts**:
+  - Added `AmendPromptResult` interface with `systemPrompt` and `userMessage` fields
+  - Updated `getAmendPrompt()` to return an object with both prompts
+  - System prompt contains amendment instructions, existing tasks, and rules
+  - User message contains the new task description to trigger Claude to start
+
+- **src/commands/plan.ts**:
+  - Updated `runPlanCommand()` to destructure and use both prompts
+  - Updated `runAmendCommand()` to destructure and use both prompts
+
+### New Test Files
+
+- **tests/unit/planning-prompt.test.ts**: 13 tests covering:
+  - Prompt splitting functionality
+  - System prompt content (instructions, paths, templates)
+  - User message content (project description only)
+  - Proper separation of concerns
+
+- **tests/unit/claude-runner-interactive.test.ts**: 8 tests covering:
+  - Correct argument passing for system prompt and user message
+  - Flag order verification (--model, --append-system-prompt, -p)
+  - Model configuration
+  - Working directory passing
+  - Exit code handling
+  - No --dangerously-skip-permissions for interactive mode
+
+### Updated Test File
+
+- **tests/unit/plan-command.test.ts**:
+  - Updated all `getAmendPrompt()` tests to use new return type
+  - Added 3 new tests for prompt splitting verification
+
+## How It Works
+
+Before (broken):
+```
+claude --model opus --append-system-prompt "All instructions including user input"
+Claude: [waiting for user input...]
+```
+
+After (fixed):
+```
+claude --model opus --append-system-prompt "Instructions" -p "User's project description"
+Claude: [immediately starts analyzing and interviewing]
+```
+
+The `-p` flag provides an initial user message that triggers Claude to begin working, while the system prompt provides all the necessary context and instructions.
+
+## Acceptance Criteria Met
+
+- [x] `raf plan` starts Claude session and Claude immediately begins asking questions
+- [x] `raf plan --amend` starts Claude session and Claude immediately begins asking questions
+- [x] No regression in existing planning functionality
+- [x] All tests pass (628 total, 24 new tests added)
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 1
+- Elapsed time: 4m 26s
+- Completed at: 2026-01-31T14:20:43.696Z

package/RAF/012-name-picker-buffet/outcomes/008-add-auto-flag-for-plan-mode.md

@@ -0,0 +1,77 @@
+# Outcome: Add Auto Flag for Plan Mode
+
+## Summary
+
+Added `--auto` / `-y` CLI flag to `raf plan` command to skip Claude's permission prompts during planning sessions. This allows for automated workflows or when users trust Claude's file operations.
+
+## Key Changes
+
+### Modified Files
+
+- **src/commands/plan.ts**:
+  - Added `auto?: boolean` to `PlanCommandOptions` interface
+  - Added `-y, --auto` option to Commander.js command definition with description "Skip Claude's permission prompts for file operations"
+  - Updated `runPlanCommand()` and `runAmendCommand()` to accept `autoMode` parameter
+  - Pass `dangerouslySkipPermissions: autoMode` to `claudeRunner.runInteractive()`
+  - Added warning log when auto mode is enabled
+
+- **src/core/claude-runner.ts**:
+  - Added `dangerouslySkipPermissions?: boolean` to `ClaudeRunnerOptions` interface
+  - Updated `runInteractive()` to conditionally add `--dangerously-skip-permissions` flag when option is true
+  - Placed the flag after `--model` and before `--append-system-prompt` in the args array
+
+### New Test Files
+
+- **tests/unit/plan-command-auto-flag.test.ts**: 7 tests covering:
+  - CLI option parsing for `--auto` and `-y` flags
+  - Flag description contains "permission"
+  - Flag is a boolean (no required argument)
+  - Coexistence with `--amend`, `--model`, and `--sonnet` options
+
+### Updated Test Files
+
+- **tests/unit/claude-runner-interactive.test.ts**: 4 new tests for `--dangerously-skip-permissions`:
+  - Should NOT include flag by default
+  - Should include flag when option is true
+  - Should NOT include flag when option is false
+  - Should place flag after `--model` and before `--append-system-prompt`
+
+## Acceptance Criteria Met
+
+- [x] `raf plan --auto` or `raf plan -y` starts planning without permission prompts
+- [x] `raf plan --amend <id> --auto` works similarly
+- [x] Regular `raf plan` (without flag) still shows permission prompts
+- [x] Claude's AskUserQuestion prompts for planning interview still work (not bypassed)
+- [x] Help text accurately describes the flag
+- [x] All tests pass (638 total, 11 new tests added)
+
+## Usage
+
+```bash
+# Skip permission prompts during planning
+raf plan --auto
+raf plan -y
+
+# With project name
+raf plan my-project --auto
+
+# With amend mode
+raf plan --amend my-project --auto
+
+# Combined with model selection
+raf plan --auto --model sonnet
+```
+
+## Notes
+
+- The `-y` shorthand follows common CLI conventions (like `apt -y`, `npm -y`)
+- A warning message is logged when the flag is used to remind users that permissions are being skipped
+- This flag only affects file operation permissions; Claude can still ask planning interview questions
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 1
+- Elapsed time: 3m 29s
+- Completed at: 2026-01-31T14:24:13.579Z

package/RAF/012-name-picker-buffet/plans/001-name-picker-for-raf-plan.md

@@ -0,0 +1,47 @@
+# Task: Name Picker for `raf plan`
+
+## Objective
+Generate 3-5 project name suggestions using Claude Sonnet and let the user pick one via arrow-key navigation or provide a custom name.
+
+## Context
+Currently `raf plan` requires a project name upfront. This task adds intelligent name generation when no name is provided, making project creation faster and more creative.
+
+## Requirements
+- Generate 3-5 project names with varied styles (fun, metaphor, descriptive, somewhat-related-and-fun)
+- Use Claude Sonnet for name generation (more capable for creative tasks)
+- Pass the project description (input.md content) as context for relevant suggestions
+- When project has many unrelated tasks, prefer abstract/metaphorical/fun names over descriptive ones
+- Use `@inquirer/prompts` for arrow-key selection UI
+- Include "Other (enter custom name)" option that triggers text input
+- Names should be kebab-case and suitable for folder names
+
+## Implementation Steps
+1. Add `@inquirer/prompts` as a dependency if not already present
+2. Create a new module `src/core/name-generator.ts`:
+   - `generateProjectNames(description: string): Promise<string[]>` - calls Claude Sonnet API
+   - Include prompt instructions for variety in naming styles
+3. Create a new module `src/ui/name-picker.ts`:
+   - `pickProjectName(names: string[]): Promise<string>` - shows arrow-key list with custom option
+   - Handle "Other" selection by showing text input prompt
+4. Update `src/commands/plan.ts`:
+   - Check if name is provided in `raf plan [name]`
+   - If not, read input.md content
+   - Call name generator with description
+   - Show name picker UI
+   - Continue with selected/custom name
+5. Add unit tests for name generator (mock Claude API)
+6. Add unit tests for name picker UI (mock inquirer)
+
+## Acceptance Criteria
+- [ ] Running `raf plan` without a name shows 3-5 generated names
+- [ ] Names have variety in style (not all the same pattern)
+- [ ] User can select with arrow keys and Enter
+- [ ] User can choose "Other" and type custom name
+- [ ] Selected name is used for project folder creation
+- [ ] All tests pass
+
+## Notes
+- Use Claude Sonnet (not Haiku) for better creative output
+- Ensure names are valid for file system (no special chars, kebab-case)
+- The name generator should be fast - consider streaming or timeout
+- Include prompt instruction: if the project has many unrelated tasks (detected by diverse/disconnected topics in description), prefer more abstract, metaphorical, or fun names rather than trying to be descriptive about all tasks

package/RAF/012-name-picker-buffet/plans/002-interactive-project-picker-for-raf-do.md

@@ -0,0 +1,43 @@
+# Task: Interactive Project Picker for `raf do`
+
+## Objective
+Allow users to run `raf do` without specifying a project name and interactively select from pending projects using arrow-key navigation.
+
+## Context
+Currently `raf do` requires a project identifier. This task adds an interactive picker when no identifier is provided, making it easier to continue work on pending projects.
+
+## Requirements
+- Show all pending projects when `raf do` is called without arguments
+- Use `@inquirer/prompts` for arrow-key selection UI
+- Display project info: number, name, and progress (e.g., "001 fix-auth-bug (2/5 tasks)")
+- Order by project number (oldest first)
+- Handle case when no pending projects exist (show message, exit gracefully)
+
+## Implementation Steps
+1. Create a new module `src/ui/project-picker.ts`:
+   - `pickPendingProject(): Promise<string | null>` - shows arrow-key list of pending projects
+   - Format each choice with project number, name, and task progress
+   - Return selected project folder name or null if cancelled/empty
+2. Update `src/commands/do.ts`:
+   - Check if project identifier is provided
+   - If not, call `discoverProjects()` and filter to pending/in-progress
+   - If no pending projects, show message and exit
+   - Show project picker UI
+   - Continue with selected project
+3. Reuse existing state derivation logic from `src/core/state-derivation.ts`:
+   - `deriveProjectState()` to get task counts
+   - `getDerivedStats()` to get pending/completed counts
+4. Add unit tests for project picker UI (mock inquirer and file system)
+
+## Acceptance Criteria
+- [ ] Running `raf do` without arguments shows pending projects list
+- [ ] Projects show number, name, and progress (X/Y tasks)
+- [ ] User can navigate with arrow keys and select with Enter
+- [ ] Selected project is executed
+- [ ] Empty list shows friendly message "No pending projects found"
+- [ ] Ctrl+C exits gracefully
+- [ ] All tests pass
+
+## Notes
+- Consider using `@inquirer/prompts` select with separator or descriptions for better UX
+- This task depends on `@inquirer/prompts` being added in task 001, but can be done in parallel if the dependency is already installed

package/RAF/012-name-picker-buffet/plans/003-raf-status-truncation.md

@@ -0,0 +1,36 @@
+# Task: Enhanced `raf status` with Last 10 Projects
+
+## Objective
+Modify `raf status` to show only the last 10 projects with a "... and N more" indicator for older projects.
+
+## Context
+As RAF accumulates more projects, the status list becomes unwieldy. Showing only recent projects with a truncation indicator keeps the output manageable while indicating more history exists.
+
+## Requirements
+- Show last 10 projects by default (most recent at bottom)
+- Display "... and N more projects" at the top when list is truncated
+- Maintain existing project display format (number, name, progress, status)
+- Sort by project number (ascending) within the displayed 10
+
+## Implementation Steps
+1. Update `src/commands/status.ts`:
+   - In `listAllProjects()` function, check total project count
+   - If > 10 projects, slice to last 10
+   - Add "... and N more projects" line at the top of output when truncated
+   - Keep existing sorting (by project number ascending)
+2. Add constant for max displayed projects (10) for easy adjustment
+3. Update any existing tests that check status output format
+4. Add new test case for truncation behavior
+
+## Acceptance Criteria
+- [ ] `raf status` shows max 10 projects
+- [ ] When > 10 projects exist, shows "... and N more projects" at top
+- [ ] Projects are sorted by number (ascending) with newest at bottom
+- [ ] When ≤ 10 projects, no truncation indicator shown
+- [ ] Individual project status (`raf status <id>`) unchanged
+- [ ] All tests pass
+
+## Notes
+- The truncation indicator should be visually distinct (maybe dimmed or prefixed with ...)
+- Consider adding a `--all` flag in a future task to show all projects
+- This is a simple change - focus on clean implementation and tests

package/RAF/012-name-picker-buffet/plans/004-failure-reason-details.md

@@ -0,0 +1,46 @@
+# Task: Failure Reason Details in Outcome Files
+
+## Objective
+Add a "Failure History" section to outcome files that lists all previous failure attempts with bullet points for each failure reason.
+
+## Context
+When tasks fail multiple times, understanding the history of failures helps debugging. Currently only the final status is tracked. This task adds detailed failure history to outcome files.
+
+## Requirements
+- Track all failure attempts (not just the most recent)
+- Display as bullet points with attempt number and reason
+- Add to outcome details section in outcome files
+- Include failure reasons from both programmatic failures (timeout, context overflow) and Claude analysis
+
+## Implementation Steps
+1. Update failure tracking in `src/core/failure-analyzer.ts`:
+   - Ensure failure reasons are captured from both programmatic detection and Claude analysis
+   - Store failure reason string (1-2 sentences max)
+2. Update `src/commands/do.ts` execution loop:
+   - Track failure reasons across retry attempts in an array
+   - Pass failure history to outcome generation
+3. Update outcome file generation (likely in `src/core/project-manager.ts` or similar):
+   - Add "## Failure History" section when there are any failures
+   - Format as:
+     ```markdown
+     ## Failure History
+     - **Attempt 1**: Context overflow detected after 45 minutes
+     - **Attempt 2**: API rate limit exceeded
+     - **Attempt 3**: Success
+     ```
+   - Only include this section if there were any failures (not for clean runs)
+4. Update outcome file parsing if needed to handle new section
+5. Add tests for failure history tracking and formatting
+
+## Acceptance Criteria
+- [ ] Outcome files include failure history when any attempts failed
+- [ ] Each failed attempt shows attempt number and short reason
+- [ ] Successful final attempt also shows in history (if preceded by failures)
+- [ ] Clean runs (no failures) don't show failure history section
+- [ ] Failure reasons are concise (1-2 sentences)
+- [ ] All tests pass
+
+## Notes
+- Keep failure reasons short - full details are in the analysis section
+- Consider: should successful attempt be included in history? (Yes, shows the journey)
+- The failure history should appear before the `<promise>` marker

package/RAF/012-name-picker-buffet/plans/005-remove-raf-commits.md

@@ -0,0 +1,42 @@
+# Task: Remove All RAF-Side Git Commits
+
+## Objective
+Remove all git commit operations from RAF since Claude will handle all commits during task execution.
+
+## Context
+Currently RAF commits after planning and after project completion. The new workflow has Claude handle all commits as part of task execution - one commit per task containing both code changes and outcome file.
+
+## Requirements
+- Remove the planning phase commit (`RAF[NNN:plan]`)
+- Remove the outcome/completion commit (`RAF[NNN:outcome]`)
+- Keep git utility functions that might be needed for other purposes (status checks, stashing)
+- Update CLAUDE.md to reflect new commit workflow
+
+## Implementation Steps
+1. Update `src/commands/plan.ts`:
+   - Remove call to `commitProjectFolder(..., 'plan')`
+   - Remove any related error handling for commit failures
+2. Update `src/commands/do.ts`:
+   - Remove call to `commitProjectFolder(..., 'outcome')`
+   - Remove the auto-commit logic after task/project completion
+   - Keep stash logic for failed tasks (still useful)
+3. Review `src/core/git.ts`:
+   - Keep the module but remove or deprecate `commitProjectFolder` if no longer needed
+   - Alternatively, keep it for potential future use but remove all callers
+4. Update any tests that verify RAF commit behavior
+5. Update CLAUDE.md "Git Commit Schema" section:
+   - Remove "RAF-generated commits" section
+   - Update to show only Claude-generated commits
+
+## Acceptance Criteria
+- [ ] `raf plan` does not create any git commits
+- [ ] `raf do` does not create any git commits
+- [ ] Git stashing on failure still works
+- [ ] No errors when running in non-git directories
+- [ ] CLAUDE.md updated to reflect new workflow
+- [ ] All tests pass (update tests that expected commits)
+
+## Notes
+- This is a simplification - less code, clearer responsibility
+- Make sure to remove/update tests that verified commit behavior
+- Keep git.ts utilities that are still useful (hasUncommittedChanges, stashChanges)

package/RAF/012-name-picker-buffet/plans/006-update-execution-prompt-for-commits.md

@@ -0,0 +1,47 @@
+# Task: Update Execution Prompt for Commit Workflow
+
+## Objective
+Update Claude's execution prompt to instruct it to commit code changes and outcome file together, then produce the completion marker.
+
+## Context
+With RAF no longer handling commits (task 005), Claude must commit as part of task execution. The prompt needs to clearly instruct this workflow and provide file location information.
+
+## Requirements
+- Instruct Claude to commit code changes + outcome file in ONE commit
+- Provide clear file paths for where to write outcome file
+- Specify commit message format: `RAF[NNN:task] description`
+- Ensure `<promise>COMPLETE</promise>` comes AFTER the commit
+- Handle the case where there are no code changes (outcome-only commit)
+
+## Implementation Steps
+1. Update `src/prompts/execution.ts`:
+   - Add section about git commit workflow
+   - Specify outcome file path explicitly: `RAF/NNN-project/outcomes/NNN-task-name.md`
+   - Instruct: write outcome file → git add → git commit → produce `<promise>COMPLETE</promise>`
+   - Include commit message format with example
+2. Add instruction about staging specific files (not `git add .`):
+   - Stage changed code files by name
+   - Stage outcome file by path
+3. Add instruction for failed tasks:
+   - Still write outcome file with `<promise>FAILED</promise>`
+   - Do NOT commit on failure (keep changes for debugging)
+4. Review and update the execution prompt template to include:
+   - Explicit outcome file path
+   - Project folder path
+   - Task number and name
+5. Add/update tests for prompt generation
+
+## Acceptance Criteria
+- [ ] Execution prompt includes commit instructions
+- [ ] Outcome file path is explicitly provided
+- [ ] Commit message format is specified: `RAF[NNN:task] description`
+- [ ] Instructions specify: write outcome → commit → output marker
+- [ ] Failed tasks: write outcome with FAILED marker, no commit
+- [ ] Claude commits code + outcome in single commit during execution
+- [ ] All tests pass
+
+## Notes
+- Depends on task 005 (remove RAF commits) - Claude must commit because RAF won't
+- The sequence is critical: outcome file must be committed BEFORE the marker is output
+- Consider adding examples in the prompt for clarity
+- Test manually after implementation to verify Claude follows instructions

package/RAF/012-name-picker-buffet/plans/007-fix-plan-mode-user-prompt.md

@@ -0,0 +1,55 @@
+# Task: Fix Plan Mode User Prompt
+
+## Objective
+Fix Claude getting stuck in plan mode by splitting the prompt into system instructions and user message, so Claude immediately starts the interview process.
+
+## Context
+Currently, `runInteractive()` passes everything via `--append-system-prompt` without a user message. Claude waits for user input instead of starting the planning interview. Non-interactive execution (`run()`/`runVerbose()`) already works correctly because it passes a user message via `-p`.
+
+This affects both:
+- `raf plan` (regular planning)
+- `raf plan --amend` (amendment mode)
+
+## Requirements
+- Pass planning instructions via `--append-system-prompt` (system prompt)
+- Pass the user's project description via `-p` flag (user message)
+- This applies to both regular plan and amend modes
+- Claude should immediately begin identifying tasks and preparing questions
+- The prompt structure should mirror the non-interactive execution pattern
+
+## Implementation Steps
+1. Update `src/core/claude-runner.ts` `runInteractive()` method:
+   - Add a second parameter for user message content
+   - Pass system instructions via `--append-system-prompt`
+   - Pass user message via `-p` flag
+   - Method signature: `runInteractive(systemPrompt: string, userMessage: string, options?)`
+
+2. Update `src/prompts/planning.ts`:
+   - Split `getPlanningPrompt()` into two functions or return an object with both parts
+   - System prompt: Planning instructions, project location, rules
+   - User message: The actual project description (input.md content)
+
+3. Update `src/prompts/amend.ts`:
+   - Split `getAmendPrompt()` similarly
+   - System prompt: Amendment instructions, existing tasks, rules
+   - User message: The new task description
+
+4. Update `src/commands/plan.ts`:
+   - Update `runPlanCommand()` to call `runInteractive()` with both prompts
+   - Update `runAmendCommand()` to call `runInteractive()` with both prompts
+
+5. Add/update unit tests for:
+   - ClaudeRunner.runInteractive() accepting both system and user prompts
+   - Planning prompt split functions
+   - Amend prompt split functions
+
+## Acceptance Criteria
+- [ ] `raf plan` starts Claude session and Claude immediately begins asking questions
+- [ ] `raf plan --amend` starts Claude session and Claude immediately begins asking questions
+- [ ] No regression in existing planning functionality
+- [ ] All tests pass
+
+## Notes
+- The user message triggers Claude to start working, while system prompt provides the context
+- This mirrors how execution mode already works with the `-p 'Execute the task...'` pattern
+- Keep the existing logic for processing Claude's output after the session

package/RAF/012-name-picker-buffet/plans/008-add-auto-flag-for-plan-mode.md

@@ -0,0 +1,49 @@
+# Task: Add Auto Flag for Plan Mode
+
+## Objective
+Add `--auto` / `-y` CLI flag to `raf plan` command to skip Claude's permission prompts during planning sessions.
+
+## Context
+Execution mode (`raf do`) already uses `--dangerously-skip-permissions` for non-interactive Claude sessions. Users may want the same capability during planning to avoid manually approving file writes (decisions.md, plan files). This is useful for automated workflows or when the user trusts Claude's actions.
+
+## Requirements
+- Add `--auto` and `-y` flags to the `raf plan` command
+- When flag is set, pass `--dangerously-skip-permissions` to Claude
+- Works for both regular `raf plan` and `raf plan --amend`
+- Flag is opt-in (not the default behavior)
+- Maintain interactive TTY behavior (Claude can still ask planning questions)
+
+## Implementation Steps
+1. Update `src/commands/plan.ts`:
+   - Add `--auto` and `-y` options to Commander.js command definition
+   - Pass the flag value to `runPlanCommand()` and `runAmendCommand()`
+
+2. Update `src/core/claude-runner.ts` `runInteractive()`:
+   - Add optional `dangerouslySkipPermissions` flag to options
+   - When true, include `--dangerously-skip-permissions` in args
+   - Method signature: `runInteractive(systemPrompt, userMessage, { dangerouslySkipPermissions?: boolean, ...})`
+
+3. Update `src/commands/plan.ts`:
+   - Pass the flag through to `claudeRunner.runInteractive()`
+
+4. Update CLI help text to explain what the flag does:
+   - Short description: "Skip Claude's permission prompts"
+   - Clarify this is for file write permissions, not for skipping the planning interview
+
+5. Add unit tests for:
+   - ClaudeRunner.runInteractive() with dangerouslySkipPermissions option
+   - Command option parsing for --auto and -y flags
+
+## Acceptance Criteria
+- [ ] `raf plan --auto` or `raf plan -y` starts planning without permission prompts
+- [ ] `raf plan --amend <id> --auto` works similarly
+- [ ] Regular `raf plan` (without flag) still shows permission prompts
+- [ ] Claude's AskUserQuestion prompts for planning interview still work (not bypassed)
+- [ ] Help text accurately describes the flag
+- [ ] All tests pass
+
+## Notes
+- This flag only affects file operation permissions, not the planning interview questions
+- The `-y` shorthand matches common CLI conventions (like `apt -y`, `npm -y`)
+- Consider adding a warning message when flag is used to remind user that permissions are skipped
+- Task 007 (fix-plan-mode-user-prompt) should be completed first as it changes runInteractive() signature

package/RAF/013-dependencies-watchdog/decisions.md

@@ -0,0 +1,37 @@
+# Project Decisions
+
+## How should dependencies be specified in plan files? Should they use task IDs (e.g., `001`, `002`) or full task names?
+Task IDs only (Recommended) - Dependencies: 001, 002 - Simple, unambiguous, and matches existing naming.
+
+## Where in the plan file should dependencies be placed?
+New 'Dependencies' section (Recommended) - Add a dedicated ## Dependencies section after Context, before Requirements.
+
+## When a dependency fails, what should happen to the dependent task?
+Auto-fail with explanation (Recommended) - Mark as FAILED immediately, create outcome file explaining the dependency failure.
+
+## Should there be a new task status 'blocked' (distinct from 'failed') shown in status displays?
+Yes, add 'blocked' status (Recommended) - Shows as BLOCKED in status, distinct from tasks that failed on their own.
+
+## How should circular dependencies be handled (e.g., task 002 depends on 003, but 003 depends on 002)?
+Add instruction in planning system prompt to order files in suggested order of execution and avoid circular dependencies. No programmatic validation - rely on Claude's planning intelligence.
+
+## Should Claude ask about dependencies during the planning interview, or infer them automatically from task descriptions?
+Infer automatically (Recommended) - Claude analyzes task relationships and adds dependencies without asking.
+
+## What dependency context should Claude receive when executing a task that has dependencies?
+Show dependency outcomes (Recommended) - Include outcome summaries of completed dependency tasks in execution context.
+
+## What marker should blocked tasks use in their outcome files?
+New BLOCKED marker (Recommended) - Use `<promise>BLOCKED</promise>` - distinct from COMPLETE and FAILED.
+
+## [Amendment] For the 'act' alias of 'raf do': Should it be a complete alias (same options, same behavior) or just a shortcut with any differences?
+Complete alias (Recommended) - raf act = raf do with all the same options and behavior.
+
+## [Amendment] For the ctrl-c message: When should this message be displayed?
+After plan created (Recommended) - Show when planning is complete, before Claude exits.
+
+## [Amendment] What should the exact message say after planning?
+Generic message (Recommended) - Press Ctrl-C twice to exit. Then run: raf do <project>
+
+## [Amendment] Should the message also mention that planning can be amended later?
+No, keep it simple (Recommended) - Only show ctrl-c and raf do instructions.

package/RAF/013-dependencies-watchdog/input.md

@@ -0,0 +1 @@
+when "raf do" add dependency check on other tasks, account for this in planning prompts. for example when building complex project plan could be dependant on each other, we order them on planning stage, that is good, but what if dependancy task fails, we need to account for that and don't do other tasks (fail them). instruct claude to check for it in system prompts