feat(hire): add hire service#1276
Conversation
|
|
📝 WalkthroughWalkthroughAdds the Feishu/Lark "hire" service: registers service metadata and README entry, embeds and merges builtin registry JSON during init, and includes full CLI skill documentation and a recruitment-pipeline reference. ChangesHire Service Integration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
internal/registry/meta_data_default.json (1)
89-89: 💤 Low valueEight methods have placeholder
"-"descriptions.The following methods use
"-"instead of descriptive text:application.get-detail,application.recover,job.get-detail,job.recruiter,offer.offer-status,talent.onboard-status,talent.remove-to-folder, andtalent.tag. This reduces discoverability for users reading schemas or help output.Consider updating these descriptions with user-friendly summaries when upstream API documentation becomes available.
Also applies to: 264-264, 575-575, 708-708, 936-936, 1178-1178, 1201-1201, 1215-1215
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/registry/meta_data_default.json` at line 89, Several methods in meta_data_default.json use a placeholder description "-" which harms discoverability; update the "description" fields for the listed methods (application.get-detail, application.recover, job.get-detail, job.recruiter, offer.offer-status, talent.onboard-status, talent.remove-to-folder, talent.tag) to concise, user-friendly summaries that explain each endpoint's purpose and main behavior (e.g., "Retrieve detailed information about an application by ID" for application.get-detail), and apply the same fixes at the other occurrences mentioned (lines noted in the review) so every method has a meaningful description string instead of "-".skills/lark-hire/SKILL.md (1)
27-33: 💤 Low valueConsider adding a language specifier to the fenced code block.
The ASCII diagram representing resource relationships doesn't specify a language. Adding
textafter the opening backticks would satisfy markdown linters and improve rendering consistency.📝 Proposed fix
-``` +```text Job (job_id) └── Application (application_id) ← talent + job ├── Talent (talent_id)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@skills/lark-hire/SKILL.md` around lines 27 - 33, The fenced ASCII diagram block should include a language specifier to satisfy markdown linters and improve rendering; update the opening backticks of the diagram that begins with "Job (job_id)" / "Application (application_id)" to use ```text so the block is marked as plain text (e.g., change ``` to ```text).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@internal/registry/meta_data_default.json`:
- Line 89: Several methods in meta_data_default.json use a placeholder
description "-" which harms discoverability; update the "description" fields for
the listed methods (application.get-detail, application.recover, job.get-detail,
job.recruiter, offer.offer-status, talent.onboard-status,
talent.remove-to-folder, talent.tag) to concise, user-friendly summaries that
explain each endpoint's purpose and main behavior (e.g., "Retrieve detailed
information about an application by ID" for application.get-detail), and apply
the same fixes at the other occurrences mentioned (lines noted in the review) so
every method has a meaningful description string instead of "-".
In `@skills/lark-hire/SKILL.md`:
- Around line 27-33: The fenced ASCII diagram block should include a language
specifier to satisfy markdown linters and improve rendering; update the opening
backticks of the diagram that begins with "Job (job_id)" / "Application
(application_id)" to use ```text so the block is marked as plain text (e.g.,
change ``` to ```text).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 14ee103f-f9ea-41d9-9ee4-f1198535568b
📒 Files selected for processing (5)
README.mdinternal/registry/meta_data_default.jsoninternal/registry/service_descriptions.jsonskills/lark-hire/SKILL.mdskills/lark-hire/references/recruitment-pipeline.md
There was a problem hiding this comment.
🧹 Nitpick comments (1)
skills/lark-hire/SKILL.md (1)
27-33: ⚡ Quick winAdd a language tag to the relationship diagram code fence.
This fence is missing a language identifier (MD040). Using
textkeeps docs lint-clean and improves rendering consistency.Proposed patch
-``` +```text Job (job_id) └── Application (application_id) ← talent + job ├── Talent (talent_id) ├── Stage 招聘阶段 └── Offer (offer_id)</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@skills/lark-hire/SKILL.mdaround lines 27 - 33, The fenced code block
containing the ASCII relationship diagram in SKILL.md (the triple-backtick block
that starts with "Job (job_id)" and contains "Application (application_id) ←
talent + job") is missing a language tag; update the opening fence from ``` to
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@skills/lark-hire/SKILL.md`:
- Around line 27-33: The fenced code block containing the ASCII relationship
diagram in SKILL.md (the triple-backtick block that starts with "Job (job_id)"
and contains "Application (application_id) ← talent + job") is missing a
language tag; update the opening fence from ``` to ```text so the block is
lint-compliant (MD040) and renders consistently.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 76e228ba-1727-4f8f-a15d-01156c43387c
📒 Files selected for processing (7)
README.mdinternal/registry/loader.gointernal/registry/loader_embedded.gointernal/registry/meta_data_builtin.jsoninternal/registry/service_descriptions.jsonskills/lark-hire/SKILL.mdskills/lark-hire/references/recruitment-pipeline.md
✅ Files skipped from review due to trivial changes (3)
- skills/lark-hire/references/recruitment-pipeline.md
- README.md
- internal/registry/service_descriptions.json
Embed meta_data_builtin.json and always merge its services into the registry (loadBuiltinIntoMerged), after the remote overlay. This is the channel for services the remote api_definition endpoint does not serve. Starts empty; meta_data_default.json (the fallback) is untouched.
parseEmbeddedServices also parses meta_data_builtin.json, so the schema command and other embedded-spec consumers (which bypass the remote overlay for deterministic output) can see built-in services such as hire.
kirklin
changed the title
There was a problem hiding this comment.
🧹 Nitpick comments (1)
skills/lark-hire/SKILL.md (1)
55-62: ⚡ Quick winDocument the
--yesconfirmation requirement for high-risk-write operations.Line 57 mentions both
writeandhigh-risk-writerisk levels but only documents the--dry-runworkflow. Operations marked ashigh-risk-writerequire an explicit--yesflag to execute (not just removing--dry-run). Consider adding a note explaining this distinction so users understand the confirmation gate before encountering theconfirmation_requirederror.📝 Suggested addition
After line 57, add:
高风险操作（`high-risk-write`）需额外传 `--yes` 确认： ```bash lark-cli hire <resource> <method> --data `@data.json` --dry-run lark-cli hire <resource> <method> --data `@data.json` --yes # high-risk-write 必须</details> Based on the confirmation gate shown in internal/schema/assembler.go and internal/cmdutil/confirm.go. <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@skills/lark-hire/SKILL.mdaround lines 55 - 62, Add a note after the
"写/删除接口" paragraph clarifying that operations labeled "high-risk-write" require
an explicit --yes flag (not just removing --dry-run) to execute; update the
example to show the two-step flow (first with --dry-run, then with --yes) and
mention the potential confirmation_required error; reference the risk label
"high-risk-write", the CLI flags "--dry-run" and "--yes", and the internal
confirmation logic (confirmation_required in internal/schema/assembler.go and
internal/cmdutil/confirm.go) so readers understand the extra confirmation gate.</details> </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.Nitpick comments:
In@skills/lark-hire/SKILL.md:
- Around line 55-62: Add a note after the "写/删除接口" paragraph clarifying that
operations labeled "high-risk-write" require an explicit --yes flag (not just
removing --dry-run) to execute; update the example to show the two-step flow
(first with --dry-run, then with --yes) and mention the potential
confirmation_required error; reference the risk label "high-risk-write", the CLI
flags "--dry-run" and "--yes", and the internal confirmation logic
(confirmation_required in internal/schema/assembler.go and
internal/cmdutil/confirm.go) so readers understand the extra confirmation gate.</details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: defaults **Review profile**: CHILL **Plan**: Pro **Run ID**: `4077017a-33a4-4ee4-9ae6-07c42b3d33d8` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between b7bb8c3c82dc64574bb51dfd94755c0921bd6388 and d833bb2642bf1c282805d6c111f9416210ba68a0. </details> <details> <summary>📒 Files selected for processing (7)</summary> * `README.md` * `internal/registry/loader.go` * `internal/registry/loader_embedded.go` * `internal/registry/meta_data_builtin.json` * `internal/registry/service_descriptions.json` * `skills/lark-hire/SKILL.md` * `skills/lark-hire/references/recruitment-pipeline.md` </details> <details> <summary>✅ Files skipped from review due to trivial changes (2)</summary> * README.md * skills/lark-hire/references/recruitment-pipeline.md </details> <details> <summary>🚧 Files skipped from review as they are similar to previous changes (2)</summary> * internal/registry/loader_embedded.go * internal/registry/loader.go </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
2 participants
Summary
Adds the Hire (招聘 / recruitment) business domain to lark-cli — the full surface: jobs, talents, applications, offers, interviews, onboarding, referrals, agencies, websites and ecosystem integrations (background-check / exam). It is wired through the existing metadata-driven service architecture (no per-endpoint Go code), so
lark-cli hire <resource> <command>runs through the same machinery as every other service.Changes
internal/registry/meta_data_builtin.json: all 77 resources / 180 methods (v1 + v2) in the standard meta format (path,httpMethod,parameters,scopes,risk,accessTokens,docUrl,parameterOrder).servicePathis/open-apis/hireand each method path carries its version prefix (v1/.../v2/...), so both API versions resolve under one service. 174/180 methods carry their required scopes (any-of, extracted from the official docs), so the CLI's scope pre-check works for hire.internal/registryembedsmeta_data_builtin.jsonand always merges it (loadBuiltinIntoMerged) after the remote overlay; it is also included in the embedded-spec map so theschemacommand and scope pre-check see hire. It leavesmeta_data_default.json(the empty fallback) untouched and does not affect the remote-synced services or first-run sync-fetch.hireinservice_descriptions.json.skills/lark-hire/(SKILL.md+references/), referencinglark-shared.Being pure metadata,
hireinherits the full pipeline:--params/--data,--as user|bot, scope pre-check, risk gating, pagination (--page-all),--jq,--format,--dry-run, andlark-cli schema hire.<resource>.<method>.Test Plan
go build ./...succeeds.internal/registry,internal/schemaandcmd/servicetests pass with the standard meta present (the CI condition); the built-in hire merge does not regress them (meta_data_default.jsonis untouched, soTestCacheHit_WithinTTLstays green).open.feishu.cn:lark-cli hire --helplists all 77 resources;lark-cli hire talent --helpshows v1 + v2 methods (get,get_v2, …).lark-cli schema hire.job.listresolves parameters and scopes (hire:job:readonly);lark-cli schema hire.role.listshowshire:authscopes.lark-cli hire job list --params '{"page_size":"3"}' --jq '.data.items[] | {id, title}'returns live data.lark-cli hire talent get_v2 --params '{"talent_id":"…"}'returnscode: 0, confirming/open-apis/hire/v2/...assembly.LARKSUITE_CLI_REMOTE_META=off(built-in only).Related Issues
Notes
larksuite/oapi-sdk-gohire service and the official docs; regenerating refreshes them.requestBodyfield schemas (forschema-command display of write bodies). Request bodies are already callable via--data.Summary by CodeRabbit
New Features
Documentation
hirecommand guide with examples, usage patterns, parameter/body conventions, and safety notes for write operations.Chores