Skill purpose
Organize scattered work ideas, directions given by leadership, or existing practices into objectives and initiatives that can be directly entered into an OKR system. The output must satisfy SMART and PDCA, while also retaining specific work content, using the person's own perspective, and avoiding writing explanatory materials, slogans, or demands on others.
Applicable trigger words include: OKR, quarterly objectives, initiatives, SMART, PDCA, personal behavior, objective names, leadership reporting language, polishing initiatives.
Core principles
1. Objectives must be verifiable
An objective is not a directional label. The objective sentence must contain at least the following information:
- Time range: for example Q3, before the end of September.
- Work object: for example AI code review, end-to-end PRD generation, cross-session memory.
- Application scope: for example no fewer than 3 requirements, actual development commits, a specified business domain.
- Verifiable result: for example accuracy, reuse rate, quantity, number of completed rounds, or deliverable.
Prefer the following sentence patterns:
Q3 在 [范围] 中完成 [具体动作]，形成/达到 [可衡量结果]，并在 [时间点] 前完成 [交付物或复盘]。
When there is no reliable historical data, do not fabricate comparative metrics such as "improve by 20%"; instead use coverage quantity, number of valid materials, number of pilots, number of retrospectives, or number of deliverables.
2. Initiatives must be "things I can do myself"
Initiatives start with "I will" or "I will" and clearly state the actions I will take, how to do them, and what evidence to leave. Do not write initiatives as instructions to the team, an introduction to a system, or a description of what others should do.
Each initiative is recommended to use 1 natural paragraph, controlled at 120 to 220 Chinese characters. Retain enough business detail so readers can see the work is not empty talk.
Recommended structure:
我会先/持续 [本人动作]，针对 [场景或已有问题] 采用 [具体做法]，
并记录/交付 [可检查证据]；在 [时间或节奏] 根据 [反馈或数据] 调整，
以支撑 [目标中的结果]。
3. Use PDCA to organize 4 initiatives, but there is no need to write the abbreviation into the body text
Naturally organize the 4 initiatives into a closed loop:
- P, identify the problem accurately: take stock of existing practices, baselines, rejection reasons, or applicable scope.
- D, real implementation: complete pilots in real requirements, code commits, or platform features.
- C, check results: record adoption status, problem types, review feedback, test evidence, or metric changes.
- A, continuously solidify: optimize weekly or biweekly, and distill effective experience into rules, Skills, Agents, templates, user preferences, or project knowledge.
If the user has already completed part of the work, write "continue improving" starting from existing results, and do not write Q3 as building from zero.
4. Preserve "human-like" expression
Short anthropomorphic subheadings can be used to aid reading, such as "first lay a solid foundation," "hold the quality bottom line," "prove results with data," but the subheading must be followed by specific actions and facts.
Use natural, professional Chinese:
- Good:
我会把 Q2 被拒绝的问题按误报、上下文不足和规则不适用分类，再据此调整审查记忆。 - Bad:
构建全链路智能化质量赋能体系，全面提升协同效能。 - Good:
写完不验证不算完成，我会保留构建、测试和评审结果。 - Bad:
要求团队严格执行五道门禁。
Avoid too many four-character slogans, stacked concepts, and words such as "empower, lever, closed loop, full chain." When these words need to be used, they must be immediately followed by actual actions or results.
Workflow
Step 1: Extract facts
Identify and list from the user's description:
- The practices currently completed, and whether this quarter is a new build or continued optimization.
- The direction given by leadership, known platform capabilities, and capability boundaries that cannot be speculated about.
- Quantifiable metrics, time milestones, pilot scope, and known data baselines.
- Final use: system entry, leadership reporting, personal work plan, or team reuse.
When key definitions are missing, replace fabricated improvement percentages with safe, verifiable quantitative results, and provide one item to be confirmed when necessary.
Step 2: Give the objective first, then the initiatives
Default output order:
- Objective name/objective description: a complete SMART sentence that can be directly entered into the system.
- 4 initiatives: each is 1 natural paragraph, in first person, progressing according to P-D-C-A.
- Optional definition notes: only when the calculation method for accuracy rate, reuse rate, etc. may be ambiguous, define it in one or two sentences without expanding into a lecture.
If the user only wants the "objective name", output only one SMART objective sentence and one conservative alternative for when there is no baseline, without expanding into initiatives.
Step 3: Supplement substantive content according to task type
AI code review
- Using the existing Q2 results as input, first take stock of adopted/rejected issues and their reasons.
- Connect verified rules, historical defects, and business constraints to Memory; use CodeGraph to supplement the call chain and dependency context.
- In real commits, record the adoption, rejection, type, and handling result of each issue.
- Review rejected issues and reasons weekly, and adjust prompts, rules, Memory, or CodeGraph scope every two weeks.
- "Accuracy rate" is defined by default as: the number of issues adopted or confirmed as needing repair/included in the repair plan ÷ the total number of issues raised by AI.
AI image generation and end-to-end PRD generation
- First confirm the input, output, image-text mounting method, and boundaries of the end-to-end platform; do not assume that the platform already has a certain capability.
- Organize the processes, roles, page states, and exception rules in the PRD into structured input with consistent text and images.
- Complete the verification of "diagram generation - platform generation - review - PRD write-back" in a real PRD.
- Record generation deviations and feedback, and consolidate prompts, image-text templates, and reusable operation guidelines.
Cross-session memory
- At the end of a session, consolidate only experience confirmed by requirements, verified by code, or supported by testing.
- Classify as project rules, business knowledge, user preferences, debugging experience, review rules, or Skill/Agent candidates.
- In the next session, retrieve relevant memories by project, module, and trigger conditions, and do not stuff all historical information into the context.
- For experience that recurs and has been verified as effective multiple times, upgrade it to formal rules, Skills, Agents, review rules, or user preferences after manual confirmation.
Output template
## 目标 [序号]：[一句完整 SMART 目标]
**举措 1：[自然的小标题]**
我会……
**举措 2：[自然的小标题]**
我会……
**举措 3：[自然的小标题]**
我会……
**举措 4：[自然的小标题]**
我会……
Self-check before delivery
- The objective states time, scope, results, and at least one verifiable definition.
- Each initiative is an action that you can directly execute yourself, and has not turned into "require the team" or "the platform must".
- The content is based on the existing practices given by the user, and has not written "continue improving" as "build from scratch".
- The 4 initiatives can form a closed loop from problem identification, implementation, inspection, to iterative consolidation.
- The terminology, platform capabilities, and metric definitions were not fabricated out of thin air.
- The language can be given directly to leadership or entered into the system, unlike an explanatory draft that describes the writing approach to readers.