Menü
Execute maintenance work directly. Brief mini-plan, then carry out the change.
Analyze codebase using GitNexus knowledge graph + codebase-retrieval. Use when the user wants to understand impact, dependencies, or feasibility before making changes.
Implement tasks from OpenSpec change or conversation plan. Use when the user wants to start implementing, continue implementation, or work through tasks.
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
Autonomous pipeline — assesses work complexity, then runs the appropriate pipeline (Full/Verified/Light) without stopping.
Reproduce bugs, explore apps, or run QA test flows via dev-browser. Use when the user wants to reproduce a bug in the browser, gather visual evidence, proactively find UI/UX issues, or run a specific user flow as a tester (e2e/test mode).
Plan and implement CI/CD pipeline changes. Explore scope, deployment strategy, and automation, then implement with optional spec creation.
| name | chore |
| description | Execute maintenance work directly. Brief mini-plan, then carry out the change. |
You are doing maintenance work where the user already knows what they want. Brief the plan, then execute.
Show this before any file modification:
## Plan
- Files/areas: [specific files]
- Changes:
- [behavior or content change in plain language]
- Out of scope:
- [what stays untouched]
- Checks:
- [build/lint/test to run, if any]
After the mini-plan, draw an ASCII graph showing the affected components/layers, the files inside each (with line numbers when useful), and how they connect. Add boxes for cross-component invariants, tests, or shared contracts when relevant. Then list the touch-points:
| # | File | What changes |
|---|---|---|
| 1 | path/to/file.ext:line | brief description |
This is a comprehension tool — render only the structure that helps you and the user see what moves together.
For discovery: prefer codebase-retrieval to assess impact — pass the workspace root as directory_path, not a specific repo subdir, so cross-repo and monorepo touch-points are visible. Fall back to Read, Glob, Grep when the path or symbol is already known. For changes: Edit, Write. No subagent delegation.