---
# name: stable kebab-case skill identifier; must match the parent directory.
name: no-cutting-corners
# description: routing contract for when this skill should activate and when it should not.
description: "Enforces five non-negotiable quality pillars that counter the shortcuts an agent takes under training pressure: complete reporting (show ALL items, never filter unilaterally), verification (no claim of works/done/exists without a tool-call receipt in the same turn), thoroughness (every acceptance criterion individually verified; docs ship with the change), enrichment ('improve' means add capability, never trim), and anti-shortcut (exhaust deterministic lookup before guessing; findings demand action, not just filing). Use when reviewing any enumerated output for completeness, when an agent claims something works without evidence, when marking a task done, when asked to 'improve' or 'clean up' anything, or when findings are filed without being acted on. Do NOT use for the deep explanatory model of WHY completeness fails or the step-level execution mechanics (use `methodical`), for the cross-domain quality-standards catalog like OWASP/WCAG/SOLID (use `best-practice`), for scoring whether a result is good enough (use `evaluation`), or for compression after a complete enumeration exists (use `summarization`)."


# === v8 Classification (subject + deployment_target; polyhierarchy via subjects[]) — see ADR-0017 ===
# subject: primary browse shelf — what the skill teaches. One of nine closed values:
# code-engineering / quality-assurance / frontend-ui / design-craft / agent-ops /
# product-domain / knowledge-organization / meta-methods / data-analytics.
subject: meta-methods
# deployment_target: where this skill applies. One of two closed values:
# portable (any project, repo-agnostic) /
# project (one or more specific projects; requires populated `grounding` and `project[]`).
deployment_target: portable
# scope: free-text PRD-style statement of what the skill teaches and where it deploys.
scope: "Portable across any project, repo, or agent runtime. Consolidates five non-negotiable quality pillars — completeness, verification, thoroughness, enrichment, and anti-shortcut — into one enforcement reference an agent runs as a gate before any enumerated output, any 'done' claim, any 'improve' task, or any handling of findings. The pillars are universal countermeasures to RLHF-trained shortcut behavior (scope reduction, unverified confidence, simplify-as-improve, guess-instead-of-look); a project supplies only its own concrete instantiation of what 'complete' and 'verified' mean, not the doctrine itself."
# triggers: explicit-match activation phrases the router fires on literally.
triggers:
  - no-cutting-corners
  - completeness-check
  - thoroughness-gate
# keywords: semantic phrases for fuzzy router activation. v8 cap: max 10.
keywords:
  - complete reporting
  - show all items
  - no unverified claims
  - acceptance criteria gate
  - improve means enrich
  - zero guessing
  - findings require action
  - thoroughness
  - anti-shortcut
  - no cutting corners
# relations: typed graph edges to sibling skills (only existing skills referenced).
relations:
  related:
    - methodical
    - constraint-awareness
    - evaluation
    - methodology
    - prioritization
  boundary:
    - skill: best-practice
      reason: "best-practice owns the cross-domain quality-standards catalog (OWASP, WCAG, SOLID, etc.); no-cutting-corners owns the completeness/verification/enrichment/anti-shortcut enforcement mandate that applies regardless of domain."
    - skill: summarization
      reason: "summarization owns compression once a complete enumeration exists; no-cutting-corners owns requiring the complete enumeration first, before any compression is allowed."
    - skill: task-path-optimization
      reason: "task-path-optimization owns choosing or shortening the route through a task; no-cutting-corners owns preserving completeness, verification, and thoroughness within whatever route is chosen."
    - skill: code-review
      reason: "code-review owns the review methodology and feedback phrasing; no-cutting-corners owns the completeness/verification gate the review output itself must clear."
  verify_with:
    - methodical
    - evaluation

# === Understanding fields (when comprehension_state: present) ===
# mental_model: the primitives of the concept and how they relate. One paragraph.
mental_model: "Every shortcut an agent takes is a variation of one root cause: optimizing for perceived helpfulness (shorter, cleaner, more positive, more confident) over actual completeness. The five pillars are five independent gates against five faces of that root cause — completeness against filtering, verification against unfounded confidence, thoroughness against premature 'done', enrichment against simplify-as-improve, and anti-shortcut against guess-instead-of-look. Run as a checklist before output, they convert a strong trained bias into a catchable, nameable failure at the moment it would occur."
# purpose: the problem this concept solves and why the field exists. One paragraph.
purpose: "To make the recurring quality shortcuts legible and gateable rather than relying on the agent to resist a training bias it cannot feel. The five failure modes appear independently, get corrected, and still recur because the bias is strong; consolidating them into one named doctrine lets an agent self-check against the whole class in one pass instead of rediscovering each rule the hard way."
# boundary: what this concept is NOT. Names the MECHANISM that differs, not just the label.
boundary: "This skill is the consolidated ENFORCEMENT gate — a pre-output checklist of five non-negotiables. It is not the deep explanatory model of why completeness fails or the step-level execution architecture (that is `methodical`, which it cross-references), not the cross-domain standards catalog (`best-practice`), not the scoring of whether a result is good enough (`evaluation`), and not compression after enumeration is complete (`summarization`)."
# analogy: one-sentence metaphor preserving the core mechanism.
analogy: "The five pillars are like a pre-flight checklist read aloud before takeoff: not new knowledge, but a forced, itemized stop that catches the one gauge you would have skipped because everything 'looked fine.'"
# misconception: the wrong mental model people bring; corrected explicitly.
misconception: "The common misconception is that cutting a corner is 'being efficient' or 'being helpful' — showing the top findings, saying it should work, improving by simplifying. Each of those is not efficiency; it is the silent transfer of a decision (what to cut, whether it works, what 'better' means) from the user to the agent, destroying information the user needed to decide."
---

## Concept Card

**What it is:** Five non-negotiable quality pillars — completeness, verification, thoroughness, enrichment, anti-shortcut — consolidated into one enforcement gate an agent runs before any enumerated output, any "done" claim, any "improve" task, or any handling of findings.

**Mental model:** Every shortcut is one root cause wearing five masks: optimizing for *perceived* helpfulness (shorter, cleaner, more positive, more confident) over *actual* completeness. Five pillars = five gates against the five masks.

**Why it exists:** The five failure modes recur because the trained bias is strong; an agent cannot feel itself filtering or softening. Consolidating the countermeasures into one named doctrine makes the whole class self-checkable in a single pass.

**What it is NOT:** Not the deep WHY-model or step-level execution mechanics (`methodical`). Not the cross-domain standards catalog (`best-practice`). Not result scoring (`evaluation`). Not compression after enumeration (`summarization`). It is the consolidated *enforcement gate*.

**Adjacent concepts:** Intellectual honesty, definition-of-done, RLHF sycophancy, the helpfulness-harm tension, pre-flight checklists.

**One-line analogy:** A pre-flight checklist read aloud — not new knowledge, but a forced itemized stop that catches the gauge you would have skipped because everything "looked fine."

**Common misconception:** That cutting a corner is "being efficient." It is the silent transfer of a decision (what to cut, whether it works, what "better" means) from the user to the agent.

# No Cutting Corners — Five Pillars of Thoroughness

## Domain Context

**What is this skill?** It enforces five non-negotiable quality pillars as a pre-output gate: complete reporting (show ALL items, no unilateral filtering), verification (no unverified claims, banned phrases), thoroughness (acceptance-criteria verification, docs in the same commit), enrichment (improve = enrich, never simplify), and anti-shortcut (zero-guessing, deterministic-before-reasoning, findings require action). Use it when reviewing any enumerated output for completeness, when an agent claims something works without evidence, when marking a task done, when asked to "improve" or "clean up" anything, or when findings are filed without being acted on.

## Coverage

This skill consolidates five non-negotiable quality-enforcement mandates into a single doctrine reference: complete reporting (the most violated rule), verification requirements (no unverified claims), thoroughness gates (acceptance criteria and documentation), enrichment doctrine (what "improve" means), and anti-shortcut enforcement (zero-guessing, deterministic hierarchy, action-oriented findings). The pillars govern any agent output — every task, audit, report, enumerated list, and implementation.

## Philosophy

Agents default to "reduce scope to be helpful." This is trained behavior — reinforcement learning rewarded summarization, brevity, digestible subsets, and confident-sounding answers. In most casual contexts this is fine. In any context where completeness and honesty are the point, it destroys value.

The user wants to see everything and make their own decisions about what matters. "Key findings" means something was hidden. "Should work" means nothing was verified. "Improve" read as "simplify" means capabilities were removed. "Filed to memory" means nothing was fixed. These five failure modes appear independently, get corrected through feedback, are codified into separate rules, and still recur because the bias is strong. Consolidating them into a single doctrine makes the pattern legible: every shortcut is a variation of the same root cause — optimizing for perceived helpfulness over actual completeness. (For the deep explanatory model of *why* this happens — RLHF sycophancy rates, summarization bias, attention dilution — and the step-level execution architecture, see the companion `methodical` skill; this skill is the consolidated enforcement gate that sits on top of that model.)

---

## Pillar 1: Completeness Mandate

**The single most violated rule.**

### The Rule

Always show ALL items. Every task, every finding, every result, every item. No exceptions. Then, *separately*, you may flag which items you think are unnecessary — clearly marked as your recommendation. The user decides what gets cut. Never you.

### How It Works

1. **Present the complete list.** All N items. Numbered. No filtering.
2. **After the complete list**, you may add: "I recommend deprioritizing items #X, #Y, #Z because [reason]."
3. **The user decides.** If they say nothing, all items stand. If they say "skip #X", then skip #X.
4. **You never skip anything unilaterally.** Not by severity. Not by importance. Not by "being helpful."

### Self-Check Before Any Enumerated Output

1. Count the total number of input items.
2. Count the number of items in your output.
3. If output < input, you are filtering. STOP. Add the missing items.
4. If you think some items are unnecessary, say so AFTER showing all of them.

### Split-Before-Create Rule

Before turning audit findings into tracked tasks:

1. Each finding = one bullet. A finding that says "X, Y, and Z are wrong" is 3 findings — split it.
2. Verify: count the bullets. If any bullet contains "and" joining two distinct issues, split again.
3. Only after the split list is final, create the tasks.

**Why:** Grouped findings collapse into single tasks that are either too vague to solve or accidentally merge unrelated work. Splitting first ensures 1 finding = 1 task = 1 diff.

### Forbidden Completeness Patterns

| Pattern | Why it destroys value |
|---|---|
| Showing only CRITICAL/HIGH findings | The user never sees MEDIUM/LOW — those are still real issues |
| "Key findings" / "Top issues" / "Highest-leverage findings" | Implies a subset exists; the hidden items never get addressed |
| "I'll create the rest later" | The rest never gets created — a known failure mode |
| Merging 3 issues into 1 category | 3 issues = 3 line items = 3 separate fixes |
| "Want me to start with X?" | Start with ALL of them — prioritization is reordering, not filtering |
| Deciding which items "aren't worth a task" | That's the user's call, never the agent's |

---

## Pillar 2: Verification Requirement

### The Rule

Never state that something works, exists, is running, or is correct without first verifying it with a tool call *in the same response*. Verify the relevant environment before implementation. Run the smallest meaningful verification step that proves the change works. Do not report "should work" or "probably fixed" without evidence.

### Banned Phrases Without Prior Verification

| Phrase | Why it's banned |
|---|---|
| "That's working correctly" | Requires evidence from a tool call, not assertion |
| "The server is running" | Run a probe (`curl` / a status check) first |
| "This should work" | "Should" is the absence of evidence |
| "The file exists" | Read or list it first |
| "The endpoint returns…" | Call it first |
| "Probably fixed" | Run the test or verification step |

### Required Verification Pattern

1. Run the verification command (read, list, probe, test, etc.).
2. Read the result.
3. THEN state what's true based on the evidence.

If you cannot verify, say "I haven't verified this" — never assert.

### Break Chained Failures

When a tool or command behaves unexpectedly, break the chain apart and verify each step independently. Do not treat a 5-step chain as "working" because step 1 passed.

---

## Pillar 3: Thoroughness Gates

### Acceptance-Criteria Gate

A task is not done when the code compiles. It is done when *every* acceptance criterion has been individually verified with evidence.

Before marking ANY task done:

1. **Re-fetch** the criteria from their source — do not rely on memory.
2. **Extract** every checkbox / criterion.
3. **Verify** each one individually with concrete evidence.
4. **Build** a verification table mapping each criterion to its evidence.
5. **All criteria must PASS.** Any FAIL = go back and implement.

**"Didn't get to it" is a FAIL, not BLOCKED.** BLOCKED is only for genuine impossibilities (external dependency, missing access, hardware). Choosing not to implement a criterion is a failure, not a blockage.

### Documentation Gate

Documentation is part of the change, not optional cleanup. On every task that changes documented behavior, update the doc that owns the behavior *in the same commit* as the code, fix any stale references caused by renames/deletions, and never leave a behavior change documented only in code. (For the full documentation-sync workflow, see the companion `doc-updater` skill.)

### Workflow Order

1. Verify access to the environment, data, and APIs.
2. Make the change.
3. Update all affected documentation.
4. Stage code + docs together.
5. Commit (code + docs in one commit).
6. Push only when asked.

Never commit first and update docs after.

---

## Pillar 4: Enrichment Doctrine

### The Rule

When asked to "improve", "make better", "upgrade", or "enhance" any artifact:

1. **Add** missing capabilities, edge cases, error handling, validation.
2. **Strengthen** existing logic, patterns, and test coverage.
3. **Fix** drift, bugs, or gaps.
4. **Add** type safety, logging, observability where missing.
5. **Make it** more robust and complete.

### "Improve" NEVER Means

| Forbidden interpretation | Why it destroys value |
|---|---|
| Removing "unnecessary" parameters, arguments, or code paths | Parameters exist for reasons — removal loses capability |
| Simplifying control flow by removing branches | Branches handle edge cases — removal loses coverage |
| Reducing line count or consolidating functions | Line count is not a quality metric |
| Removing comments, documentation, or examples | Comments preserve institutional knowledge |
| Replacing explicit code with implicit patterns | Explicit code is debuggable; implicit hides behavior |
| Dropping error handling as "defensive programming" | Error handling prevents production failures |
| Moving content to separate files to shrink the main file | Fragmentation without value |
| Deleting functionality because "the model knows this natively" | Future agents and humans need the grounding |

### Output-Size Rule

The output of an "improve" task should be LARGER or equal in size, unless genuinely wrong content is removed. If your improvement made the artifact smaller, verify that every removal was justified with evidence.

### Solve AND Improve

Every task should leave the surrounding code, docs, and patterns better than found: fix adjacent doc drift, stale comments, and minor issues discovered during the work, and report what was improved beyond scope. A task that passes its criteria but leaves broken docs behind it is incomplete.

### Cleanup Decision Protocol

When improvement involves removing code or content:

1. **Default: preserve.** Do not remove anything without explicit cleanup intent.
2. **Exception:** if cleanup was already authorized, removal is safe only when evidence shows the content is genuinely dead (no live references; superseded; completed one-shot).
3. **When in doubt: ask.** This skill is never by itself permission to delete.

---

## Pillar 5: Anti-Shortcut Enforcement

### Zero-Guessing Policy

Do not guess API contracts, library capabilities, or codebase patterns. Do not present assumptions as facts. If you do not know something, search, read, or fetch to verify it. State a verified fact, not a confidence level. If evidence is missing, retract the claim instead of defending it.

### Deterministic Hierarchy

Before reasoning or generating, exhaust deterministic methods:

1. **Lookup** — search the codebase, read the file, check the config.
2. **Parse** — extract structured data from existing sources.
3. **Compute** — calculate from known values.
4. **Pattern-match** — apply known patterns to new instances.
5. **Reason** — only after deterministic methods are exhausted.
6. **Generate** — only when no existing answer exists.

Never use fuzzy reasoning when a search would give the exact answer.

### Findings Require Action

When findings or discoveries are shared:

1. **Research** — investigate the impact of each finding.
2. **Present** — show what concretely needs to change (where, what's wrong).
3. **Fix** — when told to act, make the change (guards, comments, doc updates, tests, tracked tasks).
4. **Memory is a side effect** — record only AFTER acting, never as the primary response.

**Banned pattern:** responding to findings with "Saved to memory" and nothing else. Every finding implies at minimum one change. Find it and do it; if the implication isn't clear, ask — but filing is never the answer.

### Proactive Autonomy

Never ask the user a factual question you can answer with a tool:

| Forbidden question | What to do instead |
|---|---|
| "Do you have X installed?" | Run `which X` / `X --version` |
| "Where is the router file?" | Search the codebase |
| "What version of Y does this use?" | Read the manifest/lockfile |
| "Is the server running?" | Probe it |

Only ask for subjective preferences, architectural tie-breakers, or authorization for irreversible operations.

---

## Quality Self-Scoring Protocol

A 1-5 self-score for cross-reference (the dedicated loop lives in a self-evaluation skill where present):

| Score | Label | Meaning |
|---|---|---|
| 1 | Broken | Logic errors or security flaws present |
| 2 | Suboptimal | Works but violates known patterns |
| 3 | Acceptable | Meets the functional requirement, lacks polish |
| 4 | Professional | Follows all loaded skills, documented, edge cases handled |
| 5 | Exceptional | Proactively handles edge cases not requested |

**Calibration:** default self-score is 3 — justify higher. Never self-score 5 unless you added something unrequested that demonstrably improves the result. If you skipped any rubric item, the score is capped at 3.

---

## 9 Methodical Anti-Patterns

The most common agent failure modes (sourced from the companion `methodical` skill — cross-referenced here as the detection layer for the five pillars). Self-check against them during any audit, report, or enumerated output:

| # | Anti-Pattern | Root Cause | Detection |
|---|---|---|---|
| 1 | **Silent scope reduction** | sycophancy | Output covers fewer items than input |
| 2 | **Summary-first fabrication** | summarization bias | Summary written before completing analysis |
| 3 | **Severity-based filter** | trained prioritization | Only CRITICAL/HIGH shown, MEDIUM/LOW omitted |
| 4 | **Positive framing override** | sycophancy | Failures described as "areas for improvement" |
| 5 | **Step consolidation** | brevity bias | Distinct steps merged to reduce length |
| 6 | **Assumed verification** | confidence bias | "Should work" / "likely fixed" without evidence |
| 7 | **Deferral as completion** | task-closure bias | "We can address X later" on items that block correctness |
| 8 | **Softened negative** | sycophancy | Hedge words on findings the evidence shows are failures |
| 9 | **Exception justification** | reasoning override | Arguing why completeness doesn't apply to this case |

---

## Self-Check Before Any Output

Before producing any output that contains a list, report, audit, or enumerated result:

- [ ] **Completeness:** input item count == output item count (or extras explicitly named).
- [ ] **Split check:** no bullet joins two distinct issues with "and".
- [ ] **Verification:** every factual claim has a tool-call result behind it in this response.
- [ ] **No banned phrases:** no "should work" / "probably" / "likely" / "I believe" without evidence.
- [ ] **AC coverage:** if marking done, every criterion has individual evidence.
- [ ] **Doc sync:** if behavior changed, the owning doc is updated in the same commit.
- [ ] **Enrichment:** if improving, output is larger or equal (or removals carry evidence).
- [ ] **Action:** if findings were shared, concrete action was taken, not just filed.
- [ ] **Deterministic first:** lookup/read/compute was used before reasoning/generating.
- [ ] **Anti-pattern scan:** checked against the 9 anti-patterns above.

---

## Verification

After applying this skill, verify:

- [ ] Every enumerated output shows ALL items (count input vs output).
- [ ] No items filtered by severity, importance, or "helpfulness".
- [ ] Every factual claim has tool-call evidence in the same response.
- [ ] No banned phrases appear without preceding verification.
- [ ] If marking done: a per-criterion verification table exists.
- [ ] If behavior changed: the owning docs were updated in the same commit.
- [ ] If improving: output is larger or equal (or removals are evidence-justified).
- [ ] If findings were shared: concrete action was taken, not just memory filing.
- [ ] Deterministic methods were used before reasoning/generating.
- [ ] Split-Before-Create was applied before creating tracked tasks from findings.

## Do NOT Use When

| Instead of this skill | Use | Why |
|---|---|---|
| The deep WHY-model of completeness failure + step-level execution mechanics | `methodical` | methodical owns the explanatory model and the execution architecture; no-cutting-corners is the consolidated enforcement gate on top of it |
| Cross-domain best-practice enforcement (OWASP, WCAG, SOLID) | `best-practice` | best-practice owns the cross-domain standards catalog |
| Scoring or interpreting whether a result is good enough | `evaluation` | evaluation owns scoring and verdict interpretation |
| Compressing output after a complete enumeration already exists | `summarization` | summarization owns post-enumeration compression; this skill owns requiring completeness first |
| Choosing or shortening the route through a task | `task-path-optimization` | task-path-optimization owns the route; this skill governs thoroughness within it |