Contributing

Thanks for helping improve public Xquik SDKs, docs, skills, plugins, examples, and package metadata.

Find work#

• Browse issues labeled good first issue for small tasks.
• Browse issues labeled help wanted for broader contributions.
• Ask for clarification before starting unclear or overlapping work.

Grow with a project#

• Start with a small task and read the repository's roadmap.
• Build useful contributions through focused, reviewed pull requests.
• Never split work or inflate metrics to qualify for recognition.
• Link merged work in the OpenSSF human evidence tracker.

Before opening an issue or PR#

• Use the affected repository when possible.
• Search existing issues and PRs for the same request.
• Keep reports specific, reproducible, and public-safe.
• Never include credentials, cookies, webhook secrets, or private routing details.
• Remove private account data from screenshots before posting.
• For suspected vulnerabilities, follow SECURITY.md.

Useful issue details#

• Repository or package name
• Version, language, and install command
• Minimal reproduction or failing command
• Expected and actual behavior
• Links to public docs, registry pages, or examples involved

Pull requests#

• Keep changes focused on one public issue or improvement.
• Create a branch and open a pull request.
• Run the affected repository's documented format, lint, test, build, security, and package checks.
• Add regression tests for behavior changes and tests for major new functionality.
• Prefer small documentation, metadata, example, or workflow fixes over broad rewrites.
• Verify public behavior against canonical repository sources.
• Use source, generated SDKs, OpenAPI, or registry metadata as evidence.
• Leave generated SDK internals to the generator.
• Edit generated paths only when repository guidance permits it.
• Avoid adding package-health, score, compatibility, or performance claims unless they are source-backed and current.
• Follow the code review policy.

Developer Certificate of Origin#

Every non-trivial contribution requires a DCO 1.1 sign-off.

Run git commit -s with your real name and a reachable email address.

The sign-off certifies your right to submit the work.

Acceptance requirements#

• Follow the affected repository's language and formatting rules.
• Keep compiler, type, lint, and security warnings at zero.
• Add tests for major functionality and corrected defects.
• Keep statement coverage at 90% or higher.
• Keep branch coverage at 80% or higher.
• Update documentation when behavior or interfaces change.
• Preserve the repository's declared license.
• Resolve every blocking review comment.

Automated changes require an accountable human author and reviewer.

Public discoverability#

• Use descriptive headings that match supported tasks.
• Answer concrete questions with tested examples.
• Keep repository descriptions and page metadata unique.
• Link each claim to current public documentation or code.
• Prefer precise terminology over keyword variations.
• Avoid repeated keywords, hidden text, and unsupported comparisons.
• Keep agent indexes concise, current, and machine-readable.
• Treat llms.txt as an optional agent aid, not a ranking signal.

Xquik is an independent third-party service. Not affiliated with X Corp. "Twitter" and "X" are trademarks of X Corp.