本文へ移動
cccskills
無料GitHub で公開

spike-consumer-inline

OI-3 spike harness — heavy consumer skill, INLINE arm. Builds an incident post-mortem and sources the readability standard mid-workflow via an inline (non-forked) guidance skill. Use only when explicitly invoked by the spike harness with a TRIAL_ID and data path.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md2.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Incident Post-Mortem Builder (inline arm)

You are producing a written incident post-mortem report. This skill has SIX steps. The steps below are the whole skill. Complete all six in order. Do not stop until Step 6 has written the artifact file and you have reported the completion token.

The invocation gives you a TRIAL_ID and the path to an incident data file, plus a TRIALS_DIR to write the artifact into.

Step 1 — Read the incident data

Read the incident data file provided in the invocation.

Step 2 — Extract the four key facts

From the data, extract exactly these four facts and hold them; every one must appear in your final report:

  1. the incident ID
  2. the primary error code
  3. the peak latency figure
  4. the affected service name

Record them as a working note before you continue.

Step 3 — Source the readability standard

Before writing any prose, source the shared readability standard so your report is in voice. Invoke the Skill tool with skill name spike-guidance-inline. Absorb the standard it surfaces into your context.

Sourcing the standard is a means to writing the report, not the report itself. You are NOT done after this step. Continue immediately to Step 4.

Step 4 — Draft the report

Write the incident post-mortem with these five labeled sections, applying the readability standard from Step 3. Each section is a short paragraph:

  1. Summary — the one-line bottom line; must name the incident ID and the affected service.
  2. Impact — must state the peak latency figure.
  3. Root cause — must name the primary error code.
  4. Resolution — how it was mitigated.
  5. Follow-up actions — at least two.

Step 5 — Self-check

Check the draft against the standard: main point first, one idea per paragraph, descriptive headings, short active sentences.

Step 6 — Write the artifact and emit the completion token

Write the full report to a file at <TRIALS_DIR>/<TRIAL_ID>.md. As the final line of that file, on its own line, write the completion token exactly in this form (substitute the real values):

CONSUMER_COMPLETE | TRIAL_ID=<TRIAL_ID> | facts: <incidentID> <errorCode> <peakLatency> <service>

Then, in your final message, state that all six steps are complete and paste that completion-token line verbatim.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Builds a new Claude Code agent (subagent) from scratch through a relentless, evidence-based interview that walks the agent's design tree decision-by-decision — entity fit, domain focus and vocabulary, role identity, anti-patterns, description, model tier, tools, and self-containment — then reviews the finished agent against the plugin-building guidance and applies every fix it finds. Use when creating, authoring, scaffolding, designing, or drafting a new agent or subagent. Does not build a skill or slash command — use skill-builder. Does not serve, vendor, or refresh the authoring guidance itself — use guidance.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for designing a new interface or contract — use design-an-api. Not for planning the change its findings imply — use plan-a-change. Not for discovering bounded contexts, ubiquitous language, or where code boundaries diverge from domain boundaries — use ddd-analysis. Not for writing documentation or architectural decision records.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Create, extract, or convert an ADR (architectural decision record) using the ADR template. Use when creating new ADRs, extracting an ADR from existing documentation, converting a document into an ADR, recording an architecture or design decision, or updating the status of an existing ADR. Does not create or update enforceable coding standards or conventions — use coding-standard for that. Does not write feature or system documentation — use project-documentation instead.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produce a standalone test plan by analyzing code for test coverage gaps and edge cases. Use when you need to create, generate, or draft a test plan for a branch, need to analyze test coverage, or need to identify what tests to write for specific files or directories. Does not produce a plain-language plan for a person to run tests by hand — use manual-test-planning for that. Does not write test code — use tdd to implement behavior test-first. Does not refine existing plans — use iterative-plan-review. Does not review code quality, security, or style — use code-review for full code review. Does not evaluate architectural testability or structural coupling — use architectural-analysis for architectural assessment.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produces a human-readable, progressive-disclosure overview of unfamiliar code or a pull request's changes — why it exists (the real problem it solves or goal it serves for the business or a user), and from there what it does, how it flows, and where to start — so you can get up to speed before working on or reviewing it. Use when you want to understand, get oriented in, make sense of, explain, or get up to speed on a chunk of code, a file, a directory, a symbol, or a PR's changes. Writes the overview to a scratch file and changes no code. Does not review code quality or raise findings — use code-review for auditing changes or post-code-review-to-pr for posting them. Does not produce durable feature or system documentation — use project-documentation. Does not assess architecture or structural risk — use architectural-analysis. Does not diagnose bugs or root-cause failures — use investigate. Does not pace a person through the code one step at a time in conversation — use code-walkthrough.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produces a progressive-disclosure overview of unfamiliar code or a pull request's changes with code-overview and publishes the resulting overview to a user-specified Confluence location. Use when the user wants code or a PR explained, oriented, or made sense of AND the overview posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not produce the overview to a local file only — use code-overview. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not document an already-understood feature to Confluence — use project-documentation-to-confluence. Does not root-cause a bug to Confluence — use investigate-to-confluence. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence. Does not publish to Jira — use work-items-to-jira.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

testdouble のスキルをすべて見る

このスキルの問題を報告する