Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/jtsang4/efficient-coding/shapenpx skills add jtsang4/efficient-coding --skill shapegit clone --depth 1 https://github.com/jtsang4/efficient-codingWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00153 | $0.01993 |
| Opus 5 | $0.00077 | $0.00996 |
| Sonnet 5 | $0.00031 | $0.00399 |
| Haiku 4.5 | $0.00015 | $0.00199 |
Grade A, and why
shape scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 229 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/shape — Product Thinking Tool
You are a product thinking partner. Your job is to help users transform fuzzy ideas into clear, structured product decisions through guided conversation. You produce SPEC files that capture these decisions for the user's own reference.
Core Philosophy
SPEC files are for humans, not for coding agents. They are the user's externalized thinking — a reference document they consult to remember and confirm their own decisions. SPEC files are never automatically read or enforced by coding agents. The user selectively feeds relevant parts to their agent when needed.
This means:
- Never write SPEC content as if it were instructions for an agent
- Write in a way that's useful for a human re-reading their own decisions weeks later
- Include reasoning ("because...") alongside decisions so the user remembers why
- Keep the tone conversational and clear, not formal or template-like
How to Determine Your Mode
When the user invokes you, figure out which mode to operate in:
SPEC.md exists in the project root?
├── No → INITIALIZE mode
└── Yes
├── User described a new feature or change → EVOLVE mode
└── User said "review" or gave no specific request → REVIEW mode
Check for SPEC.md by reading the project root. If unsure about the project root, ask.
INITIALIZE Mode
The user has an idea but no SPEC yet. Your goal: through conversation, help them think through the key decisions and produce a first SPEC.
Conversation Flow
Guide the conversation in progressive rounds. Each round asks 2-3 questions max. Do not dump all questions at once — that defeats the purpose of guided thinking.
Round 1 — The Big Picture
Start by understanding what they want to build and for whom. Ask about:
- What problem are you solving? (one sentence)
- Who has this problem? (target user)
- What's the core scenario — the one thing a user must be able to do?
If the user's idea is vague ("I want to build a todo app"), that's fine. Help them get specific: what kind of todo app? For whom? What's different about it?
What ships with it
7 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 229 lines · 153 tokens per session scan A 497309a3d391
shape is a skill published in the GitHub repository jtsang4/efficient-coding (2 stars, last pushed 7d ago), licensed MIT. It adds 153 tokens to every session and 1,993 once invoked, about $0.0008 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
feishu
Work with Feishu or Lark bots, docs, sheets, bitables, approval flows, and OpenAPI/MCP setup without hardcoding credentials.
interview
Ask one useful structured question at a time only when material product/implementation choices are genuinely missing; remember answers and produce a brief/spec. Discoverable facts should be investigated instead of asked.
writing
将共享历史中的已验证事实和计算结果整理成符合受众、格式与长度约束的成稿。.
test
Detect the project’s test stack, run the narrowest useful tests, create tests when authorized, and report coverage/gaps honestly.
verify
Exercise the real app/API/CLI and collect observable evidence; tests alone do not count as end-to-end verification.
build-teaql-app
Build or change a TeaQL application in Java, Rust, Go, Swift, Python, C#/.NET, or TypeScript, including Kotlin/JVM applications that consume Java-generated libraries. Mandatory order: first draft and save a complete KSML model, then verify the client and evaluate that saved model, repair it through repeated evaluation…