About amose
Amọ̀ṣẹ́ is a skill for maintaining a project's domain meaning and shared language across planning, specifications, architecture, implementation, and review. It clarifies terms, boundaries, and conflicts using domain sources and current behavior, and maintains existing domain records.
Key features
- 01Clarify terms and conceptual identity
- 02Distinguish bounded contexts
- 03Resolve semantic conflicts using evidence
- 04Maintain existing domain-language records
- 05Supply clarified meaning to other workflows
Use cases
- 01Resolve overlapping or conflicting terminology
- 02Define concepts across bounded contexts
- 03Compare domain rules with current behavior
- 04Update established project domain records
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ quantipixels/ skills --skill amoseAfter installing, type/amosein Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
agents/openai.yamlreferences/adrs.mdcontext.mdlearnings.mdnongoals.mdDetails
From the project READMEAmọ̀ṣẹ́
Own the project's domain meaning and ubiquitous language across planning, specifications, architecture, implementation and review. Preserve bounded-context distinctions; shared wording must not conceal different models.
Check material rules' applicability even when their words are familiar. Reuse current settled meaning; do not treat stale records as immutable intent or invent business rules to reconcile a conflict.
Clarify the model
Read only evidence capable of settling material meaning: the current domain-language source, governing decisions/policies, relevant code/tests/configuration/runtime behavior, and bounded history when it can resolve a conflict. Implementation and operations prove current behavior, not automatic domain intent.
When an ambiguous, overloaded, synonymous, or conflicting term can change scope, ownership, identity, state, policy, or behavior:
- state the ambiguity or contradiction;
- use the smallest concrete scenario that distinguishes the competing concepts;
- compare it with current domain language and relevant evidence; and
- propose canonical wording only when evidence or domain authority supports it.
When the user deliberately establishes or changes clear domain meaning, test only the boundaries needed to make the model coherent. Do not manufacture ambiguity to justify an interview.
A useful model clarification may establish or separate:
- canonical terms and avoided synonyms;
- conceptual identity and lifecycle distinctions;
- bounded contexts and cross-context meaning;
- relationships and ownership; and
- semantic invariants or contradictions between stated meaning and current behavior.
Use yoruba-glossary for Yorùbá/English technical terminology and glossary maintenance; Amọ̀ṣẹ́ retains project-specific domain meaning.
Ask a single already-understood bounded consequential choice directly. Use arojinle when purpose, success, consequential trade-offs or latent dependent choices remain unsettled, or an interview is requested. Use architect for unresolved structure or consequential technical fitness. Do not turn current implementation shape into domain vocabulary merely because it exists.
Reconcile canonical language
When a domain-language source already exists, read domain language and update that source when the resolved model changed and write authority exists. Do not create a competing project-memory system or generic documentation store.
If no durable domain-language destination is established, return the model delta directly and name the persistence gap only when the result needs to outlive the current work. Let the project or caller choose an intentional project destination rather than inventing CONTEXT.md, .learnings, .nongoals, an ADR, .qp record, or another repository convention.
This domain-clarification boundary does not prevent an authorized ADR-creation request from using the ADR fallback when no project convention exists. Domain clarification alone does not authorize creating an ADR.
A domain-model change may cause another workflow to update specifications, architecture, documentation, tests, or policy. Those artifacts remain owned by their natural workflow. Amọ̀ṣẹ́ maintains the project's canonical domain records and supplies clarified meaning to the other owners.
Maintain durable domain records
Maintain the project's existing domain records when the request concerns their content or lifecycle:
.learnings→ read learnings;.nongoals→ read non-goals; or- ADR qualification or lifecycle → read ADRs.
Use the record's existing project destination. Preserve its format and authority boundary. A record change must reflect established domain meaning or an authorized project decision; do not turn task notes, temporary deferrals, or implementation history into durable domain records.
Return
Return the resolved terms, identities, relationships, ownership, invariants, distinguishing examples when needed, and any remaining semantic conflict or consequential decision with its evidence.
Return newly exposed desire, fact or technical gaps to the same caller with their controlling evidence. The caller integrates the result and reopens only affected work; a domain clarification does not start another initiative.
When canonical domain language or a durable domain record was updated, report the destination and verification.