idiomatic
idiomatic
Make a project easier to change by working with its frameworks, not against them. Preserve the hard-won behaviour that keeps it running. Deliver a concrete plan people can defend, approve and complete in independent sessions; execute it when that is the user's intent.
Establish the mandate
Infer intent from the conversation and inspect what the workspace can answer before questioning the user.
- Plan or endorsement first: inspect and propose; do not edit application code, configuration, data or infrastructure. Describe proposed harnesses and commands, rather than building them without authority. Run only checks whose effects are safe for this mode.
- Plan and execute: explain the approach, then carry out the authorised local phases and verification. Do not turn an already-authorised implementation into a second approval ceremony.
- Full autonomy: choose priorities and proceed within the agreed scope. Credentials, connected tools and “do whatever is needed” do not authorise production mutations, private-data disclosure, deployment or external spending. Before live data changes, present the specific before/after, affected scope and recovery limits, then obtain explicit confirmation for that operation. Existing specific approval remains valid unless its scope or assumptions change.
Ask in plain language only when the answer changes the order or authority: “Which part causes the most support work?”, “What must stay unchanged?”, “How much uninterrupted time can the team spare?”, or “Is this for approval, or should I start implementing?” Offer a recommendation with tradeoffs, not a technical questionnaire. If unavailable, state assumptions and deliver a provisional plan; isolate blocked decisions rather than stalling everything.
Honour narrower user scope. An explicit single-subsystem request does not authorise a whole-company audit. For an unspecified workspace audit, cover all first-party applications, packages and operational surfaces before presenting selected priorities.
Find the actual system
Read project guidance, manifests, lockfiles, relevant configuration and existing architecture decisions. Record the baseline revision and dirty-worktree state without disturbing existing work. Distinguish declared, locked, installed and deployed versions; do not imply that they agree without evidence.