SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillscs-trick

cs-trick

Coding & development

View repository

Updated 10-15 20:21

About this skill

cs-trick

Required reading at startup

Before making any judgment or taking any action, first read .codestable/attention.md; if missing, treat the skeleton as incomplete, prompt to fill it in first or run cs-onboard, and do not fall back to an external AI entry file.

cs-trick is a problem-orientedprescriptive reference library, answering:To do X, what is the proven correct approach? No trigger event is needed; whenever you find a pattern or usage worth accumulating, you can write it directly.

Typical content: the standard way to write a certain design pattern in this project / the core API usage of a certain library + known pitfalls / the command recipe for a certain type of operation.

For shared paths and naming conventions, see .codestable/reference/shared-conventions.md. Artifacts are written to .codestable/compound/, named YYYY-MM-DD-trick-{slug}.md, with frontmatter containing doc_type: trick。

Three types

The type field of the frontmatter:

Type Applicable context Example
pattern Design patterns / architectural patterns / programming idioms "Use the Repository pattern to isolate the data access layer", "Use Builder to construct complex configurations"
library Usage / configuration method / common pitfalls of a certain library / framework "The correct way to write Prisma transactions", "Error handling in Pinia store actions"
technique Specific operational tricks / tool usage / command recipes "Use jq to extract nested fields from JSON", "Use git bisect to locate the commit that introduced a bug"

Query purpose: for "how should the code be organized" → pattern; "how to use some API of a library / framework" → library; "how to do this type of operation" → technique. If unclear, choose the closest one;type does not affect search usability.

Document format

For frontmatter / body template / long examples, see the same directory reference.md. Process constraints:

  • type Only pattern / library / technique
  • Examples should preferably use the project's real code or commands
  • "When it does not apply / known pitfalls / related documents" are optional sections; if the user says "nothing", omit them

Workflow phases

Phase 1: Identify the type

At most two questions:

  1. "Is this about a pattern / structure, the usage of some library / framework, or an operational trick / command?" → determine type
  2. "Say it in one sentence: in what situation would it be used?" → determine topic

If the user's description is already clear, skip directly to Phase 1.5.

Phase 1.5: Check for overlap and route intent (mandatory)

According to shared-conventions.md §6 items 5/6:

  • If it contains "change / update / revise / supplement / some trick" or points to an old document → directly go toupdate existing, and do not enter the creation process
  • Otherwise use the search tool --query to search once topic, and when a close match is found, list the candidates for the user

Update process: read the old document → align with the user on which sections to change → skip the full code investigation in Phase 2 (the code involved in the changed sections must be reread to confirm it is not invalid) → draft a diff for the user to review → write back + updated: YYYY-MM-DD。

Phase 2: Code investigation (mandatory, cannot be skipped)

Techniques are embodied through code—the user not pasting code does not mean there is no need to look at code. The AI must proactively investigate the code repository.

Why it is mandatory: a "technique" written without looking at the code will remain at an abstract level. Next time someone tries to find code according to this entry, they will not find the corresponding real example, and will instead lose confidence.

  1. Search the code repository according to topic + type—Grep keywords (function names / class names / library imports / pattern characteristics); search related files; supplement with semantic search when necessary
  2. Read key files—the code locations where the technique is actually used / implemented:library class: look for imports and call sites;pattern class: look for structural code (interface definitions / class inheritance / composition);technique class: look for scripts or configuration corresponding to the operation steps
  3. Output—record file paths and key code snippets. If nothing can be found at all (purely experiential techniques, external tool usage), then when drafting in Phase 3 state that "this technique currently has no in-project code instance"

Supplement: user provides attached files → still search the code repository once to confirm whether there are other usage points; search results are empty → may continue but must note this in the document; found code contradicts the user's description → proactively confirm with the user.

Phase 3: Extract key points (one question at a time)

Combined with the code found in Phase 2ask questions—do not ask about things the user can already see in the code:

  1. "What is the standard practice?" (if the implementation has already been seen, directly present your understanding and ask the user to confirm)
  2. "Why is doing it this way effective? What is the principle?"
  3. "In what situations should it not be used?" (optional)
  4. "Any pitfalls hit or things to watch out for?" (optional; for library, ask with emphasis)
  5. "Code snippet or command example?" (if actual code has already been found, skip and directly use the real code as the example)

If the user says "nothing much" or "skip", skip it; better to omit a section than to fill it with empty talk.

Phase 4: Draft + user review

The AI drafts the complete document in one pass (YAML frontmatter + body). For example code, prioritize the real project code found in Phase 2 (can be trimmed); do not write it out of thin air. Show it to the user.

Phase 5: Archiving

  • New: write to compound/YYYY-MM-DD-trick-{slug}.md, frontmatter includes doc_type: trick
  • Update: write back to the original file located in Phase 1.5 + updated: YYYY-MM-DD
  • supersede: handle according to shared-conventions.md §6 item 5

Phase 6: Discoverability check

After writing, if you find one or two lines of project hard constraints that "should be known every time the CodeStable skill starts", prompt the user to use cs-note to append to .codestable/attention.md. Do not change attention on your own initiative, and do not write external AI entry points.

Search tools

For complete syntax see .codestable/reference/tools.md。

# 按类型 + 框架筛选

python .codestable/tools/search-yaml.py --dir .codestable/compound --filter doc_type=trick --filter type=library --filter framework~={库名}

# 按技术栈浏览

python .codestable/tools/search-yaml.py --dir .codestable/compound --filter doc_type=trick --filter language=typescript --filter status=active

# 归档后查重叠

python .codestable/tools/search-yaml.py --dir .codestable/compound --filter doc_type=trick --query "{关键词}" --json

Guard rules

For shared archiving rules see shared-conventions.md Section 6. Specific to this skill:

  1. Only archive verified practices—"maybe it should be done this way" is not archived; it must have been confirmed effective by the user or AI
  2. Must investigate the code repository—Phase 2 cannot be skipped. For example code, prioritize the project's real code; do not write it out of thin air
  3. Do not write the principle on behalf of the user—if the user cannot clearly explain "why it is effective", write "principle to be supplemented"; do not fabricate
  4. Examples before descriptions— If code can make it clear, use code
  5. Only recognize its own doc_type— Only read and write doc_type: trick