FE Tech Design

Create a concise NAS frontend technical design document in Lark. Use when a frontend PR has more than 1000 changed lines, when preparing a large feature for review, or when the user asks for a FE tech design; include diagrams when routing, user flow, or frontend architecture needs explanation.

Source: .agents/skills/fe-tech-design/SKILL.md

Metadata

• name: fe-tech-design
• version: 1.0.0
• bins: ["lark-cli"]

Content

FE Tech Design

Prerequisite: Read installed lark-shared, lark-doc, and lark-wiki when parent wiki placement is involved. Use lark-cli shortcuts before raw OpenAPI calls.

Create a Lark technical design document for significant nas-fe changes. Use it when a PR exceeds 1000 changed lines, when ready-pr triggers the large-PR doc gate, or when the user asks for a frontend tech design.

Reference Format

Follow the frontend template:

https://nasdaily.sg.larksuite.com/docx/SRNKdvHCQoU5pMx2CxGliaNygc6

Use that document as a template reference, not as a source to overwrite. Create a fresh tech-design doc for each feature or large PR. Keep the doc concise and focused on frontend behavior. The template structure is:

• <title>[YYYY-MM-DD] Short Feature Name</title>
• short purpose note
• Links
• What Changed
• Frontend Design
• Diagram
• User Flows
• Risks
• Validation

Default parent for new frontend tech-design docs:

https://nasdaily.sg.larksuite.com/wiki/F1B7w2BY5iIWNwkd0U4u1VXhs6a

Use parent token:

F1B7w2BY5iIWNwkd0U4u1VXhs6a

Required Skills

Read installed upstream skills before writing:

• lark-shared
• lark-doc
• lark-wiki if creating under a wiki parent or inspecting wiki nodes

For create/update syntax, follow lark-doc v2 XML rules. Use docs +create --api-version v2.

Permissions

Operation	Required scope
Create Docx document	docx:document:create
Write Docx document content	docx:document:write_only
Read template or existing document content	docs:document.content:read or docx:document:readonly
Upload or insert document media	docs:document.media:upload
Resolve wiki parent or node placement	Scope reported by lark-wiki for the target parent

Preflight

Before creating or updating Lark docs:

command -v lark-cli
lark-cli auth status

Handle results:

• If lark-cli is missing, do not create the doc. Return the XML draft or doc outline and tell the user to install/configure Lark CLI.
• If user identity is unavailable, user-owned docs/wiki parents cannot be accessed. Start split auth through lark-shared for the minimum doc/wiki scope needed.
• If bot identity is unavailable, do not use bot-owned creation paths. Prefer --as user for user/wiki docs.
• If user identity needs refresh, continue with --as user; if refresh fails, follow lark-shared.
• If parent inspection fails because metadata/wiki scopes are missing, ask for the exact parent token or run split auth for the reported scope.

Trigger And Inputs

Before creating the doc:

1. Identify the PR diff or branch diff.
2. Count changed lines with additions plus deletions from git diff --shortstat or PR diff stats.
3. Gather:
   • PR URL/title if available
   • Lark task/PRD links
   • Figma links
   • affected routes/pages/components/services
   • user flow, routing, or state/data flow that would benefit from a diagram
   • frontend API calls and backend dependencies
   • validation already run
   • frontend risk notes

If the target Lark parent is not specified, use the default frontend tech-design parent above. If the user provides another parent, use the user-provided parent.

Document Shape

Use XML content and keep it reviewer-friendly:

<title>[YYYY-MM-DD] Short Feature Name</title>

<p><b>Frontend review note:</b> Keep this short. Explain what changes in the UI or browser flow, why the approach is safe, and how it was checked.</p>

<h1>Links</h1>
<table>...</table>

<h1>What Changed</h1>
<table>...</table>

<h1>Frontend Design</h1>
<table>...</table>

<h1>Diagram</h1>
<table>...</table>

<h1>User Flows</h1>
<table>...</table>

<h1>Risks</h1>
<table>...</table>

<h1>Validation</h1>
<table>...</table>

Do not add backend architecture, launch plans, long PRD summaries, or exhaustive edge-case lists unless they directly affect frontend behavior. Prefer short tables and plain language over long prose.

Include one simple diagram when it helps reviewers understand the frontend change:

• user-flow diagram for multi-step user states, checkout/auth/member flows, or approval flows
• routing diagram for URL contracts, redirects, query params, ISR/SSR/static routing, or post-login handoff
• state/data-flow diagram for component/context/hook ownership, service calls, polling, or API response handling

Skip the diagram when the change is small or the table explanation is clearer. Prefer Mermaid source or a small Lark whiteboard; keep labels short and business-readable.

Commands

Create under the default frontend tech-design parent unless the user provides another parent:

lark-cli docs +create --api-version v2 --as user --parent-token F1B7w2BY5iIWNwkd0U4u1VXhs6a --doc-format xml --content @.git/fe-tech-design.xml

If the command fails because the parent token needs wiki node creation or move semantics, use lark-wiki to resolve the node and follow its instructions. Do not improvise raw API calls unless shortcuts cannot support the required operation.

Output

Return:

• created Lark URL/token
• PR link
• changed line count that triggered the doc
• sections included
• missing source context or review caveats

Safety

• Never overwrite an existing Lark TD unless the user explicitly asks and the latest doc was fetched first.
• Do not include secrets, raw env values, private tokens, customer PII, or unnecessary provider payloads.
• If auth or permissions are missing, report the exact missing scope and stop.