lineage: Skill for Claude Code

Lineage Open Source Review Guardrails

Lineage should be easy to contribute to without letting quality, safety, or roadmap clarity drift.

Contribution Rules

• Contributors should assign an issue before starting work.
• PRs should target develop and link the assigned issue, except maintainer-only housekeeping.
• Every PR should include relevant tests added/updated, or a clear no-test reason.
• Keep project-board status simple: Todo, In Progress, Under Review, Done.
• Milestones are goals, not dates.
• Keep labels small and meaningful: bug, enhancement, documentation, security, critical, needs:decision.

Review Standard

Review for correctness first, then safety, tests, maintainability, and documentation.

Look especially for:

• package inputs treated as trusted;
• provider-specific behavior leaking into core;
• missing tests for safety or idempotency;
• CLI output that cannot be inspected or tested;
• docs that imply future capabilities are already implemented;
• accidental disclosure of private roadmap, secrets, credentials, or machine-local state.

Public Voice

• Keep public docs focused on the agent-environment distribution layer.
• Avoid overpromising marketplace, enterprise, billing, cloud, vector DB, or workflow-engine capabilities.
• Prefer plain explanations of what currently works, what is experimental, and what is intentionally out of scope.

Maintainer Checklist

Before merge:

• Linked issue is assigned or the PR is explicit maintainer housekeeping.
• Required checks pass.
• Tests match the risk of the change.
• Branch target is develop.
• Safety checklist is credible, not just checked.