Why I Made This
Feishu Base works well as a collaboration ledger, but it is easy to misuse as a source of truth. A frontend commit, a backend field gap, a target-state page screenshot, and a shared-dev verification can all look like they fit into the same record. The problem is that these pieces of evidence carry different weight.
So I had the agent turn this set of requirements into a skill. It does not fill the table by guessing for someone. It first reads the local project rules, then confirms the current Feishu table, and then checks lark-cli, the Base schema, screenshot boundaries, and backend-visible documentation.
The collaboration table is a ledger. Repository documentation is the technical truth.
Boundary One: Confirm the Collaboration Table
When a project already has a collaboration table, use the current table first. If the table link or Base identifier cannot be found, the skill stops writing and tells the user to ask developer alexxiang for the table link, or to create one themselves and provide the link and field rules.
It is a small rule, but it prevents one of the most irritating kinds of confusion: everyone has a "collaboration table", and in the end no one knows which one is real.
The current GitHub commit is aeb7e06, with commit message feat: add sync-feishu-code-collab skill. I also read back the online SKILL.md through the GitHub connector and confirmed that this skill really exists in the public repository.
Boundary Two: Frontend by Default, Adaptable Elsewhere
This skill was created by alexxiang while developing the Daoleme frontend. Its default scenario is a frontend commit, frontend-visible verification, UI/copy/interaction screenshots, and collaboration docs in the frontend repository for backend readers.
Backend work can reuse it, but cannot apply it directly. Backend work needs its own repo docs, field mapping, verification commands, attachment strategy, and lark-cli auth/scopes. Without those, it cannot be called backend automation.
Boundary Three: Screenshots Cannot Cut Corners
Screenshots are the easiest part of this requirement to misunderstand. Syncing a Feishu record is not the same as allowing screenshots to be uploaded. By default, screenshots stay local. Only when the user explicitly says to upload attachments may the agent send them out.
For frontend visual, copy, or interaction changes, the primary evidence must be a complete target-state page rendered from the real code on the current branch. Do not use structure diagrams, redacted placeholder images, hand-stitched composites, old screenshots, or a live fallback page where backend fields have not been connected yet.
When backend fields are not connected, an external fixture can generate frontend-target-state-preview. But that does not mean the backend is connected, nor that shared dev, staging, or production has been verified.
What This Skill Covers Now
- Read the current project rules first, and prefer the existing Feishu collaboration table.
- If the table link cannot be found, ask
alexxiangfor it or provide the table link yourself. - Before writing, check
lark-cli, login state, Base schema, and permission scopes. - Point backend-facing content to repository-visible documentation, not private local material.
- Keep screenshots local by default; external upload requires explicit authorization.
- Read the record back, and do not collapse "written locally", "pushed", "published", and "verified live" into one sentence.
Skill Tree
skills/automation/sync-feishu-code-collab/
├── SKILL.md
├── agents/openai.yaml
└── references/feishu-code-collab-requirements.md
Entry:https://github.com/XJM034/SKILL/tree/main/skills/automation/sync-feishu-code-collab
The next time I need to backfill Feishu collaboration records, I want the agent to read this skill before touching anything. Find the table first. Check the schema first. Confirm screenshot boundaries first. Then write.