Body
Summary
The EFDC Repo Template is a public GitHub template repository maintained by the Eisenberg Family Depression Center that makes it easier for researchers to start sharing their code on GitHub. It removes the setup work that usually stands between a working script and a published repository: the README structure, U-M copyright and license notices, license and notice files, citation and archival metadata, and sample source files with standard headers in fourteen languages are already written and correctly placed. It also includes a University of Michigan stylesheet and a unified AGENTS.md instruction file that directs AI coding agents to produce secure, accessible, and well-documented code.
A researcher can create a new repository from the template in a few minutes, fill in the project-specific details, and end up with code that is documented, properly licensed, and ready to be cited.
Template repository: https://github.com/DepressionCenter/EFDC-Repo-Template
Details
What it is
The EFDC Repo Template is a GitHub "template repository," which is a repository GitHub allows you to copy in a single click through the Use this template button. Unlike a fork, a repository generated from a template starts with a clean commit history and no upstream link, so it becomes your project immediately.
The template contains no application logic. Everything in it is scaffolding: the documentation, legal notices, metadata, and coding-standard files that every University of Michigan research software project needs but that are easy to omit, get wrong, or copy incorrectly from an older project.
The current contents of the template are:
README.md — standard README with all required sections in the recommended orderLICENSE — the full text of the GNU General Public License v3.0NOTICE — copyright notice, software license notice, and documentation license noticeAGENTS.md — the single, authoritative instruction file for AI coding agentsCLAUDE.md, CODEX.md, GEMINI.md, KIMI.md, CONVENTIONS.md, and .github/copilot-instructions.md — short redirect stubs that point every major AI coding tool back to AGENTS.mdCITATION.cff — Citation File Format metadata so GitHub renders a Cite this repository button.zenodo.json — Zenodo deposition metadata for DOI generation and archival.gitignore — files to ignore on commit, with sensible defaults for R, Python, editors, logs, operating-system cruft, and AI tool configuration filessrc/ — sample code files with correct, language-appropriate standard headersstyles/um-style.css — a reusable University of Michigan branding stylesheet intended for web developmentimages/ — placeholder preview images referenced by the README and the EFDC Open Source Hub
Why researchers should use it
Publishing code makes research more reproducible, more visible, and more reusable. It lets reviewers verify an analysis, lets collaborators build on the work instead of rewriting it, and turns a set of scripts into a durable, citable research product. This template exists to make publishing research software as easy as possible: the README structure, license text, copyright notices, and citation metadata are already written and correctly placed, so publishing becomes a matter of filling in project-specific details.
The template also protects the researcher's time after publication. A repository that explains its own setup, inputs, and outputs answers most questions before they are asked, and a documented maintainer contact routes the rest to the right place rather than to the original author's inbox years later. Publishing under the EFDC GitHub organization means support questions reach a group address instead of an individual.
Finally, the template ensures researchers get credit for their work. Citation and archival metadata are included so the repository can be assigned a DOI and cited like any other scholarly output, with authors and ORCID identifiers recorded properly.
Concrete benefits:
- No license or copyright guesswork. The U-M copyright line, the GPL v3.0 software license notice, and the GNU FDL v1.3 documentation license notice are already written and correctly placed in the README, in the
NOTICE file, and in every sample source file header.
- Faster project setup. A new repository that would otherwise take a half day of documentation and licensing work is usable in minutes. The only required edits are replacing bracketed placeholders such as
< PROJECT NAME > and 2026-01-01.
- Citability and credit.
CITATION.cff and .zenodo.json make the repository citable and DOI-ready, so your software counts as a scholarly output rather than an untracked byproduct of a study.
- Reproducibility. The mandated README sections (quick start, requirements and configuration, inputs and outputs, detailed setup and usage) are precisely the sections a reader needs to reproduce an analysis.
- Protection against accidental data disclosure. The
.gitignore and the AGENTS.md rules on secrets and Protected Health Information (PHI) reduce the risk of committing credentials, participant identifiers, or raw data to a public repository.
- Consistency across a core, lab, or center. Every project looks the same, so staff moving between projects already know where to find setup instructions, contacts, and license terms.
- Higher-quality AI-assisted code.
AGENTS.md converts institutional expectations regarding security, privacy, accessibility, and documentation into instructions that AI coding agents actually follow.
How to use it
- Create the repository. Open https://github.com/DepressionCenter/EFDC-Repo-Template, select Use this template, then Create a new repository.
- Choose the owning organization (for EFDC work,
DepressionCenter), give the repository a name, and set visibility.
- Alternatively, use the GitHub CLI:
gh repo create <owner>/<repo-name> --template DepressionCenter/EFDC-Repo-Template --public.
- Check the name before you commit to it. Search the web and package registries for the proposed name to rule out trademark conflicts and collisions with existing software or research groups. Renaming a published repository breaks links, citations, and DOIs.
- Fill in the README. Replace every placeholder delimited by angle brackets, including
< Repository Title >, < Program/Library name >, the About the Team paragraph, the maintainer group email address, and the Credits entries. Remove sections that genuinely do not apply rather than leaving them empty. Keep the License, Copyright Notice, and Citation sections intact.
- Update the metadata files. In
CITATION.cff and .zenodo.json, replace [repository_name], author names, and ORCID identifiers with real values, and confirm the copyright year. Leave the DOI as a placeholder until one has actually been minted; do not invent a DOI.
- Add your code and apply the standard headers. Copy the sample file from
src/ that matches your language, or copy its header block into your existing files. Delete the sample files you do not need. Do not delete LICENSE or NOTICE.
- Review the
.gitignore before the first commit. Add patterns for your data files, credential files, and environment files. Confirm that no secrets or participant data are staged.
- Point your AI coding tools at
AGENTS.md(optional). Most current agents read AGENTS.md automatically. The redirect stubs handle the tools that look for their own filename instead. Note that the stub files and common agent directories are listed in .gitignore, so the template's intent is that AGENTS.md is the only instruction file tracked in a downstream project.
- Publish and archive (optional). Once the code in your repository is public and stable, connect it to Zenodo to generate a DOI on every release. Once you create the first release, Zenodo will automatically create an archive with a new DOI#. Tecord the DOI in the README Citation section and in the metadata files.
Features
Standard README structure
The README enforces a fixed section order: Description, Quick Start Guide, Documentation, Additional Resources, About the Team, Contact, Credits (authors, contributors, and upstream work this project is based on), License (copyright notice, software and library license notice, documentation license notice), and Citation with an example citation and optional release history. The README itself opens with an HTML comment header carrying the same authorship and license block used in source files, and it links to the EFDC knowledge base at https://michmed.org/efdc-kb as the default location for full documentation.
Correct license files and notices
The template ships the complete GPL v3.0 text in LICENSE and a NOTICE file containing three distinct notices: the copyright notice naming The Regents of the University of Michigan, the software and library license notice (GPL v3.0 or later), and the documentation license notice (GNU Free Documentation License v1.3 or later). Separating the software and documentation licenses matters because the license appropriate for code is not appropriate for documentation, data dictionaries, or figures.
Sample code files with standard headers
The src/ directory contains header-bearing sample files for CSS, generic text, HTML, JavaScript, JSON, Lua, Markdown, PHP, PowerShell, Python, R, R Markdown, SQL, and Stata. Each uses the comment syntax native to that language while carrying the same header fields:
This file is part of < PROJECT NAME >
< CLASS, MODULE OR FILE NAME >
Author(s): First Last; First Last.
Created: 2026-01-01
Last Modified: 2026-01-01
Summary: < SUMMARY OF WHAT THIS FILE OR MODULE DOES >
Notes: See README file for documentation and full license information.
Copyright © 2026 The Regents of the University of Michigan
< license notice >
This provides provenance and license terms in every file, which matters because individual scripts are frequently emailed, pasted into tickets, or copied into other projects without the surrounding repository.
AGENTS.md for AI-assisted development
AGENTS.md is the most substantial file in the template. It is a seventeen-section standard that instructs any AI coding agent working in the repository. Its major provisions include:
- Engineering style. Readable before clever, modular without unnecessary abstraction, configurable instead of hard-coded, explicit about data types, units, formats, and time zones, with UTC for stored and exchanged timestamps.
- Factual integrity. Agents must not invent requirements, APIs, or schemas, and must not claim that code was executed, compiled, or tested unless it actually was.
- File headers and comments. The header format above is mandatory. Comments must explain intent, constraints, and data meaning rather than restating syntax, must avoid line-number references, must use
TODO: markers for deferred work, and must never reference material outside the repository such as ignored files or internal plans.
- Security. Input validation with allowlists, parameterized SQL, no credentials or participant data in logs or errors, fail-closed authorization, and OWASP ASVS 5.0 as the verification reference for secure web applications. If a requested approach creates a material security risk, the agent must explain the risk and offer a safer implementation rather than implementing it silently.
- Research and health-data safeguards. Assume data may contain PHI unless established otherwise. Preserve source data and transform copies, keep identifiers out of logs, filenames, URLs, and screenshots, use de-identified synthetic examples in documentation and tests, validate joins against accidental row multiplication, and flag decisions that require IRB, privacy, or Information Assurance review. Compliance may not be claimed on the basis of code review alone.
- Accessibility. WCAG 2.1 AA or 2.2 AA is the target for web interfaces: semantic HTML, complete keyboard operation with no traps, meaningful alternative text, associated form labels, no reliance on color alone, and contrast compliance.
- Error handling, testing, and documentation. Failures must be visible and actionable, stack traces must not reach end users, success messages must not precede verified success, and claims that tests pass require execution evidence.
- A required response format. Implementation responses are structured as Result, Files Changed, Implementation, Security Review, Accessibility Review, Verification, Documentation, and Assumptions, with sections omitted when they have nothing to report.
- Definition of done and priority order. Work is complete only when the problem is solved securely and accessibly, secrets and PHI are separated, documentation matches implementation, and U-M licensing and attribution are preserved. When goals conflict, the order is safety and privacy, correctness, accessibility, maintainability, reproducibility, performance, and convenience, and the first four may not be traded away silently.
Single instruction file, many agents
Rather than maintaining divergent instructions for each vendor, the template places all rules in AGENTS.md and ships one-paragraph redirect stubs for Claude, Codex, Gemini, Kimi, Aider (CONVENTIONS.md), and GitHub Copilot. Each stub instructs the agent to read AGENTS.md instead. This prevents configuration drift, in which one tool follows outdated standards because its instruction file was never updated.
Citation and archival metadata
CITATION.cff uses Citation File Format 1.2.0 and includes type, title, DOI, repository URL, SPDX license identifier (gpl-3.0-or-later), and author entries with ORCID identifiers and affiliations. GitHub reads this file and renders a Cite this repository control on the repository page. .zenodo.json supplies matching deposition metadata, including creators with ORCID identifiers, the University of Michigan ROR identifier, publisher, resource type, rights, access status, and the depressioncenter Zenodo community, so that releases are archived and issued a DOI with correct attribution.
Sensible .gitignore defaults
The .gitignore excludes RStudio project files and R session state, Python caches and virtual environments, editor directories, log files, operating-system artifacts, and AI coding tool configuration directories, while explicitly preserving AGENTS.md. It also includes a commented pattern block showing how to ignore all data files while allowing a single tracked sample file, which is the pattern research repositories usually need.
University of Michigan stylesheet
styles/um-style.css is a reusable stylesheet derived from the EFDC knowledge base styles, providing consistent University of Michigan color, typography, and component styling for project web pages, GitHub Pages sites, and dashboards.
Notes
This template was developed based on best practices for GitHub repositories and AI assisted development, as well as guidance from the Michigan Open Source Software (MOSS) office, the Automators Anonymous community of practice, and members of the Mobile Technologies Research Innovation Collaborative (MeTRIC).
Resources
About the Author
 |
Gabriel Mongefranco is a Mobile Data Architect at the University of Michigan's Eisenberg Family Depression Center. Gabriel has over a decade of experience with automation, data analytics, database architecture, dashboard design, software development, and technical writing. He supports U-M researchers with data cleaning, data pipelines, automation and enterprise architecture for wearables and other mobile technologies.
| | |
|