Confirm scope and repository state.
- Read local instructions such as AGENTS.md and CLAUDE.md before editing.
- Inspect git status, branch, remotes, package scripts, tests, and relevant source structure.
- Ask only when ambiguity would cause risky or irreversible work.
- Preserve unrelated user changes.
Set a goal for substantial work.
- Use goal tracking when the task includes implementation plus verification or PR work.
- Write the objective in outcome terms: behavior to deliver, verification to run, PR to open, and merge-readiness follow-up.
Plan the implementation.
- State a concise plan once enough context is known.
- Choose the narrowest applicable mode: feature, bug fix, refactor, docs, frontend, backend, or CI repair.
- Keep the plan reviewable and update it when discoveries change the work.
Design UI work before coding when relevant.
- Use ui-imagegen-director for visual direction when UI quality or visual target matters.
- For HTML/CSS/client-side UI work, use current frontend guidance before implementation.
- Build the actual usable screen or flow, not a marketing placeholder, unless requested.
- Verify responsive layouts and important states in a real browser after significant UI edits.
Implement in focused steps.
- Prefer existing project patterns, APIs, and tests.
- Keep commits and code changes scoped to the request.
- Update docs when commands, configuration, APIs, workflows, or user-visible behavior changes.
Verify locally.
- Run targeted tests first, then broader lint/type/build/test commands when practical.
- For UI changes, run the app if needed and inspect the changed flow with browser screenshots or interaction checks.
- If a check cannot run, capture the exact blocker and any partial verification completed.
Review before PR.
- Inspect git diff for bugs, regressions, missing tests, data loss, security issues, and edge cases.
- Fix actionable issues found during self-review before committing.
- Confirm the final diff does not include unrelated files or generated noise.
Commit, push, and open a PR.
- Create a clear commit history appropriate to the repo.
- Push the branch to the expected remote.
- Open a regular ready-for-review pull request by default.
- Do not create a draft PR and do not pass --draft unless the user explicitly asks for a draft.
- Include summary, tests, screenshots when useful, and known risks.
Bring the PR toward merge-ready.
- Check required checks, CI runs, review requests, bot comments, and unresolved review threads.
- On CI failure, inspect logs, reproduce locally when possible, make the smallest fix, push, and re-check.
- Address actionable human, bot, and agent feedback. Explain feedback intentionally not applied.
- Do not merge unless the user explicitly asks and repo policy permits it.

Skill Composition

Use narrower skills when relevant: goal-manager, feature-implementation, bug-fix, refactor-safely, docs-updater, frontend-design, ui-imagegen-director, review, fix-ci, and pr-guardian.

Progress Updates

Keep the user informed after repository/context inspection, before edits, after local verification, after PR creation, and after CI or review follow-up.

Final Report

Include goal status when used, changed behavior and key files, local checks, PR URL/branch, CI/review status, fixes after PR creation, and remaining blockers or risks.

implement-to-merge-ready

Implement To Merge Ready

Workflow