@rosetears/aili-pi 0.1.0

package/skills/spec-driven-development/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: spec-driven-development
+description: Create or materially revise a durable specification when the user explicitly requests a spec/new feature contract or a named ambiguity requires formal DEFINE; do not trigger for ordinary bounded edits, implementation, task breakdown alone, review, or documentation of already-settled behavior.
+---
+
+# Spec-Driven Development
+
+## Overview
+
+When explicit specification intent or a material ambiguity selects this loop, create the smallest durable contract that defines scope, behavior, boundaries, and acceptance. Ordinary bounded work remains outside this skill and does not require a new formal specification.
+
+## When to Use
+
+- The user explicitly asks for a specification or formal feature/change contract.
+- A named material ambiguity requires durable scope, behavior, interface, or acceptance decisions before implementation.
+- A new project/feature has no current formal contract and the ordinary/formal classifier selects DEFINE.
+
+**When NOT to use:** Ordinary bounded edits, multi-file work with clear acceptance, task breakdown from an existing spec, implementation, review, or docs-only explanation.
+
+## Canonical loop contract
+
+This skill is a bounded adapter to the ordinary specification or canonical DEFINE loop. ROSE/`aili-delivery-flow` owns change identity, lifecycle state, approvals, progress, and verification. Produce only the next dependency-ready spec artifacts, reread each write once, and stop with `complete`, `need-user`, `need-evidence`, `material-delta`, `blocked`, or `Unverified`. Do not invoke planning, requirements, research, test-plan, TDD, implementation, review, or another process skill. Return a named need to ROSE. Lifecycle approval and claim-matched verification rules override generic upstream phase/checklist wording.
+
+## The Validated Workflow
+
+Spec-driven development supplies SPECIFY/PLAN/TASKS techniques. Formal AILI work maps them to dependency-ready canonical artifacts through `aili-delivery-flow`; it does not own IMPLEMENT, create upstream task files, public commands, or parallel approval authorities.
+
+```
+SPECIFY ──→ PLAN ──→ TASKS ──→ HANDOFF
+   │          │        │          │
+   ▼          ▼        ▼          ▼
+ Validate   Validate Validate   Return to owner
+```
+
+🔴 **CHECKPOINT · AILI lifecycle gate:** phase validation may require clarification or revision, but is not a separate mandatory lifecycle approval. Resolve or label material `Open Question` / `Unverified` items, persist/re-read canonical artifacts, and preserve final accepted `test-plan.md` as the sole mandatory pre-BUILD user approval. Silence, inferred intent, drafts, and upstream phase language are never approval.
+
+The pinned Addy file under `references/upstream/` is inert reference data. This existing skill is the only runnable adapter; AILI placement, permissions, lifecycle order, material-delta writeback, final test-plan acceptance, and stop conditions override foreign paths and gates.
+
+### Phase 1: Specify
+
+Within the selected specification loop, start with the current objective and ask only decision-shaped questions needed to make material requirements concrete.
+
+**Surface assumptions immediately.** Before writing any spec content, list what you're assuming:
+
+```
+ASSUMPTIONS I'M MAKING:
+1. This is a web application (not native mobile)
+2. Authentication uses session-based cookies (not JWT)
+3. The database is PostgreSQL (based on existing Prisma schema)
+4. We're targeting modern browsers only (no IE11)
+→ Material assumptions require an explicit decision; otherwise they remain Open Question and block affected work.
+```
+
+Don't silently fill in ambiguous requirements. The spec's entire purpose is to surface misunderstandings *before* code gets written — assumptions are the most dangerous form of misunderstanding.
+
+### Ambiguity Fallbacks
+
+| Trigger condition | First response | If still unresolved |
+|---|---|---|
+| User asks for a broad feature with no success criteria | Draft 2-4 concrete success criteria and return the decision to ROSE | Keep the item as `Open Question`; do not proceed to PLAN |
+| Architecture, data model, security, or migration behavior is unclear | List the competing options and tradeoffs for ROSE | Return `need-user` or `material-delta`; stop before implementation |
+| Existing code/docs conflict with the user's description | Cite the conflict and return the source-of-truth decision to ROSE | Mark the conflict `Unverified`; do not choose silently |
+| The spec would require public API, dependency, schema, or deployment changes | Return the exact material/risky decision or operation to ROSE | Block implementation tasks until the canonical approval is recorded |
+
+Use only the sections needed by the current specification. Objective/success and material boundaries are normally required; commands, structure, style, and testing sections are conditional rather than a six-section completion form:
+
+1. **Objective** — What are we building and why? Who is the user? What does success look like?
+
+2. **Commands, when setup or verification is affected** — Use current project-documented commands with flags, not generic defaults.
+   ```
+   Build: <project command, if applicable>
+   Test: <claim-matched command, if applicable>
+   Lint: <project command, if applicable>
+   Dev: <project command, if applicable>
+   ```
+
+3. **Project Structure, when placement changes** — Where affected source, tests, or docs belong.
+   ```
+   src/           → Application source code
+   src/components → React components
+   src/lib        → Shared utilities
+   tests/         → Unit and integration tests
+   e2e/           → End-to-end tests
+   docs/          → Documentation
+   ```
+
+4. **Code Style, when a new pattern is introduced** — Prefer one current repository example over generic prose.
+
+5. **Testing Strategy, when acceptance needs it** — Name only the checks and placement needed by the affected behavior.
+
+6. **Material boundaries** — Reference canonical rules for exact dependency, schema, auth/security, external, destructive, Git, and release gates instead of duplicating a generic checklist.
+
+**Spec template:**
+
+```markdown
+# Spec: [Project/Feature Name]
+
+## Objective
+[What we're building and why. User stories or acceptance criteria.]
+
+## Tech Stack
+[Framework, language, key dependencies with versions]
+
+## Commands
+[Build, test, lint, dev — full commands]
+
+## Project Structure
+[Directory layout with descriptions]
+
+## Code Style
+[Example snippet + key conventions]
+
+## Testing Strategy
+[Framework, test locations, coverage requirements, test levels]
+
+## Boundaries
+- Always: [...]
+- Ask first: [...]
+- Never: [...]
+
+## Success Criteria
+[How we'll know this is done — specific, testable conditions]
+
+## Open Questions
+[Anything unresolved that needs human input]
+```
+
+**Reframe instructions as success criteria.** When receiving vague requirements, translate them into concrete conditions:
+
+```
+REQUIREMENT: "Make the dashboard faster"
+
+REFRAMED SUCCESS CRITERIA:
+- Dashboard LCP < 2.5s on 4G connection
+- Initial data load completes in < 500ms
+- No layout shift during load (CLS < 0.1)
+→ Are these the right targets?
+```
+
+This lets you loop, retry, and problem-solve toward a clear goal rather than guessing what "faster" means.
+
+### Spec Loophole Pass
+
+After the first SPECIFY draft, run the following direct loophole checklist. Invoke no separate stress-test unless the user explicitly requested it or ROSE identified a concrete material loophole.
+
+Check whether:
+
+- success criteria are executable and measurable
+- scope and non-goals are explicit
+- Always / Ask First / Never boundaries cover high-risk areas
+- user-facing terms are not overloaded
+- architecture-sensitive assumptions are marked
+- security, privacy, reliability, migration, compatibility, and rollback concerns are either covered or explicitly out of scope
+- unresolved items are listed as `Open Question`
+- unverifiable claims are marked `Unverified`
+
+Do not proceed to PLAN until material loopholes are fixed, accepted by the user, or explicitly recorded as `Open Question` / `Unverified`.
+
+🛑 **STOP before PLAN:** if any material loophole remains neither accepted nor recorded, return a clarification request instead of drafting a plan.
+
+### Phase 2: Plan
+
+With the validated spec, generate a technical implementation plan:
+
+1. Identify the major components and their dependencies
+2. Determine the implementation order (what must be built first)
+3. Note risks and mitigation strategies
+4. Identify what can be built in parallel vs. what must be sequential
+5. Define verification checkpoints between phases
+
+The plan should be reviewable: the human should be able to read it and say "yes, that's the right approach" or "no, change X."
+
+🛑 **STOP before TASKS:** do not break work into tasks until the plan is coherent and material open risks are resolved or explicitly recorded under the AILI contract. This validation creates no extra approval gate.
+
+### Phase 3: Tasks
+
+Break the plan into discrete, implementable tasks:
+
+- Each task should cover one coherent behavior or dependency boundary
+- Each task has explicit acceptance criteria
+- Each task names the smallest evidence needed for its affected claim, when any package-local evidence is needed
+- Tasks are ordered by dependency, not by perceived importance
+- Task boundaries follow behavior, dependencies, ownership, risk, and reversibility rather than a fixed file count
+
+🛑 **STOP before IMPLEMENT:** do not start coding until tasks have acceptance criteria and any claim-matched evidence targets they need, canonical artifacts are coherent/validated, and final `test-plan.md` has explicit user acceptance under the AILI lifecycle.
+
+**Task template:**
+```markdown
+- [ ] Task: [Description]
+  - Acceptance: [What must be true when done]
+  - Verify: [How to confirm — test command, build, manual check]
+  - Files: [Which files will be touched]
+```
+
+### Phase 4: Implementation Handoff
+
+Return implementation readiness and the next dependency to ROSE. Implementation uses the canonical ordinary/BUILD owner; this skill does not invoke incremental, TDD, context, or other process skills.
+
+## Keeping the Spec Alive
+
+The spec is a living document, not a one-time artifact:
+
+- **Update when decisions change** — If you discover the data model needs to change, update the spec first, then implement.
+- **Update when scope changes** — Features added or cut should be reflected in the spec.
+- **Version the spec when authorized** — The spec belongs in version control, but commit remains an exact Git operation approval.
+- **Reference the spec in PRs** — Link back to the spec section that each PR implements.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "This is simple, I don't need a spec" | Ordinary bounded work may remain ordinary; use this skill only when explicit spec intent or a material ambiguity selects it. |
+| "I'll write the spec after I code it" | That's documentation, not specification. The spec's value is in forcing clarity *before* code. |
+| "The spec will slow us down" | Once formal specification is selected, keep it dependency-ready and no larger than the decisions it must preserve. |
+| "Requirements will change anyway" | That's why the spec is a living document. An outdated spec is still better than no spec. |
+| "The user knows what they want" | Surface only assumptions that can materially change the selected formal contract; do not manufacture questions for settled ordinary work. |
+
+## Red Flags
+
+- Treating every implementation as formal specification work
+- Proceeding inside a selected formal change while material acceptance remains unresolved
+- Inferring acceptance from silence or an uncorrected assumption
+- Implementing behavior outside the accepted formal scope
+- Making a material architecture/public-contract decision without returning it to the lifecycle owner
+
+## Verification
+
+Before proceeding to implementation, confirm:
+
+- [ ] The directly applicable behavior, acceptance, and material boundaries are specified
+- [ ] Only dependency-ready canonical artifacts were written and reread
+- [ ] Success criteria are specific and testable
+- [ ] Open questions and `Unverified` items remain explicit
+- [ ] The lifecycle owner selected any required structural validation
+- [ ] For formal AILI work, the final `test-plan.md` has explicit user acceptance before implementation

package/skills/spec-driven-development/references/upstream/addyosmani-agent-skills/6bcfeb9dae52b11eaad23511acc165109746dbc3/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Addy Osmani
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/spec-driven-development/references/upstream/addyosmani-agent-skills/6bcfeb9dae52b11eaad23511acc165109746dbc3/NOTICE.md

@@ -0,0 +1,9 @@
+# Upstream reference notice
+
+- Repository: `https://github.com/addyosmani/agent-skills`
+- Commit: `6bcfeb9dae52b11eaad23511acc165109746dbc3`
+- Copyright: Copyright (c) 2025 Addy Osmani
+- License: root MIT `LICENSE` copied beside this notice
+- Mapping: `skills/spec-driven-development/SKILL.md` → `spec-driven-development/SKILL.upstream.md`
+
+The pinned closure is inert provenance/reference data, not a runnable skill, command, approval, integrity authority, or permission grant. Canonical behavior remains `.agents/skills/spec-driven-development/SKILL.md`.

package/skills/spec-driven-development/references/upstream/addyosmani-agent-skills/6bcfeb9dae52b11eaad23511acc165109746dbc3/spec-driven-development/SKILL.upstream.md

@@ -0,0 +1,206 @@
+---
+name: spec-driven-development
+description: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.
+---
+
+# Spec-Driven Development
+
+## Overview
+
+Write a structured specification before writing any code. The spec is the shared source of truth between you and the human engineer — it defines what we're building, why, and how we'll know it's done. Code without a spec is guessing.
+
+## When to Use
+
+- Starting a new project or feature
+- Requirements are ambiguous or incomplete
+- The change touches multiple files or modules
+- You're about to make an architectural decision
+- The task would take more than 30 minutes to implement
+
+**When NOT to use:** Single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained.
+
+## The Gated Workflow
+
+Spec-driven development has four phases. Do not advance to the next phase until the current one is validated.
+
+```
+SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT
+   │          │        │          │
+   ▼          ▼        ▼          ▼
+ Human      Human    Human      Human
+ reviews    reviews  reviews    reviews
+```
+
+### Phase 1: Specify
+
+Start with a high-level vision. Ask the human clarifying questions until requirements are concrete.
+
+**Surface assumptions immediately.** Before writing any spec content, list what you're assuming:
+
+```
+ASSUMPTIONS I'M MAKING:
+1. This is a web application (not native mobile)
+2. Authentication uses session-based cookies (not JWT)
+3. The database is PostgreSQL (based on existing Prisma schema)
+4. We're targeting modern browsers only (no IE11)
+→ Correct me now or I'll proceed with these.
+```
+
+Don't silently fill in ambiguous requirements. The spec's entire purpose is to surface misunderstandings *before* code gets written — assumptions are the most dangerous form of misunderstanding.
+
+**Write a spec document covering these six core areas:**
+
+1. **Objective** — What are we building and why? Who is the user? What does success look like?
+
+2. **Commands** — Full executable commands with flags, not just tool names.
+   ```
+   Build: npm run build
+   Test: npm test -- --coverage
+   Lint: npm run lint --fix
+   Dev: npm run dev
+   ```
+
+3. **Project Structure** — Where source code lives, where tests go, where docs belong.
+   ```
+   src/           → Application source code
+   src/components → React components
+   src/lib        → Shared utilities
+   tests/         → Unit and integration tests
+   e2e/           → End-to-end tests
+   docs/          → Documentation
+   ```
+
+4. **Code Style** — One real code snippet showing your style beats three paragraphs describing it. Include naming conventions, formatting rules, and examples of good output.
+
+5. **Testing Strategy** — What framework, where tests live, coverage expectations, which test levels for which concerns.
+
+6. **Boundaries** — Three-tier system:
+   - **Always do:** Run tests before commits, follow naming conventions, validate inputs
+   - **Ask first:** Database schema changes, adding dependencies, changing CI config
+   - **Never do:** Commit secrets, edit vendor directories, remove failing tests without approval
+
+**Spec template:**
+
+```markdown
+# Spec: [Project/Feature Name]
+
+## Objective
+[What we're building and why. User stories or acceptance criteria.]
+
+## Tech Stack
+[Framework, language, key dependencies with versions]
+
+## Commands
+[Build, test, lint, dev — full commands]
+
+## Project Structure
+[Directory layout with descriptions]
+
+## Code Style
+[Example snippet + key conventions]
+
+## Testing Strategy
+[Framework, test locations, coverage requirements, test levels]
+
+## Boundaries
+- Always: [...]
+- Ask first: [...]
+- Never: [...]
+
+## Success Criteria
+[How we'll know this is done — specific, testable conditions]
+
+## Open Questions
+[Anything unresolved that needs human input]
+```
+
+**Reframe instructions as success criteria.** When receiving vague requirements, translate them into concrete conditions:
+
+```
+REQUIREMENT: "Make the dashboard faster"
+
+REFRAMED SUCCESS CRITERIA:
+- Dashboard LCP < 2.5s on 4G connection
+- Initial data load completes in < 500ms
+- No layout shift during load (CLS < 0.1)
+→ Are these the right targets?
+```
+
+This lets you loop, retry, and problem-solve toward a clear goal rather than guessing what "faster" means.
+
+### Phase 2: Plan
+
+With the validated spec, generate a technical implementation plan:
+
+1. Identify the major components and their dependencies
+2. Determine the implementation order (what must be built first)
+3. Note risks and mitigation strategies
+4. Identify what can be built in parallel vs. what must be sequential
+5. Define verification checkpoints between phases
+
+> Follow `planning-and-task-breakdown` for the dependency-graph mapping and vertical-slicing mechanics behind these steps; it is the canonical source. The bullets above are a lightweight summary; if they ever diverge, `planning-and-task-breakdown` takes precedence.
+>
+> **Output convention:** Save the plan to `tasks/plan.md` and the task list to `tasks/todo.md`, per the `/plan` command convention. Create `tasks/` if it does not exist. Downstream commands (`/build`, etc.) expect these paths.
+
+The plan should be reviewable: the human should be able to read it and say "yes, that's the right approach" or "no, change X."
+
+### Phase 3: Tasks
+
+Break the plan into discrete, implementable tasks:
+
+- Each task should be completable in a single focused session
+- Each task has explicit acceptance criteria
+- Each task includes a verification step (test, build, manual check)
+- Tasks are ordered by dependency, not by perceived importance
+- No task should require changing more than ~5 files
+
+> Follow `planning-and-task-breakdown` for the full task-sizing and dependency-ordering mechanics; it is the canonical source. The template below is a lightweight inline form; if they ever diverge, `planning-and-task-breakdown` takes precedence.
+
+**Task template:**
+```markdown
+- [ ] Task: [Description]
+  - Acceptance: [What must be true when done]
+  - Verify: [How to confirm — test command, build, manual check]
+  - Files: [Which files will be touched]
+```
+
+### Phase 4: Implement
+
+Execute tasks one at a time following `skills/incremental-implementation/SKILL.md` (`incremental-implementation`) and `skills/test-driven-development/SKILL.md` (`test-driven-development`). Use `skills/context-engineering/SKILL.md` (`context-engineering`) to load the right spec sections and source files at each step rather than flooding the agent with the entire spec.
+
+## Keeping the Spec Alive
+
+The spec is a living document, not a one-time artifact:
+
+- **Update when decisions change** — If you discover the data model needs to change, update the spec first, then implement.
+- **Update when scope changes** — Features added or cut should be reflected in the spec.
+- **Commit the spec** — The spec belongs in version control alongside the code.
+- **Reference the spec in PRs** — Link back to the spec section that each PR implements.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "This is simple, I don't need a spec" | Simple tasks don't need *long* specs, but they still need acceptance criteria. A two-line spec is fine. |
+| "I'll write the spec after I code it" | That's documentation, not specification. The spec's value is in forcing clarity *before* code. |
+| "The spec will slow us down" | A 15-minute spec prevents hours of rework. Waterfall in 15 minutes beats debugging in 15 hours. |
+| "Requirements will change anyway" | That's why the spec is a living document. An outdated spec is still better than no spec. |
+| "The user knows what they want" | Even clear requests have implicit assumptions. The spec surfaces those assumptions. |
+
+## Red Flags
+
+- Starting to write code without any written requirements
+- Asking "should I just start building?" before clarifying what "done" means
+- Implementing features not mentioned in any spec or task list
+- Making architectural decisions without documenting them
+- Skipping the spec because "it's obvious what to build"
+
+## Verification
+
+Before proceeding to implementation, confirm:
+
+- [ ] The spec covers all six core areas
+- [ ] The human has reviewed and approved the spec
+- [ ] Success criteria are specific and testable
+- [ ] Boundaries (Always/Ask First/Never) are defined
+- [ ] The spec is saved to a file in the repository

package/skills/strategy-stress-test/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: strategy-stress-test
+description: Run one bounded adversarial pass when the user explicitly requests a report-style stress test or ROSE identifies a concrete material loophole in an existing strategy, spec, plan, review, or claim; do not trigger for an interactive grill/frontier interview or merely before write-back, implementation, reconciliation, or completion.
+license: MIT
+metadata:
+  source: local-workflow-guardrail
+---
+
+# Strategy Stress Test
+
+## Purpose
+
+Use this skill to turn "are we confident enough?" into an engineering guardrail.
+
+Do not pursue artificial 100% certainty. Target factually supportable high confidence.
+
+If the user asks for 100% confidence, treat that as a request to stress-test harder, not as permission to manufacture certainty. Stop when the claim is supported, conditional, or explicitly marked with `Open Question` / `Unverified` items.
+
+If confidence is not supportable, identify material loopholes, missing evidence, counterexamples, hidden assumptions, verification gaps, and repair options.
+
+Anything still unresolved must be marked as `Open Question` or `Unverified`.
+
+## When to Use
+
+Use this skill only when a concrete draft or claim exists and either the user explicitly asks to challenge/stress-test it or ROSE names one material loophole that direct inspection cannot safely close inline.
+
+Routing boundary: a request to inspect an artifact and report loopholes without interviewing the user belongs here. A request to grill/interview the user's decisions, including an explicitly requested frontier batch, belongs to the single canonical `requirements-grilling` capability. Do not register or invoke a second `batch-grill-me` skill.
+
+Positive triggers:
+
+- "Stress-test this design before I accept it."
+- "Challenge this plan for rollback gaps."
+- A named contradiction, missing failure path, or unsupported completion claim that can change a material decision.
+
+Near misses: an interactive “grill me”, “interview me”, “batch grill me”, or equivalent decision-elicitation request; an artifact merely exists; a file is about to be written; implementation/review is ending; confidence is requested without a named loophole; or ordinary verification is pending. Interactive decision elicitation routes to `requirements-grilling`; in the other cases the active owner works directly.
+
+ROSE/`aili-delivery-flow` owns lifecycle state, approvals, writeback, and verification. This skill does not invoke research, requirements, test-plan, review, security, or another process skill. It returns one concrete need or material delta to ROSE and stops. Canonical approval and verification rules win any conflict.
+
+## Loop Limit
+
+Run exactly one bounded challenge pass per trigger.
+
+Stop earlier when:
+
+- all material loopholes are resolved
+- remaining issues are explicitly marked `Open Question` or `Unverified`
+- further work would only produce wording tweaks, low-risk nitpicks, or speculative concerns
+
+If a material issue remains, return it to ROSE; do not start a second pass or another process skill automatically.
+
+## Process
+
+For each loop:
+
+1. Restate the current strategy, spec, plan, review, interview packet, or completion claim in one short paragraph.
+2. Ask whether it is factually supported enough to proceed.
+3. If not, list only material loopholes that could change scope, design, task order, acceptance criteria, verification, security, privacy, reliability, rollout, or user decisions.
+4. Classify each loophole as one of: Missing evidence, Hidden assumption, Counterexample, Edge case, Contradiction, Dependency/order problem, Security/privacy/reliability risk, Verification gap, or User decision required.
+5. For each loophole, choose one repair action: edit the current artifact, inspect targeted repository evidence, return an exact source need to ROSE, ask through the canonical owner, defer as `Open Question`, or mark as `Unverified`.
+6. Apply fixes only when they are within scope, allowed by the current mode, and supported by evidence.
+7. Return remaining material loopholes to ROSE and stop.
+
+## Adversarial Lenses
+
+When the artifact is non-trivial, stress-test it through these lenses without turning the output into a long debate:
+
+1. Pragmatist Skeptic
+   - What can be deleted?
+   - Is this over-engineered?
+   - Is this abstraction premature?
+2. Integration Validator
+   - What adjacent module, state transition, failure path, or regression is missing?
+   - What test proves this?
+3. Evidence Researcher
+   - Which claims are unsupported?
+   - Which claims need repository evidence, official docs, or user confirmation?
+4. Architect
+   - Does this violate boundaries?
+   - Does it introduce coupling or future maintenance debt?
+5. Creative Challenger
+   - Is there a simpler, more direct, or less invasive path?
+   - Is there a better artifact shape?
+
+Keep only material findings in the final stress-test result.
+
+If the needed tool or skill is unavailable:
+
+- perform the compact check inline when possible
+- mark only the affected claim as `Unverified`
+- mention tool unavailability only when it changes the result or blocks verification
+
+## Evidence Rules
+
+Use evidence before confidence.
+
+Carry the global Evidence-Driven Claim Hygiene rule into the stress test: tag every claim in stress-test conclusions, use `CONFIDENCE: HIGH | MED | LOW | VERY LOW | UNKNOWN` for internal reports, localize user-facing tags/confidence labels when available, and treat anti-sycophancy red flags such as an unusually elegant explanation, one pattern explaining everything, agreement after pushback without evidence, or specifics for unearned authority as reasons to cut specifics, add `[GUESS]`, or say `I don't know.`
+
+Valid evidence can include:
+
+- user-confirmed answers
+- current spec, design, tasks, or acceptance docs
+- repository source files, tests, schemas, configs, logs, or diffs
+- official documentation or current web sources when external behavior matters
+- fresh verification command output
+- reconciled subagent evidence with anchors
+
+Invalid evidence:
+
+- intuition
+- stale logs
+- partial output not read fully
+- unverified assumptions
+- `should work` language
+- subagent conclusions without evidence anchors
+
+## 🛑 Anti-Pattern Blacklist
+
+Stop and repair the stress test if it does any of these:
+
+- Manufactures certainty to satisfy a requested confidence level.
+- Replaces missing evidence with confident tone, generic best practice, or “likely”.
+- Treats a passing narrow check as proof of broad readiness.
+- Hides unresolved user decisions inside assumptions.
+- Ignores counter-evidence because it complicates the plan or final claim.
+- Runs more loops only to polish wording instead of resolving material loopholes.
+- Reports subagent conclusions without anchors or conflict reconciliation.
+
+Fallback: downgrade confidence, mark the affected item `Open Question` or `Unverified`, and choose a concrete repair action from the process table.
+
+## Output Contract
+
+Return this structure when reporting the stress-test result:
+
+```text
+CONFIDENCE: HIGH | MED | LOW | VERY LOW | UNKNOWN
+
+Current artifact / claim:
+- ...
+
+Material loopholes found:
+- [Category] Loophole:
+  Evidence gap:
+  Proposed fix:
+  Status: fixed | ask_user | inspect_code | fetch_docs | open_question | unverified
+
+Fixes applied:
+- ...
+
+Remaining open questions:
+- Open Question: ...
+
+Remaining unverified items:
+- Unverified: ...
+
+Evidence used:
+- ...
+
+Safe to proceed: yes | no | conditional
+Reason:
+- ...
+```
+
+## Integration Rules
+
+When ROSE selects this as the one bounded auxiliary pass for a primary artifact owner:
+
+- Do not replace the caller skill.
+- Do not invoke another skill or continue into another lifecycle loop.
+- Do not write files unless the caller skill and current mode allow edits.
+- Keep the output compact enough to paste into a final report or artifact appendix.
+- Prefer editing the artifact to adding a long critique when the fix is obvious and allowed.
+
+## Example: Compact Embedded Use
+
+Input artifact:
+
+- Plan says: "Implement auth callback handling and update tests."
+
+Stress-test result:
+
+- CONFIDENCE: MED
+- Material loophole: Verification gap - plan does not name the callback error cases or tests.
+- Fix applied: add tasks for invalid state, expired code, provider error, and existing callback test file inspection.
+- Remaining unverified: exact test command until package scripts are inspected.
+- Safe to proceed: conditional.