Skip to main content

​
Welcome

Rifteo Community is a community-driven project. Contributions (new skills, bug fixes, documentation improvements) are all welcome. This page explains the process.

​
What you can contribute

TypeDescription
New skillA new audit check that doesn’t exist yet
Skill improvementFix a bug or extend an existing skill
DocumentationFix errors, improve clarity, add examples
Bug reportOpen an issue with reproduction steps

​
Process for contributing a skill

1

Open an issue first

Before writing code, open a GitHub issue describing:
  • What the skill checks
  • Which compliance framework or requirement it covers
  • Any known edge cases or limitations
This avoids duplicate work and lets the team give early feedback.
2

Fork and branch

git clone https://github.com/Rifteo-Community/skills
cd skills
git checkout -b skill/your-skill-name
3

Build the skill

Follow the structure defined in Skills Overview:
skills/
└── your-skill-name/
  ├── SKILL.md
  ├── references/  (optional)
  └── scripts/   (optional)
4

Write documentation

Create skills/your-skill-name.mdx following the Style Guide. No skill ships without documentation.
5

Add to docs.json

Add your skill page to the appropriate group in docs.json under the Skills tab. Place it in the group that matches the skill category:
{
 "group": "Web Application",
 "pages": [
  "skills/existing-skill",
  "skills/your-skill-name"
 ]
}
Available groups: Web Application, API Security, Infrastructure, Reconnaissance, Reporting, Compliance, Workflow, Integrations.
6

Submit a pull request

Open a PR against main. The PR description should include:
  • What the skill does
  • How to test it
  • A link to the open issue
7

Review and approval

A team member will review both the code and the documentation. All feedback must be addressed before merge. No skill merges without at least one approval.

​
Review checklist

Before submitting, verify:
  • SKILL.md frontmatter has all required fields (name, description, license, metadata)
  • SKILL.md body has When to Use, at least one step section, Output Format, and Rules
  • Documentation follows the Style Guide exactly
  • No section in the documentation is left empty
  • Examples use realistic, not trivial, inputs
  • Known limitations are documented honestly

​
Code of conduct

  • Be respectful in reviews and issues
  • Give feedback on the work, not the person
  • Assume good intent

​
Questions?

Open a GitHub issue with the question label or reach out via the team’s internal channel.