Skip to main content

harden-task-file

Harden a manifest-dev task guidance file for one-shot quality — either /define's quality-gate/Default set or figure-out's probe set. Iterates: orthogonality gap analysis, user-approved additions, prompt review, fix, converge. Use when a task file needs comprehensive coverage or "harden task file".

Informações da origem

Repositório
doodledood/manifest-dev
Última atividade na origem
27 de julho de 2026 às 09:14
Idioma detectado do SKILL.md
inglês
Estrelas
73
Forks
10

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
harden-task-file
description
Harden a manifest-dev task guidance file for one-shot quality — either /define's quality-gate/Default set or figure-out's probe set. Iterates: orthogonality gap analysis, user-approved additions, prompt review, fix, converge. Use when a task file needs comprehensive coverage or "harden task file".
user-invocable
true
metadata
{"internal":true}
**User request**: $ARGUMENTS Systematically harden a /define task guidance file until manifests built from it produce deliverables that don't need iteration. If no arguments, ask which task file to harden. ## Context Task files come in two parallel, decoupled sets, each keyed by task type and hardened for one-shot quality. Harden whichever set the target file belongs to: - **`/define`'s task files** (`claude-plugins/manifest-dev/skills/define/tasks/`) carry encoder data: - **Quality Gates** — Verifiable output properties. Can split into baselines (always enforced) and selectable (meaningful rigor choices) - **Defaults** — process practices always worth doing, carried into the manifest without probing; `/define` decides the encoding, and routes one whose violation would be unsafe or irreversible to a binding invariant rather than advice - **figure-out's task files** (`claude-plugins/manifest-dev/skills/figure-out/tasks/`) carry probing fuel: - **Blind-spot probes** — Non-natural angles the model skips by default (failure modes, pre-mortem fuel), phrased as the question that opens a branch - **Forced trade-offs** — Competing tensions the model must drive to a decision New items must match the depth and structural conventions of the owning skill (`define/SKILL.md` or `figure-out/SKILL.md`) and its existing sibling task files. ## Goal The task file should be comprehensive enough that a manifest built with it surfaces all criteria needed for one-shot quality — figure-out's probes surface the non-natural angles during understanding; /define's gates and Defaults encode the verifiable bar. "One-shot" = the deliverable passes review without iteration. ## Log Write findings to `/tmp/harden-{timestamp}.md` after each round. Read full log before each new round — prevents re-proposing rejected items and losing dimension context. Per-round log structure: ``` ## Round N ### Dimension Map [dimension → items mapping] ### Gaps Found [uncovered dimensions] ### Proposals [item: accepted/rejected by user] ### Reviewer Findings [finding: agree/disagree, applied/skipped] ``` ## Orthogonality Analysis The core discipline. Map every item in the file to a dimension — an independent axis of concern. A dimension is a top-level concern like "evidence quality" or "audience fit"; items are specific checks within a dimension like "source credibility" or "cross-referencing". Two items share a dimension if improving one naturally helps the other. User validates the dimension map before gap-filling begins. Gaps = dimensions with no coverage. Examples of dimension sources: deliverable lifecycle (creation → review → use → maintenance), rejection triggers, wrongness vs incompleteness, base-rate failures for this task class, user interaction points. If the first analysis finds no gaps, invoke the reviewer once and exit if clean — not every task file needs hardening. ## Iteration Loop Each iteration achieves: - **Gaps identified** via orthogonality analysis - **Additions designed** — invoke the prompt-engineering skill before proposing changes - **User-approved additions** applied (all additions via AskUserQuestion) - **Quality validated** — invoke the review-prompt skill on the task file after applying changes - **Reviewer findings evaluated critically** — not all are valid. Present assessment with rationale; user decides - **Log updated** after each round Converged when criteria in Convergence section met. ## Section Placement Each item belongs in exactly one section, and a safety rule whose violation would be unsafe or irreversible is a Default even when verifiable — that clause wins over the Quality Gate (baseline) row below, which every safety rule also matches. A file holds only its own set's sections — a `/define` file never carries probes/trade-offs, a figure-out file never carries gates/Defaults: | Section | Set | What it checks | Test | |---------|-----|----------------|------| | Quality Gate (baseline) | /define | Output property that should always be true | Would omitting this ever be acceptable? No → baseline, unless violating it would be unsafe or irreversible → Default | | Quality Gate (selectable) | /define | Output property representing a meaningful rigor choice | Reasonable to skip for some tasks? Yes → selectable | | Default | /define | Process practice always worth doing | Can't verify from output, or a safety rule whose violation would be unsafe or irreversible? → Default | | Blind-spot probe | figure-out | A non-natural failure mode / pre-mortem angle the model skips by default | "Imagine this was rejected because..." AND a capable model wouldn't raise it unprompted? → probe | | Forced trade-off | figure-out | Competing tension with no universal right answer | Both sides have legitimate merit? → trade-off | A concern appears once, in its most natural section. When the same concern appears in multiple sections, keep the stronger version. ## Principles | Principle | Enforcement | |-----------|-------------| | Orthogonality over volume | Cover all dimensions, not all possible items within a dimension | | User approves all changes | Propose via AskUserQuestion, never auto-add | | Critical reviewer evaluation | Evaluate each finding independently — push back with rationale when wrong. When reviewer suggests items in already-covered dimensions, orthogonality wins | | No redundancy across sections | Same concern in both risks and scenarios = pick one | | Principles over thresholds | "Corroborated across independent sources" not "verified across 2+ sources" | | No capability instructions | Don't prescribe verification methods — parent skill handles that | | Match complexity to domain | Not every task file needs 17 quality gates — match depth to the diversity of ways the deliverable can fail | ## Never - Auto-add items without user approval - Blindly apply all reviewer suggestions - Add arbitrary numerical thresholds - Prescribe verification methods (parent skill handles this) - Re-propose items the user already rejected (check log) ## Convergence Done when: - Orthogonality analysis finds no new uncovered dimensions - Prompt reviewer finds no MEDIUM+ issues - User confirms satisfaction
Ver no GitHub