Workflow Automation Notes From Inside Cursor

Our team tracks issues in GitHub and talks in Lark. When assignees change, or when someone needs to follow up, everyone should theoretically know. In practice, people often forget to mention it in the group chat.

Later, I connected “check issues, change assignee, notify Lark” into a fixed workflow inside Cursor, and kept the commands and prompts as notes. The first half of this article is about that setup and the Skill around it. The second half records a few adjacent workflow habits: still “a human in the editor, asking an agent to run terminal commands,” but not necessarily related to Lark.

Installing Lark CLI

The package name is @larksuite/cli. I usually install it globally:

npm install -g @larksuite/cli

After installation, the terminal provides lark-cli. The official repository also includes AI skills. Pulling them with npx installs them into the user directory, and Cursor can use them too:

npx skills add https://github.com/larksuite/cli -y -g

For first-time app setup, I used:

lark-cli config init --new

This is interactive. The terminal pauses, the browser opens the developer platform, and you finish authorization by following the prompts. The link contains a user_code with an expiration time, so if it expires, rerun the command.

If you prefer fewer browser steps and more scripting, use a non-interactive form and read the app secret from stdin, so the secret does not appear in command-line arguments where ps might expose it. Exact subcommands can differ by version, so check lark-cli --help on your machine. A typical form looks like:

lark-cli config init --app-id '<your app id>' --app-secret-stdin --brand feishu

Secrets and real .env values follow the same rule: do not commit them, and do not paste them into chat.

On the GitHub side, log in to the CLI once:

gh auth login

After that, listing issues and changing assignees becomes much easier.

The Skill Grew Over Time

At first, there was only one team rule: when someone creates an issue through Lark, the body should mention the responsible person using the Lark directory name, not just the GitHub username. That kind of content fits Cursor rules; it controls wording.

The harder part was this: after gh changes the assignee, Lark should be notified in the same conversation. Otherwise, people leave and forget. I later wrote a Skill that describes trigger conditions, target chat, and failure handling. The triggers are roughly two kinds: I used gh to change assignees in this conversation, or I explicitly said “assign this to someone and notify Lark.”

Target chats also differ. A summary for myself goes to a default chat from environment variables. If it needs to notify another person, it goes to the engineering group, and the chat ID is looked up from the mapping table in the project. Do not casually type an arbitrary chat ID.

Another rule is not to mix two sets of credentials. Python scripts in repositories usually read the business bot from .env; lark-cli uses the credentials shown by lark-cli config show. Some chats only admit one of the bots. If mixed, errors like “bot is not in the conversation” appear. In the Skill, I kept a skeleton like lark-cli im +messages-send --as bot, with --chat-id and --markdown, and the message body includes title, mention, and issue link. Every time I hit a pitfall, I add a short note to the Skill, including this one: if sending fails, do not pretend it succeeded.

If I were writing it from scratch today, I would first make sending stable, then split default chat and engineering chat, then handle credentials and errors. Trying to make it perfect in one pass usually slows it down.

Prompts I Often Type

These are not templates to copy exactly. They are examples of the tone and shape I use.

To list my open issues across repositories and send a short Lark summary:

Use gh to find all open issues assigned to me, group by repository, and send a Markdown summary card to the default chat. Do not paste full issue bodies.

To change assignment inside Cursor and notify Lark:

Assign issue #123 to a teammate’s GitHub login. Follow the repository rules to notify the Lark engineering group, mention the responsible person using github-team-map, and tell me whether sending succeeded.

To list issues without sending anything:

List open issues assigned to me in the current repository, include links, and do not send to Lark.

To confirm assignment before sending:

After changing the assignee, use gh issue view to inspect assignees from JSON, then send the Lark message.

If you click Assign on github.com in the browser, Cursor rules or Skills do not automatically run. That is a different chain. If you need a web-side assignment to trigger Lark, use GitHub Actions or a webhook. Most of my assignment work happens in Cursor, so same-conversation notification is enough.

Two Useful gh Commands

Current repository only:

gh issue list --assignee @me

All repositories, assigned to me, still open:

gh search issues --assignee @me --state open --limit 100 \
  --json number,title,url,repository,updatedAt

The second command outputs JSON. With jq or a few lines of Python, it is easy to group by repository and generate a Lark-friendly Markdown message, which is much better than copying from the web UI.

Other Workflows Use The Same Habit

Issue and Lark notification is the workflow I documented most carefully, but Cursor is useful for many other “repeated small process” tasks.

Git and PRs. After local changes, opening a PR, checking a diff, and looking at CI can all be done with gh pr create, gh pr view, and gh pr checks. Sometimes I simply ask: push the current branch, open a draft PR through gh, and write the title and body according to repository conventions.

Tests as gates. When a module changes, I ask the agent to run only relevant tests instead of a full test suite that takes ten minutes. This works best when repository conventions are written in AGENTS.md or README. A sentence like “run the tests covering this change, and stop if they fail” is often enough.

MCP browser checks. If the project has a browser MCP, the agent can open the local dev URL, click through a main path, and take a screenshot. This does not replace formal E2E tests, but it is good enough for quick checks like “did this route become a 404?”

Stats and reports. If the repository has scripts that read databases or logs, such as daily call counts or error summaries, Cursor can run them, turn output into a few Markdown lines, and send or save the result. This is the same category as issue notification: terminal produces structured output, and the human decides where it goes.

Multi-file refactors. For renames, moves, and import updates, I ask the agent to work in steps: first list files that will be touched, then edit, then run lint or type checks. Large replacements are easy to miss; “run a package-level check after the edit” catches many mistakes earlier.

Docs and migration notes. When an API changes, update OpenAPI, README, or internal docs in the same PR. Data migration scripts or one-off SQL can also be written according to the transaction and rollback rules in AGENTS.md, then reviewed by a human before execution.

The common point is not “let the background run everything.” It is: write repository habits clearly, write Skills that know when to stop and ask, and then build the habit of giving precise commands in the chat box.

A Small Journal Helps

I also keep a journal.md in the project. Sometimes it records which command worked today and which error code blocked me. It is not for publishing; it is there so I do not forget the setup two weeks later. Lark, gh, tests, and MCP checks can all leave one line there. Later, when updating a Skill or investigating an old workflow, those notes save time.

WeChat

Follow ZiCode on WeChat

If this post was useful, you can follow later updates on WeChat as well.

X / Twitter

Follow @ax2_zicode

Faster technical notes, short thoughts, and new-post alerts are posted on X.

X Open X Profile @ax2_zicode