Run any Skill in Manus with one click

1k-defi-module-integration

App-side OneKey DeFi guide for Earn, Borrow, Staking, vaults, lending, protocol integrations, ABI-backed operations, native/provider-backed operations, pending transactions, history, route handoffs, risk display, and DeFi regression review.

Run Skill in Manus

Stars2,376

Forks515

UpdatedJune 6, 2026 at 15:12

Source

OneKeyHQ

OneKeyHQ/app-monorepo

View GitHub Repository View Creator Repositories

Install command

Download

Run Skill in Manus

Useful forSOC

Software DevelopersComputer and Mathematical Occupations15-1252L4

File Explorer

7 files

SKILL.md

readonly

name	1k-defi-module-integration
description	App-side OneKey DeFi guide for Earn, Borrow, Staking, vaults, lending, protocol integrations, ABI-backed operations, native/provider-backed operations, pending transactions, history, route handoffs, risk display, and DeFi regression review.

DeFi Module Integration

Use this skill when App code touches Earn, Borrow, Staking, vault/lending/yield protocols, operation modals, pending/history, or protocol-specific DeFi flows.

This is an App development skill. It should guide implementation and review from current repository code and App behavior, not from external workflow details.

Core Model

The canonical DeFi App path is:

host/route -> home -> list/detail -> operation modal -> transaction sequence -> pending refresh -> history -> cross-surface handoff

Most requirements are not "add a protocol" only. They are route, data, operation, pending, and platform integration requirements.

Scenario Router

Classify the change first:

Existing Earn protocol or Earn detail/list behavior.
Existing Borrow protocol, market, reserve, or health-factor behavior.
New DeFi module that does not fit Earn/Borrow.
ABI-backed protocol operation where App builds contract calls from typed parameters.
Native/provider-backed operation where App delegates protocol details to a provider or chain-specific service.
Swap-assisted operation such as funding, wrap, repay-with-collateral, or Trade/Buy handoff.
Regression/review of routing, pending refresh, history, or platform layout.

If the scenario is unclear, map its operation contract before choosing UI structure.

Default Workflow

Read app-architecture.md to place the feature in the App flow.
Use code-map.md to find stable anchors.
Define the operation contract in operation-flow.md: operation type, parameters, setup tx, business tx, status, risk, and refresh.
Define route, state, pending, and platform ownership in state-and-routing.md.
Run checklists.md, including ABI/native readiness drills when adding a protocol integration.
Validate on the route and platform that own the behavior.

Reference Map

Need	Reference
Understand Earn/Borrow/Staking flow	app-architecture.md
Find current repo anchors	code-map.md
Define operation and transaction contracts	operation-flow.md
Route, state, pending, history, and platform ownership	state-and-routing.md
Prevent common integration failures	checklists.md

Readiness Drills

Use these drills to judge whether the skill can guide fast protocol integration:

ABI-backed protocol: can you identify network/account, contract address, read params, write params, approval/permit needs, tx labels, pending tags, refresh scope, and history semantics without a one-off template?
Native/provider-backed protocol: can you identify provider capability, native token handling, setup/business sequence, unsupported states, account derive requirements, and completion polling?
New L2/protocol module: can you decide whether it belongs under Earn/Borrow, a new DeFi surface, a Discovery-hosted flow, or a Trade handoff based on operation semantics?

If a drill cannot be completed from the references, improve the abstraction before implementing.

Hard Stops

Do not place native Earn routes as if they are desktop/web Earn tabs; native hosts Earn under Discovery.
Do not add a protocol until route params, provider identity, operation contract, pending tags, and refresh scope are named.
Do not mix setup tx, approval, wrap, quote, and business tx into one opaque action.
Do not rely on optional fields to avoid defining pending/history identity.
Do not call native crash or freeze bugs fixed from state reasoning alone; capture the Android/iOS log, Sentry event, or JS/native boundary that proves the failing operation path.
Do not hand-edit generated locale files; use /1k-i18n.
Do not broaden shared Staking/Borrow utilities without existing-protocol regression reasoning.

Related Skills

/1k-i18n for translation keys and generated locale workflow.
/1k-coding-patterns for React and TypeScript patterns.
/1k-state-management for Jotai and state ownership.
/1k-cross-platform for platform-specific routing and layout.
/1k-trade-swap-market for Swap-assisted funding or repay flows.

More from this repository

same repository

1k-create-pr

OneKeyHQ/app-monorepo

Creates a Pull Request from current changes for OneKey app-monorepo. Use when user wants to create PR, submit changes, or merge feature branch. Handles branch creation, commit, push, and PR creation with conversation context extraction for code review AI.

2026-06-172.4k

1k-trade-swap-market

OneKeyHQ/app-monorepo

App-side OneKey Trade/Swap/Market guide for Swap core, Swap Pro, Market speed-swap, K-line/chart, token selectors, cold-start frame-by-frame validation, quote/build/send flows, history/status, provider channels, PrivateSend-like channels, stock-trading channels, limit/order flows, fees, slippage, ETA, and cross-module funding handoffs.

2026-06-152.4k

1k-ui-verify

OneKeyHQ/app-monorepo

AI-agent-driven UI verification for OneKey. Use to actually drive the running app and confirm a visual/interactive change works — Electron desktop via Chrome DevTools Protocol (CDP) on port 9222 with playwright-core, and React Native (iOS/Android) via callstack agent-device. Triggers on "verify the UI", "drive the app", "screenshot the change", "check it on desktop/simulator", "CDP 9222", "agent-device", "UI 验证", "跑一下看看", "截图确认".

2026-06-092.4k

1k-perps-module

OneKeyHQ/app-monorepo

Use only for explicit OneKey Perps/Hyperliquid (`views/Perp`, ServiceHyperLiquid, perpetuals, 永续/合约, Perps trading). Covers orderbook/L2/BBO, TWAP, scale/TIF/trigger/reduce-only, Perps TradingView/K-line, Perps Relay deposit, token selector, positions/account state/PnL/funding/margin/liquidation. Exclude generic Swap/Market/TradingView; Swap Relay quote/status/pending/requestId alone is not enough unless Perps deposit/Hyperliquid/`views/Perp`/`usePerpDeposit`/`fetchPerpDeposit*`/`perpsDepositOrderAtom` is explicit.

2026-06-062.4k

1k-debug-logging

OneKeyHQ/app-monorepo

Standardize temporary debug console logs in OneKey code with a consistent prefix and safe stringify helper. Use when adding, reviewing, or cleaning local debug logs, temporary console.log output, debug helpers, or troubleshooting-only logging. Do not use for analytics, server logs, LogToServer, or permanent business metrics.

2026-06-022.4k

1k-tradingview-communication

OneKeyHQ/app-monorepo

OneKey TradingView app bridge guide. Use when changing or debugging TradingView/WebView/iframe communication, chart URL params, kline/history/realtime messages, marks, Hyperliquid price scale, Perps SYMBOL_CHANGE, chart lines, order draft/cancel/drag-amend messages, FORCE_RECOVER_WS, or tradingview_* methods between the app repo and the chart repo. 适用于 TradingView 通信、图表 WebView 通信、K 线、perps 线、marks、消息桥排查。

2026-05-132.4k

name	1k-defi-module-integration
description	App-side OneKey DeFi guide for Earn, Borrow, Staking, vaults, lending, protocol integrations, ABI-backed operations, native/provider-backed operations, pending transactions, history, route handoffs, risk display, and DeFi regression review.

DeFi Module Integration

Use this skill when App code touches Earn, Borrow, Staking, vault/lending/yield protocols, operation modals, pending/history, or protocol-specific DeFi flows.

This is an App development skill. It should guide implementation and review from current repository code and App behavior, not from external workflow details.

Core Model

The canonical DeFi App path is:

host/route -> home -> list/detail -> operation modal -> transaction sequence -> pending refresh -> history -> cross-surface handoff

Most requirements are not "add a protocol" only. They are route, data, operation, pending, and platform integration requirements.

Scenario Router

Classify the change first:

Existing Earn protocol or Earn detail/list behavior.
Existing Borrow protocol, market, reserve, or health-factor behavior.
New DeFi module that does not fit Earn/Borrow.
ABI-backed protocol operation where App builds contract calls from typed parameters.
Native/provider-backed operation where App delegates protocol details to a provider or chain-specific service.
Swap-assisted operation such as funding, wrap, repay-with-collateral, or Trade/Buy handoff.
Regression/review of routing, pending refresh, history, or platform layout.

If the scenario is unclear, map its operation contract before choosing UI structure.

Default Workflow

Read app-architecture.md to place the feature in the App flow.
Use code-map.md to find stable anchors.
Define the operation contract in operation-flow.md: operation type, parameters, setup tx, business tx, status, risk, and refresh.
Define route, state, pending, and platform ownership in state-and-routing.md.
Run checklists.md, including ABI/native readiness drills when adding a protocol integration.
Validate on the route and platform that own the behavior.

Reference Map

Need	Reference
Understand Earn/Borrow/Staking flow	app-architecture.md
Find current repo anchors	code-map.md
Define operation and transaction contracts	operation-flow.md
Route, state, pending, history, and platform ownership	state-and-routing.md
Prevent common integration failures	checklists.md

Readiness Drills

Use these drills to judge whether the skill can guide fast protocol integration:

ABI-backed protocol: can you identify network/account, contract address, read params, write params, approval/permit needs, tx labels, pending tags, refresh scope, and history semantics without a one-off template?
Native/provider-backed protocol: can you identify provider capability, native token handling, setup/business sequence, unsupported states, account derive requirements, and completion polling?
New L2/protocol module: can you decide whether it belongs under Earn/Borrow, a new DeFi surface, a Discovery-hosted flow, or a Trade handoff based on operation semantics?

If a drill cannot be completed from the references, improve the abstraction before implementing.

Hard Stops

Do not place native Earn routes as if they are desktop/web Earn tabs; native hosts Earn under Discovery.
Do not add a protocol until route params, provider identity, operation contract, pending tags, and refresh scope are named.
Do not mix setup tx, approval, wrap, quote, and business tx into one opaque action.
Do not rely on optional fields to avoid defining pending/history identity.
Do not call native crash or freeze bugs fixed from state reasoning alone; capture the Android/iOS log, Sentry event, or JS/native boundary that proves the failing operation path.
Do not hand-edit generated locale files; use /1k-i18n.
Do not broaden shared Staking/Borrow utilities without existing-protocol regression reasoning.

Related Skills

/1k-i18n for translation keys and generated locale workflow.
/1k-coding-patterns for React and TypeScript patterns.
/1k-state-management for Jotai and state ownership.
/1k-cross-platform for platform-specific routing and layout.
/1k-trade-swap-market for Swap-assisted funding or repay flows.