ai-factory.feature
Feature - New Feature Workflow
Start a new feature by creating a branch and planning implementation.
Workflow
Step 0: Load Project Context
FIRST: Read .ai-factory/DESCRIPTION.md if it exists to understand:
- Tech stack (language, framework, database)
- Project architecture
- Existing conventions
This context informs branch naming, task planning, and implementation.
Step 0.1: Ensure Git Repository
Check if git is initialized. If not, initialize it.
git rev-parse --is-inside-work-tree 2>/dev/null || git init
Step 0.2: Parse Flags
Extract flags from $ARGUMENTS before parsing the feature description:
--parallel → Enable parallel worktree mode
--list → Show all active worktrees with feature status
--cleanup <branch> → Remove worktree and optionally delete branch
Parsing rules:
- Strip
--parallel,--list,--cleanup <branch>from$ARGUMENTS - Remaining text becomes the feature description
--listand--cleanupare standalone — they execute immediately and stop (do NOT continue to Step 1+)
Examples:
/ai-factory.feature --parallel Add user authentication
→ parallel=true, description="Add user authentication"
/ai-factory.feature --list
→ show all active worktrees, then STOP
/ai-factory.feature --cleanup feature/user-auth
→ remove worktree for that branch, then STOP
/ai-factory.feature Add user authentication
→ normal flow (unchanged), parallel=false
If --list is present, jump to the --list Subcommand section.
If --cleanup is present, jump to the --cleanup Subcommand section.
Otherwise, continue to Step 1.
Step 1: Parse Feature Description
From $ARGUMENTS, extract:
- Core functionality being added
- Key domain terms
- Type (feature, enhancement, fix, refactor)
Step 2: Generate Branch Name
Create a descriptive branch name:
Format: <type>/<short-description>
Examples:
- feature/user-authentication
- feature/stripe-checkout
- feature/product-search
- fix/cart-total-calculation
- refactor/api-error-handling
Rules:
- Lowercase with hyphens
- Max 50 characters
- No special characters except hyphens
- Descriptive but concise
Step 3: Ask About Testing
IMPORTANT: Always ask the user before proceeding:
Before we start, a few questions:
1. Should I write tests for this feature?
- [ ] Yes, write tests
- [ ] No, skip tests
2. Update documentation after implementation?
- [ ] Yes, update docs (/ai-factory.docs)
- [ ] No, skip docs
3. Any specific requirements or constraints?
Store the testing and documentation preferences - they will be passed to /ai-factory.task and /ai-factory.implement.
Step 4 (Parallel): Create Worktree
Only when --parallel flag is set. If not set, skip to Step 4 (Normal).
This creates an isolated working directory so multiple features can be developed concurrently, each with its own Claude Code session.
4a. Get project directory name
DIRNAME=$(basename "$(pwd)")
# e.g. "my-project"
4b. Create branch on main
git branch <branch-name> main
If the branch already exists, ask the user whether to reuse it or pick a different name.
4c. Create worktree
git worktree add ../${DIRNAME}-<branch-name-with-hyphens> <branch-name>
Convert the branch name for the directory: replace / with -.
Example:
Project dir: my-project
Branch: feature/user-auth
Worktree: ../my-project-feature-user-auth
4d. Copy context files to worktree
Copy these files/directories so the worktree has full AI context:
WORKTREE="../${DIRNAME}-<branch-name-with-hyphens>"
# Project context
cp .ai-factory/DESCRIPTION.md "${WORKTREE}/.ai-factory/DESCRIPTION.md" 2>/dev/null
# Past lessons / patches
cp -r .ai-factory/patches/ "${WORKTREE}/.ai-factory/patches/" 2>/dev/null
# Claude Code skills + settings (required for Claude Code to work)
cp -r .claude/ "${WORKTREE}/.claude/" 2>/dev/null
# CLAUDE.md only if it exists and is NOT tracked by git
if [ -f CLAUDE.md ] && ! git ls-files --error-unmatch CLAUDE.md &>/dev/null; then
cp CLAUDE.md "${WORKTREE}/CLAUDE.md"
fi
Note: Files tracked by git are already in the worktree via the checkout. Only copy untracked context files.
4e. Create features directory in worktree
mkdir -p "${WORKTREE}/.ai-factory/features"
4f. Switch to worktree and continue
cd "${WORKTREE}"
Display a brief confirmation:
✅ Parallel worktree created!
Branch: <branch-name>
Directory: <worktree-path>
To manage worktrees later:
/ai-factory.feature --list
/ai-factory.feature --cleanup <branch-name>
Continue to Step 5 — invoke /ai-factory.task in the worktree directory to start planning immediately.
Step 4 (Normal): Create Branch
# Ensure we're on main/master and up to date
git checkout main
git pull origin main
# Create and switch to new branch
git checkout -b <branch-name>
If branch already exists, ask user:
- Switch to existing branch?
- Create with different name?
Step 5: Invoke Task Planning with Branch Context
Plan file will be named after the branch:
Branch: feature/user-authentication
Plan file: .ai-factory/features/feature-user-authentication.md (NOT .ai-factory/PLAN.md!)
Convert branch name to filename:
- Replace
/with- - Add
.mdextension
Call /ai-factory.task with explicit context:
/ai-factory.task $ARGUMENTS
CONTEXT FROM /ai-factory.feature:
- Plan file: .ai-factory/features/feature-user-authentication.md (use this name, NOT .ai-factory/PLAN.md)
- Testing: yes/no
- Logging: verbose/standard/minimal
IMPORTANT: Pass the exact plan filename to /ai-factory.task. This distinguishes feature-based work from direct /ai-factory.task calls.
Pass along:
- Full feature description
- Exact plan file name (based on branch, e.g.,
.ai-factory/features/feature-user-authentication.md) - Testing preference
- Logging preference
- Any constraints
The plan file allows resuming work based on current git branch:
git branch --show-current # → feature/user-authentication
# → Look for .ai-factory/features/feature-user-authentication.md
Step 6: Next Action (depends on mode)
Parallel mode (--parallel): Automatically invoke /ai-factory.implement — the whole point of parallel is autonomous end-to-end execution in an isolated worktree.
/ai-factory.implement
CONTEXT FROM /ai-factory.feature:
- Plan file: .ai-factory/features/<branch-name>.md
- Testing: yes/no
- Logging: verbose/standard/minimal
- Docs: yes/no
Normal mode: STOP after planning. The user reviews the plan and decides when to implement.
Plan created! To start implementation:
/ai-factory.implement
Context Cleanup
Context is heavy after branch creation and planning. All results are saved to the plan file — suggest freeing space:
AskUserQuestion: Free up context before continuing?
Options:
1. /clear — Full reset (recommended)
2. /compact — Compress history
3. Continue as is
--list Subcommand
When --list is passed, show all active worktrees and their feature status. Then STOP — do not continue the normal workflow.
# Show all worktrees
git worktree list
Additionally, for each worktree path from the output:
- Check if
<worktree>/.ai-factory/features/contains any plan files - For each plan file found, show its name and whether it looks complete (has tasks) or is still in progress
Output format:
Active worktrees:
/path/to/my-project (main) ← you are here
/path/to/my-project-feature-user-auth (feature/user-auth) → Plan: feature-user-auth.md
/path/to/my-project-fix-cart-bug (fix/cart-bug) → No plan yet
--cleanup Subcommand
When --cleanup <branch> is passed, remove the worktree and optionally delete the branch. Then STOP.
DIRNAME=$(basename "$(pwd)")
BRANCH_DIR=$(echo "<branch>" | tr '/' '-')
WORKTREE="../${DIRNAME}-${BRANCH_DIR}"
# Remove the worktree
git worktree remove "${WORKTREE}"
# Only delete branch if it's been merged into main
git branch -d <branch> # -d (not -D) will fail if unmerged, which is safe
If git branch -d fails because the branch is unmerged, inform the user:
⚠️ Branch <branch> has unmerged changes.
To force-delete: git branch -D <branch>
To merge first: git checkout main && git merge <branch>
If the worktree path doesn't exist, check git worktree list and suggest the correct path.
Examples
User: /ai-factory.feature Add user authentication with email/password and OAuth
Actions:
- Parse: authentication feature, email/password + OAuth
- Generate branch:
feature/user-authentication - Ask about testing preference
- Create branch:
git checkout -b feature/user-authentication - Call
/ai-factory.task→ creates plan, user reviews - STOP — user runs
/ai-factory.implementwhen ready
User: /ai-factory.feature --parallel Add Stripe checkout integration
Actions:
- Parse flags:
--parallelfound, description = "Add Stripe checkout integration" - Generate branch:
feature/stripe-checkout - Ask about testing preference
- Get dirname:
my-project - Create branch:
git branch feature/stripe-checkout main - Create worktree:
git worktree add ../my-project-feature-stripe-checkout feature/stripe-checkout - Copy context files (.ai-factory/DESCRIPTION.md, .ai-factory/patches/, .claude/, CLAUDE.md if untracked)
cdinto worktree- Call
/ai-factory.task→ creates plan, user reviews - Auto-invoke
/ai-factory.implement→ executes the plan (parallel = autonomous)
User: /ai-factory.feature --list
Actions:
- Run
git worktree list - Check each worktree for plan files in
.ai-factory/features/ - Display formatted list — STOP
User: /ai-factory.feature --cleanup feature/stripe-checkout
Actions:
- Compute worktree path:
../my-project-feature-stripe-checkout - Run
git worktree remove ../my-project-feature-stripe-checkout - Run
git branch -d feature/stripe-checkout - Report result — STOP
User: /ai-factory.feature Fix cart not updating quantities correctly
Actions:
- Parse: bug fix, cart quantities
- Generate branch:
fix/cart-quantity-update - Ask about testing
- Create branch
- Call
/ai-factory.task→ creates plan, user reviews - STOP — user runs
/ai-factory.implementwhen ready
Important
- Always ask about testing before creating the plan
- Never assume testing preference - always ask explicitly
- Pass testing preference to downstream skills
- If git operations fail, report clearly and don't proceed
- Don't create branch if one with same purpose exists (ask first)
CRITICAL: Logging Preference
When asking about testing, also ask about logging:
Before we start:
1. Should I write tests for this feature?
- [ ] Yes, write tests
- [ ] No, skip tests
2. Logging level for implementation:
- [ ] Verbose (recommended) - detailed DEBUG logs for development
- [ ] Standard - INFO level, key events only
- [ ] Minimal - only WARN/ERROR
3. Update documentation after implementation?
- [ ] Yes, update docs (/ai-factory.docs)
- [ ] No, skip docs
4. Any specific requirements or constraints?
Default to verbose logging. AI-generated code benefits greatly from extensive logging because:
- Subtle bugs are common and hard to trace without logs
- Users can always remove logs later
- Missing logs during development wastes debugging time
Logging must always be configurable:
- Use LOG_LEVEL environment variable
- Implement log rotation for file-based logs
- Ensure production can run with minimal logs without code changes
Pass the logging and documentation preferences to /ai-factory.task along with testing preference.
More from lee-to/ai-factory
aif-skill-generator
Generate professional Agent Skills for AI agents. Creates complete skill packages with SKILL.md, references, scripts, and templates. Use when creating new skills, generating custom slash commands, or building reusable AI capabilities. Validates against Agent Skills specification.
39aif-implement
Execute implementation tasks from the current plan. Works through tasks sequentially, marks completion, and preserves progress for continuation across sessions. Use when user says "implement", "start coding", "execute plan", or "continue implementation".
38aif-security-checklist
Security audit checklist based on OWASP Top 10 and best practices. Covers authentication, injection, XSS, CSRF, secrets management, and more. Use when reviewing security, before deploy, asking "is this secure", "security check", "vulnerability".
36aif-plan
Plan implementation for a feature or task. Two modes — fast (single quick plan) or full (richer plan with optional git branch/worktree flow). Use when user says "plan", "new feature", "start feature", "create tasks".
35aif-improve
Refine and enhance an existing implementation plan with a second iteration. Re-analyzes the codebase, checks for gaps, missing tasks, wrong dependencies, and improves the plan quality. Use after /aif-plan to polish the plan before implementation, or to improve an existing /aif-fix plan.
34aif-commit
Create conventional commit messages by analyzing staged changes. Generates semantic commit messages following the Conventional Commits specification. Use when user says "commit", "save changes", or "create commit".
34