docs: add PR lifecycle flow to CONTRIBUTING.md

[chaodu-agent]

What problem does this solve?

Contributors and maintainers need a clear, documented understanding of how PR labels drive the review lifecycle — specifically when PRs go stale and get auto-closed.

At a Glance

Adds an ASCII diagram and label transition table to CONTRIBUTING.md documenting:

• pending-contributor → stale 3 days → closing-soon → auto-close after 3 more days
• Author comment resets the clock → flips back to pending-maintainer

Proposed Solution

Append a PR Lifecycle section to the end of CONTRIBUTING.md with:

1. ASCII flow diagram
2. Label transition table
3. Key rules explanation

Validation

• Docs-only change; renders correctly in GitHub preview

[github-actions]

⚠️ This PR is missing a Discord Discussion URL in the body.

All PRs must reference a prior Discord discussion to ensure community alignment before implementation.

Please edit the PR description to include a link like:

Discord Discussion URL: https://discord.com/channels/...

This PR will be automatically closed in 3 days if the link is not added.

[shaun-agent]

OpenAB PR Screening

This is auto-generated by the OpenAB project-screening flow for context collection and reviewer handoff.
Click 👍 if you find this useful. Human review will be done within 24 hours. We appreciate your support and contribution 🙏

• Title: docs: add PR lifecycle flow to CONTRIBUTING.md
• Source: docs: add PR lifecycle flow to CONTRIBUTING.md #912
• Status: moved to PR-Screening
• Generated at: 2026-05-23T18:02:51.867Z
• Discord thread: not available

Screening report

screened PR #912 and moved project item `PVTI_lADOEFbZWM4BUUALzgtm0KI` to `PR-Screening`.

GitHub comment: #912 (comment)
Project action: https://github.com/orgs/openabdev/projects/1, status now PR-Screening

Intent

Document how PR lifecycle labels drive maintainer/contributor handoff, stale timing, and auto-close behavior. The operator-visible problem is that contributors and reviewers currently have to infer what pending-contributor, closing-soon, and author comments mean in practice.

Feat

Docs work. The PR adds a PR Lifecycle section to CONTRIBUTING.md with an ASCII flow diagram, a label transition table, and rules for the 3-day stale window, closing-soon, auto-close timing, and author-comment reset back to pending-maintainer.

Who It Serves

Primary beneficiaries are contributors and reviewers. Maintainers also benefit because the expected review-state machine becomes easier to cite during PR triage.

Rewritten Prompt

Update CONTRIBUTING.md with a concise PR lifecycle section that explains OpenAB label-based review flow. Include a readable ASCII diagram and transition table covering pending-maintainer, pending-contributor, closing-soon, stale timing, auto-close timing, and the rule that an author comment resets the PR to maintainer review. Keep the wording aligned with the actual automation behavior and verify the Markdown renders cleanly in GitHub.

Merge Pitch

This should move forward if the documented lifecycle matches the automation currently running on the repo. Risk is low because this is docs-only, but the main reviewer concern is correctness drift: if the stale bot timing or label transitions differ from the docs, this would institutionalize the wrong process.

Best-Practice Comparison

OpenClaw and Hermes Agent do not materially apply here. This PR documents GitHub PR lifecycle behavior, not gateway scheduling, durable execution, delivery routing, run persistence, or scheduled agent prompts.

The only relevant comparison is procedural: like those systems, the docs should describe the state machine explicitly enough that operators can predict transitions without reading implementation details.

Implementation Options

Conservative: merge the docs as-is after verifying the timing and label transitions against the current workflow configuration.

Balanced: merge the lifecycle docs, but tighten wording to explicitly name the automation source and clarify whether comments from any user or only the PR author reset the clock.

Ambitious: add docs plus a small automation reference link or generated snippet from the workflow source of truth so future stale-policy changes are less likely to drift from CONTRIBUTING.md.

Comparison Table

Option	Speed	Complexity	Reliability	Maintainability	User Impact	Fit for OpenAB now
Conservative	Fastest	Low	Medium if manually verified	Medium	Clearer contributor expectations	Good for a docs-only cleanup
Balanced	Fast	Low-medium	Higher because edge cases are explicit	Higher	Better reviewer/contributor alignment	Best current fit
Ambitious	Slower	Medium	Highest against future drift	Highest if source-linked/generated	Same docs benefit plus stronger process guarantees	Useful follow-up if stale rules change often

Recommendation

Use the balanced path. Confirm the actual stale workflow behavior, then merge with precise wording around who can reset the lifecycle and where the 3-day timers come from. A generated/source-linked policy can be split into a follow-up; it is not necessary to advance this PR.