Contributing - Rifteo

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

Type	Description
New skill	A new audit check that doesn’t exist yet
Skill improvement	Fix a bug or extend an existing skill
Documentation	Fix errors, improve clarity, add examples
Bug report	Open an issue with reproduction steps

Process for contributing a skill

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.

Fork and branch

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

Build the skill

Follow the structure defined in Skills Overview:

skills/
└── your-skill-name/
  ├── SKILL.md
  ├── references/  (optional)
  └── scripts/   (optional)

Write documentation

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

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.

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

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.

​Welcome

​What you can contribute

​Process for contributing a skill

​Review checklist

​Code of conduct

​Questions?