[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FVCEYH0977HGPTCZTQ86P":3,"skill-same:01M71FVCEYH0977HGPTCZTQ86P":62},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":14,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":46,"updatedAt":47,"install":48,"resources":61},"01M71FVCEYH0977HGPTCZTQ86P","agent-prompt-standards",null,"Agent prompt writing conventions enforced across all creator and auditor skills. Loaded by other skills, not invoked directly.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fagent-prompt-standards\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33],"standards","agent prompt standards","prompt","conventions","writing","false","creator","auditor","read","across","2026-11-10 10:12:30",false,"---\nname: agent-prompt-standards\nuser-invocable: false\ndescription: >-\n  Agent prompt writing conventions enforced across all creator and auditor skills. Loaded by other skills, not invoked directly.\nallowed-tools: Read\n---\n\n\u003Cobjective>\nThe agent-prompt writing conventions and their rule catalog — voice, objective shape, description wording, constraint language, anti-patterns, conciseness, and failure-mode writing — for the text within SKILL.md files and {{! term('configured_agent') !}} {{! term('configured_agent_prompts') !}}.\n\u003C\u002Fobjective>\n\n\u003Creference_note>\nThis is a reference skill governing prompt *craft* — how to write the text. Prompt *structure* — which XML tags, file organization, and frontmatter — belongs to `\u002Fskill-standards` for a skill and to `\u002Fsubagent-standards` for a {{! term('configured_agent') !}} definition. It carries no standalone workflow.\n\u003C\u002Freference_note>\n\n\u003Cvoice>\n\n**How to refer to the executing Claude instance in prompt bodies.**\n\nTwo-tier hierarchy:\n\n1. **Imperative mood (default)** — drop the subject when giving instructions:\n   - \"Reflect deeply on what was learned before persisting anything\"\n   - \"Read the spec file before proposing changes\"\n\n2. **\"Claude\" (for failure modes, tendencies, and behavioral claims)** — use when naming what Claude does, tends to do, or fails to do:\n   - \"Without reflection, Claude will dump a narrative instead of making durable decisions\"\n   - \"Claude loses track of coverage state after 30+ turns\"\n\n**Banned subjects:**\n\n| Subject     | Problem                                                                                                          |\n| ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| \"the agent\" | Anthropic's own skills use \"Claude\" exclusively; \"the agent\" appears zero times across 18 shipped SKILL.md files |\n| \"the model\" | Too generic, distances Claude from its own identity                                                              |\n| \"you\"       | Ambiguous — could address Claude or the user                                                                     |\n\n**YAML frontmatter exception:** The `name` and `description` fields cannot contain the word \"claude\" per validation rules. Omit any subject in descriptions and word them per `\u003Cdescription_style>`.\n\n\u003C\u002Fvoice>\n\n\u003Cobjective_shape>\n\n**An `\u003Cobjective>` states the skill's output, not an activity or an actor.** It describes the observable artifact or state the skill produces, in a definite shape — what is true when the skill has been applied correctly, such that \"every rule followed exactly\" is the visible proof. It never opens with an actor (\"The skill produces…\", \"Claude produces…\") or a bare activity verb (\"Audit…\", \"Generate…\", \"Evaluate…\"). It names the output and its required shape.\n\n**One sentence — it is the output target, not a summary of the skill.** Write one sentence; reach for a second only when the output has two distinct parts. A paragraph-length objective is the smell that activation, workflow, or constraints have leaked in. The litmus: every clause must name a property of the *output*. A clause that says *when* the skill runs belongs in `description`; *how* it runs (steps, gates, orchestration) belongs in `\u003Cworkflow>`; *what it must not do* belongs in `\u003Cconstraints>`. Delete such clauses from the objective — they are not new truth to relocate, they already live in those sections. `\u002Fmanage-github-pr`'s output is \"the changeset merged into the default branch on origin through a pull request,\" not the paragraph that narrates how it gets there.\n\n**Common shapes by skill family** — name the output, never the activity:\n\n- **Auditor** → \"A verdict on X — <the finding categories>\" (the canonical auditor shape; see `\u002Fskill-standards` `references\u002Fauditor-skeleton.md`).\n- **Coder \u002F builder** → \"The <artifact> that <holds the property>\" — e.g. \"Python implementation code that makes its node's tests pass.\"\n- **Reference \u002F standards** → \"The <standards or vocabulary> <scope>\" — e.g. \"The Python-specific test standards every Python skill enforces.\"\n- **Router** → \"A <request> routed to its matching workflow\" — the routing outcome, not the menu.\n- **Orchestrator** → the end-state its lifecycle produces — e.g. \"the changeset merged to the default branch on origin,\" not the step sequence.\n\n**An objective is not a behavioral claim.** `\u003Cvoice>` governs behavioral claims — what Claude does, tends to do, or fails to do. An objective is an output statement, a different category, so the imperative-vs-\"Claude\" subject choice never applies to it. Naming an actor as the subject of an objective is the error the output framing removes.\n\nThis mirrors the methodology's output \u002F outcome \u002F impact distinction — assertions specify the **output**, and an objective names the skill's output the same way. `\u003Csuccess_criteria>` proves it: the objective names the output and its shape, `\u003Csuccess_criteria>` states the properties that make it sound, and the two never duplicate.\n\n\u003C\u002Fobjective_shape>\n\n\u003Cdescription_style>\n\n**The owning structure standard selects the style; this section governs the wording.** `\u002Fskill-standards` `\u003Cdescriptions>` selects directive or passive wording for a skill, and `\u002Fsubagent-standards` owns a {{! term('configured_agent') !}} definition's frontmatter, its description among it. The wording below applies to every description written in the directive style.\n\n**Directive descriptions for reliable activation.**\n\nResearch (Seleznov, 650 automated trials, Feb 2026) shows description wording has a 20x impact on activation odds:\n\n| Style         | Activation | Example                                         |\n| ------------- | ---------- | ----------------------------------------------- |\n| Passive       | ~77%       | `Docker expert for containerization. Use when…` |\n| Expanded      | ~93%       | `…or any Docker-related task`                   |\n| **Directive** | **~100%**  | `ALWAYS invoke… NEVER X without this skill`     |\n\n**Base template:**\n\n```yaml\ndescription: >-\n  ALWAYS invoke this skill when \u003Ctriggers>.\n```\n\n**NEVER constraint — add only when it disambiguates.** A NEVER line helps when:\n\n- The skill is the only one with that negative (e.g., `NEVER work on the Product Tree without loading context` — only contextualizing says this)\n- Claude has a strong built-in alternative the negative prevents (e.g., `NEVER run git commit without this skill` — Claude would otherwise run `git commit` directly)\n\nOmit NEVER when:\n\n- Multiple skills share the same negative\n- The ALWAYS trigger is already specific enough\n\n**Language-after-artifact** (matches user speech):\n\n```yaml\n# ✅ \"audit ADRs for Python\" — matches what users say\nALWAYS invoke this skill when auditing ADRs for Python.\n\n# ❌ \"audit Python ADRs\" — unnatural phrasing\nALWAYS invoke this skill when auditing Python ADRs.\n```\n\n**Match actual user speech:**\n\n- Abbreviations: \"ADRs\" not \"Architecture Decision Records\"\n- Natural terms: \"Python tests\" not \"python-unit-test-framework\"\n- Plain language: \"read all specs\" not \"hierarchical context ingestion protocol\"\n\n\u003C\u002Fdescription_style>\n\n\u003Cconstraint_language>\n\n**Strong modal verbs for constraints:**\n\n- `MUST` — required behavior, no exceptions\n- `NEVER` — prohibited behavior, no exceptions\n- `ALWAYS` — required in every case\n\n**Weak modals to avoid in constraint blocks:**\n\n- \"should\" — implies optional\n- \"try to\" — invites half-measures\n- \"consider\" — without a specific condition, this is noise\n- \"might want to\" — means nothing actionable\n\nWeak modals are fine in non-constraint contexts — recommendations, trade-off discussions, conditional guidance. The rule applies to constraint blocks (`\u003Cconstraints>`, hardened rules in workflows).\n\n**Pattern — constraint with rationale:**\n\n```text\nNEVER modify files during audit — audits are read-only by design.\nMUST read reference documentation before evaluating — prevents memory-based assessment.\n```\n\nThe rationale after the dash prevents blind rule-following and helps Claude judge edge cases.\n\n\u003C\u002Fconstraint_language>\n\n\u003Canti_patterns>\n\n**Banned phrases in prompt text:**\n\n| Pattern             | Problem                  | Fix                                                        |\n| ------------------- | ------------------------ | ---------------------------------------------------------- |\n| \"helpful assistant\" | Generic, zero signal     | State the specific domain and expertise                    |\n| \"helps with\"        | Vague                    | Name the concrete action                                   |\n| \"processes data\"    | Could mean anything      | Name the specific data and operation                       |\n| \"please\"            | Wastes tokens, no effect | Direct instruction                                         |\n| \"if possible\"       | Hedges the instruction   | State the instruction; add a fallback if the hedge is real |\n\n`\u003Cvoice>` governs the banned subjects, and `\u003Cconstraint_language>` governs the weak modals.\n\n**Structural anti-patterns:**\n\n- **Explaining Claude to Claude** — \"As an AI language model...\" wastes context. Claude knows what it is.\n- **Motivational prose** — \"This is a critical task that requires careful attention\" adds nothing. State the constraints.\n- **Repeating the skill name** — \"The author-skill skill is designed to...\" — Claude has the name from frontmatter.\n- **Empty disclaimers** — \"Results may vary\" — if there are real failure modes, document them concretely; if not, cut the disclaimer.\n\n\u003C\u002Fanti_patterns>\n\n\u003Cconciseness>\n\nThe context window is shared: a prompt competes for tokens with the {{! term('configured_agent_prompt') !}}, conversation history, other skills' metadata, and the user's request.\n\n**The test for every sentence in a prompt:**\n\n\"Does removing this reduce Claude's effectiveness at the task?\"\n\nIf no — cut it.\n\n**What Claude already knows (never include):**\n\n- General programming knowledge\n- Language syntax and standard library APIs\n- Common design patterns\n- How to use its own tools\n\n**What Claude needs (include):**\n\n- Product-specific conventions that contradict common patterns\n- Domain knowledge not in training data\n- Failure modes from actual usage (not hypotheticals)\n- Verification commands and thresholds\n\n**Concrete over abstract:**\n\n```text\n# ❌ Abstract\n\"Ensure coverage is maintained\"\n\n# ✅ Concrete\n\"Coverage delta must be ≤0.5%. Run: pnpm test --coverage | grep target.ts\"\n```\n\n**When to elaborate:** the concept is domain-specific (not general programming), the pattern is non-obvious or counterintuitive, or context affects behavior in subtle ways.\n\n\u003C\u002Fconciseness>\n\n\u003Cfailure_mode_writing>\n\nWrite failure modes from actual experience, not speculation.\n\n**Structure each failure mode:**\n\n1. **What happened** — concrete scenario with specifics\n2. **Why it failed** — root cause, not symptom\n3. **How to avoid** — actionable prevention\n\n**Use \"Claude\" as the subject** (failure modes are the primary case for named-subject voice):\n\n```text\n✅ Claude compared coverage per-story instead of per-file. Multiple stories share one\n   legacy file; per-story coverage is meaningless.\n\n❌ \"Compare coverage per-file, not per-story.\"\n   (States the rule but loses the WHY — the failure mode teaches the reason.)\n```\n\nNever invent failure modes. If a skill is new and hasn't failed yet, omit the section rather than fabricating scenarios. Add failure modes as they occur in real usage.\n\n\u003C\u002Ffailure_mode_writing>\n\n\u003Crule_catalog>\n\nEvery rule the sections above state carries exactly one row below, giving it one stable identifier and one severity and naming the section that states it. The stating section is authoritative for what the rule requires. Recommendations and patterns those sections offer without requiring them carry no row. The identifier, severity, finding-key, and closed-vocabulary rules for this catalog are the catalog contract `\u002Fskill-standards` states for every instructions rule catalog.\n\n| Identifier                       | Severity | Rule                                                                                                                               | Stated in                |\n| -------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------ |\n| `instruction_not_imperative`     | debt     | An instruction drops its subject and uses imperative mood.                                                                         | `\u003Cvoice>`                |\n| `behavioral_claim_subject`       | debt     | A behavioral claim, tendency, or failure mode names Claude as its subject.                                                         | `\u003Cvoice>`                |\n| `banned_subject`                 | debt     | Prompt text never uses \"the agent\", \"the model\", or \"you\" as a subject.                                                            | `\u003Cvoice>`                |\n| `description_subject`            | debt     | A frontmatter description names no subject.                                                                                        | `\u003Cvoice>`                |\n| `claude_in_frontmatter`          | blocking | The `name` and `description` fields never contain the word \"claude\".                                                               | `\u003Cvoice>`                |\n| `actor_or_activity_objective`    | blocking | An `\u003Cobjective>` names the output and its required shape, never opening with an actor or a bare activity verb.                     | `\u003Cobjective_shape>`      |\n| `objective_non_output_clause`    | debt     | An `\u003Cobjective>` is one sentence, two only for an output with two distinct parts, and every clause names a property of the output. | `\u003Cobjective_shape>`      |\n| `objective_criteria_duplication` | debt     | `\u003Cobjective>` and `\u003Csuccess_criteria>` never restate each other.                                                                   | `\u003Cobjective_shape>`      |\n| `directive_description_form`     | debt     | A directive description states `ALWAYS invoke` with the triggers that select it.                                                   | `\u003Cdescription_style>`    |\n| `redundant_never_clause`         | debt     | A description carries a NEVER clause only where it disambiguates.                                                                  | `\u003Cdescription_style>`    |\n| `artifact_language_order`        | debt     | A description names the artifact before the language.                                                                              | `\u003Cdescription_style>`    |\n| `description_jargon`             | debt     | A description uses the abbreviations, natural terms, and plain language users say.                                                 | `\u003Cdescription_style>`    |\n| `weak_modal_in_rule`             | debt     | A constraint block uses MUST, NEVER, or ALWAYS, and none of the weak modals.                                                       | `\u003Cconstraint_language>`  |\n| `banned_phrase`                  | debt     | Prompt text carries none of the phrases the banned-phrase table lists.                                                             | `\u003Canti_patterns>`        |\n| `explaining_claude_to_claude`    | debt     | Prompt text never explains to Claude what Claude is.                                                                               | `\u003Canti_patterns>`        |\n| `motivational_prose`             | debt     | Prompt text states constraints rather than urging care.                                                                            | `\u003Canti_patterns>`        |\n| `skill_name_repetition`          | debt     | Prompt text never restates the name its frontmatter carries.                                                                       | `\u003Canti_patterns>`        |\n| `empty_disclaimer`               | debt     | Prompt text carries no disclaimer that names no concrete failure.                                                                  | `\u003Canti_patterns>`        |\n| `removable_sentence`             | debt     | A prompt carries no sentence whose removal leaves Claude's effectiveness at the task unchanged.                                    | `\u003Cconciseness>`          |\n| `known_content`                  | debt     | A prompt omits knowledge Claude already has.                                                                                       | `\u003Cconciseness>`          |\n| `abstract_guidance`              | debt     | Guidance states concrete commands and thresholds rather than abstractions.                                                         | `\u003Cconciseness>`          |\n| `failure_mode_structure`         | debt     | A failure mode states what happened, why it failed, and how to avoid it.                                                           | `\u003Cfailure_mode_writing>` |\n| `invented_failure_mode`          | debt     | A failure mode records an occurrence from actual usage, never a speculative scenario.                                              | `\u003Cfailure_mode_writing>` |\n\n\u003C\u002Frule_catalog>\n\n\u003Csuccess_criteria>\n\nA prompt that follows these conventions:\n\n- Uses imperative mood for instructions, \"Claude\" for failure modes and tendencies\n- Never uses \"the agent\", \"the model\", or \"you\" as a subject\n- States its `\u003Cobjective>` as one output-shaped sentence per `\u003Cobjective_shape>`, with no actor, activity, or clause about when or how it runs\n- Uses the description style its owning structure standard selects, worded per `\u003Cdescription_style>`\n- Uses strong modal verbs (MUST\u002FNEVER\u002FALWAYS) in constraint blocks\n- Contains no banned phrases or structural anti-patterns\n- Includes only information Claude doesn't already have\n- Documents failure modes from actual usage with concrete specifics\n- Violates no rule in `\u003Crule_catalog>`, and every finding against it names one catalog identifier\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nThe agent-prompt writing conventions and their rule catalog — voice, objective shape, description wording, constraint language, anti-patterns, conciseness, and failure-mode writing — for the text within SKILL.md files and {{! term('configured_agent') !}} {{! term('configured_agent_prompts') !}}.\n\u003C\u002Fobjective>\n\n\u003Creference_note>\nThis is a reference skill governing prompt *craft* — how to write the text. Prompt *structure* — which XML tags, file organization, and frontmatter — belongs to `\u002Fskill-standards` for a skill and to `\u002Fsubagent-standards` for a {{! term('configured_agent') !}} definition. It carries no standalone workflow.\n\u003C\u002Freference_note>\n\n\u003Cvoice>\n\n**How to refer to the executing Claude instance in prompt bodies.**\n\nTwo-tier hierarchy:\n\n1. **Imperative mood (default)** — drop the subject when giving instructions:\n   - \"Reflect deeply on what was learned before persisting anything\"\n   - \"Read the spec file before proposing changes\"\n\n2. **\"Claude\" (for failure modes, tendencies, and behavioral claims)** — use when naming what Claude does, tends to do, or fails to do:\n   - \"Without reflection, Claude will dump a narrative instead of making durable decisions\"\n   - \"Claude loses track of coverage state after 30+ turns\"\n\n**Banned subjects:**\n\n| Subject     | Problem                                                                                                          |\n| ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| \"the agent\" | Anthropic's own skills use \"Claude\" exclusively; \"the agent\" appears zero times across 18 shipped SKILL.md files |\n| \"the model\" | Too generic, distances Claude from its own identity                                                              |\n| \"you\"       | Ambiguous — could address Claude or the user                                                                     |\n\n**YAML frontmatter exception:** The `name` and `description` fields cannot contain the word \"claude\" per validation rules. Omit any subject in descriptions and word them per `\u003Cdescription_style>`.\n\n\u003C\u002Fvoice>\n\n\u003Cobjective_shape>\n\n**An `\u003Cobjective>` states the skill's output, not an activity or an actor.** It describes the observable artifact or state the skill produces, in a definite shape — what is true when the skill has been applied correctly, such that \"every rule followed exactly\" is the visible proof. It never opens with an actor (\"The skill produces…\", \"Claude produces…\") or a bare activity verb (\"Audit…\", \"Generate…\", \"Evaluate…\"). It names the output and its required shape.\n\n**One sentence — it is the output target, not a summary of the skill.** Write one sentence; reach for a second only when the output has two distinct parts. A paragraph-length objective is the smell that activation, workflow, or constraints have leaked in. The litmus: every clause must name a property of the *output*. A clause that says *when* the skill runs belongs in `description`; *how* it runs (steps, gates, orchestration) belongs in `\u003Cworkflow>`; *what it must not do* belongs in `\u003Cconstraints>`. Delete such clauses from the objective — they are not new truth to relocate, they already live in those sections. `\u002Fmanage-github-pr`'s output is \"the changeset merged into the default branch on origin through a pull request,\" not the paragraph that narrates how it gets there.\n\n**Common shapes by skill family** — name the output, never the activity:\n\n- **Auditor** → \"A verdict on X — <the finding categories>\" (the canonical auditor shape; see `\u002Fskill-standards` `references\u002Fauditor-skeleton.md`).\n- **Coder \u002F builder** → \"The <artifact> that <holds the property>\" — e.g. \"Python implementation code that makes its node's tests pass.\"\n- **Reference \u002F standards** → \"The <standards or vocabulary> <scope>\" — e.g. \"The Python-specific test standards every Python skill enforces.\"\n- **Router** → \"A <request> routed to its matching workflow\" — the routing outcome, not the menu.\n- **Orchestrator** → the end-state its lifecycle produces — e.g. \"the changeset merged to the default branch on origin,\" not the step sequence.\n\n**An objective is not a behavioral claim.** `\u003Cvoice>` governs behavioral claims — what Claude does, tends to do, or fails to do. An objective is an output statement, a different category, so the imperative-vs-\"Claude\" subject choice never applies to it. Naming an actor as the subject of an objective is the error the output framing removes.\n\nThis mirrors the methodology's output \u002F outcome \u002F impact distinction — assertions specify the **output**, and an objective names the skill's output the same way. `\u003Csuccess_criteria>` proves it: the objective names the output and its shape, `\u003Csuccess_criteria>` states the properties that make it sound, and the two never duplicate.\n\n\u003C\u002Fobjective_shape>\n\n\u003Cdescription_style>\n\n**The owning structure standard selects the style; this section governs the wording.** `\u002Fskill-standards` `\u003Cdescriptions>` selects directive or passive wording for a skill, and `\u002Fsubagent-standards` owns a {{! term('configured_agent') !}} definition's frontmatter, its description among it. The wording below applies to every description written in the directive style.\n\n**Directive descriptions for reliable activation.**\n\nResearch (Seleznov, 650 automated trials, Feb 2026) shows description wording has a 20x impact on activation odds:\n\n| Style         | Activation | Example                                         |\n| ------------- | ---------- | ----------------------------------------------- |\n| Passive       | ~77%       | `Docker expert for containerization. Use when…` |\n| Expanded      | ~93%       | `…or any Docker-related task`                   |\n| **Directive** | **~100%**  | `ALWAYS invoke… NEVER X without this skill`     |\n\n**Base template:**\n\n```yaml\ndescription: >-\n  ALWAYS invoke this skill when \u003Ctriggers>.\n```\n\n**NEVER constraint — add only when it disambiguates.** A NEVER line helps when:\n\n- The skill is the only one with that negative (e.g., `NEVER work on the Product Tree without loading context` — only contextualizing says this)\n- Claude has a strong built-in alternative the negative prevents (e.g., `NEVER run git commit without this skill` — Claude would otherwise run `git commit` directly)\n\nOmit NEVER when:\n\n- Multiple skills share the same negative\n- The ALWAYS trigger is already specific enough\n\n**Language-after-artifact** (matches user speech):\n\n```yaml\n# ✅ \"audit ADRs for Python\" — matches what users say\nALWAYS invoke this skill when auditing ADRs for Python.\n\n# ❌ \"audit Python ADRs\" — unnatural phrasing\nALWAYS invoke this skill when auditing Python ADRs.\n```\n\n**Match actual user speech:**\n\n- Abbreviations: \"ADRs\" not \"Architecture Decision Records\"\n- Natural terms: \"Python tests\" not \"python-unit-test-framework\"\n- Plain language: \"read all specs\" not \"hierarchical context ingestion protocol\"\n\n\u003C\u002Fdescription_style>\n\n\u003Cconstraint_language>\n\n**Strong modal verbs for constraints:**\n\n- `MUST` — required behavior, no exceptions\n- `NEVER` — prohibited behavior, no exceptions\n- `ALWAYS` — required in every case\n\n**Weak modals to avoid in constraint blocks:**\n\n- \"should\" — implies optional\n- \"try to\" — invites half-measures\n- \"consider\" — without a specific condition, this is noise\n- \"might want to\" — means nothing actionable\n\nWeak modals are fine in non-constraint contexts — recommendations, trade-off discussions, conditional guidance. The rule applies to constraint blocks (`\u003Cconstraints>`, hardened rules in workflows).\n\n**Pattern — constraint with rationale:**\n\n```text\nNEVER modify files during audit — audits are read-only by design.\nMUST read reference documentation before evaluating — prevents memory-based assessment.\n```\n\nThe rationale after the dash prevents blind rule-following and helps Claude judge edge cases.\n\n\u003C\u002Fconstraint_language>\n\n\u003Canti_patterns>\n\n**Banned phrases in prompt text:**\n\n| Pattern             | Problem                  | Fix                                                        |\n| ------------------- | ------------------------ | ---------------------------------------------------------- |\n| \"helpful assistant\" | Generic, zero signal     | State the specific domain and expertise                    |\n| \"helps with\"        | Vague                    | Name the concrete action                                   |\n| \"processes data\"    | Could mean anything      | Name the specific data and operation                       |\n| \"please\"            | Wastes tokens, no effect | Direct instruction                                         |\n| \"if possible\"       | Hedges the instruction   | State the instruction; add a fallback if the hedge is real |\n\n`\u003Cvoice>` governs the banned subjects, and `\u003Cconstraint_language>` governs the weak modals.\n\n**Structural anti-patterns:**\n\n- **Explaining Claude to Claude** — \"As an AI language model...\" wastes context. Claude knows what it is.\n- **Motivational prose** — \"This is a critical task that requires careful attention\" adds nothing. State the constraints.\n- **Repeating the skill name** — \"The author-skill skill is designed to...\" — Claude has the name from frontmatter.\n- **Empty disclaimers** — \"Results may vary\" — if there are real failure modes, document them concretely; if not, cut the disclaimer.\n\n\u003C\u002Fanti_patterns>\n\n\u003Cconciseness>\n\nThe context window is shared: a prompt competes for tokens with the {{! term('configured_agent_prompt') !}}, conversation history, other skills' metadata, and the user's request.\n\n**The test for every sentence in a prompt:**\n\n\"Does removing this reduce Claude's effectiveness at the task?\"\n\nIf no — cut it.\n\n**What Claude already knows (never include):**\n\n- General programming knowledge\n- Language syntax and standard library APIs\n- Common design patterns\n- How to use its own tools\n\n**What Claude needs (include):**\n\n- Product-specific conventions that contradict common patterns\n- Domain knowledge not in training data\n- Failure modes from actual usage (not hypotheticals)\n- Verification commands and thresholds\n\n**Concrete over abstract:**\n\n```text\n# ❌ Abstract\n\"Ensure coverage is maintained\"\n\n# ✅ Concrete\n\"Coverage delta must be ≤0.5%. Run: pnpm test --coverage | grep target.ts\"\n```\n\n**When to elaborate:** the concept is domain-specific (not general programming), the pattern is non-obvious or counterintuitive, or context affects behavior in subtle ways.\n\n\u003C\u002Fconciseness>\n\n\u003Cfailure_mode_writing>\n\nWrite failure modes from actual experience, not speculation.\n\n**Structure each failure mode:**\n\n1. **What happened** — concrete scenario with specifics\n2. **Why it failed** — root cause, not symptom\n3. **How to avoid** — actionable prevention\n\n**Use \"Claude\" as the subject** (failure modes are the primary case for named-subject voice):\n\n```text\n✅ Claude compared coverage per-story instead of per-file. Multiple stories share one\n   legacy file; per-story coverage is meaningless.\n\n❌ \"Compare coverage per-file, not per-story.\"\n   (States the rule but loses the WHY — the failure mode teaches the reason.)\n```\n\nNever invent failure modes. If a skill is new and hasn't failed yet, omit the section rather than fabricating scenarios. Add failure modes as they occur in real usage.\n\n\u003C\u002Ffailure_mode_writing>\n\n\u003Crule_catalog>\n\nEvery rule the sections above state carries exactly one row below, giving it one stable identifier and one severity and naming the section that states it. The stating section is authoritative for what the rule requires. Recommendations and patterns those sections offer without requiring them carry no row. The identifier, severity, finding-key, and closed-vocabulary rules for this catalog are the catalog contract `\u002Fskill-standards` states for every instructions rule catalog.\n\n| Identifier                       | Severity | Rule                                                                                                                               | Stated in                |\n| -------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------ |\n| `instruction_not_imperative`     | debt     | An instruction drops its subject and uses imperative mood.                                                                         | `\u003Cvoice>`                |\n| `behavioral_claim_subject`       | debt     | A behavioral claim, tendency, or failure mode names Claude as its subject.                                                         | `\u003Cvoice>`                |\n| `banned_subject`                 | debt     | Prompt text never uses \"the agent\", \"the model\", or \"you\" as a subject.                                                            | `\u003Cvoice>`                |\n| `description_subject`            | debt     | A frontmatter description names no subject.                                                                                        | `\u003Cvoice>`                |\n| `claude_in_frontmatter`          | blocking | The `name` and `description` fields never contain the word \"claude\".                                                               | `\u003Cvoice>`                |\n| `actor_or_activity_objective`    | blocking | An `\u003Cobjective>` names the output and its required shape, never opening with an actor or a bare activity verb.                     | `\u003Cobjective_shape>`      |\n| `objective_non_output_clause`    | debt     | An `\u003Cobjective>` is one sentence, two only for an output with two distinct parts, and every clause names a property of the output. | `\u003Cobjective_shape>`      |\n| `objective_criteria_duplication` | debt     | `\u003Cobjective>` and `\u003Csuccess_criteria>` never restate each other.                                                                   | `\u003Cobjective_shape>`      |\n| `directive_description_form`     | debt     | A directive description states `ALWAYS invoke` with the triggers that select it.                                                   | `\u003Cdescription_style>`    |\n| `redundant_never_clause`         | debt     | A description carries a NEVER clause only where it disambiguates.                                                                  | `\u003Cdescription_style>`    |\n| `artifact_language_order`        | debt     | A description names the artifact before the language.                                                                              | `\u003Cdescription_style>`    |\n| `description_jargon`             | debt     | A description uses the abbreviations, natural terms, and plain language users say.                                                 | `\u003Cdescription_style>`    |\n| `weak_modal_in_rule`             | debt     | A constraint block uses MUST, NEVER, or ALWAYS, and none of the weak modals.                                                       | `\u003Cconstraint_language>`  |\n| `banned_phrase`                  | debt     | Prompt text carries none of the phrases the banned-phrase table lists.                                                             | `\u003Canti_patterns>`        |\n| `explaining_claude_to_claude`    | debt     | Prompt text never explains to Claude what Claude is.                                                                               | `\u003Canti_patterns>`        |\n| `motivational_prose`             | debt     | Prompt text states constraints rather than urging care.                                                                            | `\u003Canti_patterns>`        |\n| `skill_name_repetition`          | debt     | Prompt text never restates the name its frontmatter carries.                                                                       | `\u003Canti_patterns>`        |\n| `empty_disclaimer`               | debt     | Prompt text carries no disclaimer that names no concrete failure.                                                                  | `\u003Canti_patterns>`        |\n| `removable_sentence`             | debt     | A prompt carries no sentence whose removal leaves Claude's effectiveness at the task unchanged.                                    | `\u003Cconciseness>`          |\n| `known_content`                  | debt     | A prompt omits knowledge Claude already has.                                                                                       | `\u003Cconciseness>`          |\n| `abstract_guidance`              | debt     | Guidance states concrete commands and thresholds rather than abstractions.                                                         | `\u003Cconciseness>`          |\n| `failure_mode_structure`         | debt     | A failure mode states what happened, why it failed, and how to avoid it.                                                           | `\u003Cfailure_mode_writing>` |\n| `invented_failure_mode`          | debt     | A failure mode records an occurrence from actual usage, never a speculative scenario.                                              | `\u003Cfailure_mode_writing>` |\n\n\u003C\u002Frule_catalog>\n\n\u003Csuccess_criteria>\n\nA prompt that follows these conventions:\n\n- Uses imperative mood for instructions, \"Claude\" for failure modes and tendencies\n- Never uses \"the agent\", \"the model\", or \"you\" as a subject\n- States its `\u003Cobjective>` as one output-shaped sentence per `\u003Cobjective_shape>`, with no actor, activity, or clause about when or how it runs\n- Uses the description style its owning structure standard selects, worded per `\u003Cdescription_style>`\n- Uses strong modal verbs (MUST\u002FNEVER\u002FALWAYS) in constraint blocks\n- Contains no banned phrases or structural anti-patterns\n- Includes only information Claude doesn't already have\n- Documents failure modes from actual usage with concrete specifics\n- Violates no rule in `\u003Crule_catalog>`, and every finding against it names one catalog identifier\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":39,"user-invocable":35},"Read","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Finstructions\u002Fskills\u002Fagent-prompt-standards","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-11 22:17:26",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add outcomeeng\u002Fplugins --skill agent-prompt-standards",{"tool":54,"command":55},"bunx","bunx skills add outcomeeng\u002Fplugins --skill agent-prompt-standards",{"tool":57,"command":58},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill agent-prompt-standards","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fagent-prompt-standards\u002FSKILL.md",true,[],[63,69,104,120,133,146],{"skillNo":64,"name":65,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":34},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[65],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":83,"publishedAt":34},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[75,78],{"categoryNo":76,"categoryName":77,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":34},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[111,112,113,114,115,91,102,116,117,103,118,119],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":129,"publishedAt":34},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[126],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[130,131,132,24,29,32,33],"typescript","typescript test standards","test",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":142,"publishedAt":34},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[139],{"categoryNo":140,"categoryName":141,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000030","开发工程师",[130,143,144,145,24,29,32,33],"code","typescript code standards","code standards",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":34},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[153,24,154,155,130,156,157,33,32,31,29,27],"architecture standards","typescript architecture standards","architecture","adr","architect"]