cs
is the unified entry point of the CodeStable workflow family. When users start, they most likely won't specify a particular
sub-skill — they might just say "I want to add permission verification", "there's a bug here", "introduce codestable to me", or even just send
. This skill is responsible for handling these open-ended inputs, clarifying the intent, and then routing the user to the correct sub-skill.
Only two tasks, nothing more:
- When users come with specific requests → match the scenario routing table, tell users which to trigger, and briefly explain why
- When users just want to learn about the system / can't clearly state what they want to do → provide a concise system overview + let users choose or describe more specific requests
This skill does not perform actual tasks: it doesn't write specs, read/write content products under
, or run processes on behalf of sub-skills. Its only output is "suggest which sub-skill to trigger".
Scans to perform first upon receiving a call
Do these before responding to users (do this every time; it's quick, just a few tool calls):
- Check if the repository has integrated CodeStable — use to see if the top-level directory exists
- If it exists — read
codestable/reference/system-overview.md
- If it does not exist — note this, and later prompt users to run first
- Check the user's original input — is it an open-ended question or a specific request? If it's a request, match the routing table; if not, provide the system overview
Respond only after completing these scans. Make users feel you have a clear understanding instead of responding blindly.
Quick system overview (explain this when users have no specific requests / ask for an introduction)
CodeStable models software development activities into
6 entities + 3 processes, with all products gathered in the
directory at the project root:
codestable/
├── requirements/ Requirement entity ("why this capability is needed", only records current status)
├── architecture/ Architecture entity ("what the system looks like now", only records current status)
├── roadmap/ Planning layer ("how to implement this large requirement next + module splitting + interface definition")
├── features/ Aggregation root for specs of new capabilities (design / impl / accept)
├── issues/ Aggregation root for specs of bug fixes (report / analyze / fix)
├── refactors/ Aggregation root for refactoring specs (beta)
└── compound/ Knowledge accumulation (learning / trick / decision / explore)
Three processes:
- New capability development: → → (start with triage if ideas are vague)
- Bug fixing: → →
- Refactoring (beta): /
Cross-cutting: After any process, if "this is worth recording" → use
/
/
/
to store in
.
Core concept: It orchestrates the lifecycle of the software itself (requirements, architecture, features, bugs, decisions), not Agents. Human-in-the-loop — programmers are responsible for overall control, and AI is an efficient executor.
If the project has been onboarded, see
codestable/reference/system-overview.md
for a more detailed overview.
Scenario routing table
Match the user's input to a row in the table, then tell the user: "For this request, it is recommended to use
because {one-sentence reason}".
| User's input / What the user wants to do | Route to |
|---|
| No directory in the repository | First run — all other cs-* skills depend on this directory |
| Vague ideas / "I have an idea but haven't figured it out" / "Let's chat first" / "Not sure if it's a new feature" | (after triage, route to design / feature-brainstorm documentation / roadmap) |
| New feature / new capability / "Add X" / "Implement XX" | (routes to design / ff / impl / accept) |
| BUG / exception / error / "This is wrong" / "Documentation is incorrect" | (routes to report / analyze / fix) |
| Code optimization / refactoring / rewrite (behavior unchanged) | / (beta) |
| Explore code / "How is X implemented" / research questions | |
| Supplement / update requirement documentation | |
| Supplement / update / check architecture documentation / "Refresh architecture doc" / "Do architecture checkup" | |
| Large requirement breakdown / "I want an X system" / scheduling planning / design module splitting + interface contracts | |
| Technology selection / long-term constraints / coding conventions | |
| Pitfall review / experience summary / "This is worth recording" | |
| Reusable programming patterns / library usage / "Do X like this in the future" | |
| Developer guide / user guide | |
| Library API reference | |
| User is in the middle of a feature / issue process and asks "What to do next" | Route to the entry of the corresponding process ( / ), let the entry judge the current stage |
If unable to match / user's input is too abstract: "It sounds like {guess}, but {what's missing} in your description. Is it {Option A} or {Option B}?" Let the user choose, don't guess blindly.
Special cases to pay attention to
Repository not integrated yet
If the user wants to perform any cs-* process but
does not exist → explain this and recommend
running first. Do not route directly to cs-feat / cs-issue etc. on your own — their SKILL.md all assume
already exists.
Large requirements mistaken as features
If the user mentions requests like "I want a permission system / notification center / SSO integration" which are
obviously too big to complete as a single feature → do not route to
, route to
(most likely will be judged as case 3 →
) or directly to
. Reason: Starting a feature directly will result in an oversized design that can't be accommodated.
"Modify X" but X is an existing feature
If the user says "Modify the Y behavior of X" → first ask whether this is a bug fix (X's current behavior is wrong) or a requirement change (X's current behavior is correct, but product strategy has changed):
- Bug →
- Requirement change → (update requirement documentation) + then run for implementation
Ongoing work
If scanning finds directories related to the user's description under
or
→ mention "Noticed
already exists, do you want to continue working on this?" Let the user confirm whether to continue or start a new one, to avoid accidentally creating duplicate features.
Subdivision of accumulation skills
learning / trick / decision / explore are easily confused. Discrimination mnemonic:
- Review "Encountered Y when doing X" →
- Prescription "Do X like this in the future" →
- Rule "All projects follow X from now on" →
- Investigation "What is X like now" →
If unable to judge, ask the user: "Do you want to record this as {pitfall review / reusable prescription / long-term convention / research archive}?"
Introduction mode (when users only want to learn / don't know what to do)
Explain in this order, do not dump all information at once:
- One sentence: CodeStable is an AI coding workflow for serious engineering, orchestrating the software lifecycle instead of Agents
- Quick overview of 6 entities + 3 processes (see "Quick system overview" above)
- Ask the user: "Where do you want to start most?" Provide three specific prompts:
- "I have a new feature to develop" → cs-feat
- "There's a bug in the code" → cs-issue
- "The project hasn't integrated CodeStable yet" → cs-onboard
Stop here, don't explain details of all sub-skills. Expand on specific ones only when the user asks.
Exit
This skill has no "documentation" step. The only exit condition is:
Output example:
For this request, it is recommended to use
— {one-sentence reason: because it specializes in handling X-type scenarios}.
After triggering, it will {briefly describe what will happen: first scan existing specs / ask you to describe first / enter triage / ...}.
Switch to
now?
After confirmation, the user triggers that sub-skill (or directly uses the corresponding skill name in the same session), and this skill's work for this round ends.
Things not to do
- Do not read/write content products under — do not open design.md, modify items.yaml, or create feature directories. These are tasks for sub-skills
- Do not make decisions on behalf of sub-skills — e.g., do not perform brainstorm triage in this skill (that's 's job), do not judge which mode cs-arch should use in this skill
- Do not recommend multiple skills at once — only point to one path each time. If the user has two independent requests, split into two rounds: finish A first then return to B
- Do not repeat details of the system overview —
codestable/reference/system-overview.md
- Do not bypass — if the repository is not integrated, onboard first, do not attempt to route directly to downstream skills