enhancements

README.md

@@ -1,6 +1,7 @@
 # A Copier Template to augment github repos with AI capabilities
 
-This template uses the code-scaffolding tool [copier](https://copier.readthedocs.io/) to automatically set up AI-powered GitHub Actions in any existing repository.
+This template uses the code-scaffolding tool [copier](https://copier.readthedocs.io/) to apply AI integrations to an existing project.
+See [Applying multiple templates to the same subproject](https://copier.readthedocs.io/en/stable/configuring/#applying-multiple-templates-to-the-same-subproject)
 
 ## What it does
 
@@ -17,10 +18,35 @@ For more background, please see:
 
 ## Usage
 
-In an existing repo, run this:
-
 `copier copy https://github.com/ai4curation/github-ai-integrations .`
 
+Previous answers will be saved (TODO: figure out why copier won't save answers to new Qs)
+
+Note that assumptions are made that you are following Mungall group/Monarch best practice, e.g. use of `uv` over `poetry`.
+
+This works best if you are overlaying on top of a project seeded with one of the following:
+
+- <https://github.com/linkml/linkml-project-copier>
+- <https://github.com/monarch-initiative/monarch-project-copier/>
+
+Your previous answers to `copier` should be the default.
+
+There are 3 flavors, which can be combined. You will be asked for yes/no for the following
+
+- linkml schema repos
+- python repos (default is true)
+- ontology repos
+
+Answer yes to the first if a focal point of your repo is a linkml schema. This will include
+instructions for the AI on how to edit the yaml, rebuild, run examples, etc. This assumes
+a modern justfile-based setup rather than the older makefile based approach.
+
+Answer yes to the second if your repo contains python files which the AI should edit. Do not say
+yes if the repo contains only derived python from linkml files. Saying yes here will include
+best practice for python code.
+
+Answer yes to the third if your schema contains ontologies using the standard ODK layout.
+
 ## Setting up GitHub secrets
 
 Set up the following env vars:

copier.yaml

@@ -14,11 +14,47 @@ project_name:
   help: What is your github project name?
   default: my-awesome-tool
 
+project_slug:
+  type: str
+  help: A slug of the name. Must be a valid and unused Python package name.
+  default: >-
+    {% from pathjoin('includes', 'slugify.jinja') import slugify -%}
+    {{ slugify(project_name) }}
+  # regex_search is part of a jinja extension loaded by default.
+  # It is case insensitive by default. We need to set ignorecase=False to make
+  # it case sensitive.
+  validator: >-
+    {% if not (project_slug | regex_search('^[a-z][_a-z0-9\-]+$',
+       ignorecase=False)) %}
+    project_slug must start with a lowercase letter, followed by lowercase
+    letters, digits, dashes or underscores.
+    {% endif %}
+
 github_handle:
   help: github username of the author. Will be assigned as a-controller
   type: str
   default: "cmungall"
 
+project_description:
+  help: A short description of the project
+  type: str
+  default: This is the project description.  
+
+is_linkml_schema:
+  help: Is this repo primarily for managing a linkml schema?
+  type: bool
+  default: false
+
+is_python_project:
+  help: Is this a python repo?
+  type: bool
+  default: true
+
+is_ontology_project:
+  help: Doe this repo contain the source/edit files for one or more ontologies?
+  type: bool
+  default: false
+
 # === copier configuration options ===
 # https://copier.readthedocs.io/en/stable/configuring/#available-settings
 
@@ -42,8 +78,17 @@ _message_after_copy: |
 
   ** PROJECT CREATION COMPLETE **
 
-  Next step (if you have not previously initialized your project)
-  run "just setup" in the root of your project directory.
+  Next steps:
+
+  1. Adjust your CLAUDE.md
+
+  2. Perform additional claude configuration (e.g. `/agents/`)
+
+  3. if your project is already on GitHub, and your keys are set as env vars, then run:
+
+     `just setup-ai`
+
+
 
 _migrations:
   # Migrations are only run on update (not on copy) and only if the update goes

template/CLAUDE.md.jinja

@@ -1,5 +1,91 @@
 # CLAUDE.md for {{project_name}}
 
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+{{ project_description }}
+
+TODO: fill in extra description here
+
+## Repo management
+
+This repo uses `uv` for managing dependencies. Never use commands like `pip` to add or manage dependencies.
+`uv run` is the best way to run things, unless you are using `justfile` or `makefile` target
+
+`mkdocs` is used for documentation.
+
+{%- if is_linkml_schema -%}
+
+## This is a LinkML Schema repository
+
+Layout:
+
+ * `src/{{project_slug}}/schema/{{project_slug}}.yaml` - LinkML source schema (edit this)
+ * `project` - derived files (do not edit these directly, they are derived from the LinkML)
+ * `src/docs` - source markdown for documentation
+ * `docs` - derived docs - do not edit these directly
+ * `src/data/examples/{valid,invalid}` - example data files
+    * always include positive examples of each class in the `valid` subfolder
+    * include negative examples for unit tests and to help illustrate pitfalls
+    * format is `ClassName-{SOMENAME}.yaml`
+ * `examples` - derived examples. Do not edit these directly
+
+Building and testing:
+
+* `just --list` to see all commands
+* `just gen-project` to generate `project` files
+* `just test` to test schema and pos/neg examples
+* `just lint` analogous to ruff for python
+
+These are wrappers on top of existing linkml commands such as `gen-project`, `linkml-convert`, `linkml-run-examples`.
+You can run the underlying commands (with `uv run ...`) but in general justfile targets should be favored.
+
+Best practice:
+
+* For full documentation, see https://linkml.io/linkml/
+* Follow LinkML naming conventions (CamelCase for classes, snake_case for slots/attributes)
+* For schemas with polymorphism, consider using field `type` marked as a `type_designator: true`
+* Include meaningful descriptions of each element
+* map to standards where appropriate (e.g. dcterms)
+* Never guess OBO term IDs. Always use the OLS MCP to look for relevant ontology terms
+* be proactive in using due diligence to do deep research on the domain, and look at existing standards
+
+{%- endif -%}
+
+{%- if is_python_project -%}
+
+## This is a Python repository
+
+Layout:
+
+ * `src/{{project_slug}}/` - Code goes here
+ * `docs` - mkdocs docs
+ * `mkdocs.yml` - index of docs
+ * `tests/input` - example files
+
+Building and testing:
+
+* `just --list` to see all commands
+* `just test` performs unit tests, doctests, ruff/liniting
+* `just test-full` as above plus integration tests
+
+You can run the underlying commands (with `uv run ...`) but in general justfile targets should be favored.
+
+Best practice:
+
+* Use doctests liberally - these serve as both explanatory examples for humans and as unit tests
+* For longer examples, write pytest tests
+* always write pytest functional style rather than unittest OO style
+* use modern pytest idioms, including `@pytest.mark.parametrize` to test for combinations of inputs
+* NEVER write mock tests unless requested. I need to rely on tests to know if something breaks
+* For tests that have external dependencies, you can do `@pytest.mark.integration`
+* Do not "fix" issues by changing or weakening test conditions. Try harder, or ask questions if a test fails.
+* Avoid try/except blocks, these can mask bugs
+* Fail fast is a good principle
+* Follow the DRY principle
+* Avoid repeating chunks of code, but also avoid premature over-abstraction
+* Pydantic or LinkML is favored for data objects
+* For state in engine-style OO classes, dataclasses is favored
+* Declarative principles are favored
+* Always use type hints, always document methods and classes
+
+{%- endif -%}
+
 
-REMOVE THIS LINE AND FILL IN YOUR OWN DETAILS HERE