I usually start investigation with analyze, asking the agent to inspect the existing implementation, trace relevant behavior, and separate evidence from assumptions.

Business and domain perspectives help question user needs and operational constraints. A role focuses the analysis; its findings still need support from requirements and observed behavior.

For planning, I start with a native Codex plan task. If the decisions need more scrutiny, I use ralplan for consensus planning. I occasionally use deep-interview for clarification; otherwise, I generate and iterate on the brief directly.

Output: understood requirements, constraints, explicit decisions, and acceptance criteria that guide implementation and review.

For small tasks, I use native Codex implement / execute: give a focused prompt, get an early result, test and review it, then correct or extend it.

For larger work, I specify stages upfront and use ultragoal to organise implementation around goals and verification checkpoints. When the task allows independent work in parallel, I sometimes use the team skill instead to coordinate parallel agents.

When delegation helps, each subagent gets bounded ownership and an expected result. I integrate the contributions and check intermediate results before dependent stages continue.

Feedback should be concrete: identify the incorrect behavior or assumption, clarify the requirement, and repeat the affected checks. I prefer a reviewable next step over accumulating a large unexamined change.

I use focused code-review prompts through four lenses:

• Requirements: does this satisfy the intended behavior?
• Correctness: what bugs or regressions remain?
• Test coverage: Do tests cover the changed behaviour and likely regressions?
• Simplicity: would refactoring help? Recheck behavior after changes.

I use ultraqa when relevant, and project-specific tools such as BugBot where appropriate. Findings feed into corrections and PR signoff.

I scale CI effort: small checks on routine pushes and PR updates, broader local/manual checks, and the full workflow at main integration. Exact triggers depend on the project; post-merge checks are distinct from pre-merge gates.

Depending on the project, I package recurring workflows as project-specific skills, then schedule daily runs—for example, documentation maintenance as code evolves.

The skill defines the procedure; the schedule defines when it runs.

The aim is less repeated setup and routine work, with changes and findings available for review. I remain responsible for deciding whether the result meets its acceptance criteria.

Next on my list are narrow, fully autonomous R&D agents for recurring research and experimentation workflows. This is planned work, not an existing part of my setup.