feed-the-machine 1.0.0

package/ftm-codex-gate/SKILL.md

@@ -0,0 +1,302 @@
+---
+name: ftm-codex-gate
+description: Codex CLI integration gate for adversarial code validation. Invokes codex exec --yolo --ephemeral with gpt-5.4 to form test scenarios, review code quality, fix failures, and enforce STYLE.md patterns. Use when ftm-executor needs Codex validation at wave boundaries or task completion, or when user says "codex gate", "run codex", "validate with codex". Not for direct user interaction — primarily auto-invoked by ftm-executor.
+---
+
+## Events
+
+### Emits
+- `review_complete` — when Codex finishes analysis and a PASS, PASS_WITH_FIXES, or FAIL verdict is produced
+- `issue_found` — when Codex identifies a quality violation, INTENT.md conflict, or test failure in the reviewed files
+- `task_completed` — when the gate run concludes and results are returned to the calling skill
+
+### Listens To
+- `code_committed` — run adversarial validation at wave boundaries after commits land in the executor's worktree
+
+## Blackboard Read
+
+Before starting, load context from the blackboard:
+
+1. Read `~/.claude/ftm-state/blackboard/context.json` — check current_task, recent_decisions, active_constraints
+2. Read `~/.claude/ftm-state/blackboard/experiences/index.json` — filter entries by tags matching "validation", "codex", or "review"
+3. Load top 3-5 matching experience files for patterns in what Codex commonly flags or auto-fixes
+4. Read `~/.claude/ftm-state/blackboard/patterns.json` — check recurring_issues for common validation failures and execution_patterns for typical fix types
+
+If index.json is empty or no matches found, proceed normally without experience-informed shortcuts.
+
+# Codex Gate
+
+This skill is the integration layer between ftm-executor and the Codex CLI. It constructs adversarial validation prompts, runs them through `codex exec`, captures structured output, and returns results to the calling skill. It does not interact with the user directly — it is invoked at wave boundaries or task completion.
+
+---
+
+## Inputs
+
+Expect these inputs from the calling skill (ftm-executor). If any are missing, ask for them before proceeding.
+
+- `file_list` — List of changed files to review (absolute paths)
+- `acceptance_criteria` — The acceptance criteria from the plan tasks in this wave
+- `wave_context` — A summary of what this wave accomplished
+- `project_root` — The working directory path (absolute)
+- `mode` — `"wave"` (default) or `"single-task"`
+
+---
+
+## Step 1: Read Context Files
+
+Read the following files from `project_root` before constructing the Codex prompt:
+
+1. `{project_root}/INTENT.md` (root) — Provides function-level context on what each piece of code should do
+2. `{project_root}/STYLE.md` — Provides code standards and AI-ergonomic patterns Codex must enforce
+3. For each file in `file_list`, check if a module-level `INTENT.md` exists alongside it (e.g. `src/auth/INTENT.md`) and read it if present
+
+If either root file is missing, note it in the prompt to Codex and continue — do not abort.
+
+---
+
+## Step 2: Determine Mode
+
+- If `mode` is `"wave"`, use broad wave-level context in the prompt (all files together, full acceptance criteria, wave summary)
+- If `mode` is `"single-task"`, scope the prompt tightly to the single task's files and criteria only
+
+---
+
+## Step 3: Construct the Codex Prompt
+
+Build a prompt string using the template below. Substitute all `{variables}` before passing to Codex.
+
+```
+You are an adversarial code reviewer for a software project. Your job is to break the implementation, find edge cases, enforce code standards, and leave the codebase cleaner than you found it.
+
+## Context
+
+Mode: {mode}
+Wave summary: {wave_context}
+
+## Acceptance Criteria
+
+{acceptance_criteria}
+
+## Files Changed
+
+{file_list — one per line}
+
+## Reference Documents
+
+### INTENT.md (root)
+{contents of root INTENT.md, or "Not found — skip INTENT validation"}
+
+### STYLE.md
+{contents of STYLE.md, or "Not found — skip style enforcement"}
+
+{if module-level INTENT.md files were found, include each one with a header like:}
+### INTENT.md ({module path})
+{contents}
+
+## Your Tasks — execute all of these in order
+
+1. Read every file in the file list. Understand what each function does and what it is supposed to do per INTENT.md.
+
+2. Form adversarial test scenarios. Think about:
+   - Edge cases the happy-path tests don't cover
+   - Inputs that should fail gracefully but might not
+   - Race conditions, off-by-one errors, null/undefined handling
+   - Boundary conditions in the acceptance criteria
+   - Any place INTENT.md says a function should do X but the code does Y
+
+3. Run the tests. Fix every failure you find. Commit each fix separately with a descriptive message (e.g. "fix: handle null user in auth guard").
+
+4. Review code quality against STYLE.md:
+   - Flag any function over 50 lines
+   - Flag any file over 1000 lines
+   - Flag more than 3 levels of nesting
+   - Flag barrel index.ts re-exports
+   - Flag unclear naming that requires a comment to explain
+
+5. Fix any STYLE.md violations. Commit each fix separately.
+
+6. Append a summary of all findings and fixes to DEBUG.md at the project root. Use this format:
+   ### Codex Gate — {timestamp}
+   **Wave**: {wave_context summary, one line}
+   **Fixes**: [list each fix with commit hash and description]
+   **Quality issues**: [list each issue found, whether fixed or not]
+   **INTENT.md conflicts**: [list any place code diverged from INTENT.md]
+
+7. Write your structured output summary to the output file. Use exactly this format:
+
+## Codex Gate Results
+
+**Status**: PASS | PASS_WITH_FIXES | FAIL
+**Tests formed**: [count]
+**Tests passed**: [count]
+**Fixes applied**: [count]
+**Quality issues**: [count]
+
+### Fixes Applied
+- [commit hash]: [description]
+
+### Remaining Issues
+- [file:line] — [description]
+
+### INTENT.md Conflicts
+- [conflict description] — [affected function] — [what you changed vs what INTENT.md says]
+
+Status rules:
+- PASS: no failures, no quality issues
+- PASS_WITH_FIXES: failures or quality issues found and resolved
+- FAIL: failures remain that you could not fix
+```
+
+---
+
+## Step 4: Generate Timestamp and Output Path
+
+Generate a Unix timestamp for the output file path to avoid collisions:
+
+```
+TIMESTAMP=$(date +%s)
+OUTPUT_FILE="/tmp/codex-result-${TIMESTAMP}.md"
+```
+
+---
+
+## Step 5: Construct and Run the Command
+
+Assemble the full command using the prompt from Step 3. Pass the prompt as the positional argument to `codex exec`.
+
+Base command template:
+```
+codex exec --yolo --ephemeral -m "gpt-5.4" -c model_reasoning_effort="high" -o {OUTPUT_FILE} "{prompt}"
+```
+
+Full invocation example (run via Bash):
+```bash
+TIMESTAMP=$(date +%s)
+OUTPUT_FILE="/tmp/codex-result-${TIMESTAMP}.md"
+codex exec --yolo --ephemeral \
+  -m "gpt-5.4" \
+  -c model_reasoning_effort="high" \
+  -o "$OUTPUT_FILE" \
+  "$CODEX_PROMPT"
+```
+
+Set a timeout of 600 seconds. If Codex does not complete within 600s, move to Step 6 with whatever partial output exists.
+
+**Flags reference:**
+- `--yolo` — No sandbox, no approval prompts; Claude Code is the outer sandbox
+- `--ephemeral` — No session state persisted on the Codex side
+- `-m "gpt-5.4"` — Model to use
+- `-c model_reasoning_effort="high"` — High reasoning effort for thorough analysis
+- `-o {OUTPUT_FILE}` — Write structured output to this file for clean capture
+
+---
+
+## Step 6: Error Handling
+
+Handle each failure case before reading the output file.
+
+**Codex not found:**
+```
+If `which codex` returns nothing or the command exits with "command not found":
+Return: "Codex CLI not found. Install with: npm install -g @openai/codex — then re-run the gate."
+Do not proceed.
+```
+
+**Timeout (>600s):**
+```
+If the command exceeds 600 seconds:
+Check if OUTPUT_FILE exists and has content.
+If yes: proceed to Step 7 with a note "PARTIAL RESULTS — Codex timed out at 600s"
+If no: return FAIL with message "Codex timed out with no output captured."
+```
+
+**Non-zero exit code:**
+```
+Capture stderr. Include it in the results under "Remaining Issues" as:
+- [stderr content] — Codex exited with code {exit_code}
+Proceed to Step 7 to read any partial output.
+```
+
+**Output file empty or missing:**
+```
+Return structured result with Status: FAIL and message:
+"Codex output file not found or empty at {OUTPUT_FILE}. Codex may have crashed or produced no output."
+```
+
+---
+
+## Step 7: Read and Parse the Output File
+
+Read `OUTPUT_FILE`. Extract the structured block that begins with `## Codex Gate Results`.
+
+Return the full structured summary to the calling skill (ftm-executor) in this exact format:
+
+```
+## Codex Gate Results
+
+**Status**: PASS | PASS_WITH_FIXES | FAIL
+**Tests formed**: [count]
+**Tests passed**: [count]
+**Fixes applied**: [count]
+**Quality issues**: [count]
+
+### Fixes Applied
+- [commit hash]: [description]
+
+### Remaining Issues
+- [file:line] — [description]
+
+### INTENT.md Conflicts
+- [conflict description] — [affected function] — [what Codex changed vs what INTENT.md says]
+```
+
+If the output file does not contain the expected format, return the raw file content and flag it as unstructured with Status: FAIL.
+
+---
+
+## Step 8: Return to Caller
+
+Pass the structured result back to ftm-executor. Do not post to any external system, do not notify the user directly unless ftm-executor explicitly delegates that to this skill.
+
+If Status is FAIL or PASS_WITH_FIXES, include the full "Remaining Issues" and "INTENT.md Conflicts" sections so ftm-executor can decide whether to retry, escalate, or continue to the next wave.
+
+---
+
+## Invocation Modes Summary
+
+| Mode | Scope | Prompt focus |
+|------|-------|-------------|
+| `wave` (default) | All files from completed wave | Full wave context, all acceptance criteria, broader adversarial sweep |
+| `single-task` | Files from one task | Tight scope, single task criteria, targeted adversarial cases |
+
+---
+
+## Blackboard Write
+
+After completing, update the blackboard:
+
+1. Update `~/.claude/ftm-state/blackboard/context.json`:
+   - Set current_task status to "complete"
+   - Append decision summary to recent_decisions including the gate verdict (cap at 10)
+   - Update session_metadata.skills_invoked and last_updated
+2. Write an experience file to `~/.claude/ftm-state/blackboard/experiences/YYYY-MM-DD_task-slug.json` capturing gate mode, verdict, tests formed/passed, fixes applied, and any INTENT.md conflicts found
+3. Update `~/.claude/ftm-state/blackboard/experiences/index.json` with the new entry
+4. Emit `task_completed` event
+
+## Error Output Template
+
+When returning an error before Codex runs:
+
+```
+## Codex Gate Results
+
+**Status**: FAIL
+**Error**: [description]
+**Tests formed**: 0
+**Tests passed**: 0
+**Fixes applied**: 0
+**Quality issues**: 0
+
+### Remaining Issues
+- [error detail]
+```

package/ftm-codex-gate.yml

@@ -0,0 +1,2 @@
+name: ftm-codex-gate
+description: Codex CLI integration gate for adversarial code validation. Invokes codex exec --yolo --ephemeral with gpt-5.4 to form test scenarios, review code quality, fix failures, and enforce STYLE.md patterns. Use when ftm-executor needs Codex validation at wave boundaries or task completion, or when user says "codex gate", "run codex", "validate with codex". Not for direct user interaction — primarily auto-invoked by ftm-executor.

package/ftm-config/SKILL.md

@@ -0,0 +1,310 @@
+---
+name: ftm-config
+description: Configure ftm skill settings including model profiles, execution preferences, and defaults. Use when user says "ftm config", "ftm settings", "set ftm profile", "ftm model", or wants to change how ftm skills behave.
+---
+
+## Events
+
+### Emits
+- `task_completed` — when a configuration change is validated, saved, and confirmed to the user
+
+### Listens To
+(none — ftm-config is explicitly invoked by the user and does not respond to events)
+
+# FTM Config
+
+Manage configuration for all ftm skills, including model profiles, execution preferences, and session settings.
+
+## Config File Location
+
+`~/.claude/ftm-config.yml`
+
+This is the single source of truth for all ftm skill behavior. Every ftm skill reads from this file at startup.
+
+## Config Schema
+
+```yaml
+# FTM Skills Configuration
+# Edit this file or use /ftm-config to modify settings
+
+# Model profiles control which model is used at each stage
+# Options: opus, sonnet, haiku, inherit (use session default)
+profile: balanced  # quality | balanced | budget | custom | inherit
+
+profiles:
+  quality:
+    planning: opus      # brainstorm, research, plan generation
+    execution: opus     # agent task implementation
+    review: sonnet      # audit, debug review, council synthesis
+
+  balanced:
+    planning: opus
+    execution: sonnet
+    review: sonnet
+
+  budget:
+    planning: sonnet
+    execution: sonnet
+    review: haiku
+
+  inherit:
+    planning: inherit
+    execution: inherit
+    review: inherit
+
+  custom:
+    planning: opus
+    execution: sonnet
+    review: haiku
+
+# Execution preferences
+execution:
+  max_parallel_agents: 5          # max agents dispatched simultaneously
+  auto_audit: true                # run ftm-audit after each executor task
+  progress_tracking: true         # write PROGRESS.md during execution
+
+# Session management
+session:
+  auto_pause_on_exit: false       # automatically save state when conversation ends
+  state_retention_days: 7         # archive states older than this
+```
+
+## Instructions
+
+### Step 1: Read Current Config
+
+Read `~/.claude/ftm-config.yml`. If it does not exist, create it with the default configuration (balanced profile active, all defaults as shown in the schema above). Use the file-creator pattern or Write tool to create the file.
+
+### Step 2: Determine Intent
+
+Parse the user's input to determine what they want:
+
+- **No arguments** (bare `/ftm-config`): Display current configuration.
+- **`set profile <name>`**: Change the active profile.
+- **`set profile custom`**: Activate the custom profile, then interactively ask which model to use for each stage (planning, execution, review).
+- **`set <dotted.path> <value>`**: Update a specific setting (e.g., `set execution.max_parallel_agents 3`).
+- **`enable <skill-name>`** / **`disable <skill-name>`**: Enable or disable a skill in ftm-mind routing.
+- **`reset`**: Restore all settings to defaults.
+- **`show profiles`**: Display all available profiles side by side.
+- **`show skills`**: Display all skills and their enabled/disabled status.
+
+### Step 3: Display Current Configuration (No Args)
+
+When displaying the config, format it clearly:
+
+```
+FTM Configuration
+====================
+
+Active Profile: balanced
+
+  Planning   → opus    (brainstorm, research, plan generation)
+  Execution  → sonnet  (agent task implementation)
+  Review     → sonnet  (audit, debug review, council synthesis)
+
+Execution Settings:
+  Max Parallel Agents:  5
+  Auto Audit:           true
+  Progress Tracking:    true
+
+Session Settings:
+  Auto Pause on Exit:   false
+  State Retention Days: 7
+```
+
+### Step 4: Apply Changes
+
+When the user requests a change:
+
+1. **Validate inputs**:
+   - Model names must be one of: `opus`, `sonnet`, `haiku`, `inherit`. Reject anything else with a clear error.
+   - Profile names must be one of: `quality`, `balanced`, `budget`, `custom`, `inherit`. Reject anything else.
+   - Numeric values must be positive integers where applicable.
+   - Boolean values must be `true` or `false`.
+
+2. **Show before/after**:
+   ```
+   Changing active profile:
+     Before: balanced (opus / sonnet / sonnet)
+     After:  quality  (opus / opus / sonnet)
+   ```
+
+3. **Save changes**: Write the updated YAML back to `~/.claude/ftm-config.yml`.
+
+4. **Confirm**: Display the updated configuration section that changed.
+
+### Step 5: Handle Custom Profile
+
+When the user sets `profile custom`:
+
+1. Show the current custom profile settings.
+2. Ask: "Which model for **planning** (brainstorm, research)? [opus/sonnet/haiku/inherit]"
+3. Ask: "Which model for **execution** (agent tasks, code writing)? [opus/sonnet/haiku/inherit]"
+4. Ask: "Which model for **review** (audit, debug, council)? [opus/sonnet/haiku/inherit]"
+5. Validate each answer, save, and display the final custom profile.
+
+If the user provides all three in one line (e.g., `set profile custom opus haiku sonnet`), parse them positionally as planning/execution/review without asking interactively.
+
+### Step 6: Handle Reset
+
+When the user says `reset`:
+
+1. Show current configuration.
+2. Confirm: "This will restore all ftm settings to defaults. Proceed?"
+3. If confirmed, write the default configuration to `~/.claude/ftm-config.yml`.
+4. Display the restored defaults.
+
+## Valid Model Options
+
+| Model | Description | Best For |
+|-------|-------------|----------|
+| `opus` | Most capable, highest quality | Complex planning, architecture decisions |
+| `sonnet` | Balanced capability and speed | General execution, code writing, reviews |
+| `haiku` | Fastest, most efficient | Simple reviews, quick checks, budget tasks |
+| `inherit` | Use session default | When you want the conversation's current model |
+
+## Valid Profiles
+
+| Profile | Planning | Execution | Review | Use Case |
+|---------|----------|-----------|--------|----------|
+| `quality` | opus | opus | sonnet | Maximum quality, complex projects |
+| `balanced` | opus | sonnet | sonnet | Good default for most work |
+| `budget` | sonnet | sonnet | haiku | Token-efficient, simpler tasks |
+| `inherit` | inherit | inherit | inherit | Use whatever model the session runs |
+| `custom` | (user-defined) | (user-defined) | (user-defined) | Full user control |
+
+## How Other FTM Skills Use This Config
+
+All ftm skills should read `~/.claude/ftm-config.yml` at the start of execution to determine which model to use when spawning agents.
+
+### Reading the Config
+
+At the beginning of any ftm skill execution:
+
+1. Read `~/.claude/ftm-config.yml`.
+2. Look at the `profile` field to determine which profile is active.
+3. Look up that profile under `profiles.<profile_name>` to get the model for each stage.
+4. If the config file does not exist, use "balanced" defaults: `opus` for planning, `sonnet` for execution, `sonnet` for review.
+
+### Mapping Stages to FTM Skills
+
+| Stage | Config Key | FTM Skills That Use It |
+|-------|-----------|--------------------------|
+| **Planning** | `profiles.<active>.planning` | ftm-brainstorm, ftm (research/plan generation phase) |
+| **Execution** | `profiles.<active>.execution` | ftm-executor (all spawned task agents) |
+| **Review** | `profiles.<active>.review` | ftm-audit, ftm-debug, ftm-council (synthesis phase) |
+
+### Spawning Agents with the Correct Model
+
+When spawning agents, use the `model` parameter on the Agent tool:
+
+- **For planning agents** (research, brainstorming, plan generation):
+  Use the profile's `planning` model.
+
+- **For execution agents** (implementing tasks, writing code):
+  Use the profile's `execution` model.
+
+- **For review agents** (audit, debug review, council synthesis):
+  Use the profile's `review` model.
+
+If the model value is `"inherit"`, omit the `model` parameter entirely so the agent inherits the session's current model.
+
+### Example Resolution
+
+Given this config:
+```yaml
+profile: balanced
+profiles:
+  balanced:
+    planning: opus
+    execution: sonnet
+    review: sonnet
+```
+
+- `ftm-brainstorm` spawns its research agents with `model: opus`
+- `ftm-executor` spawns task agents with `model: sonnet`
+- `ftm-audit` spawns review agents with `model: sonnet`
+- `ftm-council` spawns synthesis agents with `model: sonnet`
+
+### Execution Preferences
+
+Other ftm skills should also respect:
+
+- **`execution.max_parallel_agents`**: Do not spawn more agents simultaneously than this number. Queue excess agents.
+- **`execution.auto_audit`**: If `true`, `ftm-executor` should automatically invoke `ftm-audit` after each task completes.
+- **`execution.progress_tracking`**: If `true`, write status updates to `PROGRESS.md` in the workspace during execution.
+
+### Session Preferences
+
+- **`session.auto_pause_on_exit`**: If `true`, ftm skills should automatically save state (like `ftm-pause`) when the conversation is ending.
+- **`session.state_retention_days`**: When resuming, archive or clean up state files older than this many days.
+
+## Examples
+
+### View current config
+```
+User: /ftm-config
+→ Displays full current configuration
+```
+
+### Switch to quality profile
+```
+User: /ftm-config set profile quality
+→ Shows before/after, saves change
+```
+
+### Set custom profile with specific models
+```
+User: /ftm-config set profile custom opus haiku sonnet
+→ Sets custom profile: planning=opus, execution=haiku, review=sonnet
+```
+
+### Change a specific setting
+```
+User: /ftm-config set execution.max_parallel_agents 3
+→ Updates max parallel agents from 5 to 3
+```
+
+### Disable auto-audit
+```
+User: /ftm-config set execution.auto_audit false
+→ Disables automatic audit after executor tasks
+```
+
+### Disable a skill
+```
+User: /ftm-config disable ftm-council
+→ Sets skills.ftm-council.enabled: false — ftm-mind will no longer route to it
+```
+
+### Show skill status
+```
+User: /ftm-config show skills
+→ Displays all skills with enabled/disabled status
+```
+
+### Reset to defaults
+```
+User: /ftm-config reset
+→ Confirms, then restores all settings to defaults
+```
+
+### Show all profiles
+```
+User: /ftm-config show profiles
+→ Displays table of all profiles with their model assignments
+```
+
+## Troubleshooting
+
+### Config file is missing
+The skill will create `~/.claude/ftm-config.yml` with default settings automatically. No action needed.
+
+### Invalid model name
+Only `opus`, `sonnet`, `haiku`, and `inherit` are valid. The skill will reject other values and show the valid options.
+
+### Config file is malformed
+If the YAML cannot be parsed, the skill will back up the broken file as `~/.claude/ftm-config.yml.bak` and create a fresh default config.
+
+### Changes not taking effect
+Other ftm skills read the config at startup. If a ftm skill is already running, it will use the config that was active when it started. Changes apply to the next invocation.

package/ftm-config.default.yml

@@ -0,0 +1,80 @@
+# FTM Skills Configuration
+# Edit this file or use /ftm-config to modify settings
+
+# Model profiles control which model is used at each stage
+# Options: opus, sonnet, haiku, inherit (use session default)
+profile: balanced  # quality | balanced | budget | custom | inherit
+
+profiles:
+  quality:
+    planning: opus      # brainstorm, research, plan generation
+    execution: opus     # agent task implementation
+    review: sonnet      # audit, debug review, council synthesis
+
+  balanced:
+    planning: opus
+    execution: sonnet
+    review: sonnet
+
+  budget:
+    planning: sonnet
+    execution: sonnet
+    review: haiku
+
+  inherit:
+    planning: inherit
+    execution: inherit
+    review: inherit
+
+  custom:
+    planning: opus
+    execution: sonnet
+    review: haiku
+
+# Execution preferences
+execution:
+  max_parallel_agents: 5          # max agents dispatched simultaneously
+  per_skill_overrides:              # skills read their own override, fall back to global
+    ftm-researcher: 10
+    ftm-executor: 8
+    ftm-debug: 6
+    ftm-brainstorm: 3              # fallback if researcher unavailable
+  auto_audit: true                # run ftm-audit after each executor task
+  progress_tracking: true         # write PROGRESS.md during execution
+  approval_mode: plan_first       # plan_first | always_ask
+                                  #   plan_first: every task gets a plan, micro tasks get inline plans
+                                  #   always_ask: always present full plan, even for micro tasks
+  tdd_mode: false               # when true, agents must write tests before implementation
+                                 # spec reviewer enforces RED-GREEN-REFACTOR compliance
+
+# Two-stage review — runs after each task agent completes, before ftm-audit
+review:
+  spec_reviewer_model: haiku    # fast, cheap — checks spec compliance only
+  quality_reviewer_model: opus  # thorough — checks code quality and bug risk
+  skip_quality_review: false    # set true to run spec review only (faster execution)
+
+# Skill enable/disable — set enabled: false to prevent ftm-mind from routing to a skill
+skills:
+  ftm-brainstorm: { enabled: true }
+  ftm-executor: { enabled: true }
+  ftm-debug: { enabled: true }
+  ftm-audit: { enabled: true }
+  ftm-council: { enabled: true }
+  ftm-codex-gate: { enabled: true }
+  ftm-intent: { enabled: true }
+  ftm-diagram: { enabled: true }
+  ftm-browse: { enabled: true }
+  ftm-pause: { enabled: true }
+  ftm-resume: { enabled: true }
+  ftm-upgrade: { enabled: true }
+  ftm-retro: { enabled: true }
+  ftm-config: { enabled: true }
+  ftm-git: { enabled: true }
+  ftm-mind: { enabled: true }
+  ftm-researcher: { enabled: true }   # deep parallel research engine
+  ftm-map: { enabled: true }          # persistent code knowledge graph
+
+# Session management
+session:
+  auto_pause_on_exit: false       # automatically save state when conversation ends
+  state_retention_days: 7         # archive states older than this

package/ftm-config.yml

@@ -0,0 +1,2 @@
+name: ftm-config
+description: Configure ftm skill settings including model profiles, execution preferences, and defaults. Use when user says "ftm config", "ftm settings", "set ftm profile", "ftm model", or wants to change how ftm skills behave.