Token导航 LogoToken导航TokenDH.com
开发只读github未标认证来源可访问许可证需确认审计通过

conscientiousnessconscientiousness 命令行

Agent Skill

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

总安装

441

周安装

18

GitHub Stars

12

下载量

141
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

简介

conscientiousness 强调系统性严谨性和任务完成后的验证机制,确保交付成果完整且符合标准。

  • 适用于复杂多步骤操作后的复核、代码提交前的最终检查以及文档发布的质量保障环节。
  • 通过 GitHub 安装并使用 npx skills add 命令添加,具体行为依赖预设的系统提示和规则引擎。
  • 使用前应确认其是否会触发文件读写或外部调用,并评估对当前工作流的潜在影响。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

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

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

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