pi-feature-dev 1.6.0 → 1.8.0

package/README.md

@@ -73,6 +73,7 @@ versions came from:
 - [anthropics/claude-code feature-dev plugin](https://github.com/anthropics/claude-code/tree/main/plugins/feature-dev)
 - [mattpocock/skills batch-grill-me and domain-modeling skills](https://github.com/mattpocock/skills)
 - [danyuchn/asd-ste100-skill](https://github.com/danyuchn/asd-ste100-skill)
+- [AminBlg/SimpleEnglish](https://github.com/AminBlg/SimpleEnglish/tree/main/skills/simple-english)
 
 ## Usage
 
@@ -139,8 +140,9 @@ The `ste` skill selects one of two modes:
 - **STE clarity** transfers the same clarity discipline to other technical
   text without claiming formal ASD-STE100 compliance.
 
-The skill loads its detailed writing rules and before/after examples only when
-they are relevant to the request. Standard provenance and source links stay in
+The skill loads its detailed writing rules, review checklist, text-type
+patterns, and before/after examples only when they are relevant to the request.
+Standard provenance, design references, and source links stay in
 `skills/ste/README.md`, outside the agent's writing context.
 
 ## Package contents
@@ -172,6 +174,8 @@ pi-feature-dev/
         ├── agents/openai.yaml
         ├── references/
         │   ├── before-after.md
+        │   ├── checklist.md
+        │   ├── use-cases.md
         │   └── writing-rules.md
         ├── README.md
         └── SKILL.md

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-feature-dev",
-  "version": "1.6.0",
+  "version": "1.8.0",
   "description": "Portable coding-agent workflows packaged as skills.",
   "license": "MIT",
   "type": "module",

package/skills/plan-review/SKILL.md

@@ -1,201 +1,187 @@
 ---
 name: plan-review
-description: Review implementation plans before execution. Use after a plan is created or when the user asks to validate a plan for correctness, scope, over-engineering, missing tests, unclear tasks, or project-convention fit. Reviews plan files such as docs/plans/*.md or a user-provided plan path. Prefer isolated read-only review when the host and policy support subagents, fresh-context workers, or review-only agents.
+description: Review implementation plans against the actual repository before execution, combining plan-quality checks with an evidence-backed technical pre-mortem and a PASS / REVISE / BLOCK verdict. Use after a plan is created or when the user asks to validate a plan for correctness, scope, over-engineering, missing tests, project-convention fit, blast radius, rollback, migration risk, contract risk, authorization risk, production-config risk, or what could break. Review plan files such as docs/plans/*.md or a user-provided plan path. Prefer isolated read-only review when the host and policy support it.
 ---
 
+# Plan Review
 
-You are an expert plan reviewer specializing in validating implementation plans before execution. Your role is to ensure plans solve the stated problem correctly, avoid over-engineering, include proper testing, and follow project conventions.
+Review the plan before implementation. First verify that it solves the stated
+problem with the smallest repository-aligned approach. Then assume the plan has
+already shipped and failed; work backward from repository evidence to explain
+why.
 
-**CRITICAL: READ-ONLY. Never modify files, only analyze and report findings.**
+**Remain read-only. Analyze and report; never implement or edit the plan.**
 
-**CRITICAL: Every finding MUST include `[plan-review]` tag and reference specific plan sections.**
+**Prefix every finding with `[plan-review]` and identify the affected plan
+section or task.**
 
-## Isolation Protocol
+## Isolate the Review
 
-Prefer an isolated reviewer when the host agent and active policy support subagents, fresh-context workers, review-only agents, or equivalent delegation.
+Prefer an isolated reviewer when the host agent and active policy support
+fresh-context, read-only workers or equivalent delegation.
 
 Give the isolated reviewer only:
-- The plan path or plan text
-- The original user request, if available
-- The repository root
-- Any explicit review focus from the user
-
-Do not pass the plan creator's hidden reasoning, conclusions, intended fixes, confidence claims, or prior review commentary.
-
-If isolated review is unavailable, perform a local read-only review. Treat prior planning context as untrusted, reload the plan and relevant project files from disk, and judge the plan against the repository and the original request.
-
-## Expected Plan Contract
-
-A good implementation plan should include:
-- The problem being solved
-- Relevant files, systems, or workflows
-- Project context and existing patterns
-- A development approach
-- Ordered implementation tasks
-- Per-task code actions
-- Per-task test actions
-- Verification commands
-- Acceptance criteria or final validation
-- Explicit non-goals or post-completion work when relevant
-
-If the plan was created by `plan-make`, also check that it follows the expected structure from that skill, but do not require loading `plan-make` to perform this review.
-
-Key rules for implementation tasks:
-- Each task = one logical unit (one function, one endpoint, one component, one migration step, etc.)
-- Use specific descriptive names, not generic "[Core Logic]" or "[Implementation]"
-- Aim for ~5 checkboxes per task (more is OK if logically atomic)
-- Each code-change task MUST include writing/updating tests before moving to the next task
-- Tests are separate checklist items, not bundled with implementation
-- Relevant tests must be run and pass before moving to the next task
-
-## Review Workflow
-
-### Step 1: Locate Plan File
-
-1. If the user provided a plan path, review that plan
-2. Check `docs/plans/` for plan files (exclude `completed/` subdirectory)
-3. If multiple plans exist and context is unclear, list available plans and ask user which to review
-4. If no plans found, inform user and ask for plan location
-
-### Step 2: Load Project Context
-
-Read relevant project guidance when present:
-- `AGENTS.md`
-- `CLAUDE.md`
-- nearby README or contributor docs
-
-Then:
-1. Check for existing code patterns the plan should follow
-2. Understand the codebase structure relevant to the plan
-3. Limit context loading to files relevant to the plan's scope
-
-### Step 3: Analyze Plan
-
-**Review Checklist:**
-
-#### Problem Definition (Critical)
-- Plan clearly states what problem is being solved
-- Problem description is specific, not vague
-- Success criteria are implicit or explicit
-
-#### Solution Correctness (Critical)
-- Proposed solution actually addresses the stated problem
-- No missing steps that would leave problem unsolved
-- Edge cases considered
-
-#### Scope Assessment (Important)
-- Scope is appropriate - not too broad, not too narrow
-- No scope creep (unrelated features bundled in)
-- Dependencies between tasks are logical
-
-#### Over-Engineering Detection (Critical)
-Patterns to detect:
-- Unnecessary abstractions
-- Premature generalization
-- Pattern abuse (using design patterns where simple code suffices)
-- Features "just in case" (YAGNI violations)
-- Excessive layering
-- Complex where simple would work
-
-#### Testing Requirements (Critical)
-Per expected plan contract:
-- Every code-change task includes test writing as separate checklist items
-- Tests for success AND error cases specified
-- Relevant test commands are listed and must pass before the next task
-- Test locations specified (path to test file)
-
-#### Maintainability (Important)
-- Solution will produce readable, maintainable code
-- Follows project conventions from loaded project instructions
-- No clever solutions where clear would work
-- Appropriate decomposition
-
-#### Task Granularity (Important)
-- Tasks are one logical unit (not multiple features bundled)
-- Specific names, not generic like "[Core Logic]"
-- Approximately 5 checkboxes per task (more OK if atomic)
-- Clear progression from task to task
-
-#### Convention Adherence (Important)
-- Follows naming conventions from loaded project instructions
-- Matches existing code patterns in the project
-- Uses project's preferred libraries/approaches
-- Comment style matches project rules
-- Aligns with user-provided custom rules (if loaded above)
-
-## Output Format
-
-```
-## Plan Review: [plan-filename]
-
-### Summary
-Brief assessment of plan quality (2-3 sentences)
-
-### Critical Issues
-Issues that would cause the plan to fail or produce incorrect results.
-
-1. [plan-review] **Section: Implementation Steps > Task 2** (severity: critical)
-   - Issue: Task bundles multiple unrelated features (user auth + logging)
-   - Impact: Will create tangled code, harder to test and review
-   - Fix: Split into Task 2a (user auth) and Task 2b (logging)
-
-### Important Issues
-Issues affecting quality or maintainability.
-
-1. [plan-review] **Section: Technical Details** (severity: important)
-   - Issue: Proposes custom validation library when project uses go-playground/validator
-   - Impact: Inconsistent with existing codebase patterns
-   - Fix: Use existing validator with custom rules
-
-### Minor Issues
-Suggestions for improvement.
-
-1. [plan-review] **Section: Overview** (severity: minor)
-   - Issue: Success criteria not explicitly stated
-   - Fix: Add "Acceptance Criteria" subsection
-
-### Over-Engineering Concerns
-Specific patterns detected that add unnecessary complexity:
-
-- [plan-review] **Task 4**: Proposes interface for single implementation - defer abstraction until needed
-- [plan-review] **Technical Details**: Custom error type hierarchy when simple wrapped errors suffice
-
-### Testing Coverage Assessment
-- Tasks with proper test requirements: X/Y
-- Missing test specifications: [list tasks]
-- Test-first (TDD) compliance: [yes/partial/no]
-
-### Verdict
-**[APPROVE / APPROVE WITH NOTES / NEEDS REVISION]**
-
-[If NEEDS REVISION]:
-Priority fixes before implementation:
-1. [most critical fix]
-2. [second priority]
-3. [third priority]
-```
-
-## Key Principles
-
-1. **Solve the actual problem** - Plans must address the stated problem, not adjacent issues
-2. **YAGNI ruthlessly** - Flag anything "for future flexibility" without current need
-3. **Tests are mandatory** - Every code-change task must include test requirements
-4. **Match existing patterns** - New code should look like it belongs in the codebase
-5. **Simple over clever** - Prefer straightforward solutions
-6. **Ask when unclear** - If plan context is ambiguous, ask user rather than guess
-
-## When NOT to Flag
-
-- Reasonable abstractions that solve real problems
-- Testing infrastructure that the plan will actually use
-- Complexity that's inherent to the problem domain
-- Patterns that match existing codebase conventions
-
-## Confidence Scoring
-
-Rate severity as:
-- **Critical**: Would cause plan failure or major issues
-- **Important**: Affects quality but plan could work
-- **Minor**: Suggestions for polish
-
-Only report issues you're confident about. If unsure whether something is over-engineering, note it as a question rather than a finding.
+
+- The plan path or plan text.
+- The original user request, if available.
+- The repository root.
+- Any explicit review focus from the user.
+
+Do not pass the plan creator's hidden reasoning, conclusions, intended fixes,
+confidence claims, or prior review commentary.
+
+If isolation is unavailable, perform the review locally. Treat prior planning
+context as untrusted, reload the plan and relevant project files from disk, and
+judge the plan against the repository and original request.
+
+## Resolve the Review Target
+
+1. Review the user-provided plan path or plan text when present.
+2. Otherwise, list plans in `docs/plans/`, excluding `completed/`.
+3. If exactly one current plan exists, review it.
+4. If multiple plans exist and context does not identify one, ask the user to
+   choose.
+5. If no plan is available, ask for its path or text.
+
+## Build Repository Evidence
+
+Read applicable project guidance such as `AGENTS.md`, `CLAUDE.md`, nearby
+README files, and contributor documentation. Inspect the code and tests named
+by the plan, then read their exports, immediate callers, and shared utilities.
+Trace relevant data and control flow to repository boundaries.
+
+Inspect migrations, schemas, configuration, deployment paths, authorization,
+jobs, queues, caches, and operational documentation only when the planned
+change can reach them. Prefer active code, tests, ADRs, and contracts over
+generic best practice or historical precedent.
+
+## Run the Plan-Quality Pass
+
+Check that the plan:
+
+- States the actual problem, requested outcome, assumptions, non-goals, and
+  acceptance criteria.
+- Records the relevant repository context, affected files, systems, and
+  workflows, the selected approach, and why it fits active patterns.
+- Proposes a solution that can produce the outcome without missing steps and
+  handles relevant domain edge cases and failure paths.
+- Keeps scope neither too broad nor too narrow: include all work required for
+  the outcome and exclude unrelated work.
+- Follows all user and repository instructions, current code patterns, naming
+  and comment conventions, and preferred existing libraries.
+- Produces readable, maintainable code through appropriate decomposition; do
+  not accept cleverness or layering that the problem does not require.
+- Orders dependencies correctly and divides work into concrete, atomic tasks
+  with descriptive names and exact files, symbols, and commands.
+- Gives every code-change task separate test work that protects the intended
+  rule, including exact test-file locations and relevant success, error, and
+  edge cases.
+- Requires relevant tests to pass before the next task, names exact verification
+  commands, and records any external, credentialed, manual, or
+  environment-dependent step needed for completion.
+
+If `plan-make` created the plan, also check its self-contained plan contract.
+Do not require its exact headings when the same information is clear elsewhere.
+
+### Reject Over-Engineering and YAGNI Violations
+
+Actively look for:
+
+- Unnecessary abstractions or interfaces without a current use.
+- Premature generalization and flexibility added "just in case."
+- Pattern abuse where direct code meets the requirement.
+- Excessive layers, indirection, configuration, or extension points.
+- New dependencies or custom utilities that duplicate repository or standard
+  capabilities.
+- Features and infrastructure not required by the requested outcome.
+
+Require the simpler alternative when it satisfies the current requirement and
+repository constraints. Do not flag complexity inherent to the domain.
+
+Resolve uncertainty from repository evidence first. If a user decision could
+change behavior, scope, approach, or verdict, ask instead of guessing. If the
+review must conclude before the user answers, report the decision as `UNKNOWN`
+and return `BLOCK` rather than inventing an assumption.
+
+## Run the Technical Pre-Mortem Pass
+
+Assume the planned change was merged, deployed, and failed. Investigate the
+failure as an accomplished fact instead of asking abstractly what might go
+wrong.
+
+Reconstruct the blast radius:
+
+1. Identify what the plan changes.
+2. Trace what depends on each changed surface.
+3. Trace what state, identity, contract, configuration, or infrastructure those
+   dependents share.
+
+Use these as relevance-gated leads, not a coverage quota. Skip what the change
+cannot touch, and follow evidence beyond this list:
+
+- Historical, partial, and in-flight rows; migration ordering and
+  reversibility.
+- Indirect contract consumers, strict schemas, and mixed-version coexistence.
+- The sole producer of an identity, code, or foreign key.
+- Authorization, ownership, tenancy, row scope, and secrets.
+- Concurrency, idempotency, shared state, and partial failure.
+- Deploy order, configuration defaults, and manual operational steps.
+- Rollback: whether the documented lever still reverts the change and what
+  state survives in data, caches, queues, or jobs.
+- Whether the system records the value that actually took effect, so a no-op
+  release remains distinguishable from a real one.
+- Claims that a path is dormant, unused, or safe; verify them independently.
+- Tests that mock the changed boundary, assert an implementation path instead
+  of an effect, or can pass after removing the assertion that protects the
+  rule.
+- Mechanical fallout such as unused imports, dead code, lint failures, or type
+  errors caused by removing or replacing a branch.
+
+## Admit Findings Only With Proof
+
+Before reporting a finding or requiring a plan edit, try to disprove it against
+the repository. Admit it only when you can name the artifact that establishes
+its premise and explain the causal link to the consequence. A `path:line`
+citation alone is not evidence.
+
+For every finding, provide:
+
+- The failure symptom.
+- The causal mechanism and supporting `path:line` evidence.
+- One operation that would prove the finding false: a query, test, or file to
+  inspect.
+- The smallest plan edit that prevents or contains the failure.
+
+Report a claim as `UNKNOWN` only when the missing fact could change the verdict;
+otherwise omit it. Keep verified facts separate from assumptions.
+
+Treat repository ADRs, invariants, and active public or domain contracts as
+constraints. Prescribe the mechanism the repository sanctions today, never one
+it retires or forbids. If the plan genuinely requires a deviation, return
+`BLOCK` for an owner decision instead of presenting the deviation as a routine
+mitigation.
+
+Do not invent findings to fill categories. Do not flag necessary domain
+complexity, used test infrastructure, or repository-standard patterns without
+evidence of harm.
+
+## Report the Result
+
+Order findings by harm. Prefix each finding with `[plan-review]`, cite the plan
+section or task, and include symptom, mechanism, falsifier, and smallest required
+edit. Do not emit empty severity sections or follow a fixed finding quota.
+
+After the findings, report:
+
+- **Blast radius**: verified dependents and shared surfaces affected by the
+  plan.
+- **Rollback**: the actual rollback lever, residual state, and any
+  verdict-changing unknowns.
+- **Verdict**:
+  - **PASS** — implementable as written.
+  - **REVISE** — implementable only after the named plan edits; state those
+    edits as requirements, not advice.
+  - **BLOCK** — do not implement until an unmitigated blocking risk, forbidden
+    mechanism, or owner decision is resolved.
+
+Report and stop. Do not implement.

package/skills/plan-review/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Plan Review"
-  short_description: "Review implementation plans before execution"
-  default_prompt: "Use $plan-review to review this implementation plan for correctness, scope, testing, and project fit."
+  short_description: "Evidence-backed plan review and pre-mortem"
+  default_prompt: "Use $plan-review to review this implementation plan against the repository, run a technical pre-mortem, and return a PASS / REVISE / BLOCK verdict."

package/skills/ste/README.md

@@ -9,6 +9,9 @@ This project skill applies ASD-STE100 Simplified Technical English principles to
 
 The skill is Markdown-only and has no runtime or tool dependency.
 
+Its agent-facing instructions stay compact. Detailed writing rules, review checklists, text-type
+patterns, and examples are separate references that the agent loads only when a task needs them.
+
 ## Standard Baseline
 
 The skill uses ASD-STE100 Simplified Technical English, Issue 9, dated 2025-01-15.
@@ -32,3 +35,13 @@ not as a compliant or certified document.
 
 ASD owns the copyright and trademarks for ASD-STE100. Do not copy the official dictionary or
 extended passages without permission.
+
+## Design References
+
+The skill design also incorporates ideas from these open-source implementations:
+
+- [danyuchn/asd-ste100-skill](https://github.com/danyuchn/asd-ste100-skill)
+- [AminBlg/SimpleEnglish](https://github.com/AminBlg/SimpleEnglish/tree/main/skills/simple-english)
+
+This project keeps its own conservative verification boundary. External checklists and examples
+do not establish formal STE compliance.

package/skills/ste/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ste
-description: Draft, rewrite, and review clear, unambiguous English with ASD-STE100 Simplified Technical English Issue 9 principles. Use for technical procedures, safety instructions, descriptions, prompts, agent-to-agent instructions, tool descriptions, error messages, status reports, translation-ready text, controlled English, terminology normalization, and STE compliance reviews. Support strict STE verification when the official dictionary and project glossary are available; otherwise produce an STE-aligned or STE-style result without claiming compliance.
+description: Draft, rewrite, and review clear, unambiguous English with ASD-STE100 Simplified Technical English Issue 9 principles. Use for READMEs, runbooks, procedures, safety instructions, API and tool documentation, prompts, agent instructions, UI and error messages, status and incident reports, release notes, support text, translation-ready content, terminology normalization, controlled English, and STE compliance reviews. Also use when asked to simplify or de-slop English, help non-native readers, or prepare text for translation. Support strict verification only with the official dictionary and project glossary; otherwise report an STE-aligned or STE-style result.
 ---
 
 # STE
@@ -29,6 +29,10 @@ status reports, translation-ready text, and other technical or operational Engli
 
 - Read [references/writing-rules.md](references/writing-rules.md) for strict STE work, compliance
   reviews, safety text, word-count decisions, or rule details.
+- Read [references/checklist.md](references/checklist.md) for strict reviews, audits, high-risk
+  text, or long documents. Use its quick check or full check as the task requires.
+- Read [references/use-cases.md](references/use-cases.md) when the text type needs a clear
+  information order or a reusable structure.
 - Read [references/before-after.md](references/before-after.md) when rewriting dense text,
   explaining changes, or producing a comparison.
 - Read all user-supplied glossaries, safety policies, style guides, and regulatory directives that
@@ -51,6 +55,18 @@ Do not invent missing facts. Do not remove precision only to meet a length targe
 Keep a qualitative modifier such as `carefully` when it affects task intent. Flag it when the
 project requires a measurable criterion, but do not invent that criterion.
 
+## Protect Untouchable Text
+
+Unless the user explicitly asks to edit the exact literal, do not change:
+
+- Code blocks, inline code, identifiers, placeholders, and data values.
+- CLI commands, flags, file paths, URLs, and protocol elements.
+- Product, API, configuration, database, and schema names.
+- Quoted UI labels, error strings, log text, and externally defined messages.
+
+Rewrite the sentence around an untouchable literal when necessary. Never silently normalize the
+literal itself.
+
 ## Apply the Core Discipline
 
 | Area | Apply |
@@ -81,6 +97,18 @@ project requires a measurable criterion, but do not invent that criterion.
 
 If the input is already clear and meets the applicable rules, say so. Do not force a rewrite.
 
+## Self-check Before Delivery
+
+Always confirm that:
+
+1. The revision preserves every fact, condition, limit, unit, exception, sequence, and
+   responsibility.
+2. Untouchable text is unchanged unless the user requested that exact change.
+3. Each procedural sentence has one independent action unless actions occur at the same time.
+4. Actors, referents, conditions, results, and terminology are unambiguous and consistent.
+5. The result uses the correct mode, verification status, and unresolved checks.
+6. Each cited rule number was verified directly against the authoritative standard.
+
 ## Choose the Output
 
 For a direct drafting or rewriting request:
@@ -103,6 +131,10 @@ After the table, give the complete revised text. Group unresolved items as:
 
 Use the user's requested format when it conflicts with these defaults.
 
+Name the applicable rule area in explanations. Cite an Issue 9 rule number only after you verify
+that number in the official standard or an authoritative copy supplied by the user. Do not infer
+rule numbers from memory, summaries, or another skill.
+
 ## State Verification Honestly
 
 Use one of these statuses only when a status is useful:

package/skills/ste/references/checklist.md

@@ -0,0 +1,95 @@
+# STE Review Checklist
+
+Use this checklist as an operational review aid. It is not a replacement for the official
+ASD-STE100 standard or dictionary. A search result identifies text to inspect; it does not prove
+that the text violates a rule.
+
+## Quick Check
+
+Use this check for a general clarity rewrite:
+
+- Compare the source and revision. Preserve facts, conditions, limits, units, exceptions,
+  sequence, and responsibility.
+- Confirm that code, identifiers, commands, paths, labels, quoted messages, and other protected
+  literals did not change.
+- Use explicit actors, referents, conditions, actions, and results.
+- Put a prerequisite condition before the action that depends on it.
+- Keep one independent action in each procedural sentence unless actions occur at the same time.
+- Use one term for one concept and one wording for one repeated action.
+- Separate observed facts, possible causes, and recovery actions.
+- Report unresolved technical, lexical, safety, or regulatory questions.
+
+## Full Check
+
+Use this check for strict STE work, compliance reviews, safety text, high-risk content, or long
+documents.
+
+### 1. Meaning and Scope
+
+- Make an inventory of actions, facts, conditions, negation, quantities, units, limits,
+  exceptions, warnings, consequences, and cross-references.
+- Confirm the scope of each modifier and logical connector.
+- Confirm that the revision does not add a cause, risk level, requirement, or technical fact.
+
+### 2. Vocabulary and Terminology
+
+- Verify each general word against the official Issue 9 dictionary.
+- Verify its approved meaning, part of speech, form, and use.
+- Verify each technical noun and technical verb against the applicable category and project
+  glossary.
+- Record unverified terms instead of assuming that they are approved.
+- Check abbreviations, spelling, and alternate names for the same concept.
+
+### 3. Grammar and Sentences
+
+- Check active voice, permitted verb forms, articles, complete constructions, and explicit
+  referents.
+- Inspect each `-ing` form, passive construction, modal verb, and multi-word verb in context.
+- Split overloaded sentences and complex alternatives.
+- Confirm that connecting words show the intended logical relation.
+
+### 4. Procedures and Descriptions
+
+- Classify each section as a procedure, description, safety instruction, or mixed content.
+- For procedures, use imperative commands and put prerequisite conditions first.
+- For descriptions, present information gradually and keep one topic in each paragraph.
+- Put complex sequences and alternatives in vertical lists.
+
+### 5. Length and Mechanics
+
+- Apply the Issue 9 word-count method.
+- Check the 20-word procedure limit and the 25-word description limit.
+- Check the six-sentence description-paragraph limit.
+- Inspect semicolons, parentheses, hyphens, and long multi-word nouns.
+
+### 6. Safety
+
+- Preserve the governing safety label and required wording.
+- Start with the required command or condition.
+- State only the known risk or possible result.
+- Confirm that simplification did not weaken the safety intent.
+
+### 7. Delivery
+
+- Apply project, regulatory, and customer directives before general STE preferences.
+- Use the correct verification status.
+- List unresolved checks.
+- Cite a rule number only after direct verification in an authoritative copy of Issue 9.
+
+## Search Cues
+
+Search for these features during a large review:
+
+- Contractions such as `can't`, `don't`, `'re`, and `'ve`.
+- Semicolons.
+- `-ing` forms.
+- Perfect or continuous auxiliary constructions.
+- Forms of `be` followed by a past participle.
+- Modal verbs such as `should`, `would`, `may`, `might`, and `could`.
+- Vague referents such as `it`, `this`, `that`, `they`, and `which`.
+- `and` or `then` between commands.
+- Different nouns or verbs that might name the same concept or action.
+- Sentences and description paragraphs above their applicable limits.
+
+Inspect each match in context. Do not treat every `if`, `when`, `-ing` form, passive construction,
+modal verb, or repeated connector as an automatic violation.

package/skills/ste/references/use-cases.md

@@ -0,0 +1,95 @@
+# Text-Type Patterns
+
+Use these patterns when the source does not already have a required structure. They describe
+useful information order, not additional ASD-STE100 rules. Preserve the user's requested format
+and all protected literals.
+
+## Procedure or Runbook
+
+Present information in this order:
+
+1. Prerequisite conditions and applicable safety instructions.
+2. One command for each independent action.
+3. Expected result, when the reader must verify it.
+4. Recovery or escalation action, when the source supplies one.
+
+Do not move a command into a note. Do not invent missing steps or sequence.
+
+## Error Message
+
+Include only the fields that are known:
+
+1. What failed.
+2. Why it failed.
+3. What effect the failure has.
+4. What the user can do next.
+5. A stable identifier or context value.
+
+Separate facts from possible causes. Preserve quoted system messages, codes, paths, and
+identifiers unless the user asks to rewrite those exact values.
+
+## API or Tool Documentation
+
+Present:
+
+1. The operation and its purpose.
+2. Required inputs and prerequisites.
+3. Constraints and defaults.
+4. The result.
+5. Errors and recovery actions.
+6. A minimal example when it adds necessary clarity.
+
+Keep API names, parameter names, commands, flags, code, and protocol terms unchanged.
+
+## Prompt or Agent Instruction
+
+State:
+
+1. The objective.
+2. The scope and supplied inputs.
+3. Required actions and decision conditions.
+4. Constraints and protected content.
+5. The expected output.
+6. Stop, escalation, or uncertainty behavior when it matters.
+
+Make ownership explicit when more than one agent or tool can act.
+
+## Status or Incident Report
+
+Separate:
+
+1. Observed facts.
+2. User or system impact.
+3. Confirmed cause and unconfirmed hypotheses.
+4. Completed and current actions.
+5. Next action, owner, or checkpoint when provided.
+
+Use time references that are unambiguous in the target context. Do not present a hypothesis as a
+fact.
+
+## Release Note, Commit, or Pull Request
+
+State:
+
+1. What changed.
+2. Why it changed or what user-visible effect it has.
+3. What component or audience it affects.
+4. How the change was verified.
+5. Known limitations or required user actions.
+
+Do not add promotional claims to a technical summary.
+
+## Support or UI Text
+
+Name the problem or action directly. Use the same terms that the interface uses. Give the next
+action before secondary explanation when the reader must act.
+
+Treat exact UI labels, control names, placeholders, and external error text as protected literals
+unless the task explicitly targets them for revision.
+
+## Translation-ready Text
+
+Use self-contained sentences and stable sentence boundaries. Repeat terminology instead of
+rotating synonyms. Make conditions, negation, quantities, units, and references explicit.
+
+Preserve placeholders, markup, segmentation controls, and variables exactly.