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/cass-2003/local-workflow-skill/backend-engineeringnpx skills add cass-2003/local-workflow-skill --skill backend-engineeringgit clone --depth 1 https://github.com/cass-2003/local-workflow-skillWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/cass-2003/local-workflow-skill/backend-engineering)<a href="https://agentmods.dev/skills/cass-2003/local-workflow-skill/backend-engineering"><img src="https://agentmods.dev/badge/skills/cass-2003/local-workflow-skill/backend-engineering.svg" alt="Measured on agentmods" height="20"></a>What 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.00110 | $0.04407 |
| Opus 5 | $0.00055 | $0.02204 |
| Sonnet 5 | $0.00022 | $0.00881 |
| Haiku 4.5 | $0.00011 | $0.00441 |
Grade A, and why
backend-engineering scanned grade A with 1 finding 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 4d ago.
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.
Runs shell commandslowCapability
Expected in a hook, worth knowing in a rule or an instructions file.
- 禁止`child_process.exec(userInput)`，用`execFile`+参数数组（exec走shell可注入命令，execFile直接执行无shell解析） How it starts
The opening of the file, as written. The whole thing — 289 lines — stays where its author put it; the contents beside it link to each section on GitHub.
后端资深工程师技能 (Backend Engineering Skill)
快速规则（日常开发时自动加载，只需读到这里）
[后端核心清单] ① 入参永远不信任客户端，服务端必须重新校验所有字段（类型/范围/长度/格式） ② 错误分层处理：参数层→业务层→基础设施层，每层有明确的错误码和用户可读消息 ③ 配置不硬编码，用环境变量/配置文件/数据库，支持热加载 [事务三禁] ❌事务内调外部HTTP（外部超时=长时间持锁，全库阻塞） ❌无WHERE的UPDATE/DELETE（一次清空全表） ❌SELECT *（新增字段意外暴露敏感数据） [健壮性铁律] 外部依赖(DB/Redis/MQ/HTTP)必须有超时+重试+熔断，非核心失败不拖垮核心流程
写/改后端代码时，强制遵守：
- 入参校验：所有外部输入在handler层校验完毕再进service层，service层不处理格式问题
- 分层架构：Handler(入参校验+响应格式) → Service(业务逻辑) → DAO/Repository(数据访问)，禁止跨层调用（跨层=职责混乱，改一层影响全局，无法单独测试）
- 错误处理：每个函数返回error必须处理，禁止
_ = someFunc()忽略error（忽略的error会在生产环境变成无声的数据损坏）；错误向上传播时附加上下文 - 事务范围：事务范围最小化，只包含必须原子执行的操作；事务内禁止调外部HTTP/RPC（外部超时=长时间持锁，全库阻塞）
- 超时控制：所有外部调用(HTTP/DB/Redis/RPC)必须设置超时，无超时=潜在goroutine泄漏
- 配置管理：配置从环境变量/配置文件/数据库读取，禁止硬编码（硬编码=改配置就要重新编译部署，且密钥泄漏到Git历史无法撤回）；敏感配置(密钥/密码)不进代码仓库
- 日志规范：关键操作(支付/认证/数据变更)必须有日志；日志含请求ID可追踪；敏感数据mask
- 幂等设计：写操作必须考虑重复执行的结果；支付/订单类用唯一约束+幂等键
完整审查流程（手动 /backend-engineering 或专项审查时执行）
Phase 1: 架构与分层审查
-
目录结构扫描：
- 检查是否遵循分层架构(handler/service/model/config/middleware)
- 识别跨层调用（handler直接操作DB、service直接写HTTP响应）
- 检查循环依赖（A import B, B import A）
-
依赖注入与耦合度：
- 服务间是否通过接口解耦
- 全局变量/单例是否过多（增加测试难度和并发风险）
- 配置是否集中管理（散落的os.Getenv/硬编码）
Phase 2: 错误处理审查
-
错误传播链检查（Grep所有error处理）：
- 被忽略的error（
_ = func()或只log不return） - 错误信息是否附加了上下文（
fmt.Errorf("xxx: %w", err)vs 裸传err） - panic/recover使用是否合理（只在顶层recover，业务层禁止panic）
- 错误码体系是否统一（自定义error type vs 字符串比较）
- 被忽略的error（
-
错误分层：
| 层级 | 错误类型 | HTTP状态码 | 处理方式 |
|---|---|---|---|
| 参数校验 | 格式/类型/范围错误 | 400 | 返回具体字段+原因 |
| 业务逻辑 | 余额不足/已存在/不允许 | 422 | 返回业务错误码+用户消息 |
| 认证授权 | 未登录/无权限 | 401/403 | 统一认证中间件处理 |
| 基础设施 | DB/Redis/MQ连接失败 | 503 | 日志+告警+客户端提示重试 |
| 未知错误 | 未预期异常 | 500 | 生成唯一错误ID+日志完整堆栈 |
Phase 3: 并发与资源管理
-
并发安全：
- 共享状态(map/slice/全局变量)是否有锁保护
- goroutine是否有泄漏风险（未关闭channel/无退出条件/无超时）
- 数据库操作是否考虑并发（乐观锁/悲观锁/原子操作）
- 连接池配置是否合理（最大连接数/空闲连接/超时）
-
资源管理：
- DB连接/HTTP客户端/文件句柄是否正确关闭(defer)
- 大文件处理是否用流式(stream)而非全量加载到内存
- 定时任务/后台goroutine是否有graceful shutdown机制
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.
- 4d ago First seen · 289 lines · 110 tokens per session scan A fa9180f3c0f8
backend-engineering is a skill published in the GitHub repository cass-2003/local-workflow-skill (12 stars, last pushed 1mo ago), licensed MIT. It adds 110 tokens to every session and 4,407 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 1 finding (runs shell commands). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…