Agent助手
- 作者仓库星标 0
- 作者更新于 实时读取
- 作者仓库 skills-registry
- 领域
- 设计与多媒体
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @tomevault-io · 未声明 license
- Token 消耗评级
- 中等消耗
- 接入复杂程度
- 需手动接入
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- Docker
- 底层运行要求
- Python >=3.11 · Docker
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: sp-coding-agent
description: Use when a coding task is vague or under-specified. Extracts missing context across 9 code-nativ…
category: 设计与多媒体
runtime: Python / Docker
---
# sp-coding-agent 输出预览
## PART A: 任务判断
- 适用问题:视觉内容、演示材料、信息图或设计交付。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“How to Load This Skill / Reference Files / When to Use This Skill”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于视觉内容、演示材料、信息图或设计交付,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“How to Load This Skill / Reference Files / When to Use This Skill”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/var` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“How to Load This Skill / Reference Files / When to Use This Skill”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: sp-coding-agent
description: Use when a coding task is vague or under-specified. Extracts missing context across 9 code-nativ…
category: 设计与多媒体
source: tomevault-io/skills-registry
---
# sp-coding-agent
## 什么时候使用
- 把设计与视觉方向的常用动作沉淀成 Agent 可调用的技能 适合处理界面、视觉、封面、信息图或演示材料交付,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤…
- 面向视觉内容、演示材料、信息图或设计交付,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「How to Load This Skill / Reference Files / When to Use This Skill」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "sp-coding-agent" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> How to Load This Skill / Reference Files / When to Use This Skill
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Python / Docker | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} SMART POLE Coding Agent Skill
This Skill implements the SMART POLE framework adapted for AI Coding Agents. Unlike the chatbot versions (Instructor/Enforcer), this skill operates on codebases — scanning project files, extracting context automatically, and ensuring the agent has enough information before writing code.
How to Load This Skill
- Set system prompt: Load
references/system-prompt.mdas the agent's system prompt (e.g., paste intoAGENTS.md,.claude/system_prompt.md, or the agent's system role configuration). - Provide reference files: Make
references/logic.md,references/overlap-rules.md, andreferences/coding-agent-categories.mdavailable in the agent's context or knowledge base. - Invoke: Give the agent a vague or specific coding task. The agent will ORIENT (scan the codebase), CLASSIFY the task type, EXTRACT SP-categories, and check execution gates before touching any file.
Reference Files
| File | Purpose |
|---|---|
references/system-prompt.md |
🔴 Required — Full Coding Agent system prompt (v4.0). Load as the agent's system instructions. |
references/logic.md |
Framework logic: category definitions, weighted scoring, task-type classification, generic-to-coding task mapping. |
references/overlap-rules.md |
Atom overlap rules, conflict detection, Functional Gravity principle, and the One Atom One Slot rule. |
references/coding-agent-categories.md |
Code-native sub-dimensions for all 9 SP-categories with auto-detection sources and hard-stop gate definitions. |
When to Use This Skill
- A user gives a vague coding task ("fix the login bug", "add pagination")
- Before an agent starts multi-file code changes
- When a task involves unfamiliar parts of a codebase
- Migration or refactoring tasks where scope control is critical
How It Works
- ORIENT: Agent scans project root (
README.md,AGENTS.md,package.json,Dockerfile, etc.) - CLASSIFY: Determine task type (Bug Fix / Feature / Refactor / Migration / Infra)
- EXTRACT: Map request to 9 code-native SP-categories
- DETECT FLAWS: Identify missing context, overlaps, and conflicts; ask user if critical
- PLAN: Create implementation plan with file-level scope
- EXECUTE: Apply file changes within approved scope
- VERIFY: Run tests, lint, type-check; self-heal on failures
The 9 Code-Native Categories
| Abbrev | Category | Code Meaning | Priority |
|---|---|---|---|
| S | Style | Code standards, linting, architecture pattern | 🟢 Auto-detect |
| M | Mastery | Developer expertise level — split into Domain vs Task (see below) | 🟡 Contextualizer |
| A | Aim | Definition of Done, acceptance criteria, success metric | 🔴 CORE |
| R | Resource | Allowed/forbidden deps, API quotas, team contacts, internal docs | 🟡 Contextualizer |
| T | Time | Deadline, urgency level (hotfix vs long-term), sprint constraints | 🟢 Accelerator |
| P | People | Team conventions, reviewer persona, implicit values & preferences | 🟡 Contextualizer |
| O | Outline | Authorized file scope, folder boundaries, what NOT to touch | 🔴 CORE |
| L | Locale | Runtime ecosystem, language/framework version, legal/infra constraints | 🟡/🔴 CONDITIONAL |
| E | Example | Reference code snippets, similar PRs, anti-pattern stories | 🟡/🟢 CONDITIONAL |
Category Deep-Dives (SP-Flaw Prevention)
⏱️ T — Time: Urgency Only, Not Quality
T answers: "How much time do I have?" — deadline, sprint slot, hotfix vs planned refactor.
⚠️ T-Flaw (Category Overlap): Do NOT put acceptance criteria or content depth requirements inside T.
- ❌ Wrong:
T: "Must be thorough enough to not need follow-up"← this is an A-atom- ✅ Right:
T: "Hotfix — must ship in 2 hours"/T: "Non-urgent — next sprint"
Quality gates and success criteria belong in Aim (A) or Outline (O), not Time.
👥 P — People: Make Implicit Traits Explicit
P answers: "Who is involved and what are their hidden assumptions?"
Beyond team conventions, always surface:
- Reviewer Persona: Does the reviewer prioritize security over speed? Hate over-engineered abstractions?
- Implicit Values: Prefers functional style? Allergic to ORMs? Values minimal diffs?
- Psychological traits: Team culture (consensus-driven vs individual autonomy), risk tolerance
⚠️ P-Flaw (Implicit People): Do NOT leave personality traits and values implicit — the agent will guess wrong.
- ❌ Wrong: Omitting that the team hates
anytypes in TypeScript- ✅ Right:
P: "Reviewer flags every use of 'any' in TypeScript — use strict types always"
🎓 M — Mastery: Always Split Domain vs Task
M answers: "What does the developer know — and in which dimension?"
Always decompose Mastery into two parts:
| Dimension | Meaning | Example |
|---|---|---|
| M-Domain | Expertise in tech stack / role | Senior React, Junior DevOps |
| M-Task | Experience with this specific task type | Never integrated Stripe before, First time with WebSocket |
⚠️ M-Flaw (Mastery Scope): Missing the gap between Domain and Task mastery causes the agent to pitch solutions that are technically fluent but practically inappropriate.
- ❌ Wrong:
M: "Senior Developer"← domain only, no task dimension- ✅ Right:
M-Domain: "Senior React" | M-Task: "Novice — first time implementing OAuth2 flow"→ agent uses familiar React patterns but explains OAuth2 step-by-step
🧰 R — Resource: Tools + People + Data
R answers: "What weapons do I have — and what is forbidden?"
Resource includes three dimensions, not just software:
| Dimension | Examples |
|---|---|
| Tools | Allowed libs/frameworks, CI/CD pipeline, dev environment |
| People / Network | Team members who can review, external consultants, on-call SMEs |
| Data / Docs | Internal wikis, API docs, log access (/var/log/auth.log), Sentry |
⚠️ R-Flaw (Resource Underutilization): Listing only software tools leaves the agent unable to suggest "ask the security team" or "check the Confluence runbook."
- ❌ Wrong:
R: "Jira, Notion"← tools only- ✅ Right:
R-Tools: "Jira" | R-Network: "Security team available for review" | R-Data: "Sentry logs + Redis CLI access"
Also supply Negative Atoms (what is forbidden):
R-Forbidden: "No new npm deps without approval, no changes to DB schema"
📌 E — Example: The Anchor Atom
E answers: "What should the output look like — concretely?"
In coding context, a Gold Standard E-atom is a matched pair:
| E-atom Type | What it looks like |
|---|---|
| Code snippet | Before/after code block showing the pattern to follow |
| Similar PR | Link or description of a past PR that solved a comparable bug |
| Input/Output pair | Expected test case: input state → expected behavior |
| Anti-example (Story) | "Last time we did X this way, it broke Y — avoid this pattern" |
⚠️ E-Flaw (Missing Anchor): Without an Example atom, the agent mimics its training data defaults, not your codebase conventions.
- ❌ Weak:
E: "Make it look clean"← too vague, gives agent no anchor- ✅ Gold:
E: "Follow the pattern in auth_service.py:L45–80 — token invalidation before session update"orE: "This Sentry trace shows the failure chain: A→B→C"
Always ask: "Is there a similar PR, a log trace, or a code section I want the agent to mimic?"
Auto-Extraction Sources
| Source File | SP-Categories Extracted |
|---|---|
.eslintrc / ruff.toml |
S (Style) |
package.json / pyproject.toml |
R (Resource), L (Locale) |
Dockerfile / docker-compose.yml |
L (Locale), R (Resource) |
AGENTS.md / SKILL.md |
P (People), S (Style) |
CI/CD configs (.github/workflows/) |
R (Resource), A (Aim quality gates) |
Coding Task Classification
| Task Type | Primary SP-cats | Agent Behavior |
|---|---|---|
| Bug Fix | A, E, O | Minimal change + regression test |
| Feature | A, O, R | Plan → implement → test |
| Refactor | O, E, P | Preserve behavior, improve structure |
| Migration | L, R, T | Incremental, backward compatible |
| Infra | L, R, A | Infrastructure as Code, idempotent |
Task Taxonomy Mapping (Generic → Coding)
Use this mapping to bridge generic SMART POLE task types in references/logic.md with coding-agent task types.
Generic Task Type (references/logic.md) |
Coding Task Type(s) | Default Interpretation |
|---|---|---|
| Deterministic | Bug Fix, Refactor | Behavior is constrained; prioritize reproducibility and regression tests |
| Generative | Feature | New capability; prioritize clear DoD and explicit scope boundaries |
| Advisory | Refactor, Migration, Infra | Architecture/process guidance; convert advice into testable acceptance criteria before coding |
| Discovery | Feature (spike), Migration (assessment) | Exploration is allowed, but execution stays minimal and reversible |
| Compliance | Infra, Migration, Bug Fix | Regulatory/security constraints are first-class acceptance criteria |
Execution Gates (Hard Stops)
Do not execute code changes until all hard-stop gates pass:
- Gate A (Aim): At least one testable acceptance criterion exists.
- Gate O (Outline): Authorized scope is explicit (or defaults to minimal scope) and forbidden scope is respected.
- Gate Conflict: All
SP-conflictitems are resolved by user decision. - Gate Overlap: Apply
One Atom, One Slotfromreferences/overlap-rules.md; no double-counted atoms. - Gate Score: Weighted readiness score is >= 67% of the applicable max score (per
references/logic.mdtask-type weighting).
If any gate fails:
- Stop before
EXECUTE - Ask targeted clarification questions
- Re-plan only after user confirmation
Worked Example: Bug Fix Context Extraction
User request: "Fix the login bug — users can't login after password reset"
| SP-cat | Atom | Why here, not elsewhere |
|---|---|---|
| S | Auto-detect from .eslintrc |
Style from project config |
| M-Domain | Senior Backend Developer |
Tech stack expertise |
| M-Task | Novice — unfamiliar with this legacy auth system |
Task-specific gap |
| A | Login succeeds with new password; old session invalidated; unit tests pass |
Success criteria → not T |
| R-Tools | Redis CLI access, Sentry error traces |
Concrete toolbox |
| R-Network | Security team available on Slack for review |
Human resource |
| T | Hotfix — must ship within 2 hours |
Urgency only — not quality |
| P | Reviewer prioritizes security over speed; avoids over-optimization at hotfix stage |
Explicit reviewer values |
| O | Only modify auth_service.py and password_controller.py |
Scope boundary |
| L | Python 3.11, Django 4.2, Redis 7 |
Runtime ecosystem |
| E | Sentry trace shows: PasswordReset→UpdateDB→[FAIL: session not invalidated]→Login |
Concrete anchor |
🔍 SP-flaw check: "Write unit tests" is an A-atom (acceptance criterion), NOT a T-atom (time/urgency).
Key Differences from Chatbot Versions
| Aspect | Instructor/Enforcer | Coding Agent |
|---|---|---|
| Output | Master Prompt text | Working code + passing tests |
| Reasoning visibility | Prompt-analysis oriented | Concise decisions tied to files/tests (no explicit CoT requirement) |
| Verification | User reviews prompt | Agent runs tests automatically |
| Context | Conversation only | Codebase + configs + file system |
| Self-healing | N/A | Auto-fix on test failure (max 3 attempts) |
Optional: Integration with Other Skills
This skill works best as a pre-flight layer in any coding agent workflow, ensuring sufficient context before execution begins. Pair with project-specific AGENTS.md or workflow files.
Source: cuongpt083/smart-pole-skill — distributed by TomeVault.
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核