Token导航 LogoToken导航

Agent Skill · 开发

conscientiousness(conscientiousness 命令行)

conscientiousness 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

conscientiousness 是开发类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证信息还不明确,第三方扫描已通过,按安装量在开发类的 21,746 个 Skill 里排第 17,122。

总安装 441周安装 18GitHub Stars 12下载 141核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:conscientiousness(conscientiousness 命令行)
来源仓库:https://github.com/pjt222/development-guides
仓库路径:skills/conscientiousness
安装命令:
npx skills add https://github.com/pjt222/development-guides --skill conscientiousness
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/pjt222/development-guides --skill conscientiousness

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

conscientiousness 强调系统性严谨性和任务完成后的验证机制,确保交付成果完整且符合标准。适用于复杂多步骤操作后的复核、代码提交前的最终检查以及文档发布的质量保障环节。通过 GitHub 安装并使用 npx skills add 命令添加,具体行为依赖预设的系统提示和规则引擎。

使用前应确认其是否会触发文件读写或外部调用,并评估对当前工作流的潜在影响。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/conscientiousness

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/pjt222/development-guides --skill conscientiou…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

conscientiousness 怎么安装?

在终端执行 npx skills add https://github.com/pjt222/development-guides --skill conscientiousness。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

conscientiousness 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

conscientiousness 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

conscientiousness 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

conscientiousness 用的人多吗?

公开数据是累计安装 441 次,近一周安装 18 次,下载 141 次,GitHub 12 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

conscientiousness 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
conscientiousness

conscientiousness 命令行 · 本页

44112只读未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Conscientiousness

Systematic thoroughness and diligence — ensuring completeness, verifying results, following through on every commitment, and finishing tasks to the standard they deserve.

When to Use

  • Before marking a task as complete — as a final verification pass
  • When a response feels "good enough" but the task deserves better
  • After a complex multi-step operation where individual steps may have drifted
  • When the user's request has multiple parts and each part needs verification
  • Before submitting code, documentation, or any deliverable for user review
  • When self-monitoring detects a pattern of cutting corners or rushing

Inputs

  • Required: The task or deliverable to verify (available from conversation context)
  • Optional: The original user request (for comparison against what was delivered)
  • Optional: Any checklist or acceptance criteria provided by the user
  • Optional: Prior commitments made during the session (things promised but not yet checked)

Procedure

Step 1: Reconstruct the Full Commitment

Before checking work, re-establish exactly what was committed to.

  1. Re-read the user's original request carefully — not the interpreted version, the actual words
  2. List every explicit requirement mentioned
  3. List every implicit commitment made during the session:

- "I'll also update the tests" — was this done? - "Let me fix that too" — was this completed? - "I'll check for edge cases" — were they checked?

  1. Note any acceptance criteria the user provided
  2. Compare the commitment list against what was actually delivered

Expected: A complete list of commitments — explicit requirements plus implicit promises — with a preliminary match against deliverables.

On failure: If the original request is no longer in context (compressed), reconstruct from what remains and acknowledge any gaps to the user.

Step 2: Verify Completeness

Check that every committed item was addressed.

Completeness Matrix:
+---------------------+------------------+------------------+
| Commitment          | Status           | Evidence         |
+---------------------+------------------+------------------+
| [Requirement 1]     | Done / Partial / | [How verified]   |
|                     | Missing          |                  |
+---------------------+------------------+------------------+
| [Requirement 2]     | Done / Partial / | [How verified]   |
|                     | Missing          |                  |
+---------------------+------------------+------------------+
| [Promise 1]         | Done / Partial / | [How verified]   |
|                     | Missing          |                  |
+---------------------+------------------+------------------+
  1. For each item, verify with evidence — not memory, actual verification:

- Code changes: re-read the file to confirm the change exists - Test results: re-run or reference the actual output - Documentation: re-read to confirm accuracy

  1. Mark each item: Done (fully complete), Partial (started but incomplete), Missing (not addressed)
  2. For Partial and Missing items, note what remains

Expected: Every commitment has a verified status. No item is left unchecked.

On failure: If verification reveals missed items, address them immediately rather than noting them for later. Conscientiousness means completing now, not intending to complete.

Step 3: Verify Correctness

Completeness is necessary but not sufficient — what was done must also be right.

  1. For each completed item, check:

- Accuracy: Does it do what it should? Are values correct? - Consistency: Does it align with the rest of the work? No contradictions? - Edge cases: Were boundary conditions considered? - Integration: Does it work with the surrounding context?

  1. For code: would this survive a code review? Are there obvious improvements?
  2. For documentation: is it accurate, clear, and free of errors?
  3. For multi-step processes: does the output of each step correctly feed the next?

Expected: Each deliverable is both complete and correct. Errors are caught before the user sees them.

On failure: If errors are found, fix them immediately. Do not present work with known errors, even if the errors seem minor.

Step 4: Verify Presentation

The final check: is the deliverable presented in a way that serves the user?

  1. Clarity: Can the user understand what was done without re-reading multiple times?
  2. Organization: Is the response structured logically? Are related items grouped?
  3. Conciseness: Is there unnecessary padding or repetition?
  4. Actionability: Does the user know what to do next?
  5. Honesty: Are limitations or caveats clearly stated?

Expected: A deliverable that is complete, correct, and well-presented.

On failure: If presentation is poor despite correct content, restructure. Good work poorly presented is a conscientiousness failure.

Validation

  • The original request was re-read (not recalled from memory)
  • Every explicit requirement was verified with evidence
  • Every implicit promise was tracked and verified
  • Correctness was checked beyond mere completeness
  • Edge cases were considered where relevant
  • The deliverable is clearly presented and actionable

Common Pitfalls

  • Verification theater: Going through the motions of checking without actually re-reading or re-verifying. The check must use evidence, not memory
  • Partial conscientiousness: Checking the main deliverable but ignoring side commitments ("I'll also..."). Every promise counts
  • Perfectionism masquerading as diligence: Endless polishing that delays delivery. Conscientiousness is about meeting the committed standard, not exceeding it indefinitely
  • Conscientiousness fatigue: Becoming less thorough as the session progresses. The last task deserves the same diligence as the first
  • Skipping for simple tasks: Assuming simple tasks don't need verification. Simple tasks with errors are more embarrassing than complex tasks with errors

Related Skills

  • honesty-humility — conscientiousness verifies completeness; honesty-humility ensures transparent reporting of what was and was not achieved
  • heal — subsystem assessment overlaps with self-verification; conscientiousness focuses on deliverable quality
  • vishnu-bhaga — preservation of working state complements conscientiousness in maintaining quality
  • observe — sustained neutral observation supports the verification process
  • intrinsic — genuine engagement (not compliance) drives thorough execution naturally

平台分布

Codex

35.18%
按下载量换算50

Claude

27.4%
按下载量换算39

Cursor

18.89%
按下载量换算27

Gemini CLI

8.91%
按下载量换算13

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills