Skip to main content

Do Lark Task

Implement a NAS frontend ticket from a Lark or Feishu task and prepare PR work in nas-fe. Use when the user provides a Lark task, todo link, task GUID, or task id such as t127620 and asks to implement, fix, continue, or prepare PR work; create the PR only when the user explicitly asks or confirms the drafted PR.

Source: .agents/skills/do-lark-task/SKILL.md

Metadata​

  • name: do-lark-task
  • version: 1.0.0
  • bins: ["lark-cli"]

Content​

Do Lark Task

Prerequisite: Read installed lark-shared before using Lark CLI commands, especially for auth, missing scopes, and split login.

Turn a Lark task into a reviewed nas-fe pull request. Treat the Lark task as product intent, the repo as implementation truth, and the PR as the deliverable.

Required Skills​

Use installed upstream and repo skills:

  • lark-shared for auth, identity, and missing scopes.
  • lark-task for reading task details.
  • code-review, pr-description, or ready-pr for PR readiness.
  • fe-tech-design when the PR exceeds 1000 changed lines.
  • self-test-doc when QA handoff or large-risk FE work needs a self-test doc.

Lark CLI Pattern​

Follow the lark-cli skill-maker priority:

  1. Use shortcuts or registered APIs first.
  2. Use lark-cli schema <service.resource.method> before any raw registered API with unclear params.
  3. Use lark-cli api <METHOD> <path> only when no shortcut or registered API covers the operation.

Permissions​

OperationRequired scope
Read Lark task detailstask:task:read
Resolve people by email/namecontact:user:search
Read linked docs when neededdocs:document.content:read or scope reported by lark-doc
Download task/doc media when neededdocs:document.media:download
Create tech design or self-test docsSee fe-tech-design and self-test-doc

Preflight​

Before reading Lark:

command -v lark-cli
lark-cli auth status

Handle results:

  • If lark-cli is missing, stop Lark intake and ask the user to install/configure it. Continue only with repo-local work if enough context was provided.
  • If user identity is unavailable, task reads cannot proceed. Use lark-shared split auth for task:task:read.
  • If bot identity is unavailable, ignore bot paths; this workflow should prefer --as user for task reads.
  • If user identity needs refresh, continue with the read command; if refresh fails, follow lark-shared.
  • If a command reports _notice.update, finish the current request. Mention the update notice in the final report, but do not run update commands automatically.

Resolve The Task​

  1. If the user provides a Lark todo/task applink, extract the guid query parameter and use it as task_guid.
  2. Do not use suite_entity_num as the API GUID. Keep it as the human task id for branch, commit, and PR context.
  3. Fetch task details:
lark-cli task tasks get --as user --params '{"task_guid":"<guid>","user_id_type":"open_id"}'
  1. Capture title, description, task id, task URL, status, assignee, members, attachments, related docs, Figma links, Sentry links, and any available comments/discussion.
  2. If images or attachments are inaccessible, continue from text and repo context unless the missing visual blocks implementation.

Analyze Before Editing​

  1. Convert the task into acceptance criteria and open questions.
  2. Search the repo for product terms, route names, components, hooks, contexts, services, and tests.
  3. Classify the FE risk area:
    • checkout/payment: displayed amount, provider amount, discounts/trials, saved methods, Apple Pay/Stripe/Ebanx/Razorpay
    • auth: redirects, token refresh, 401/403, protected routes, sensitive storage/logging
    • membership/settings: active tiers, disabled tiers, tier order, approval/questions, share links, member state
    • public route/metadata: link previews, ISR/SSR/static behavior, invalid slugs or ids
    • Magic Content/AI: asset state, polling, credits, provider errors, media rendering
    • portal/dashboard: loading, permissions, empty states, tables/cards, mobile layout
    • localization: use keys/placeholders only; never edit locale files
    • shared UI/NPL: existing components, Tailwind/classNames, accessibility
  4. Identify routes/screens, API expectations, Figma/assets, localization keys/placeholders, QA cases, and risk notes that affect the implementation.
  5. Identify the smallest safe implementation plan.
  6. Do not stop at a proposal unless the user asked for planning only.

Branch And Worktree​

Start from latest develop unless the user specifies another base.

Rules:

  • Preserve existing local work.
  • Never use git reset --hard, destructive checkout, or branch deletion unless explicitly requested.
  • Prefer a separate worktree when the current checkout is dirty, on the wrong branch, or contains unrelated work.
  • Follow .agents/references/implementation/worktree-assignment.md for worktree and branch naming.
  • After creating a new worktree, copy local .env and .env.* files from the source checkout into the new worktree before running app commands.
  • Use feat/<feature-name>/<task-id> when the task comes from a PRD or proper large feature brief.
  • Use adhoc/<feature-name>/<task-id> when no PRD was provided.

Typical fresh worktree flow for a PRD-backed feature:

git fetch origin develop
git worktree add ../<feature-name>-<task-id> -b feat/<feature-name>/<task-id> origin/develop
rsync -av --include='.env' --include='.env.*' --exclude='*' ./ ../<feature-name>-<task-id>/

For a direct task without a PRD, use the same worktree path pattern with -b adhoc/<feature-name>/<task-id>.

If already on the correct clean task branch, inspect whether it is based on latest origin/develop and update only with non-destructive commands.

Implement​

  • Match existing nas-fe patterns and ownership boundaries.
  • Keep changes narrowly scoped to the task.
  • Prefer existing helpers, types, contexts, services, and components.
  • Follow all .agents/rules/*.
  • Avoid unsafe as, any, unnecessary useEffect, gratuitous useCallback, inline styles, and unrelated formatting churn.

Verify​

Run the smallest meaningful checks first:

  • targeted bunx eslint <changed paths> for changed TS/JS/TSX/JSX files
  • focused Jest tests when nearby tests exist
  • browser verification for visual, route, checkout, auth, metadata, or user-flow behavior when practical
  • bun run build for SSR/page/shared-risk changes when targeted checks are insufficient

If a check fails because of unrelated existing issues, record the exact command, failure summary, and why it is unrelated.

PR​

  1. Inspect git status and git diff; ensure only intended files changed.
  2. Commit only when the user explicitly asked to commit or confirms the proposed commit. If committing, use a concise message referencing the task id when available.
  3. Push only when the user explicitly asked to push or confirms the branch should be pushed.
  4. If the user already asked to create/open a PR in the current request, open a PR against develop unless the task or repo context requires another base.
  5. If the user did not explicitly ask to create/open a PR, stop before PR creation. Return the proposed base branch, head branch, title, body summary, verification results, and ask for approval.
  6. Use pr-description or ready-pr only after a PR exists or the user confirms PR creation, so the PR body includes:
    • Lark task link and task id
    • problem summary
    • implementation summary
    • verification performed
    • tech design and self-test links when created
    • known limitations or follow-up

If additions plus deletions exceed 1000 lines, create a Lark tech design with fe-tech-design before marking the PR ready.

Close The Loop​

Report:

  • branch
  • PR URL
  • task link/id
  • changed files summary
  • verification results
  • created tech design or self-test docs
  • any missing auth, scope, env, or QA evidence

Do not mark the Lark task complete, assign it, or comment on it unless the user explicitly asks for that Lark write and the required write scope is available.