Thank you for your interest in contributing to our Memberstack Agent Skills! We welcome contributions of all kinds, whether it's fixing inaccuracies in Memberstack API references, improving existing skills, adding new reference documentation, or proposing entirely new Memberstack-related skills.
By contributing, you agree to abide by our Code of Conduct to ensure a welcoming and respectful community for all.
- Ways to Contribute
- Getting Started
- Skill Structure
- Reference File Conventions
- Development Workflow
- Pull Request Process
- Need Help?
- Fix inaccuracies: Spot an outdated Memberstack API method or incorrect example? Submit a fix
- Improve references: Make existing Memberstack documentation clearer, more complete, or better structured
- Add references: Contribute new reference files for Memberstack APIs or topics not yet covered
- Propose new skills: Have an idea for a new Memberstack Agent Skill? Open an issue to discuss it
- Report issues: Found something broken or misleading? Let us know
- Node.js 20+
- Familiarity with Markdown and YAML frontmatter
- Understanding of Memberstack's ecosystem (Admin API, CLI, etc.)
-
Fork the repository on GitHub
-
Clone your fork locally:
git clone https://github.com/your-username/memberstack-skills.git cd memberstack-skills -
Review the repo structure:
skills/<skill-name>/ ├── SKILL.md # Entry point with frontmatter + overview + reference index ├── references/ # Detailed reference docs ├── scripts/ # Helper scripts for the skill ├── assets/ # Static assets (CSS, images, etc.) └── .claude-plugin/plugin.json # Plugin metadata (auto-synced from SKILL.md frontmatter)
Each skill lives in skills/<skill-name>/ and is anchored by a SKILL.md file with YAML frontmatter:
---
name: skill-name
description: One-line description used for discovery and matching.
license: MIT
metadata:
author: "Author Name"
version: "1.0.0"
---The SKILL.md should include a quick start workflow, core patterns, and a reference index linking to all files in references/.
To scaffold a new skill:
node scripts/add-skill.js <skill-name> "<description>"Every file in references/ must have YAML frontmatter with three fields:
---
name: "Human-Readable Title"
description: "One-line summary of the file's contents."
tags: [tag1, tag2, tag3]
---- Plain Markdown only — no JSX components (
<Tabs>,<Steps>,<Note>,<Frame>, etc.) - Use fenced code blocks with language identifiers (e.g.,
```typescript) - Use Markdown tables for structured data
- Use blockquotes (
>) for callouts and notes - Include a Table of Contents with a horizontal rule separator after it
- End each reference with a Best Practices section where applicable
- Keep references focused on one API domain or topic per file
Source documentation often uses JSX/HTML components. Convert these to plain Markdown:
| Source component | Convert to |
|---|---|
<Tabs> / <Tab> |
Separate sections with ### headings |
<Note> / <Warning> |
Blockquote (>) |
<Steps> / <Step> |
Numbered list with ### sub-headings |
<Accordion> |
Standard Markdown table or section |
<Frame> / <img> |
Remove (image URLs won't resolve in this context) |
<Button> / <a> |
Inline Markdown link |
-
Create a new branch for your changes:
git checkout -b feat/your-change-description
-
Make your changes following the conventions above
-
If you added or removed reference files, update the corresponding
SKILL.mdreference index -
If you changed
SKILL.mdfrontmatter, run:node scripts/sync-skills.js
-
Commit your changes and push to your fork
- Reference files have valid YAML frontmatter (
name,description,tags) SKILL.mdreference index is up to date with any added/removed files- Code examples are accurate and use correct Memberstack API methods
- Content follows the Markdown-only convention (no JSX/HTML components from source docs)
- Clear title: Describe what changed (e.g., "Update admin-api.md to match latest Memberstack API docs")
- Description: Explain what changed and why
- Link issues: Reference any related issues (e.g., "Fixes #123")
Use common sense when drafting your pull request. The goal is to make it easy for maintainers to review and merge your changes. Include sufficient details but avoid unnecessary information.
- GitHub Issues: For bug reports, inaccuracies, and feature requests
- GitHub Discussions: For questions and community support
Thank you for contributing!