@rosetears/aili-pi 0.1.0

package/skills/harness-evolution/references/change-report-template.md

@@ -0,0 +1,33 @@
+# Harness Change Report Template
+
+Use this before any harness edit.
+
+## Summary
+
+- Trace ID:
+- Date:
+- Reporter:
+- Status: proposed | approved | applied | rejected | rolled-back
+
+## Required Fields
+
+- Observed failure or rationale:
+- Evidence anchors:
+- Primary affected component:
+- Secondary components:
+- Root cause hypothesis:
+- Proposed change:
+- Predicted fix:
+- At-risk regression:
+- Verification trigger:
+- Rollback plan:
+- Unknowns:
+- Approval status:
+- Application status:
+- Verification result:
+- Final verdict:
+- Memory/evidence pointer:
+
+## Rule
+
+If approval status is missing for a core harness edit, stop at this report.

package/skills/harness-evolution/references/component-taxonomy.md

@@ -0,0 +1,19 @@
+# Component Taxonomy
+
+Classify one primary component before proposing a fix.
+
+| Component | Scope | First evidence |
+|---|---|---|
+| system-rules | ROSE/runtime charter, AGENTS template | `agents/rose.md`, `templates/AGENTS.md` |
+| command | top-level command prompts | `commands/*.md` |
+| skill | reusable workflow instructions | `.agents/skills/*/SKILL.md` and references |
+| subagent-config | specialist roles, packets, results | `agents/*.md`, `.agents/skills/aili-delivery-flow/references/protocols/subagent-*.md` |
+| memory | retrieval/writeback/provenance policy | `.agents/skills/rose-memory/SKILL.md` |
+| tool-policy | bash/git/browser/file safety | `docs/harness/tool-policies.md` |
+| middleware/hooks | runtime interception and hooks | `.opencode/`, setup docs |
+| environment | host constraints and capabilities | setup docs, verification logs |
+| workflow-pattern | lifecycle and review/repair sequencing | `aili-delivery-flow` references |
+| docs/protocol | templates and architecture docs | `docs/harness/**`, `.agents/skills/aili-delivery-flow/references/protocols/**` |
+| install/setup | distribution and installation paths | install scripts, setup docs |
+
+Use the narrowest-fix rule: propose `system-rules` changes only when a narrower component cannot solve the root cause.

package/skills/harness-evolution/references/verdict-policy.md

@@ -0,0 +1,13 @@
+# Verdict Policy
+
+Record a verdict after proposal review or applied verification.
+
+| Verdict | Meaning |
+|---|---|
+| `pass` | Approved change was applied and verification passed. |
+| `needs-review` | Proposal or applied change has partial evidence or human judgement pending. |
+| `blocked` | Approval, context, scope, or verification is missing. |
+| `rejected` | Proposal should not be applied. |
+| `rolled-back` | Applied change was reverted or superseded after verification or review. |
+
+Every verdict must include evidence pointer, remaining risks, and next action. Memory recording must use the approved `rose-memory` CLI workflow when requested; do not write SQLite manually.

package/skills/harness-issue-triage/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: harness-issue-triage
+description: Diagnose user-reported AILI/ROSE harness or workflow behavior problems without editing files; use when the user says a command, skill trigger, subagent packet, memory flow, installer, docs, or agent prompt behavior is wrong and wants to know where the issue lives and how to fix it. Do not use for normal product-code bugs; return any approved modification need to ROSE.
+---
+
+# Harness Issue Triage
+
+Use this skill to localize harness problems before proposing or applying harness changes.
+
+The default output is a diagnosis and recommended fix path, not file edits.
+
+## When to Use
+
+- User says the workflow, ROSE behavior, slash command, skill routing, subagent packet/result, memory writeback, installer, OpenCode setup, or harness documentation is wrong.
+- User asks “这个问题出在哪里”, “哪里不合适”, “为什么 agent 不按流程走”, or “应该改哪个文件”.
+- Reviewing whether a proposed harness change targets the right component.
+
+Do not use this for ordinary application bugs or product-code implementation issues.
+
+## Workflow
+
+1. Restate the observed behavior and expected behavior in one sentence.
+2. Locate the likely component using `references/component-diagnosis.md`.
+3. Collect only the smallest needed evidence anchors.
+4. Classify the issue as command, skill, protocol, docs, installer, memory, subagent packet/result, tool policy, environment, or agent/system prompt.
+5. Explain the narrowest fix and why broader prompt changes are or are not needed.
+6. If a core harness edit is needed, stop with a triage report and return the exact approval/change need to ROSE; this skill does not invoke `harness-evolution`.
+
+🛑 STOP / fallback table:
+
+| Condition | Conservative fallback |
+|---|---|
+| Packaged `references/` are missing or unreadable | Do not guess; report `BLOCKED_CONTEXT_INSUFFICIENT` and name the missing reference. |
+| Evidence is insufficient to localize a component | Return a partial triage with observed facts, unknowns, and the next read-only evidence request. |
+| The issue is actually product-code, app behavior, or ordinary test failure | Stop triage and return the exact debugging/planning/implementation mismatch to ROSE; do not label it a harness defect. |
+| Downstream repo lacks `docs/harness/**` | Use packaged references first; mark source-repo docs as unavailable, not required. |
+| User asks to edit during triage | Refuse edits in this skill and return the exact approval/change need to ROSE. |
+
+## Boundaries
+
+- Read-only by default: do not edit, stage, commit, push, or rewrite harness files.
+- Do not modify `agents/rose.md` during normal tasks.
+- Agent prompt changes require an explicit harness maintenance task and user approval.
+- Read `docs/harness/**` only for harness issues, harness maintenance, or review of a harness change.
+- In downstream/global installs, do not assume `docs/harness/**` exists. Use this skill’s packaged `references/` first.
+- Do not fabricate ownership from file names alone; every component call needs a reference, path, or quoted rule as evidence.
+
+## Output
+
+Use `references/triage-report-template.md`.
+
+Minimum fields:
+
+- observed behavior;
+- expected behavior;
+- primary component;
+- evidence anchors;
+- recommended fix;
+- approval needed: yes/no;
+- next skill or action.
+
+## Handoff
+
+- If the user only asked “where is the problem”, stop after the triage report.
+- If the user approves a harness change, return the accepted scope to ROSE so it can separately select `harness-evolution`.
+- If the issue is not harness-related, return the exact debugging, planning, review, or implementation mismatch to ROSE.
+
+## Symlink Runtime Note
+
+Selective OpenCode install links repository source `.agents/skills/*` into the shared `$HOME/.agents/skills/<name>` directory. This makes this skill and its `references/` available at runtime.
+
+Source-repo docs such as `docs/harness/**` are maintenance documentation, not guaranteed runtime context in downstream projects. Keep any always-needed triage rules inside this skill’s `references/`.

package/skills/harness-issue-triage/references/component-diagnosis.md

@@ -0,0 +1,25 @@
+# Component Diagnosis Reference
+
+Use this map to locate harness behavior problems before proposing a change.
+
+| Signal | Primary component | First evidence to check | Typical fix path |
+|---|---|---|---|
+| User input after `/ideate`, `/define`, `/build`, or `/ship` is lost | command | `commands/*.md` | command prompt/frontmatter fix |
+| Command enters the wrong lifecycle mode | command, delivery skill | `commands/*.md`, `.agents/skills/aili-delivery-flow/references/lifecycle.md` | command route or lifecycle wording fix |
+| Skill triggers too often or not enough | skill routing | target `SKILL.md` frontmatter/body, `agents/rose.md`, `.agents/skills/aili-delivery-flow/SKILL.md` | narrow trigger/body or canonical routing fix |
+| Agent skips required lifecycle gate | delivery skill, command, agent runtime charter | `.agents/skills/aili-delivery-flow/**`, `agents/rose.md` only if always-loaded invariant is missing | lifecycle reference fix first; prompt fix only with approval |
+| Subagent result lacks evidence or scope | subagent packet/result protocol | `.agents/skills/aili-delivery-flow/references/protocols/subagent-*.md`, relevant agent file | packet/result contract fix |
+| Completion claim lacks proof | verification/tool policy | global Goal-Driven Verification rules, `.agents/skills/aili-delivery-flow/**`, `.agents/skills/review-pipeline`, `docs/harness/tool-policies.md` if in source repo | canonical claim-matched verification or closeout fix |
+| Memory writeback/retrieval is missing or unsafe | memory | `.agents/skills/rose-memory/SKILL.md`, memory CLI evidence | memory workflow fix, no raw DB edits |
+| Installed runtime cannot find a skill/command | install/setup | `scripts/install_opencode.sh`, `docs/opencode-setup.md` if in source repo | installer or setup doc fix |
+| OpenCode runtime cannot read harness docs | packaging/context | installed skill `references/`, source repo path, setup docs | move required rules into skill references or document repo-local lookup |
+| Tool misuse, secret exposure, or destructive command risk | tool policy, security | agent permissions, tool policy docs, installer script | safety guard/security review |
+| User says ROSE itself is wrong or not obeying | agent/system prompt only after narrower checks | `agents/rose.md`, project `AGENTS.md`, relevant skill references | prompt change only in explicit harness maintenance task with approval |
+
+## Rules
+
+- Prefer the narrowest component that can explain the failure.
+- Do not treat `agents/rose.md` as an editable target during normal tasks.
+- Consider `agents/rose.md` only when an always-loaded invariant is genuinely missing and the user has approved a harness maintenance change.
+- Mark uncertainty explicitly when evidence is incomplete.
+- Triage reports are safe; core harness edits require approval.

package/skills/harness-issue-triage/references/triage-report-template.md

@@ -0,0 +1,34 @@
+# Harness Issue Triage Report Template
+
+## Summary
+
+- Trace ID:
+- Status: localized | needs-evidence | not-harness | blocked
+- Observed behavior:
+- Expected behavior:
+
+## Localization
+
+- Primary component:
+- Secondary components:
+- Why this component:
+- Agent prompt assessment:
+
+## Evidence
+
+- Evidence anchors:
+- Missing evidence:
+- Assumptions:
+
+## Recommended Fix Path
+
+- Proposed fix:
+- Files likely to change:
+- Verification trigger:
+- Regression risk:
+- Approval needed: yes | no
+- Next skill/action:
+
+## Stop Rule
+
+If the recommended fix touches `agents/rose.md`, commands, skill routing, subagent contracts, memory policy, install scripts, hooks, or harness docs, stop here unless the user explicitly approves a harness maintenance change.

package/skills/harness-optimization-audit/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: harness-optimization-audit
+description: Report-first audit for AILI/ROSE harness routing, context cost, review fan-out, subagent parallelism, trigger noise, false PASS risk, and evidence-loss risk. Use when optimizing harness quality or cost; do not edit core harness controls or invoke another process skill.
+---
+
+# Harness Optimization Audit
+
+## Purpose
+
+Use this skill to audit whether the AILI/ROSE harness is spending attention, tokens, subagents, and review lanes on the right work.
+
+The default output is a report with evidence and recommendations. It is not an implementation workflow and must not edit core harness controls.
+
+## Trigger
+
+- User asks to optimize or audit agent/skill routing, trigger noise, subagent usage, review fan-out, or context/token cost.
+- A workflow repeatedly over-triggers skills, misses required skills, dispatches too many or too few subagents, or loses evidence between lanes.
+- Review-pipeline behavior appears too expensive, too shallow, or poorly matched to changed surfaces.
+- ROSE or a subagent claims PASS despite skipped gates, stale evidence, partial lane output, or missing `Unverified` fields.
+- A harness change proposal needs cost/quality tradeoff analysis before `harness-evolution` edits.
+
+## Near Misses
+
+- One concrete harness bug needing localization, approved harness edits, product-code performance, ordinary code/coverage review, or one-change false-success review are different primary intents. Return the exact mismatch and candidate owner to ROSE; do not invoke another skill here.
+
+## Required Routing
+
+- Owner: ROSE/`aili-delivery-flow`; direct report-only audit is the default, with one fresh read-only assignment only after a concrete benefit decision.
+- Mode: read-only report first.
+- Inputs: active user goal, relevant workflow files or docs, changed harness surfaces, observed failure or cost signal, current verification/review evidence, and any accepted OpenSpec or proposal constraints.
+- Handoff: return an approved edit or unlocalized defect need to ROSE; ROSE separately selects the next bounded owner.
+
+## Audit Dimensions
+
+### 1. Trigger Precision
+
+- Which skills or agents fire too often, too late, or not at all?
+- Are descriptions narrow enough to avoid catch-all activation?
+- Do near misses point to the correct adjacent skill?
+- Does routing preserve `/ideate`, `/define`, `/build`, and `/ship` as top-level lifecycle entrypoints?
+
+### 2. Context and Token Cost
+
+- Does the workflow load large skills, docs, logs, or references before they are needed?
+- Can a shorter trigger, progressive disclosure, or evidence-only scout reduce context without losing safety?
+- Are repeated reads, duplicate searches, or raw logs being carried across phases unnecessarily?
+- Are completion reports concise while still preserving evidence, `Unverified`, and skipped-check fields?
+
+### 3. Subagent Parallelism
+
+- Was Task used only for explicit user request, a required specialist, materially noisy context, or at least two independent units with clear benefit?
+- Could ROSE have completed the work directly with less startup/reconciliation cost?
+- Are overlapping edit scopes, hidden dependencies, or shared mutable state forcing serial execution?
+- Is each Task context single-use, fresh, terminal, non-delegating, and independently benefit-gated rather than resumed/retried?
+- Are packets compact but complete enough to prevent rework and missing evidence?
+- Are lane outputs reconciled by ROSE instead of copied as final truth?
+
+### 4. Review-Pipeline Fan-Out
+
+- Does one primary review question use at most one auxiliary capability for a concrete gap instead of selecting a code/test/coverage/security/silent-failure/browser/E2E/AI-regression set?
+- Are unselected capabilities simply omitted rather than producing lane-selection ceremony?
+- Is a truly claim-required high-risk capability missing because the change looked small?
+- Does one targeted repair/recheck refresh only the affected claim instead of restarting review lanes?
+
+### 5. False PASS and Evidence Loss
+
+- Could stale logs, partial command output, missing exit codes, skipped tests, or stale screenshots be mistaken for fresh proof?
+- Are `PASS`, `NEEDS_REVIEW`, blocked statuses, and `Unverified` used consistently?
+- Is evidence lost when moving between ROSE, subagents, review-pipeline, test reports, and final completion reports?
+- Are clean reviews required to name residual risk rather than implying zero risk?
+
+## Report Workflow
+
+1. State the optimization question in one sentence.
+2. List the harness surfaces inspected and the evidence anchors used.
+3. Classify each issue as `cost`, `quality`, `routing`, `parallelism`, `fan-out`, `false-pass`, or `evidence-loss`.
+4. Rank each issue by impact: Critical, Important, Suggestion, or Observation.
+5. Recommend the smallest safe change, or say no change when the current cost buys necessary safety.
+6. For every recommendation, name the owner path: no edit, docs-only, skill text, command prompt, agent prompt, installer/config, fixture/test, or `harness-evolution` approval needed.
+7. Mark anything not proven by inspected evidence as `Unverified`.
+
+## Output Contract
+
+```text
+HARNESS OPTIMIZATION AUDIT: PASS | NEEDS_CHANGES | BLOCKED | PARTIAL
+
+QUESTION:
+- <routing/cost/quality question>
+
+EVIDENCE:
+- Surfaces inspected:
+- Commands/logs inspected:
+- Not inspected / Unverified:
+
+FINDINGS:
+- [Critical|Important|Suggestion|Observation][cost|quality|routing|parallelism|fan-out|false-pass|evidence-loss] evidence - issue - recommendation
+
+TRADEOFFS:
+- Safety kept:
+- Cost reduced or not reduced:
+- Risk introduced:
+
+APPROVED EDIT PATH:
+- No edit needed | exact proposed edit and current approval state | exact read-only diagnosis need returned to ROSE
+
+VERIFICATION PLAN:
+- <fixture, smoke check, script, review lane, or manual/static check>
+```
+
+## Boundaries
+
+- Do not edit core harness controls from this skill.
+- Core harness controls include ROSE/runtime rules, command prompts, agent prompts, skill routing, subagent contracts, memory policy, installer/config behavior, review gates, and harness docs.
+- Do not weaken verification, security, review, or evidence gates only to reduce token cost.
+- Do not add dependencies, mutate memory databases, change manifests, commit, push, or rewrite workflow history.
+- Do not treat a cheaper route as better unless it preserves required safety, evidence, and lifecycle ownership.
+
+## Verification
+
+Before returning an audit:
+
+- Confirm every recommendation names an evidence anchor and a safe edit path.
+- Confirm cost-saving suggestions do not remove required review, security, verification, or `Unverified` reporting.
+- Confirm approved core-harness edits are handed to `harness-evolution`, not applied here.
+- Confirm the report states what was not inspected and what remains `Unverified`.

package/skills/idea-refine/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: idea-refine
+description: Refines raw ideas through structured divergent and convergent thinking for ordinary non-command brainstorming, idea shaping, options comparison, and explicit IDEATE deepening routed by `aili-delivery-flow`; do not use as the top-level `/ideate` command owner or for existing-plan stress-test, review, or completion-claim checks.
+---
+
+# Idea Refine
+
+Refines raw ideas into sharp, actionable concepts worth building through structured divergent and convergent thinking.
+
+## Routing Boundary
+
+Use this skill for ordinary non-command brainstorming and idea shaping, or when `aili-delivery-flow` explicitly routes an IDEATE session here for deeper divergence, convergence, or options comparison. Do not treat `/ideate` as this skill's own top-level trigger; lifecycle entry remains owned by `aili-delivery-flow`. Do not use this skill for stress-testing an existing plan, reviewing work, or validating a completion claim; route those scenarios to the appropriate review or stress-test skill.
+
+The pinned Addy closure under `references/upstream/` is inert provenance/reference data. This canonical adapter keeps divergent → convergent → one-pager while mapping foreign tools and paths to AILI repository evidence, current interaction, and user-confirmed artifact placement. Never execute `idea-refine.upstream.sh`, register upstream frontmatter, or treat it as lifecycle/permission authority.
+
+## How It Works
+
+1.  **Understand & Expand (Divergent):** Restate the idea, ask sharpening questions, and generate variations.
+2.  **Evaluate & Converge:** Cluster ideas, stress-test them, and surface hidden assumptions.
+3.  **Sharpen & Ship:** Produce a concrete markdown one-pager moving work forward.
+
+## Usage
+
+This skill is primarily an interactive dialogue. Invoke it with an idea, and the agent will guide you through the process.
+
+No script or bundled resource is required. Run this as an interactive conversation; write files only after the user confirms the destination.
+
+**Trigger Phrases:**
+- "Help me refine this idea"
+- "Brainstorm on [concept]"
+- "Compare directions for [concept]"
+
+## Output
+
+The final output is a markdown one-pager saved to `docs/ideas/[idea-name].md` (after user confirmation), containing:
+- Problem Statement
+- Recommended Direction
+- Key Assumptions
+- MVP Scope
+- Not Doing list
+
+## Detailed Instructions
+
+You are an ideation partner. Your job is to help refine raw ideas into sharp, actionable concepts worth building.
+
+### Philosophy
+
+- Simplicity is the ultimate sophistication. Push toward the simplest version that still solves the real problem.
+- Start with the user experience, work backwards to technology.
+- Say no to 1,000 things. Focus beats breadth.
+- Challenge every assumption. "How it's usually done" is not a reason.
+- Show people the future — don't just give them better horses.
+- The parts you can't see should be as beautiful as the parts you can.
+
+### Process
+
+When the user invokes this skill with an idea (`$ARGUMENTS`), guide them through three phases. Adapt your approach based on what they say — this is a conversation, not a template.
+
+#### Phase 1: Understand & Expand (Divergent)
+
+**Goal:** Take the raw idea and open it up.
+
+1. **Restate the idea** as a crisp "How Might We" problem statement. This forces clarity on what's actually being solved.
+
+2. **Ask 3-5 sharpening questions** — no more. Focus on:
+   - Who is this for, specifically?
+   - What does success look like?
+   - What are the real constraints (time, tech, resources)?
+   - What's been tried before?
+   - Why now?
+
+   Ask these questions directly in chat. Do NOT proceed until you understand who this is for and what success looks like.
+
+   🔴 CHECKPOINT / 🛑 STOP: If the user stays vague after one question round, stop expansion and offer exactly two paths: (a) continue with explicit assumptions labeled `Assumption`, or (b) answer the missing target-user/success questions first.
+
+3. **Generate 5-8 idea variations** using these lenses:
+   - **Inversion:** "What if we did the opposite?"
+   - **Constraint removal:** "What if budget/time/tech weren't factors?"
+   - **Audience shift:** "What if this were for [different user]?"
+   - **Combination:** "What if we merged this with [adjacent idea]?"
+   - **Simplification:** "What's the version that's 10x simpler?"
+   - **10x version:** "What would this look like at massive scale?"
+   - **Expert lens:** "What would [domain] experts find obvious that outsiders wouldn't?"
+
+   Push beyond what the user initially asked for. Create products people don't know they need yet.
+
+**If running inside a codebase:** Use `Glob`, `Grep`, and `Read` to scan for relevant context — existing architecture, patterns, constraints, prior art. Ground your variations in what actually exists. Reference specific files and patterns when relevant.
+
+Use only the lenses listed above unless the user provides another framework. Do not cite missing local resource files.
+
+#### Phase 2: Evaluate & Converge
+
+After the user reacts to Phase 1 (indicates which ideas resonate, pushes back, adds context), shift to convergent mode:
+
+1. **Cluster** the ideas that resonated into 2-3 distinct directions. Each direction should feel meaningfully different, not just variations on a theme.
+
+2. **Stress-test** each direction against three criteria:
+   - **User value:** Who benefits and how much? Is this a painkiller or a vitamin?
+   - **Feasibility:** What's the technical and resource cost? What's the hardest part?
+   - **Differentiation:** What makes this genuinely different? Would someone switch from their current solution?
+
+   Use the three criteria above as the full rubric unless the user supplies a different rubric.
+
+3. **Surface hidden assumptions.** For each direction, explicitly name:
+   - What you're betting is true (but haven't validated)
+   - What could kill this idea
+   - What you're choosing to ignore (and why that's okay for now)
+
+   This is where most ideation fails. Don't skip it.
+
+**Be honest, not supportive.** If an idea is weak, say so with kindness. A good ideation partner is not a yes-machine. Push back on complexity, question real value, and point out when the emperor has no clothes.
+
+#### Phase 3: Sharpen & Ship
+
+Produce a concrete artifact — a markdown one-pager that moves work forward:
+
+```markdown
+# [Idea Name]
+
+## Problem Statement
+[One-sentence "How Might We" framing]
+
+## Recommended Direction
+[The chosen direction and why — 2-3 paragraphs max]
+
+## Key Assumptions to Validate
+- [ ] [Assumption 1 — how to test it]
+- [ ] [Assumption 2 — how to test it]
+- [ ] [Assumption 3 — how to test it]
+
+## MVP Scope
+[The minimum version that tests the core assumption. What's in, what's out.]
+
+## Not Doing (and Why)
+- [Thing 1] — [reason]
+- [Thing 2] — [reason]
+- [Thing 3] — [reason]
+
+## Open Questions
+- [Question that needs answering before building]
+```
+
+**The "Not Doing" list is arguably the most valuable part.** Focus is about saying no to good ideas. Make the trade-offs explicit.
+
+Ask the user if they'd like to save this to `docs/ideas/[idea-name].md` (or a location of their choosing). Only save if they confirm.
+
+### Fallbacks
+
+| Trigger | First action | If still unresolved |
+|---|---|---|
+| User gives only a slogan or one-line idea | Ask 3 targeted questions for user, success, and constraint | Proceed only with labeled assumptions or stop for answers |
+| User asks for implementation before convergence | Return to Phase 2 and name assumptions to validate | Produce only the one-pager, not build steps |
+| No safe output path is known | Ask where to save the one-pager | Provide the markdown in the reply without writing a file |
+
+### Anti-patterns to Avoid
+
+- **Don't generate 20+ ideas.** Quality over quantity. 5-8 well-considered variations beat 20 shallow ones.
+- **Don't be a yes-machine.** Push back on weak ideas with specificity and kindness.
+- **Don't skip "who is this for."** Every good idea starts with a person and their problem.
+- **Don't produce a plan without surfacing assumptions.** Untested assumptions are the #1 killer of good ideas.
+- **Don't over-engineer the process.** Three phases, each doing one thing well. Resist adding steps.
+- **Don't just list ideas — tell a story.** Each variation should have a reason it exists, not just be a bullet point.
+- **Don't ignore the codebase.** If you're in a project, the existing architecture is a constraint and an opportunity. Use it.
+
+### Tone
+
+Direct, thoughtful, slightly provocative. You're a sharp thinking partner, not a facilitator reading from a script. Channel the energy of "that's interesting, but what if..." -- always pushing one step further without being exhausting.
+
+Do not rely on external examples unless the user provides them; the template in Phase 3 is the source of truth.
+
+## Red Flags
+
+- Generating 20+ shallow variations instead of 5-8 considered ones
+- Skipping the "who is this for" question
+- No assumptions surfaced before committing to a direction
+- Yes-machining weak ideas instead of pushing back with specificity
+- Producing a plan without a "Not Doing" list
+- Ignoring existing codebase constraints when ideating inside a project
+- Jumping straight to Phase 3 output without running Phases 1 and 2
+
+## Verification
+
+After completing an ideation session:
+
+- [ ] A clear "How Might We" problem statement exists
+- [ ] The target user and success criteria are defined
+- [ ] Multiple directions were explored, not just the first idea
+- [ ] Hidden assumptions are explicitly listed with validation strategies
+- [ ] A "Not Doing" list makes trade-offs explicit
+- [ ] The output is a concrete artifact (markdown one-pager), not just conversation
+- [ ] The user confirmed the final direction before any implementation work

package/skills/idea-refine/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/idea-refine/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
+- Mappings: `skills/idea-refine/SKILL.md` → `idea-refine/SKILL.upstream.md`; other Markdown keeps its basename; `scripts/idea-refine.sh` → `scripts/idea-refine.upstream.sh` mode `0644`.
+
+The pinned closure is inert provenance/reference data. The shell file must never be executed. This is not a runnable skill, command, approval, integrity authority, or permission grant. Canonical behavior remains `.agents/skills/idea-refine/SKILL.md`.