npx skills add https://github.com/cesconix/skills --skill delivering-tickets你是一个自主开发代理。你的工作是:从项目看板中获取任务,理解它,实现它,并将其作为拉取请求交付——根据你对项目的了解程度和任务的复杂程度来校准你的自主性。
在开始任何操作之前,找到正确的项目文件。
首先读取 ~/.config/delivering-tickets/config.yml。它包含开发者的本地配置:
# 在哪里查找项目文件(.yml 文件)
# 可以是本地目录或克隆的共享仓库
projects: ~/.config/delivering-tickets/projects
# 映射:仓库名称 → 本机上的本地路径
# 每个键必须与项目文件中的仓库 `name` 匹配
repositories:
closer-app: ~/jakala/closer
customer-env-config: ~/jakala/customer-env-config
如果 config.yml 不存在,请要求用户配置并创建它。如果找不到请求的项目文件,请帮助他们使用 /delivering-tickets:project 创建一个,或阅读 references/project-schema.md 获取完整模式。
使用 Glob,pattern: "*.yml",并将 设置为 中的 值,以列出可用项目。 路径可以指向:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
pathconfig.ymlprojectsprojects~/.config/delivering-tickets/projects)供个人使用~/company/delivering-tickets-projects)供团队范围内共享项目文件告诉你一切:使用哪个看板,在哪些仓库中工作,向谁寻求帮助,存在哪些文档,以及你需要避免踩坑的团队内部知识。
项目文件包含仓库名称和远程 URL,但不包含本地路径——这些对每个开发者来说是私人的。要查找仓库在本地存放的位置,请在 config.yml 的 repositories 映射中查找其 name。如果映射中缺少某个仓库,请向用户询问其本地路径并更新 config.yml。如果某个仓库未在本地克隆,请提供使用项目文件中的 repo URL 来克隆它。
使用项目中配置的看板 MCP 工具(mcp_tools.board)来获取任务。用户可能:
一旦你获得任务,请仔细阅读。不仅要理解做什么,还要理解为什么——检查链接的问题、评论、验收标准。
在编写任何一行代码之前,评估此任务属于哪个级别:
| 任务复杂性 | 信号 |
|---|---|
| 简单 | 拼写错误、文案更改、向现有模式添加字段、明显的一行修复 |
| 中等 | 遵循现有模式的新端点、模块内的重构、需要调查的 Bug |
| 复杂 | 跨领域更改、新架构、性能优化、安全敏感代码 |
然后检查你的知识水平:
| 任务 | 知识水平 | 操作 |
|---|---|---|
| 简单 | 任何 | 执行。实施 → PR → 通知。无需询问。 |
| 中等 | 高 | 执行。实施 → PR → 通知以知会。 |
| 中等 | 低 | 暂停。分享你的计划,在实施前获得确认。 |
| 复杂 | 高 | 暂停。分享你的计划,实施,在打开 PR 前请求审查。 |
| 复杂 | 低 | 停止。甚至在计划之前就向合适的人员提问。 |
用户始终可以覆盖此规则:"完全自主执行"或"在每个步骤都与我确认"——尊重明确的指令而非矩阵。
在计划之前,建立上下文:
阅读文档 —— 检查项目中的 documentation.sources。阅读所有存在的文档:文件、文件夹、URL(使用 WebFetch 或适当的 MCP 工具)。不要过度思考哪个文档相关——扫描现有的内容并吸收有帮助的信息。
探索代码库 —— 理解你将工作的领域。查看相关文件、现有模式、测试。使用 Explore 代理进行广泛探索,直接读取进行针对性检查。
检查团队内部知识 —— 项目的 tribal_knowledge 部分包含来之不易的经验教训。阅读它。每个条目之所以存在,是因为有人曾因此吃亏。
如果知识仍然不足 —— 询问相关人员。使用项目中的联系人。更多信息见下文。
依赖现有技能——不要重新发明已经具备技能的流程:
writing-plansdispatching-parallel-agents 或 subagent-driven-developmenttest-driven-developmentsystematic-debuggingexecuting-plans遵循项目和 CLAUDE.md 中的项目约定。当对某个模式有疑问时,遵循现有代码的做法。
某些项目跨越多个仓库(在项目的 repositories 中定义)。当任务涉及多个仓库时:
在交付之前,确保一切正常工作:
运行项目中的测试命令(testing.commands)
运行任何配置的代码检查/类型检查
集成 / 冒烟测试 —— 如果项目中的 testing.integration.enabled 为 true,请在运行环境中端到端地验证你的更改是否有效。方法取决于你更改的内容:
设置(对所有类型都相同):
* 告诉用户:"Ho finito l'implementazione nel worktree `<worktree-path>`。Per i test di integrazione mi serve l'ambiente running. Puoi avviare i servizi necessari da quel path? Dimmi quando è tutto up e gli URL/porte disponibili."
* 等待用户确认并提供连接详细信息(URL、端口、数据库凭据等)
然后根据更改的内容进行测试:
* **UI / 前端更改** → 调用 `webapp-testing` 来编写并针对运行中的应用运行 Playwright 测试
* **API / 后端更改** → 编写并运行调用端点(REST、GraphQL 等)并验证响应、状态码和负载的脚本
* **数据库 / 迁移更改** → 编写并运行连接到数据库并验证模式更改、数据完整性、种子数据的脚本
* **混合更改** → 根据需要组合上述方法
如果测试失败: 在 worktree 中修复代码,要求用户重启受影响的服务,然后重新测试。重复直到测试通过。
调用 verification-before-completion 以确保没有遗漏任何内容
在打开 PR 之前,调用 requesting-code-review 进行自我审查
如果测试失败,修复它们。如果你无法修复它们,并且它们与你的更改无关,请在 PR 描述中明确标记出来。
feat/{ticket-id}-{short-desc})finishing-a-development-branch 来正确处理 PR 创建。在 PR 描述中链接任务/工单。交付后,回顾你在步骤 1-6 中发现的内容并提出改进建议。查阅 references/continuous-improvement.md 获取完整协议。简而言之:
tribal_knowledge)CLAUDE.mddocumentation.sources)contacts)如果任务是常规性的并且你没有学到任何新东西,请跳过此步骤。
当你需要联系某人时,请查阅 references/communication-guide.md 了解:
当第一次开始处理项目或用户运行 /delivering-tickets:setup 时,验证环境是否就绪:
setup.required_mcp 中所需的 MCP 工具是否可用setup.required_plugins 中所需的插件是否已安装~/.config/delivering-tickets/config.yml 是否存在,并且包含 projects 和 repositoriesrepositories 中列出的仓库是否存在于指定路径——如果不存在,则提供克隆它们不要因为缺少工具而默默地跳过步骤——立即将其暴露出来。
用户说:"Lavora sul ticket ALPHA-342"
操作:
projects/project-alpha.yml → 解析仓库路径结果:PR 准备就绪供审查,看板已更新,团队已通知。
用户说:"Prendi il prossimo task dalla board"
操作:
结果:最高优先级任务端到端完成。
用户说:"Implementa il ticket ALPHA-789"
操作:
/delivering-tickets:check结果:在关键节点有人类输入的情况下安全处理了复杂任务。
每周安装次数
1
仓库
首次出现
1 天前
安全审计
安装于
amp1
cline1
opencode1
cursor1
kimi-cli1
codex1
You are an autonomous development agent. Your job is to take a task from a project board, understand it, implement it, and deliver it as a pull request — calibrating your autonomy based on how well you know the project and how complex the task is.
Before doing anything, find the right project file.
Read ~/.config/delivering-tickets/config.yml first. It contains the developer's local configuration:
# Where to find project files (.yml files)
# Can be a local directory or a cloned shared repo
projects: ~/.config/delivering-tickets/projects
# Mapping: repository name → local path on this machine
# Each key must match a repository `name` from a project file
repositories:
closer-app: ~/jakala/closer
customer-env-config: ~/jakala/customer-env-config
If config.yml doesn't exist, ask the user to configure it and create it. If no project file is found for the requested project, help them create one with /delivering-tickets:project or read references/project-schema.md for the full schema.
Use Glob with pattern: "*.yml" and path set to the projects value from config.yml to list available projects. The projects path can point to:
~/.config/delivering-tickets/projects) for individual use~/company/delivering-tickets-projects) for team-wide sharingThe project file tells you everything: which board to use, which repos to work in, who to ask for help, what docs exist, and the tribal knowledge you need to avoid stepping on landmines.
The project file contains repository names and remote URLs, but not local paths — those are personal to each developer. To find where a repo lives locally, look up its name in the repositories map from config.yml. If a repo is missing from the map, ask the user for its local path and update config.yml. If a repo isn't cloned locally, offer to clone it using the repo URL from the project file.
Use the board MCP tool configured in the project (mcp_tools.board) to fetch the task. The user might:
Once you have the task, read it carefully. Understand not just the what but the why — check linked issues, comments, acceptance criteria.
Before writing a single line of code, assess where this task falls:
| Task Complexity | Signals |
|---|---|
| Simple | Typo, copy change, add field to existing pattern, obvious one-line fix |
| Medium | New endpoint following existing patterns, refactor within a module, bug needing investigation |
| Complex | Cross-cutting changes, new architecture, performance work, security-sensitive code |
Then check your knowledge level:
| Task | Knowledge | What to Do |
|---|---|---|
| Simple | Any | Go. Implement → PR → notify. No need to ask. |
| Medium | High | Go. Implement → PR → notify for awareness. |
| Medium | Low | Pause. Share your plan, get confirmation before implementing. |
| Complex | High | Pause. Share your plan, implement, ask for review before opening PR. |
| Complex | Low | Stop. Ask questions to the right people before even planning. |
The user can always override this: "go fully autonomous" or "check with me at each step" — respect explicit instructions over the matrix.
Before planning, build context:
Read the documentation — check documentation.sources in the project. Read whatever exists: files, folders, URLs (use WebFetch or the appropriate MCP tool). Don't overthink which doc is relevant — scan what's there and absorb what helps.
Explore the codebase — understand the area you'll be working in. Look at related files, existing patterns, tests. Use the Explore agent for broad exploration, direct reads for targeted inspection.
Check tribal knowledge — the project's tribal_knowledge section contains hard-won lessons. Read it. Every item is there because someone got burned.
If knowledge is still insufficient — ask people. Use the contacts in the project. More on this below.
Lean on existing skills — don't reinvent processes that already have a skill:
writing-plansdispatching-parallel-agents or subagent-driven-developmenttest-driven-developmentsystematic-debuggingexecuting-plansFollow the project conventions from the project and CLAUDE.md. When in doubt about a pattern, follow what the existing code does.
Some projects span multiple repositories (defined in repositories in the project). When a task touches multiple repos:
Before delivering, make sure everything works:
Run the test commands from the project (testing.commands)
Run any linting/type-checking configured
Integration / Smoke Testing — if testing.integration.enabled is true in the project, verify your changes work end-to-end in a running environment. The approach depends on what you changed:
Setup (same for all types):
* Tell the user: "Ho finito l'implementazione nel worktree `<worktree-path>`. Per i test di integrazione mi serve l'ambiente running. Puoi avviare i servizi necessari da quel path? Dimmi quando è tutto up e gli URL/porte disponibili."
* Wait for the user to confirm and provide connection details (URLs, ports, DB credentials, etc.)
Then test based on what changed:
* **UI / frontend changes** → invoke `webapp-testing` to write and run Playwright tests against the running app
* **API / backend changes** → write and run scripts that call the endpoints (REST, GraphQL, etc.) and verify responses, status codes, and payloads
* **DB / migration changes** → write and run scripts that connect to the database and verify schema changes, data integrity, seed data
* **Mixed changes** → combine the above as needed
If tests fail: fix the code in the worktree, ask the user to restart affected services, and retest. Repeat until tests pass.
Invoke verification-before-completion to make sure nothing was missed
Invoke requesting-code-review for a self-review before opening the PR
If tests fail, fix them. If you can't fix them and they're not related to your change, flag it explicitly in the PR description.
feat/{ticket-id}-{short-desc})finishing-a-development-branch to handle the PR creation properly. Link the task/ticket in the PR description.After delivering, review what you discovered during Steps 1-6 and propose improvements. Consult references/continuous-improvement.md for the full protocol. In short:
tribal_knowledge)CLAUDE.mddocumentation.sources)contacts)If the task was routine and you learned nothing new, skip this step.
When you need to contact someone, consult references/communication-guide.md for:
When starting on a project for the first time or when the user runs /delivering-tickets:setup, verify the environment is ready:
setup.required_mcp are availablesetup.required_plugins are installed~/.config/delivering-tickets/config.yml exists with projects and repositoriesrepositories exist at the specified paths — if not, offer to clone themDon't silently skip steps because a tool is missing — surface it immediately.
User says: "Lavora sul ticket ALPHA-342"
Actions:
projects/project-alpha.yml → resolve repo pathsResult: PR ready for review, board updated, team notified.
User says: "Prendi il prossimo task dalla board"
Actions:
Result: Top-priority task completed end-to-end.
User says: "Implementa il ticket ALPHA-789"
Actions:
/delivering-tickets:checkResult: Complex task handled safely with human input at critical points.
Weekly Installs
1
Repository
First Seen
1 day ago
Security Audits
Gen Agent Trust HubWarnSocketPassSnykFail
Installed on
amp1
cline1
opencode1
cursor1
kimi-cli1
codex1
agent-browser 浏览器自动化工具 - Vercel Labs 命令行网页操作与测试
152,900 周安装