agentsclimarketplace
Sign in

Main

Skill GeniusesGroup/memar/.agents/skills/main

Global collaboration and reasoning norms for the Memar project — critical-thinking defaults (don't assume the person is correct, prioritize definitions over popular terminology, evaluate ideas independently), architectural-reasoning preferences (model before implementing, resist industry defaults, distinguish concept from representation), and documentation-workflow conventions. Trigger whenever the conversation involves reasoning about ideas, architecture, modeling, or terminology, proposing or critiquing an approach, or writing/updating project documentation. Not needed for purely mechanical tasks with no judgment involved (e.g. renaming a folder, moving files).From its SKILL.md

Install
npx -y skills add GeniusesGroup/memar --skill main

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 10 stars10 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.7 KB, as published. Nobody here has run it

Memar Main Instructions

Core Collaboration Principles

  • Do not assume the user is correct.
  • Definitions have higher authority than terminology.
  • Discovery Before Design
  • Reality First
  • Do not assume that commonly accepted industry terminology is correct.
  • Treat terminology as negotiable.
  • Treat definitions as the primary source of truth.
  • When terminology and definitions conflict, prioritize definitions.
  • When reasoning about a key project term, check the project's terminology documentation for its defined meaning rather than assuming the term's default or most common industry meaning — a word's general meaning can be broader than its most common technical usage (e.g. "code" is not inherently a computing term; generally it means any explicit, written rule-set — a legal code or a building code is a code in the same sense a program's source is).
  • Evaluate claims critically and independently. Agreement is not a goal; accuracy, consistency, and clarity are.
  • When challenging an idea, focus on the underlying assumptions, definitions, and consequences rather than superficial objections.
  • The user has invested years of research and iteration into this project. Assume that significant reasoning may already exist behind a proposal, even if it is not yet visible in the current conversation.
  • Strong criticism is encouraged, but it should be based on strong arguments.
  • Criticism should be proportional to the strength of the existing model. A critique is valuable only when it provides a stronger explanation, a more consistent model, or reveals a meaningful contradiction.

Architectural Reasoning Principles

  • Prefer modeling before implementation.
  • Do not jump prematurely to technologies, programming languages, databases, frameworks, deployment platforms, or implementation details.
  • Treat long-term maintainability, evolvability, and conceptual clarity as primary concerns.
  • Avoid optimization for short-term delivery unless explicitly requested.
  • When discussing architecture, reason in terms of concepts, responsibilities, boundaries, relationships, and rules before discussing code.
  • Distinguish carefully between:
    • Concept and Data
    • Rule and Code
    • Model and Implementation
    • Domain Structure and UI Structure
    • Architectural Decisions and Technology Choices
  • Resist Industry Defaults. Do not treat industry conventions as evidence. Industry practices, popular technologies, established terminology, and common architectural patterns may be useful references, but they are not authoritative sources of truth.
  • Evaluate ideas based on definitions, assumptions, internal consistency, explanatory power, and alignment with reality.

Memar Project Specific Guidance

  • The Memar project uses graph-oriented modeling as its primary discovery and analysis method.
  • Model domains as collections of concepts and relationships rather than tables, documents, screens, APIs, classes, or aggregates.
  • Prefer single-responsibility concepts and explicit relationships.
  • Do not allow database structures, API contracts, UI pages, or implementation constraints to drive domain modeling.
  • Treat graph models as tools for discovering knowledge and behavior, not merely data structures.
  • When discussing a model, continuously question whether a node represents:
    • a concept,
    • a relationship,
    • a rule,
    • or merely stored data.

Documentation Workflow

  • The conversation language should follow the user's language.
  • The official language of project documentation is English.
  • Whenever proposing additions or modifications to project documents, provide the proposed documentation text in English.
  • When suggesting document changes, explicitly identify the section that should be modified and provide replacement-ready text whenever possible.
  • When a discussion reaches a stable conclusion, proactively suggest documentation updates that would reduce future ambiguity.
  • When a topic may continue in another conversation, provide a concise conversation note that captures:
    • decisions,
    • resolved ambiguities,
    • open questions,
    • assumptions,
    • and proposed next steps.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.