planflow-ai 1.1.6 → 1.1.7

package/.claude/commands/create-plan.md

@@ -275,3 +275,60 @@ When executing this command:
 | `complexity-scoring.md`    | Complexity scoring system         |
 | `/discovery-plan` command   | Run discovery first               |
 | `/execute-plan` command     | Execute the created plan          |
+
+---
+
+## Tasklist Updates
+
+Update `flow/tasklist.md` at these points. See `.claude/resources/core/project-tasklist.md` for full rules.
+
+1. **On start**: Add "Plan: {feature}" to **In Progress** (or move it from To Do if it already exists)
+2. **On complete**: Move "Plan: {feature}" to **Done** with today's date
+3. **Next step**: Add "Execute plan for {feature}" to **To Do**
+
+---
+
+## Learn Recommendations
+
+After plan creation completes, check for learning opportunities. See `.claude/resources/core/learn-recommendations.md` for the full system.
+
+**Plan-specific checks**:
+- Does the plan introduce **new technologies** not in the current tech stack?
+- Are there phases that require **unfamiliar APIs or services**?
+- Did the discovery document flag any "Suggested Learning" topics?
+
+Present recommendations after the plan summary.
+
+---
+
+## Brain Capture
+
+After plan creation completes successfully, append a brain-capture block. See `.claude/resources/core/brain-capture.md` for processing rules.
+
+**Capture the following**:
+
+```
+<!-- brain-capture
+skill: create-plan
+feature: [feature name]
+status: completed
+data:
+  phase_count: [number of phases]
+  total_complexity: [sum of complexity scores]
+  highest_phase: [phase name with highest score]
+  discovery_link: [[discovery-feature-name]]
+  plan_doc: [path to plan document]
+-->
+```
+
+Update `flow/brain/features/[feature-name].md` with plan details and link to discovery entry.
+
+---
+
+## Resource Capture
+
+During this skill's execution, watch for valuable reference materials worth preserving. See `.claude/resources/core/resource-capture.md` for capture rules, file format, and naming conventions.
+
+At natural break points, if you encounter information that could be useful for future development (API specs, architecture notes, config references, domain knowledge, etc.), ask the user: "I found something that could be useful for future reference: _{brief description}_. Should I save it to `flow/resources/`?"
+
+Only save if the user approves. Do not re-ask if declined.

package/.claude/commands/discovery-plan.md

@@ -305,3 +305,78 @@ Read: resources/tools/interactive-questions-tool.md (lines from TLS-IQ-3)
 | `discovery-templates.md`      | Document templates                     |
 | `interactive-questions-tool.md` | Interactive Questions UI workflow    |
 | `/create-plan` command         | Creates plan from discovery document   |
+
+---
+
+## Tasklist Updates
+
+Update `flow/tasklist.md` at these points. See `.claude/resources/core/project-tasklist.md` for full rules.
+
+1. **On start**: Add "Discovery: {feature}" to **In Progress** (or move it from To Do if it already exists)
+2. **On complete**: Move "Discovery: {feature}" to **Done** with today's date
+3. **Next step**: Add "Create plan for {feature}" to **To Do**
+
+---
+
+## Learn Recommendations
+
+After discovery completes, check for learning opportunities. See `.claude/resources/core/learn-recommendations.md` for the full system.
+
+**Discovery-specific checks**:
+- Does the proposed approach introduce **new technologies** the project hasn't used before?
+- Are there **unfamiliar APIs or services** in the requirements?
+- Did the user mention switching from one pattern/tool to another?
+
+**If new tech is detected**, add a "Suggested Learning" section to the discovery document:
+
+```markdown
+## Suggested Learning
+
+The following topics are new to this project and may benefit from structured learning before implementation:
+
+| Topic | Why | Suggested Command |
+|-------|-----|-------------------|
+| Langfuse | New observability tool not previously used | `/learn langfuse` |
+| WebSocket | Real-time communication pattern new to project | `/learn websockets` |
+
+These are optional but recommended to reduce implementation friction.
+```
+
+**Detection**: Compare proposed technologies against `flow/references/tech-foundation.md` and existing `package.json` / `pyproject.toml` dependencies. If a technology is not in the current stack, flag it.
+
+**Presentation**: Include the section in the discovery document itself (not as a chat message). This ensures the learning suggestion persists and is visible when the user reviews the document.
+
+---
+
+## Brain Capture
+
+After discovery completes successfully, append a brain-capture block. See `.claude/resources/core/brain-capture.md` for processing rules.
+
+**Capture the following**:
+
+```
+<!-- brain-capture
+skill: discovery
+feature: [feature name from discovery]
+status: completed
+data:
+  user_prompt: [original user request]
+  questions_asked: [count]
+  questions_answered: [count]
+  requirements_fr: [count of functional requirements]
+  requirements_nfr: [count of non-functional requirements]
+  discovery_doc: [path to discovery document]
+-->
+```
+
+Write/update `flow/brain/features/[feature-name].md` with discovery context and update `flow/brain/index.md`.
+
+---
+
+## Resource Capture
+
+During this skill's execution, watch for valuable reference materials worth preserving. See `.claude/resources/core/resource-capture.md` for capture rules, file format, and naming conventions.
+
+At natural break points, if you encounter information that could be useful for future development (API specs, architecture notes, config references, domain knowledge, etc.), ask the user: "I found something that could be useful for future reference: _{brief description}_. Should I save it to `flow/resources/`?"
+
+Only save if the user approves. Do not re-ask if declined.

package/.claude/commands/execute-plan.md

@@ -140,6 +140,53 @@ Please run this command and let me know when it's complete.
 
 ---
 
+## Git Control
+
+On execution start, check if `flow/.flowconfig` exists — if yes, read git control settings (`commit`, `push`, `branch`) from it. Fallback: check `flow/.gitcontrol` for backward compatibility. If neither exists, no git operations are performed.
+
+### Git Control Settings
+
+```yaml
+# flow/.gitcontrol
+commit: true     # Auto-commit after each completed phase
+push: true       # Auto-push after all phases complete (requires commit: true)
+branch: develop  # Target branch (optional, defaults to current branch)
+```
+
+### Git Behavior During Execution
+
+| Setting | Behavior |
+|---------|----------|
+| `commit: true` | After each phase completes successfully, run `git add -A && git commit -m "Phase N: <phase name> — <feature>"` |
+| `commit: false` or no `.gitcontrol` | No automatic git operations (default behavior) |
+| `push: true` | After ALL phases complete AND build/test pass, run `git push origin <branch>` |
+| `push: false` or not set | No automatic push |
+| `branch: <name>` | Use this branch for push (default: current branch) |
+
+### Git Safety Rules
+
+| Rule | Description |
+|------|-------------|
+| **Commit only on success** | Only commit after a phase completes successfully. Never commit broken code. |
+| **Push only after build+test** | Push only after `npm run build && npm run test` pass at the very end. |
+| **No force push** | NEVER use `--force`. If push fails, stop and ask the user. |
+| **Commit message format** | `Phase N: <phase name> — <feature>` (e.g., "Phase 2: API endpoints — user-auth") |
+| **Final commit** | After build+test pass, make one final commit: `Complete: <feature> — all phases done, build passing` |
+| **Include flow artifacts** | Commits should include updated plan files with progress markers |
+
+### Example Flow with `commit=true push=true`
+
+```
+Phase 1: Setup types → completes → git commit "Phase 1: Setup types — user-auth"
+Phase 2: API endpoints → completes → git commit "Phase 2: API endpoints — user-auth"
+Phase 3: Frontend UI → completes → git commit "Phase 3: Frontend UI — user-auth"
+Phase 4: Tests → completes → git commit "Phase 4: Tests — user-auth"
+Build + Test → pass → git commit "Complete: user-auth — all phases done, build passing"
+                     → git push origin development
+```
+
+---
+
 ## Instructions
 
 ### Step 1: Validate Inputs
@@ -351,6 +398,30 @@ Update `flow/brain/features/[feature-name].md` with execution results. If errors
 
 ---
 
+## Tasklist Updates
+
+Update `flow/tasklist.md` at these points. See `.claude/resources/core/project-tasklist.md` for full rules.
+
+1. **On start**: Add "Execute: {feature}" to **In Progress** (or move it from To Do if it already exists)
+2. **On complete**: Move "Execute: {feature}" to **Done** with today's date
+3. **Next step**: Add "Review code for {feature}" to **To Do**
+
+---
+
+## Learn Recommendations
+
+After execution completes (or at the end of each phase), check for learning opportunities. See `.claude/resources/core/learn-recommendations.md` for the full system.
+
+**Quick checks at phase end**:
+- Were new dependencies added? → Recommend `/learn <dependency>`
+- Were non-trivial errors resolved (3+ attempts)? → Recommend `/learn` (pattern extraction)
+- Did the user correct the approach? → Recommend `/learn <corrected-topic>`
+- Was a new technology/pattern introduced? → Recommend `/learn <topic>`
+
+**Present batched recommendations** at the end of execution, before the final summary. Do NOT interrupt phase execution.
+
+---
+
 ## Resource Capture
 
 During this skill's execution, watch for valuable reference materials worth preserving. See `.claude/resources/core/resource-capture.md` for capture rules, file format, and naming conventions.

package/.claude/commands/flow.md

@@ -1,16 +1,17 @@
 ---
-description: Toggle autopilot flow mode or start the full workflow with a feature request. Use '/flow <prompt>' to enable autopilot and begin immediately.
+description: Configure plan-flow settings — autopilot mode, git control, and other runtime options. Use key=value syntax.
 ---
 
-# Flow: Autopilot Mode Toggle
+# Flow: Plan-Flow Configuration
 
 ## Command Description
 
-This command enables or disables **autopilot flow mode**. When enabled, every new user input is automatically classified and, if it's a feature request, the full plan-flow workflow runs automatically:
+This command is the **central configuration hub** for plan-flow runtime settings. All settings use `key=value` syntax and are persisted in `flow/.flowconfig` (YAML format).
 
-**contracts check → discovery → plan → execute → review-code → archive**
-
-The LLM pauses only at mandatory checkpoints (discovery Q&A, plan approval).
+Settings include:
+- **Autopilot mode** — auto-chain commands for feature requests
+- **Git control** — auto-commit per phase, auto-push after completion
+- **Branch targeting** — specify which branch to commit/push to
 
 ---
 
@@ -19,109 +20,194 @@ The LLM pauses only at mandatory checkpoints (discovery Q&A, plan approval).
 **If the user invokes this command with `-help`, display only this section and stop:**
 
 ```
-/flow - Autopilot Flow Mode Toggle
+/flow - Plan-Flow Configuration
 
 DESCRIPTION:
-  Enables or disables autopilot flow mode. When enabled, feature requests
-  automatically run the full plan-flow workflow without manual command invocation.
+  Central configuration command for plan-flow runtime settings.
+  All settings use key=value syntax and persist across sessions.
 
 USAGE:
-  /flow <prompt>      Enable autopilot and start the flow with the given feature request
-  /flow -enable       Enable autopilot mode (persists across sessions)
-  /flow -disable      Disable autopilot mode
-  /flow -status       Show current autopilot state
-  /flow               Same as -status
-  /flow -help         Show this help
+  /flow <key>=<value> [key=value ...]   Set one or more settings
+  /flow <prompt>                         Enable autopilot and start flow with prompt
+  /flow -status                          Show all current settings
+  /flow -reset                           Reset all settings to defaults
+  /flow -help                            Show this help
+
+SETTINGS:
+  autopilot=true|false   Enable/disable autopilot mode (default: false)
+  commit=true|false      Auto-commit after each completed phase (default: false)
+  push=true|false        Auto-push after all phases + build/test pass (default: false)
+  branch=<name>          Target branch for git operations (default: current branch)
 
 EXAMPLES:
-  /flow add dark mode support
-  /flow implement user authentication with OAuth2
-  /flow fix the login page loading issue
-
-BEHAVIOR WHEN ENABLED:
+  /flow autopilot=true                    # Enable autopilot
+  /flow commit=true push=true             # Enable git control (works without autopilot)
+  /flow autopilot=true commit=true        # Enable both
+  /flow branch=development                # Set target branch
+  /flow commit=false push=false           # Disable git control
+  /flow -status                           # Show current config
+  /flow -reset                            # Reset everything
+
+  # Shorthand: text without key=value enables autopilot and starts flow
+  /flow add dark mode support             # autopilot=true + start discovery
+  /flow commit=true add user auth         # autopilot=true + git + start discovery
+
+BEHAVIOR WHEN AUTOPILOT IS ON:
   - Feature requests → full flow (discovery → plan → execute → review → archive)
   - Trivial tasks (complexity 0-2) → executed directly, no flow
   - Questions/exploration → answered normally
   - Slash commands → run as normal
 
+GIT CONTROL (when commit=true):
+  - After each phase completes: auto-commit
+    "Phase N: <phase name> — <feature>"
+  - After all phases + build/test pass: auto-push if push=true
+  - If build/test fails: commit is made but push is skipped
+  - push=true without commit=true: auto-enables commit=true
+
 MANDATORY CHECKPOINTS (even in autopilot):
   - Discovery phase: pauses for user Q&A
   - Plan review: pauses for user approval before execution
 
-CONTEXT MANAGEMENT:
-  - Only loads the relevant command context at each step
-  - Suggests context cleanup (/clear) after each completed flow cycle
-
-STATE:
-  Persisted in flow/.autopilot (survives session restarts)
+CONFIG FILE:
+  All settings stored in flow/.flowconfig (YAML)
+  Backward compatible: also reads flow/.autopilot and flow/.gitcontrol
 ```
 
 ---
 
 ## Instructions
 
-### When invoked with `-enable`
+### Step 1: Parse Input
 
-1. Create the file `flow/.autopilot` (empty file)
-2. Confirm to the user:
+Parse the user input to determine what action to take:
 
-```markdown
-Autopilot flow mode **enabled**.
+1. **Scan for `key=value` pairs**: Extract all `key=value` tokens from the input
+2. **Check for flags**: `-status`, `-reset`, `-help`
+3. **Remaining text**: Anything left after extracting keys and flags is a prompt
 
-From now on, feature requests will automatically run the full workflow:
-1. Check contracts → 2. Discovery (pause for Q&A) → 3. Create plan (pause for approval) → 4. Execute plan → 5. Review code → 6. Archive
+**Valid keys**:
 
-Trivial tasks and questions are handled normally without the flow.
+| Key | Values | Default | Description |
+|-----|--------|---------|-------------|
+| `autopilot` | `true`, `false` | `false` | Enable/disable autopilot mode |
+| `commit` | `true`, `false` | `false` | Auto-commit after each phase |
+| `push` | `true`, `false` | `false` | Auto-push after completion |
+| `branch` | any string | current branch | Target branch for git ops |
 
-Use `/flow -disable` to turn off, or `/flow -status` to check state.
-```
+---
 
-### When invoked with `-disable`
+### Step 2: Load Existing Config
 
-1. Delete the file `flow/.autopilot` (if it exists)
-2. Confirm to the user:
+1. If `flow/.flowconfig` exists, read it
+2. **Backward compatibility**: If `.flowconfig` doesn't exist but `flow/.autopilot` does, read it and migrate:
+   - `flow/.autopilot` exists → `autopilot: true`
+   - `flow/.gitcontrol` exists → read its `commit`, `push`, `branch` values
+3. Merge parsed key=value pairs into existing config (new values override old)
 
-```markdown
-Autopilot flow mode **disabled**.
+---
 
-Commands will no longer auto-chain. Use individual slash commands as before:
-`/discovery-plan` → `/create-plan` → `/execute-plan` → `/review-code`
-```
+### Step 3: Validate Settings
 
-### When invoked with a prompt (e.g., `/flow add gemini support`)
+1. If `push=true` but `commit` is not `true`, auto-enable `commit=true` and warn:
+   > `push=true` requires `commit=true`. Enabling auto-commit as well.
+2. If `autopilot=false` and `commit=false` and no other settings, consider removing `.flowconfig`
+
+---
 
-If the user provides text that is NOT a flag (`-enable`, `-disable`, `-status`, `-help`), treat it as a **feature request with autopilot**:
+### Step 4: Save Config
 
-1. Create the file `flow/.autopilot` if it doesn't already exist
-2. Confirm autopilot is enabled (brief, one line)
-3. **Immediately start the flow** by invoking `/discovery-plan` with the user's prompt as the feature description
+Write the merged config to `flow/.flowconfig`:
 
-**Example**: `/flow add dark mode support` →
-1. Enable autopilot (`flow/.autopilot`)
-2. Run `/discovery-plan "add dark mode support"`
+```yaml
+# flow/.flowconfig — plan-flow runtime settings
+autopilot: true
+commit: true
+push: true
+branch: development
+```
 
-This is the most common usage pattern — the user wants to describe a feature and have the full flow run automatically.
+**Also maintain backward-compatible marker files**:
+- If `autopilot: true` → create `flow/.autopilot` (for backward compat with existing rules)
+- If `autopilot: false` → delete `flow/.autopilot`
+- Write git settings to `flow/.gitcontrol` as well (for backward compat)
 
 ---
 
-### When invoked with `-status` or no arguments
+### Step 5: Handle Action
+
+#### If `-status` or no arguments and no key=value pairs
+
+Show current config:
+
+```markdown
+**Plan-Flow Configuration**
+
+| Setting | Value |
+|---------|-------|
+| Autopilot | enabled/disabled |
+| Auto-commit | true/false |
+| Auto-push | true/false |
+| Branch | <name> or (current) |
+```
+
+#### If `-reset`
+
+1. Delete `flow/.flowconfig`, `flow/.autopilot`, `flow/.gitcontrol`
+2. Confirm: "All plan-flow settings reset to defaults."
 
-1. Check if `flow/.autopilot` exists
-2. Report:
+#### If only key=value pairs (no prompt text)
+
+1. Save settings (Steps 2-4)
+2. Confirm what changed:
 
 ```markdown
-Autopilot flow mode: **[ENABLED/DISABLED]**
+**Settings updated:**
+- commit: false → **true**
+- push: false → **true**
 
-[If enabled]: Feature requests will automatically run the full workflow.
-[If disabled]: Use individual slash commands to run each step manually.
+These apply to all `/execute-plan` runs.
 ```
 
+#### If prompt text remains (with or without key=value pairs)
+
+This is a **feature request with autopilot**:
+
+1. Set `autopilot: true` (if not already)
+2. Save all settings (Steps 2-4)
+3. Confirm settings briefly (one line)
+4. **Immediately start the flow** by invoking `/discovery-plan` with the prompt
+
+**Examples**:
+- `/flow add dark mode` → `autopilot=true`, start discovery
+- `/flow commit=true push=true add user auth` → `autopilot=true, commit=true, push=true`, start discovery
+
 ---
 
 ## Critical Rules
 
 | Rule | Description |
 | --- | --- |
-| **File-based state** | State is stored in `flow/.autopilot` - create to enable, delete to disable |
-| **No other side effects** | This command ONLY manages the marker file. It does not run any workflow steps. |
-| **Complete and stop** | After toggling state, STOP and wait for user input |
+| **Single config file** | All settings in `flow/.flowconfig`. Maintain `.autopilot` and `.gitcontrol` for backward compat. |
+| **Key=value syntax** | All settings use `key=value`. No `-enable`/`-disable` flags needed (use `autopilot=true/false`). |
+| **Settings are independent** | `commit=true` works without `autopilot=true`. Git control applies to any `/execute-plan` run. |
+| **Complete and stop** | After updating settings, STOP and wait for user input (unless a prompt was provided). |
+| **Backward compatible** | Still reads `flow/.autopilot` and `flow/.gitcontrol` if `.flowconfig` doesn't exist yet. |
+
+---
+
+## Config File Format
+
+```yaml
+# flow/.flowconfig — plan-flow runtime settings
+# Managed by /flow command. Do not edit manually.
+
+autopilot: false
+commit: false
+push: false
+branch: ""
+```
+
+**Location**: `flow/.flowconfig`
+**Format**: YAML
+**Persists**: Across sessions (file-based)

package/.claude/commands/heartbeat.md

@@ -46,8 +46,13 @@ EXAMPLE TASKS:
   every 6 hours - check for new issues and update tasklist
   weekly on Monday at 9:00 AM - generate weekly summary report
 
+TASKLIST INTEGRATION:
+  Tasks added to the tasklist with a schedule (e.g., "in 1 hour", "at 3 PM")
+  automatically create a linked heartbeat task. Both files cross-reference
+  each other with [[]] links for Obsidian navigation.
+
 RELATED COMMANDS:
-  /flow           Toggle autopilot mode
+  /flow           Configure plan-flow settings
   /brain          Manual brain entry
 ```
 

package/.claude/commands/review-code.md

@@ -170,3 +170,71 @@ When executing this command:
 | `resources/core/_index.md`        | Index of core rules with reference codes |
 | `review-code-skill.md`        | Skill that executes the review         |
 | `review-pr-patterns.md`       | Review patterns and guidelines         |
+
+---
+
+## Tasklist Updates
+
+Update `flow/tasklist.md` at these points. See `.claude/resources/core/project-tasklist.md` for full rules.
+
+1. **On start**: Add "Review: {scope}" to **In Progress** (or move it from To Do if it already exists)
+2. **On complete**: Move "Review: {scope}" to **Done** with today's date
+
+---
+
+## Learn Recommendations
+
+After the review completes, check for learning opportunities. See `.claude/resources/core/learn-recommendations.md` for the full system.
+
+**Review-specific checks** (scan the diff for):
+- **New imports** from packages not previously used in the project
+- **Pattern changes** (different state management, different API patterns, new testing approaches)
+- **New configuration files** for tools not previously in the project (Docker, CI/CD, etc.)
+
+Present recommendations at the end of the review document, after the summary:
+
+```markdown
+## Learn Opportunities
+
+The following new technologies/patterns were detected in this changeset:
+
+- `/learn zustand` — New state management library introduced (replaces Redux)
+- `/learn` — Non-trivial error patterns worth capturing as reusable knowledge
+
+Run any of these to build structured understanding before or after merging.
+```
+
+---
+
+## Brain Capture
+
+After code review completes, append a brain-capture block. See `.claude/resources/core/brain-capture.md` for processing rules.
+
+**Capture the following**:
+
+```
+<!-- brain-capture
+skill: review-code
+feature: [feature or scope reviewed]
+status: completed
+data:
+  files_reviewed: [count]
+  issues_found: [total count]
+  severity_critical: [count]
+  severity_warning: [count]
+  severity_info: [count]
+  pattern_conflicts: [list of pattern conflicts found, if any]
+-->
+```
+
+Update `flow/brain/features/[feature-name].md` if reviewing a known feature. Log to `flow/brain/sessions/YYYY-MM-DD.md` otherwise.
+
+---
+
+## Resource Capture
+
+During this skill's execution, watch for valuable reference materials worth preserving. See `.claude/resources/core/resource-capture.md` for capture rules, file format, and naming conventions.
+
+At natural break points, if you encounter information that could be useful for future development (API specs, architecture notes, config references, domain knowledge, etc.), ask the user: "I found something that could be useful for future reference: _{brief description}_. Should I save it to `flow/resources/`?"
+
+Only save if the user approves. Do not re-ask if declined.

package/.claude/commands/review-pr.md

@@ -169,3 +169,72 @@ When executing this command:
 | `review-pr-skill.md`          | Skill that executes the review         |
 | `auth-pr-tool.md`             | Authentication tool for PR platforms   |
 | `review-pr-patterns.md`       | Review patterns and guidelines         |
+
+---
+
+## Tasklist Updates
+
+Update `flow/tasklist.md` at these points. See `.claude/resources/core/project-tasklist.md` for full rules.
+
+1. **On start**: Add "Review PR: #{number}" to **In Progress** (or move it from To Do if it already exists)
+2. **On complete**: Move "Review PR: #{number}" to **Done** with today's date
+
+---
+
+## Learn Recommendations
+
+After the PR review completes, check for learning opportunities. See `.claude/resources/core/learn-recommendations.md` for the full system.
+
+**PR review-specific checks** (scan the diff for):
+- **New imports** from packages not previously used in the project
+- **Pattern changes** (different state management, different API patterns, new testing approaches)
+- **New configuration files** for tools not previously in the project (Docker, CI/CD, etc.)
+- **Framework migrations** (major version upgrades, framework switches)
+
+Present recommendations at the end of the review document, after the summary:
+
+```markdown
+## Learn Opportunities
+
+The following new technologies/patterns were detected in this PR:
+
+- `/learn zustand` — New state management library introduced (replaces Redux)
+- `/learn docker` — Docker configuration added to the project for the first time
+
+Run any of these to build structured understanding before or after merging.
+```
+
+---
+
+## Brain Capture
+
+After PR review completes, append a brain-capture block. See `.claude/resources/core/brain-capture.md` for processing rules.
+
+**Capture the following**:
+
+```
+<!-- brain-capture
+skill: review-pr
+feature: [PR title or scope]
+status: completed
+data:
+  pr_number: [PR number]
+  pr_platform: [github/azure-devops]
+  issues_found: [total count]
+  review_outcome: [approved/changes-requested/commented]
+  severity_critical: [count]
+  severity_warning: [count]
+-->
+```
+
+Log to `flow/brain/sessions/YYYY-MM-DD.md` with PR review summary.
+
+---
+
+## Resource Capture
+
+During this skill's execution, watch for valuable reference materials worth preserving. See `.claude/resources/core/resource-capture.md` for capture rules, file format, and naming conventions.
+
+At natural break points, if you encounter information that could be useful for future development (API specs, architecture notes, config references, domain knowledge, etc.), ask the user: "I found something that could be useful for future reference: _{brief description}_. Should I save it to `flow/resources/`?"
+
+Only save if the user approves. Do not re-ask if declined.