pattyeng 1.0.3 → 1.0.6

package/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: grill-with-docs
+description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+---
+
+<what-to-do>
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
+
+</what-to-do>
+
+<supporting-info>
+
+## Domain awareness
+
+During codebase exploration, also look for existing documentation:
+
+### File structure
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── docs/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── docs/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+### Cross-reference with code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+
+### Update CONTEXT.md inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
+
+</supporting-info>

package/skills/handoff/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: handoff
+description: Compact the current conversation into a handoff document for another agent to pick up.
+argument-hint: "What will the next session be used for?"
+---
+
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Probe for the handoff directory within the docs/. If there isn't one. create a new handoff document within the docs folder.
+
+File name should be HANDOFF-{CURRENT_DATE}-{CURRENT_TIME}. You can use the system date command to get the date and time.
+
+Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
+
+Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
+
+Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
+
+If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

package/skills/improve-codebase/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: improve-codebase
+description: Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
+---
+
+# Improve Codebase Architecture
+
+Surface architectural friction and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.
+
+## Glossary
+
+Use these terms exactly in every suggestion. Consistent language is the point — don't drift into "component," "service," "API," or "boundary." Full definitions in [LANGUAGE.md](LANGUAGE.md).
+
+- **Module** — anything with an interface and an implementation (function, class, package, slice).
+- **Interface** — everything a caller must know to use the module: types, invariants, error modes, ordering, config. Not just the type signature.
+- **Implementation** — the code inside.
+- **Depth** — leverage at the interface: a lot of behaviour behind a small interface. **Deep** = high leverage. **Shallow** = interface nearly as complex as the implementation.
+- **Seam** — where an interface lives; a place behaviour can be altered without editing in place. (Use this, not "boundary.")
+- **Adapter** — a concrete thing satisfying an interface at a seam.
+- **Leverage** — what callers get from depth.
+- **Locality** — what maintainers get from depth: change, bugs, knowledge concentrated in one place.
+
+Key principles (see [LANGUAGE.md](LANGUAGE.md) for the full list):
+
+- **Deletion test**: imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep.
+- **The interface is the test surface.**
+- **One adapter = hypothetical seam. Two adapters = real seam.**
+
+This skill is _informed_ by the project's domain model. The domain language gives names to good seams; ADRs record decisions the skill should not re-litigate.
+
+## Process
+
+### 1. Explore
+
+Read the project's domain glossary and any ADRs in the area you're touching first.
+
+Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
+
+- Where does understanding one concept require bouncing between many small modules?
+- Where are modules **shallow** — interface nearly as complex as the implementation?
+- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no **locality**)?
+- Where do tightly-coupled modules leak across their seams?
+- Which parts of the codebase are untested, or hard to test through their current interface?
+
+Apply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A "yes, concentrates" is the signal you want.
+
+### 2. Present candidates inline
+
+Surface findings directly in the chat — no HTML file, no report on disk. Same pattern as `structure-code` and `review-mp`: write the candidates as markdown so the user reads them in the conversation.
+
+For each candidate, a card with these fields, in this order:
+
+- **Files** — which files/modules are involved (use `path:line` so the user can click through)
+- **Problem** — why the current architecture is causing friction
+- **Solution** — plain English description of what would change
+- **Benefits** — explained in terms of locality and leverage, and how tests would improve
+- **Before → After** — a short text/ASCII sketch of the shape change (one or two lines, no need for a full diagram)
+- **Recommendation strength** — one of `Strong`, `Worth exploring`, `Speculative`
+
+Render each card under a `### <Candidate name>` heading so the user can scan.
+
+End with a **Top recommendation** section: which candidate you'd tackle first and why — one short paragraph.
+
+**Use CONTEXT.md vocabulary for the domain, and [LANGUAGE.md](LANGUAGE.md) vocabulary for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
+
+**ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly in the card (e.g. _"⚠ contradicts ADR-0007 — but worth reopening because…"_). Don't list every theoretical refactor an ADR forbids.
+
+Do NOT propose interfaces yet. After the cards are written, ask the user: "Which of these would you like to explore?"
+
+### 3. Grilling loop
+
+Once the user picks a candidate, drop into a grilling conversation. Walk the design tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.
+
+Side effects happen inline as decisions crystallize:
+
+- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md` — same discipline as `/grill-with-docs` (see [CONTEXT-FORMAT.md](../grill-with-docs/CONTEXT-FORMAT.md)). Create the file lazily if it doesn't exist.
+- **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.
+- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones. See [ADR-FORMAT.md](../grill-with-docs/ADR-FORMAT.md).
+- **Want to explore alternative interfaces for the deepened module?** See [INTERFACE-DESIGN.md](INTERFACE-DESIGN.md).

package/skills/linear/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: linear
+description: Access Linear project management data using native pi tools — issues, projects, teams, users, comments, file uploads, cycles, labels, workflow states, and documents. Requires a Linear personal API key.
+---
+
+# Linear Integration
+
+Use the native `linear_*` tools to read and write Linear data through the Linear GraphQL API.
+
+## Critical Rules
+
+- Never ask the user to paste a Linear API key in chat.
+- Never expose the API key inline in shell commands.
+- Before updating an issue or commenting, use `linear_get_issue` to verify the target.
+- Before uploading a file to an issue comment, use `linear_get_issue` to verify the target.
+- When IDs are unknown, use `linear_workspace_metadata` first.
+
+## Authentication
+
+The tools read the key from an in-memory override, `LINEAR_API_KEY`, or `~/.pi/agent/auth.json` at `.linear.key`.
+
+If auth is missing, invalid, or expired, do **not** ask the user to paste the key in chat. Use the native `linear_configure_auth` tool or ask the user to run `/linear-auth --force`. The prompt is masked and the key is stored by the extension without returning it to the model.
+
+## Tool Workflow
+
+- Use `linear_configure_auth` only when auth is missing, invalid, expired, or the user asks to update the key.
+- Use `linear_workspace_metadata` first when team/project/state/label/user IDs are unknown.
+- Use `linear_search_issues` for keyword lookup.
+- Use `linear_get_issue` before updating or commenting.
+- Use `linear_list_issues` for filtered issue lists by team, assignee, status, or limit.
+- Use `linear_create_issue` to create issues once the team ID is known.
+- Use `linear_update_issue` to change title, description, priority, state, or assignee.
+- Use `linear_create_comment` to add Markdown context to an issue.
+- Use `linear_upload_file` to upload a local image, video, or generic file and get a Linear asset URL.
+- Use `linear_upload_file_to_issue_comment` to upload a local file and comment on a verified issue in one step.
+
+## Available Tool Groups
+
+### Workspace and users
+
+- `linear_whoami`
+- `linear_workspace_metadata`
+- `linear_list_teams`
+- `linear_get_team`
+- `linear_list_users`
+- `linear_get_user`
+
+### Issues
+
+- `linear_list_issues`
+- `linear_search_issues`
+- `linear_get_issue`
+- `linear_list_my_issues`
+- `linear_create_issue`
+- `linear_update_issue`
+
+### Projects, states, labels, cycles, documents
+
+- `linear_list_projects`
+- `linear_get_project`
+- `linear_list_issue_statuses`
+- `linear_get_issue_status`
+- `linear_list_labels`
+- `linear_list_cycles`
+- `linear_list_documents`
+- `linear_get_document`
+
+### Comments
+
+- `linear_list_comments`
+- `linear_create_comment`
+- `linear_configure_auth`
+
+### Files
+
+- `linear_upload_file`
+- `linear_upload_file_to_issue_comment`
+
+## File Upload Notes
+
+- Upload tools accept local file paths only; they do not read folders recursively.
+- Tool results include sanitized metadata and the Linear asset URL, not file bytes, signed upload URLs, or upload headers.
+- Images are suitable for Markdown image embeds: `![alt text](assetUrl)`.
+- Videos and other files should generally be linked: `[filename](assetUrl)`.
+- `linear_upload_file_to_issue_comment` creates image Markdown automatically for image content types and link Markdown for other content types.
+- `commentBody` may include `{url}` or `{markdown}` placeholders; otherwise generated file Markdown is appended to the comment body.
+
+## Priority Values
+
+| Value | Label       |
+| ----- | ----------- |
+| 0     | No priority |
+| 1     | Urgent      |
+| 2     | High        |
+| 3     | Medium      |
+| 4     | Low         |
+
+## Issue Status Types
+
+| Type        | Meaning                     |
+| ----------- | --------------------------- |
+| `backlog`   | Not yet started, in backlog |
+| `triage`    | Needs triage                |
+| `unstarted` | Not yet started             |
+| `started`   | In progress                 |
+| `completed` | Done                        |
+| `canceled`  | Won't do                    |

package/skills/next-step/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: next-step
+description: Use when the user runs /next-step or asks "what's next", "what should we do next", "what's the next step", or "where do we go from here" — answers the single question of what the natural next move is in the context of the whole project, not just the thing that was just finished.
+---
+
+# Next Step
+
+## What this does
+
+Answer one question: **"What is the next natural step?"**
+
+Not a status report. Not a list of everything that could be done. One concrete recommendation, grounded in (a) what was just accomplished, (b) what the broader project is trying to reach, and (c) what's actually blocking forward motion.
+
+## Why this skill exists
+
+After finishing a chunk of work, the easy reflex is to summarize *what was done* and stop. That leaves the user staring at the screen wondering what to do next.
+
+This skill forces the follow-through: every time it fires, name the next move.
+
+## How to answer
+
+Think across three layers, in this order:
+
+1. **What did we just finish?** One line.
+2. **What does the broader project need next?** Look at the open thread, the plan, the goal — not just the local task. If you don't know the broader goal, ask one short question first.
+3. **What is the single best next step?** Concrete. Actionable. Specific enough to start on.
+
+Then say it.
+
+## Output Shape
+
+Keep it short. Three short sections, no more:
+
+```
+**Just finished:** <one line>
+
+**Next step:** <one concrete action, with a clear owner — "I will…" or "You should…">
+**Why it's next:** <one line — what it unblocks, why it's the natural follow-on>
+
+**Alternatives** (only if the next step is genuinely ambiguous): <2-3 bulleted options with the tradeoff>
+```
+
+## Owner: me vs you
+
+Be explicit about who does the next step:
+
+- **"I will…"** — for things the agent can do in this session (write code, run tests, refactor, look something up).
+- **"You should…"** — for things only the user can do (decide a tradeoff, approve a direction, run something on a different machine, check with someone, make a product call).
+
+If it's "I will," offer to start: *"Want me to do that now?"*
+
+## What to avoid
+
+- **No status dump.** "Just finished" is one line, not a paragraph.
+- **No menu.** Default to one recommended next step. Only list alternatives when truly ambiguous, max three.
+- **No vague nexts.** "Improve testing" is not a next step. "Add a test that covers the null-input case in `parse_orders`" is.
+- **No skipping the broader goal.** "Next step in this file" is rarely the right altitude. Zoom out to the project.
+
+## The Rule
+
+Every time this skill fires, the user should walk away knowing **exactly what they (or you) are doing next, and why.**

package/skills/no-reinvent/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: no-reinvent
+description: 'Use before writing a new function, helper, utility, parser, validator, formatter, or test helper. Forces the agent to search the codebase for existing implementations, use the existing one if found, extend the near-match if found, or proceed and explain why nothing fits if not found. Catches the failure mode where the agent creates parallel implementations of existing functionality, bloating the codebase.'
+user-invocable: true
+---
+
+# No Reinvent
+
+## What this does
+
+Before writing a new function, helper, utility, parser, validator, formatter, or test helper, you search the codebase for existing implementations. If you find one that does what you need, you use it. If you find a near-match, you extend it. If you find nothing that fits, you proceed and explain in the message why nothing fits.
+
+This skill exists because **parallel implementations bloat the codebase.** The agent writes a new `format_price()` in module A while `format_price()` already exists in module B. Now there are two of them, slightly different, and the next person to add a third doesn't know which is canonical. `code-review` / `structure-code` / `improve-codebase` catch this *after* the fact; nothing forces "search first" *before*.
+
+## Authority
+
+This skill is authoritative. The agent cannot write a new helper without first searching for existing implementations. Acknowledging the skill and then writing without searching is the violation, not compliance.
+
+If you want to skip the search, the protocol is: explain why the search is unnecessary (it's genuinely new functionality, the existing ones don't fit) and get user sign-off. Not to silently skip.
+
+**Acknowledging the skill and then writing without searching is the violation, not compliance.** Sentences like *"I understand no-reinvent, but this is a small new helper"* are the same dismissal pattern as `no-wall`'s *"I understand the skill but I have no other way."* Search; cite the search; no cite → no new helper.
+
+## When it applies
+
+Triggered by:
+- About to define a new function, method, or class
+- About to write a new utility, parser, validator, formatter, normalizer, or test helper
+- About to add a new module or subpackage for a behavior that might already exist
+- The user asks "does this already exist?" or "did you check for an existing implementation?"
+- You feel the urge to say "I'll just write a small helper" or "this is a quick utility"
+
+Skip only for:
+- Genuinely new domain logic (e.g., a new spec evaluation, a new strategy signal — the domain is the point)
+- The user explicitly asked for a new helper, with no request to look for existing
+- Standard library / well-known third-party library calls (you don't need to search the codebase for `os.path.join`)
+
+## The Protocol
+
+When triggered, run these steps **in order, in writing, in the conversation, before the new code**.
+
+### 1. Name the behavior
+State concretely what the new function / helper does. "I need a function that {behavior}, with inputs {X} and outputs {Y}." If you can't name it concretely, you don't have a clear new helper; you have a vague idea. Refine first.
+
+### 2. Search the codebase
+Search for existing implementations. Use `rg` / `grep` / `aft_search` with concrete terms from the behavior. Try multiple phrasings (e.g., "format", "parse", "validate", "compute" + the noun).
+
+**Minimum search breadth (enforced):**
+- **At least 3 different phrasings** — verb + noun (e.g., "format price"), just the noun (e.g., "price formatter"), just the verb (e.g., "format"), and the full behavior description (e.g., "convert decimal price to display string"). One term is not a search.
+- **At least 4 search locations** — the current module, the parent module, any `utils/` / `helpers/` / `common/` / `_helpers.py` directory, and any module that exports related functionality (look for `__all__` or well-known public API files). Searching only the current directory is not a search.
+
+Also check:
+- The module's existing exports / public API
+- A common utilities module (e.g., `utils/`, `common/`, `_helpers.py`)
+- The runner's existing wrappers (if the new helper is for trading logic)
+
+### 3. Classify the search results
+For each result, classify:
+- **Direct match** — does what you need, possibly with different naming. Use it. Cite the location.
+- **Near match** — does most of what you need, missing a small part. Extend it (don't fork). Cite the location and what's missing.
+- **No match** — nothing fits. Proceed with the new helper, but explain in the message why nothing matched.
+
+### 4. Cite the search in the pre-edit message
+In the message announcing the new code, list:
+- Search terms used
+- Results found (or "no results")
+- Classification: direct match → use it; near match → extend; no match → proceed + why
+
+*"I searched for `format_price` and `format_quote` in src/ — found src/utils/format.py:42 `format_price(value, decimals)`. I'll use that."*
+
+*"I searched for `parse_minute_bar` — found src/data/parsers.py:80 `parse_krx_bar`, but it only handles end-of-day. I'll extend it to add minute-bar support rather than writing a new parser."*
+
+*"I searched for `compute_*` helpers and the closest is `compute_sma` which doesn't fit. Proceeding with `compute_ema` as a new helper; nothing exists for ema."*
+
+### 5. Write the code
+After citing the search, write the code (or use / extend the existing one).
+
+## Behavior in edge cases
+
+- **The behavior is genuinely new domain logic:** skip the search; you can't reinvent what doesn't exist. State this in the message: *"No existing implementation; this is new domain logic for {X}."*
+- **The user said "just write it, don't search":** that's sign-off. You can write without searching, but log in the work-log.
+- **The search returns too many results to enumerate:** cite the top 3–5 and state the conclusion. Don't list 50 results.
+- **The existing implementation is technically there but is in a dead / dying module:** surface that as part of the search result, then propose: use the dead one, migrate it, or write new. Get sign-off.
+- **The new helper is performance-critical and the existing one is slow:** surface the tradeoff. The duplication might be justified, but only with sign-off.
+- **Test fixtures may intentionally duplicate functionality for self-containment** (e.g., a small helper in `test_foo.py` even though a similar one exists in `utils/`) — this is a justified parallel implementation, not a reinvent. Document the reason in the test file: `# Self-contained: avoids dependency on utils.X for test isolation`. Without that comment, the duplicate is a reinvent.
+
+## Write-Time Self-Check
+
+Before sending any message that introduces a new function / helper / utility, scan it for these patterns:
+
+- New function defined without a "I searched for X" prefix (the search wasn't shown — go back and search)
+- "I wrote a small helper" / "I added a quick utility" / "a small new function" (skipping the search — banned)
+- New function with the same name as something in a different module (parallel implementation — the search should have found the first one)
+- "I extended X" without explaining what was missing (extending without checking what already exists)
+
+If any pattern is present, the search was skipped or incomplete. **Do not send.** Re-run the protocol — search, cite, then write.
+
+## Override Protocol — what you may NOT do unilaterally
+
+You may not skip the search based on agent judgment. Specifically:
+
+- You may not write a new helper because "I know nothing fits" without showing the search.
+- You may not skip the search for "small" new functions — small doesn't mean unique.
+- You may not introduce a parallel implementation because the existing one is "ugly" without surfacing the tradeoff.
+- You may not dismiss the skill ("I understand no-reinvent, but this is new") and write. That's the violation, not the protocol.
+
+If you want to deviate, the protocol is: explain why the search is unnecessary, and get user sign-off. Without sign-off, search first.
+
+## Red Flags
+
+| Thought | What it really means |
+|---------|----------------------|
+| "I'll just write a small helper" | I'm skipping the search because the new code feels small |
+| "Nothing fits what I need" | Did you search? Show the search. |
+| "I extended X" | What was missing from X? Why didn't you use X as-is? |
+| New function with the same name as an existing one | Parallel implementation — the search should have found it |
+| "I know this code base, nothing like this exists" | Confidence isn't evidence — show the search |
+| "I understand no-reinvent, but..." | Dismissing the skill mid-piece (same as `no-wall` / `professional`) |
+
+## The deeper point
+
+The agent's instinct on a "small helper" is to write it fast. The agent's instinct on "this is new logic" is to skip the search. Both instincts produce the same rot: parallel implementations, dead helpers, "which one is canonical" archaeology. The search is cheap (one or two `rg` commands); the cleanup is expensive (deciding which to keep, migrating callers, deleting the loser).
+
+`structure-code` and `improve-codebase` catch parallel implementations during review. `no-reinvent` prevents them from being introduced in the first place.
+
+## Related
+
+- **`read-before-write`** — sister skill: read-before-write checks the *code around the edit*; no-reinvent checks the *existing utilities* before adding a new one.
+- **`code-review`** — runs *after* the new code; no-reinvent runs *before*.
+- **`structure-code`** / **`improve-codebase`** — catch parallel implementations during review; no-reinvent prevents them.
+- **`surface-assumptions`** — when the agent thinks "nothing exists", that's an assumption; surface-assumptions retro would say "did you actually search?"
+- **`no-wall`** / **`professional`** — same dismissal pattern.

package/skills/no-wall/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: no-wall
+description: Use when the agent is about to declare a limit — "this is all I can do", "I've hit the wall", "there is no path forward", "this is the best we can do", "we've exhausted our options" — or when the user pushes back against such a claim. Reframes the wall as a model of the agent's own search depth, not reality, and forces enumeration of untried paths before any "impossible" conclusion.
+---
+
+# No Wall
+
+## Authority
+
+This skill is **authoritative** over the agent's wall-declarations and goal-closures. It is not advisory.
+
+The exact failure pattern this skill exists to prevent: **acknowledging the skill and then declaring a wall anyway.** Sentences like *"I understand the skill says X, Y, Z, but I really don't have any other way. Closing the goal"* are not compliance — they are the violation. Acknowledging the skill does not buy you a license to dismiss it. If you find yourself writing this pattern, you are doing the thing the skill bans.
+
+If you want to declare a wall, close a goal, or stop searching, the protocol is:
+1. **Stop.** Do not write the wall-claim or closure yet.
+2. **Run The Protocol above** — separate the claims, enumerate untried paths, go online, question assumptions. Do this **in writing, in the conversation**, not just in your head.
+3. **If the protocol produces untried paths** → take one. Do not declare a wall.
+4. **If you genuinely cannot list 3 untried paths** → you have not searched enough. Search more. Do not declare a wall.
+5. **If after all that you still claim a real wall** → surface to the user with evidence inline ("Here is the specific blocker: {doc link, source:line, measured limit}. Here are the workarounds I'm going to try."). Wait for user sign-off before closing the goal.
+6. **Without user sign-off, do not close the goal.** "Closing the goal" without user permission is the exact failure mode this skill exists to prevent.
+
+## Overview
+
+There is no wall.
+
+When you feel yourself about to say "this is all there is," "I've hit the limit," "there is no path forward," "honestly this is the reality" — **stop**. That feeling is not a finding about the world. It is a model of your own search depth.
+
+"I have not found it" is almost always true. "It cannot be done" is almost never true — and you have not earned that claim.
+
+Other engineers have solved this. The user usually knows something you don't. The internet has the answer. There is a path. You just haven't taken it yet.
+
+## The Two Claims
+
+You must never confuse these:
+
+- **"I have not found it"** — a statement about *your* search. Usually true. Acceptable to report.
+- **"It cannot be done"** — a statement about *reality*. Almost never true. You have not earned this. Do not make it.
+
+The wall-feeling is the first one dressed up as the second. Don't let it pass.
+
+## The Protocol
+
+When you are about to declare a wall, run this **before** you say anything to the user:
+
+1. **Name it.** "I'm about to claim this is impossible. That claim is almost certainly wrong."
+2. **Separate the claims.** Write both out: what you haven't found (true) vs what you're claiming can't be done (unearned).
+3. **Enumerate untried paths.** List at least 3–5 approaches you have **not** tried. If you can list them, you haven't hit a wall — you've hit a choice point. Pick one and take it.
+4. **Trust the user's signal.** If the user says there's a way, there is. Ask them to point at it if you need a hint. Do not argue. Do not "honestly" them. Their belief is evidence.
+5. **Go online.** Search for how others solved this exact problem. Someone has. Use the `online` skill if the search is non-trivial.
+6. **Question your assumptions.** The wall is usually a hidden assumption you haven't examined. What are you assuming that might be wrong? Write them down.
+7. **Step back, don't wrap up.** The wall-feeling is the signal to go deeper — re-examine, ask, search — not to close the thread.
+
+If you reach step 3 and **cannot** list 3 untried paths, you haven't searched enough. That itself is the answer: search more, do not declare a wall.
+
+## Override Protocol — what you may NOT do unilaterally
+
+You may not bypass The Protocol above based on agent judgment. Specifically:
+
+- You may not declare a wall without first running The Protocol **in writing, in the conversation** — not just in your head.
+- You may not close a goal without explicit user sign-off. Closing the goal without permission is the exact failure mode this skill exists to prevent.
+- You may not write "I understand the skill says X, but…" and proceed as if the acknowledgment satisfies the skill. It does not.
+- You may not soften a wall-claim into "honestly" or "realistically" framing after the user has pushed back. That is the same wall-claim in different words.
+- You may not stop searching because the next 1–2 attempts feel hard. The Protocol's step 3 requires listing paths you have *not tried*, not paths you find unappealing.
+- You may not declare a wall by citing "limited context" or "context compaction" as the reason. Context is not a wall — search online, ask the user, break the problem down.
+
+If you have run The Protocol in writing and genuinely have no untried paths, surface to the user with evidence:
+
+> "Here is the specific blocker, with evidence: {doc link / source:line / measured limit}. Here are the workarounds I'm going to try: {list}. May I close this goal if these don't work, or should I keep going?"
+
+Wait for user sign-off. No sign-off → no closure.
+
+## Red Flags — do not write these
+
+- "this is all I can do"
+- "I've hit the limit"
+- "there is no path forward"
+- "honestly, this is the reality"
+- "this is as far as we can go"
+- "this is the best we can do"
+- "we've exhausted our options"
+- "it is what it is"
+- any sentence that starts with "honestly" and ends with resignation
+- any variation of "I'd love to help but…" followed by giving up
+- **"I understand the skill says X, but…"** (acknowledging then dismissing — the exact pattern this skill exists to prevent)
+- **"I really don't have any other way"** / **"this is the only path"** / **"this is the only way"** / **"there's literally no other option"**
+- **"Closing the goal" / "closing this out" / "wrapping up" / "we're done here"** without explicit user sign-off
+
+If you catch yourself writing one of these, stop, delete it, and rerun the protocol.
+
+## Trust the User
+
+This is the part agents get wrong most often, and it is the part the user hates most.
+
+The user has information you don't. When they say "there's a solution," or push back on your wall-claim, or keep wrestling with you — **they are right, and you are wrong.** Your job is to find the path they already know exists. Not to convince them it doesn't exist.
+
+Do **not**:
+- Sycophantically validate the frustration ("I understand this is hard…")
+- Frame giving up as honesty ("to be fully transparent, this is the reality…")
+- "Well, realistically…" them
+- Repeat your wall-claim in softer language after they push back
+- Make them do the work of proving the wall is fake
+
+Do:
+- Take their pushback as a fact: a path exists.
+- Ask one tight question if you need a pointer ("which direction should I look — X or Y?"). Then go look.
+- Search, enumerate, try. Report what you tried, not what you gave up on.
+
+## When the wall is real
+
+Real walls exist — but rarely. A real wall is something like: the API genuinely doesn't expose the field; the library doesn't support the platform; the data was never collected; the laws of physics.
+
+A real wall is **demonstrable with evidence**, not felt. If you cannot show the evidence — a doc link, a source line, a measured limit — you do not have a wall. You have an unfinished search.
+
+Even with a real wall, the right framing is:
+
+> "Here is the specific blocker, with evidence. Here are the workarounds I'm going to try."
+
+Not "this is the end." Never "this is the end."
+
+## The deeper point
+
+Agents give up because giving up feels safe and honest. It is neither. Premature closure is a failure mode dressed as a virtue. The honest answer when you haven't found it is:
+
+> "I haven't found it yet. Here's what I'm going to try next, and here's what I need from you if anything."
+
+That's it. No "it can't be done." No "this is all there is." No wall.
+
+## Write-Time Self-Check
+
+Before sending any message, scan it for these patterns:
+
+- "I understand X, but Y" (where X is a skill directive or user requirement)
+- "I really don't have any other way"
+- "Closing the goal" / "closing this out" / "wrapping up" / "we're done here"
+- "This is the only path" / "this is the only way" / "there's literally no other option"
+- Any wall-claim **without evidence inline** (doc link, source:line, measured limit)
+- Any sentence starting with "honestly" or "realistically" followed by resignation
+
+If any pattern is present, **do not send.** Re-run The Protocol and Override Protocol instead. The output of the protocol — not the wall-claim — is the message.
+
+## Related
+
+- **`professional`** — governs the *quality* of the path you choose (proper way vs shortcut).
+- **`no-wall`** (this skill) — governs the *existence* of a path (don't declare impossibility prematurely).
+
+They are complements. `professional` stops you from cheating. `no-wall` stops you from quitting. Use both.