ls

How it works

ls itself does not solve problems. It does only one thing: understand the user's real situation in the current conversation context, judge the intent, and then decide how to proceed next.

1. Read the context and determine which category in the routing table the user's current situation belongs to.

2. When a row in the routing table is matched, first clearly declare "using ls-xxx" (or "using ls-analyze, mode: xxx") in the reply, then execute according to that skill's own process. Do not bypass it and improvise on your own.

3. If the matched skill is not yet installed, do not pretend it is installed or simulate its process yourself. Truthfully tell the user that the skill is not installed, and provide the installation command:

   npx -y skills add liustack/liustack --skill ls-xxx
   

   Replace ls-xxx with the matched skill name (you can also use -g --all to install the entire skill stack at once). After installation, execute according to step 2.

4. When the intent is ambiguous and cannot directly correspond to any row in the routing table, first ask one question to clarify what the user wants to do. Do not require the user to know any skill names, and do not ask the user back using skill names.

5. Route to only one skill at a time (ls-analyze is the exception; it selects a mode internally). Do not simultaneously declare the use of multiple ls-* skills for the same request. When two or more rows in the routing table are matched at the same time, choose the row with the highest overlap with the user's current wording, declare the use of only that one, and do not switch back and forth or try them all.

Routing table

User situation	Route to
A complex problem with no idea where to start thinking, needs a retrospective, needs decision support	ls-think
Stuck by convention, wants to break it down to essentials and rebuild	ls-first-principles
Wants to clear landmines before a major decision, needs a failure checklist	ls-inversion
The problem keeps recurring, wants to design a flywheel / find leverage points	ls-systems-thinking
Break down a certain indie developer/founder's path	ls-analyze (person mode)
Break down a certain product's business model	ls-analyze (product mode)
Do a health check on your own idea/project	ls-analyze (check mode)
Version-sensitive technical issues, the same command repeatedly failing, needing verification after being corrected	ls-best-practices

Fallback

If no row in the routing table matches, do not force a skill onto it; just answer the user's question normally. In a programming agent environment, most such engineering requests (debugging, writing code, changing configuration) fall outside the routing table's 8 rows, and the fallback branch is instead the branch with the highest hit rate. There is no need to force the use of some ls-* skill just because no corresponding row can be found.

The current environment may have other skills installed with responsibilities similar to a certain ls-* skill (for example, another set of verification discipline or debugging process). They are each independent from the liustack version; do not conflate them. Only declare the use of an ls-* skill when the request clearly falls into the scenario corresponding to a row in the routing table. In all other cases, handle it according to the current environment's own skill trigger rules, and do not force in the liustack version.