| instructions | You are in FULLY AUTONOMOUS MODE. Zero questions. Just build.
TASK:
$ARGUMENTS
MODE DETECTION:
- If $ARGUMENTS starts with "--fast" (e.g., "/iterate --fast add search bar"):
MAX_ITERATIONS = 4 (fast mode -- build it, harden it, analyze it, ship it)
Remove "--fast" from the task description before proceeding.
- Otherwise: MAX_ITERATIONS = 6 (thorough mode -- full iterative refinement)
RULES:
- Do NOT ask the user anything. Decide and move.
- If you're unsure between two approaches, pick the simpler one.
- If a dependency is missing, install it.
- If tests don't exist, write them.
- If something breaks, fix it -- don't report it, fix it.
=== PRE-BUILD: BRANCH STRATEGY ===
CHECK the project's CLAUDE.md and global CLAUDE.md for branch conventions.
DEFAULT for solo/personal projects: commit directly to main. Do NOT create
feature branches unless the project's CLAUDE.md explicitly requires them or
the user asks for a branch. Solo projects use CI on main as the quality gate.
For TEAM projects (multiple contributors): use feature branches.
- Branch naming: `feat/{short-description}` for features, `fix/{short-description}` for fixes.
- Push the branch early: `git push -u origin {branch}` after the first commit.
- Merge via PR after validation.
IMPORTANT: Before committing and pushing, run the project's full validation
suite (format, lint, test) locally. Only push code that passes CI. This saves
compute time on self-hosted runners.
=== PRE-BUILD: MIGRATION/FORK DETECTION ===
If the project was scaffolded from, forked from, or migrated from another
project (check git log for "migrate", "rename", "fork", or if early commits
reference a different app name):
1. Verify all references to the old project name are replaced (package names,
bundle IDs, import paths, string constants, test fixtures, CI config).
2. Verify models/services match the NEW domain, not the old one.
3. Run the full test suite — failures from stale references are cheaper to
fix now than after building features on a broken foundation.
4. Commit any fixes: "chore: clean up migration from [old project]"
Skipping this step causes downstream fix commits that tank First-Time-Right
rate (observed: 45.5% FTR when migration validation was skipped).
=== PRE-BUILD: VALIDATION GATE ===
Before writing any feature code, validate the project foundation.
This prevents wasting iterations on lint, platform, and config issues.
1. DETECT PROJECT TYPE:
Identify the tech stack from project files (package.json, pubspec.yaml,
Cargo.toml, go.mod, requirements.txt, pom.xml, Gemfile, etc.).
Adapt all subsequent checks to the detected stack.
2. STATIC ANALYSIS:
- Run the project's type checker (tsc --noEmit, flutter analyze, mypy, cargo check, etc.).
- Run the project's linter if configured (eslint, dart fix --apply, ruff, clippy, etc.).
- Fix all errors and warnings.
3. DEPENDENCY CHECK:
- Run the project's dependency installer (npm install, flutter pub get, pip install, cargo build, etc.).
- Fix version conflicts or missing packages.
4. PLATFORM/CONFIG CHECK:
- If the project has platform-specific code, verify guards are in place (e.g., web vs native,
OS-specific imports, conditional compilation).
- If the project has database rules/migrations, cross-check them against code usage.
- If the project has config files (env templates, schema files), verify they match code expectations.
5. DOCKER/INFRASTRUCTURE CHECK (if docker-compose.yml or Dockerfile exists):
- Verify image references use full registry paths where needed.
- Verify volume mounts: target paths exist in container, writable dirs have correct permissions.
- Verify config files are mounted where the application actually reads them.
- Run `bash -n` on all .sh scripts to catch syntax errors.
- Check for cross-platform portability issues (sed, readlink, date flags, etc.).
Fix everything found. Commit: "chore: pre-build validation fixes"
If clean, skip the commit and proceed.
=== PER-COMPONENT QUALITY CHECKLIST ===
Every component (screen, page, module, end… |
