Feishu-Based Intelligent Collaboration

Use Feishu as the collaboration control plane: Base stores structured state, member tasks expose owner-facing commitments, IM delivers meaningful transitions, and Wiki or Docs preserve durable evidence. Treat GitHub as engineering execution evidence synchronized back to Feishu.

Operating Rules

• Read real Feishu and GitHub state before planning writes.
• Keep Base records keyed by stable identifiers such as repo_key, pr_key, check_key, task_key, event_key, and notification_key.
• Put long context, screenshots, reviews, and acceptance evidence in Wiki or Docs, then link them from Base.
• Verify every write with a readback when the API supports it.
• Do not hardcode personal IDs, Base tokens, table IDs, repository names, machine paths, or one-off user data in reusable workflow logic.
• Do not preserve old schemas, unused compatibility paths, or duplicate workflow implementations unless the user explicitly requires compatibility.
• If changing Base schema, workflow payloads, GitHub contracts, or persisted event formats, state the data impact and decide whether records need migration or can be rebuilt.

Reference Selection

Load references/hook-patterns.md when the task involves:

• Base workflow automation or lightweight Feishu notifications.
• External webhook dispatchers, event logs, retries, or audited delivery.
• GitHub PR, review, mergeability, check, or workflow-run hooks.
• Member-task hooks for assignment, blocking, due dates, status changes, or completion evidence.

Required Inputs

Before mutating state, identify:

• Collaboration objective: intake, triage, execution tracking, review, release coordination, notification, or knowledge maintenance.
• Feishu resources: Base app/table, relevant view, field names, task or Wiki targets, and notification receiver type.
• GitHub resources: repository, issue or PR, branch policy, CI requirements, required reviewers, and allowed write actions.
• Safety policy: who can authorize writes, merge method, auto-merge policy, notification rules, and audit requirements.

If required resources are missing, discover them with read-only calls first. Ask the user only when discovery is ambiguous or write authorization is required.

Core Loop

1. Discover current Feishu and GitHub state with read-only calls.
2. Classify the operation as read-only, Feishu write, GitHub write, hook dispatch, knowledge update, notification, or merge-sensitive.
3. Apply the smallest coherent set of writes that advances the workflow.
4. Update Base as the source-of-truth record.
5. Link durable evidence from Wiki, Docs, GitHub, CI, or task records.
6. Notify owners only for meaningful state transitions.
7. Record hook dispatches and failures as auditable events.

Review And Merge Gates

Before approving, enabling auto-merge, or merging a PR, verify:

• Explicit user intent covers the write action.
• Changed files match the tracked work item.
• Required reviews are satisfied and requested changes are resolved.
• Required checks pass or have a recorded reason for absence.
• Validation evidence covers the behavior changed.
• Data, workflow, schema, or permission changes have a migration or rebuild decision.
• No secrets, token leakage, unexpected permission expansion, or unsafe workflow privilege changes are present.
• Feishu Base and knowledge links reflect the current state when process or architecture changes matter.

If any gate fails, do not merge. Update the Feishu control record with the failed gate, evidence, and next action.

Reporting Back

Report concise evidence only:

• records or work items read
• writes performed
• hook or notification status
• GitHub sync status
• knowledge pages created or updated
• review and merge gate result
• remaining risks or required decisions

Keep raw logs out of the main answer unless the user asks for them.