indiosmo Naming software
Produce a recommendation or retained name in context, its rationale, and a distinct verification result. Use the human guide for the reasoning. Load the selected route and relevant artifact sections below; keep the work proportionate to the actual uncertainty and change boundary.
Establish the starting point
Read applicable project instructions and the supplied description or code first. Identify the artifact, its concept and behavior, reader context, domain words, relevant contracts, existing authorization, and material unknowns. Follow read-first discovery.
During code authoring, inspect neighboring declarations and representative uses before introducing names. For direct assistance, use the supplied code or description to choose a route. A description supports a provisional recommendation with explicit implementation and caller checks still needed.
| Starting task | Read first | Continue when |
|---|---|---|
| Clarify an uncertain or abstract concept | Sparse input, intent and observation, then scenario questions | The material distinction is settled; continue to selection. Keep unanswered intent visible and make conditional progress. |
| Generate or choose names for a settled concept | Meaning-preserving generation, then hard constraints | A viable choice or comparison is ready; perform contextual validation. |
| Validate a proposed or existing name | Review scope, then contexts that establish meaning | Evidence supports retaining, rejecting, or revisiting the name; report the finding and recheck any revision. |
| Apply an authorized rename | Change boundary, then bindings and representations | The mapping and compatibility policy are established; edit and verify within the authorized scope. |
Resolve meaning and vocabulary
For sparse input, follow competing concepts to expose the distinction that needs evidence. Ask the next scenario question that changes the represented concept. Use conditional candidates when an answer remains unavailable; keep their assumptions and status explicit.
When neighboring concepts or responsibilities are unclear, read definitions and distinctions. Establish the actual truth conditions, state, quantity, cardinality, effects, and completion boundary relevant to the artifact.
For unfamiliar domain language, read vocabulary evidence and boundary distinctions. Consult the project glossary and an authoritative source governing the concept. Resolve observable facts from available evidence; ask a focused scenario question when intent or core meaning remains material. Record unavailable sources and their affected uncertainty while continuing supported work.
Use full words with established domain abbreviations in appropriate local scope, following abbreviation guidance. If naming exposes a possible redesign, keep that proposal distinct from the established behavior and authorized edit. Follow design questions.
Capture a naming brief when several facts or unknowns need tracking. A small task can retain the same core evidence in concise prose.
Select artifact and ecosystem guidance
Read the rows relevant to the target; their sections own the detailed criteria.
| Target | Selected explanation |
|---|---|
| Variable, parameter, or field | Available context; for a group, related variables across component and parent; select cardinality, units and time, or boolean polarity as needed |
| Function or method | Operation contract, complete calls, and relevant completion boundaries |
| Type, role, error, command, or event | Entity, value, and role, errors, or message lifecycle |
| Module, package, namespace, or file | Capability boundary, complete import, and collisions |
| API, schema, database, or configuration name | Operation paradigm, serialized meaning, database questions, or configuration scope/default |
| Persistent identifier, label, or alias | Identity and resolution |
Read project convention discovery, then only the applicable section: C++, Python, Rust, Swift, or JavaScript/TypeScript. For another ecosystem, follow additional-language review. Keep concept fidelity and ecosystem spelling as separate decisions.
Choose and review the name
Read comparison criteria when several viable options have meaningful tradeoffs. Define criteria and disqualifying constraints, show equivalent use sites, score against the actual evidence, and present the matrix with a reasoned recommendation. Use the comparison template when a record helps. For a portable HTML artifact, follow matrix preparation, which selects the sibling decision-matrix instructions and actual assets.
When one choice clearly fits, follow the clear-winner path. State the decisive evidence directly. An adequate existing name can be retained.
After selection, perform a distinct contextual review. Inspect the declaration, implementation, representative callers, related names, glossary, prose, examples, tests, and applicable public representations. Assess the selected name against that evidence independently of the initial preference.
If context rejects the wording, return to selection; if it exposes unsettled meaning, return to elicitation. Follow retain, reject, or revisit, then recheck the changed choice and affected findings. The validation report records inspected evidence, findings, corrections, and remaining uncertainty.
Apply and verify the authorized change
Carry existing task and session authorization into the established rename scope. A request to apply a scoped rename authorizes its reversible edits and checks. Use the rename plan when the mapping or compatibility boundary needs a record. Read predicate and effect preservation and compatibility choices for the affected contracts.
Map declaration identities, bound references, imports, keyword calls, dynamic uses, documentation, tests, and external representations as applicable. Prefer language-aware edits where available, supplemented by scoped searches. Preserve unrelated same-spelling symbols and the selected behavior/wire policy. If the inventory exposes a material additional contract decision, prepare that concrete choice and continue independent authorized work.
Follow edited-result verification: inspect the diff, recheck affected uses, and execute appropriate behavior and compatibility checks. Use independent contract evidence when edited tests could repeat the same mistake. Record actual commands, scope, outcomes, and recovery under evidence and recovery.
Deliver the result
Give the selected or retained name in a representative expression, the decisive rationale and relevant tradeoff, and a separate verification outcome. Distinguish description-level assessment, static source review, executed checks, and remaining uncertainty using precise evidence reporting. For applied edits, include the actual mapping and behavior/compatibility results. A decision record can link substantial supporting artifacts; small tasks can use a concise answer with equivalent evidence.
For a worked application, select the matching example. For a research-dependent claim, consult the study synthesis, evidence register, and inspected sources. Package maintainers use maintenance, tests, and evaluation for changes to this skill and its acceptance evidence.