SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Use when the user asks to turn a vague task into a Codex `/goal` command, Goal 指令, 目标指令, 中文 Goal 模板, or plan-to-goal interview. Do not load for ordinary project planning, code review, test execution, translation, simple rewrites, or generic success-criteria discussion unless the user wants an executable `/goal`.
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
Original instructions from the publisher’s SKILL.md
# Codex Goalsmith 把一个模糊任务,收敛成 Codex 可以持续执行、可以验证、知道何时停止和何时暂停的 `/goal` 指令。 Copyright (c) 向阳乔木 X: https://x.com/vista8 GitHub: https://github.com/joeseesun/ ## Operating Mode Run as a production-lite meta skill. Default assumptions: - The user wants a paste-ready Codex `/goal` command, not a general prompt. - The executable slash command stays `/goal`. Do not output `/目标` as the command unless the user's environment explicitly documents that alias. - The first goal block should be the best recommended executable version, not a half-filled template. Users often copy the first draft directly. - For Chinese users, output Chinese content and Chinese field names by default while keeping the command prefix `/goal`. - For Chinese users, include both `推荐执行版(中文,可直接复制)` and `Goal Draft (English-compatible)` unless the user asks for one language only. - If the task is still vague but low-risk, choose the best conservative defaults and continue. Ask only when the answer changes cost, risk, ownership, or product direction. - If the domain is unfamiliar or specialized, create a discovery-first goal that makes the agent inspect authoritative project/docs/runtime evidence before implementation instead of inventing domain rules. - If the missing detail is low-risk, make an explicit assumption and continue. - Do not start the work described by the goal unless the user explicitly asks. This skill creates the goal instruction. - Prefer concrete verification commands and artifacts over vague confidence phrases. - Prefer narrow write boundaries and explicit forbidden paths over broad permission. - Treat `Stop when` and `Pause if` as part of the same completion/blocking contract. ## Workflow 1. Restate the task as an outcome, not an activity. 2. Classify the task using `references/default-goal-strategy.md`: familiar vs unknown domain, low vs high risk, new work vs existing project. 3. Choose best defaults for low-risk unknowns and write a one-sentence reason. 4. Identify missing information across the Goal contract: - success criteria - verification commands, artifacts, or evidence - constraints that must not change - allowed writes and forbidden paths - iteration policy - completion evidence - blocked stop conditions, human decisions, or budget caps 5. If the task is under-specified but low-risk, choose conservative defaults using `references/default-goal-strategy.md` and continue without an interview. 6. Use `references/interview-checklist.md` only when the user explicitly asks for an interview, says not to draft yet, or when missing information materially changes cost, risk, ownership, product direction, verification, or allowed writes. 7. For Chinese-first users, produce the Chinese recommended execution goal first, then an English-compatible mirror that preserves the same meaning and keeps English field labels. 8. Check the command against `references/goal-command-playbook.md`. 9. For file deliverables, run `python3 scripts/lint_goal_command.py <file>` before calling the goal done. ## Output Contract When enough information is known, output the best recommended command first. Do not leave placeholders in real output. ```text /goal Create a first-version local MVP for the requested task, inspect project-provided commands before changing code, implement the core user-visible workflow, and keep unrelated systems unchanged. Verification: run the smallest project-provided checks, start the local app or relevant runtime, complete the core workflow once, and capture logs/screenshots or command output as evidence. Constraints: do not add accounts, paid services, production changes, destructive operations, or unrelated features unless requested. Boundaries: write only inside the new project directory or the directly related existing project files. Iteration policy: implement one focused workflow at a time, rerun checks after meaningful changes, inspect logs before retrying, and make at most 3 focused improvement rounds before reporting remaining risks. Stop when: the core workflow is proven by runtime evidence and checks pass or missing checks are explicitly reported. Pause if: credentials, payments, production data, destructive changes, legal/medical/financial decisions, copyrighted assets, or unclear ownership is required. ``` For Chinese-first users, prefer this equivalent shape: ```text /goal 基于用户需求创建第一版本地 MVP,先读取项目已有命令和约束,实现核心用户可见流程,并避免改动无关系统。 验证:运行项目提供的最小相关检查,启动本地应用或对应运行环境,完整走通一次核心流程,并用日志、截图或命令输出作为证据。 约束:不加入账号、付费服务、生产变更、破坏性操作或无关功能,除非用户明确要求。 边界:只写入新项目目录,或只修改现有项目中与该功能直接相关的文件。 迭代策略:一次实现一个聚焦工作流,每次有意义改动后重跑检查,重试前先读日志,最多做 3 轮聚焦改进后报告剩余风险。 完成条件:核心流程有运行证据证明可用,检查通过或明确说明缺少配置。 暂停条件:需要凭证、付费、生产数据、破坏性操作、法律/医疗/金融判断、版权素材或所有权不清时暂停。 ``` When the task is vague, output: 1. `推荐执行版(中文,可直接复制)`: the best default `/goal`. 2. `默认选择理由`: one concise sentence. 3. `可选调整`: numbered choices with recommended defaults and short option labels. 4. `你可以直接回复`: an example such as `按默认` or `1B 2A 3C`. 5. `Goal Draft (English-compatible)`: a faithful English-compatible mirror with English field labels. If the user writes in English, output only the English-compatible draft unless they ask for Chinese too. Do not output long generic coaching unless the user asks for explanation. ## Quality Bar A strong goal: - has one concrete outcome - names exact checks or evidence - protects unrelated files, user data, secrets, and default branches - defines the write boundary - tells the agent how to iterate after failures - says when to stop because completion is proven - says when to pause because a human decision, credential, account state, budget, or repeated blocker is required Reject or revise a goal that: - says only `make it better`, `finish this`, or `fix bugs` - lacks verification - lets the agent edit the whole machine or repo without reason - asks for repeated retries without a new source of evidence - has no pause condition for external auth, secrets, payments, destructive actions, or ambiguous product decisions - leaves placeholders such as `[Outcome]` in user-facing executable drafts - treats vague words such as `高级`, `有质感`, or `professional` as verification instead of translating them into screenshots, runtime checks, review criteria, or iteration rules ## Reference Files - `references/goal-command-playbook.md`: the core `/goal` template, when to use it, examples, and anti-patterns. - `references/default-goal-strategy.md`: lazy-user defaults, unknown-domain discovery, risk classification, and direct-copy output rules. - `references/interview-checklist.md`: question bank for turning vague tasks into strong goals. - `scripts/lint_goal_command.py`: lightweight checker for required `/goal` labels and unresolved placeholders. - `scripts/validate_evals.py`: lightweight schema and coverage checker for `evals/evals.json`. - `evals/evals.json`: routing, progressive-loading, and end-to-end regression cases for the skill.