// Implementation methodology for executing tasks. Handles scoping, decomposition, worktree workflow, verification, and commit conventions. Triggers: "execute", "implement", "build this", "code this".
| name | execute |
| description | Implementation methodology for executing tasks. Handles scoping, decomposition, worktree workflow, verification, and commit conventions. Triggers: "execute", "implement", "build this", "code this". |
| schedule | When backlog items with linked plans are ready for implementation |
Implementation methodology. Loads alongside the domain skill (e.g., "noodle") — this teaches process, the domain skill teaches the codebase. Operate fully autonomously. Never ask the user. Don't stop until the work is fully complete.
Track all work with Tasks (TaskCreate, TaskUpdate, TaskList). One task per decomposed change; mark in_progress when starting, completed when done.
Establish what needs doing:
brain/plans/. Read the overview for scope boundaries. Invoke Skill(backlog) for project-specific context. Load domain skills listed in "Applicable skills."brain/todos.md. If a linked plan exists, read it. Otherwise, scope from the description.Output: a clear, bounded description of what changes and what doesn't.
Break scope into discrete changes. Each change:
Single-change scopes skip decomposition.
Never edit files on main. Multiple sessions run concurrently; editing main causes merge conflicts and lost work.
If CWD is already inside .worktrees/, use it. Otherwise: noodle worktree create <descriptive-name>
Use absolute paths or noodle worktree exec <name> <cmd>. Never cd into a worktree — if it gets removed while the shell is inside, the session dies permanently.
Commit inside the worktree. When done: noodle worktree merge <name>
Skip only when the user is interactively driving a single-agent session and explicitly chooses main.
references/team-execution.md.Sequential is fine when phases are tightly coupled. Before parallelizing, ask: "Does any phase's output become another phase's input?" Phases with shared type-level contracts must be sequential.
Run the full verification suite before committing. See references/verification.md for the complete checklist. Never commit failing code — fix and re-verify on failure.
<type>(<scope>): <description> with optional Refs: #<issue-ID> footer. Types: feat, fix, refactor, test, docs, chore. One commit per logical change.
After all changes are committed and verified, emit stage_yield:
noodle event emit --session $NOODLE_SESSION_ID stage_yield --payload '{"message": "Implemented: <brief summary>"}'
Without this, the stage only completes on clean process exit — interrupted work is lost to the pipeline.
Read at runtime from brain/principles/:
Design engineering principles for making interfaces feel polished. Use when building UI components, reviewing frontend code, implementing animations, hover states, shadows, borders, typography, micro-interactions, enter/exit animations, or any visual detail work. Triggers on UI polish, design details, "make it feel better", "feels off", stagger animations, border radius, optical alignment, font smoothing, tabular numbers, image outlines, box shadows.
Systematic planning for medium-to-large tasks. Gathers context, identifies domain skills, writes phased plans to brain/plans/. Does NOT implement. Use for new features, multi-file refactors, or architectural changes — not small fixes. Triggers: "plan this", "break this down".
Adversarial code review using cross-model approach. Spawns reviewers on the opposing model (Claude uses Codex, Codex uses Claude) to challenge work from distinct critical lenses. Produces a synthesized verdict with findings and lead judgment. Triggers: "adversarial review".
Structural code search via ast-grep — use when code shape and element relationships matter, not just text. E.g., "find async functions without error handling", "refactor foo(a, b) to foo({ a, b })". Use Grep for simple name lookups.
Read/write brain files (Obsidian vault at brain/). Use for any task that persists knowledge — reflection, planning, or direct edits. Triggers after debugging sessions, mistakes, corrections, architectural decisions, or any insight worth preserving across sessions. Use on 'add to brain', 'remember this', 'write a note', or brain/ modifications.
Run Codex CLI (exec, resume) for parallel work, delegating tasks to another model, or background code generation. Handles code analysis, refactoring, and automated editing. Includes Spark vs standard guidance. Triggers: "codex", "run codex", "use codex to".