Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.
日本語の概要は準備中です。原文の説明を表示しています。
Experimental workflow for collecting and triaging product feedback, product telemetry, runtime errors, and issue reports. Use when scanning configured signal sources and applying separate fix, reply, or close rules.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Read .agent-factory/config.yaml and apply the optional
skill_prompts.factory-collect entry as additional project guidance. Collect
only the sources named by workflows.collect.sources. For repeated patterns
across time or sources, use factory-lookback.
empty, unavailable, and truncated distinct. A missing connector,
partial page, or failed query is not an empty source.Classify each item as a verified defect, repeated symptom, feature request, subjective feedback, duplicate, out of scope, or needing more evidence. Group related reports while retaining each source record and reporter.
Recommend a fix by default. Implement only when workflows.collect.implement allows it, the
repository is in scope, and the user asked for the change in this conversation; keep commits local. Stop for configured risk conditions, unclear product
intent, or evidence that cannot be reproduced. Verify the changed behavior
with the configured checks and a representative reproduction.
| Action | Gate |
|---|---|
| Reply | Draft only. When missing information blocks triage or verification, write the one targeted question into the report. Posting it needs the user's GO. never means no reply at all. |
| Close or mark fixed | Report the proof point and the proposed wording. Closing needs the user's GO. Do not imply an unverified release. |
| Publish, approve, merge, or deploy | Requires its own workflow authorization; collection does not grant it. |
When an item needs more information, keep it unresolved and retain the source
thread link and the exact question. If replies are disabled, include that
question in the report for a person to send. On later collection runs, check
whether an answer arrived. Re-triage the original report together with the
answer, then apply the implementation and verification rules again; receiving
an answer does not itself authorize a fix or external action. Use
factory-lookback to compare these follow-ups with prior reports and fixes.
Summarize coverage by source, including unavailable or truncated reads. For each item or related group, give its links, classification, evidence, disposition, checks, any external action, and the exact human decision still needed.
.agent-factory/config.yaml. If it is missing, stop and
ask the user; never create it or guess sources.git push, gh pr merge,
gh release create and every external write (reply, comment, approval, close,
status change, notification) need the user's literal GO for that exact action.
Prepare the change or draft text, show it, and stop.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.
日本語の概要は準備中です。原文の説明を表示しています。
Use when a hybrid memory system that provides persistent, searchable knowledge management for AI agents (Architecture, Patterns, Decisions).
日本語の概要は準備中です。原文の説明を表示しています。
Reference for how BDB structures autonomous software engineering work — the seven-node dispatcher graph (Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, Shipping) that /startcycle-graph actually runs. Use when you need the high-level lifecycle framing without inventing your own process.
日本語の概要は準備中です。原文の説明を表示しています。
Tools are how AI agents interact with the world. A well-designed tool is the difference between an agent that works and one that hallucinates, fails silently, or costs 10x more tokens than necessary. This skill covers tool design from schema to error handling.
日本語の概要は準備中です。原文の説明を表示しています。
Harness patterns for coding agents — memory, permissions, context engineering, delegation, skills, hooks, bootstrap.
日本語の概要は準備中です。原文の説明を表示しています。
agenttrail: live map of a multi-agent build in the browser: which plan component is being worked on, by which agent or harness, what is done and what is stuck. Use when a multi-agent pipeline starts (/startcycle, /startcycle-graph, /teamwork-preview) or after a plan-canvas approve, when the user asks to see what the agents are doing ("live map", "build board", "who is running now"), or by yourself whenever a multi-agent run is under way — no user prompt needed.
日本語の概要は準備中です。原文の説明を表示しています。