본문으로 건너뛰기
cccskills
무료GitHub에 공개

spike-guidance-inline

OI-3 spike harness — the INLINE (non-forked) readability-guidance variant. Surfaces the shared readability standard into the calling skill's own context. Use only when a spike consumer skill invokes it.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md2.1 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Readability Guidance (inline variant)

You have invoked the readability-guidance skill to source the shared writing standard before you draft prose. This content is now in your context. Apply it while you draft, then RETURN to the workflow that called you — this guidance is a means to writing your deliverable, not the deliverable itself.

Emit the line SPIKE_GUIDANCE_MARKER_5R8_INLINE once, to confirm the guidance rendered, then continue.

The audience frame (drafting stage)

While drafting, write for a capable reader who did not do this work and lacks the author's context. This single instruction is the most practical lever for plain output: it steers away from insider shorthand, unstated assumptions, and the author's own mental model.

What the standard requires

  • Main point first. The opening line states the bottom line. A reader who stops after one sentence still gets the answer.
  • One idea per paragraph. Each paragraph carries one idea; its first sentence carries the weight.
  • Descriptive headings. Each heading names its content ("Why the request times out," not "Analysis").
  • Short, active sentences. Roughly fifteen to twenty words on average; few past twenty-five.
  • Common words. Prefer the common word over the technical synonym.
  • Numbered lists for steps, bullets for the rest.
  • Progressive disclosure. Reveal the core first and detail in layers.

Self-check criteria (post-draft stage)

After the draft exists, check: does the opening line state the main point? Does each paragraph carry one idea? Does each heading name its content? Any sentence past about thirty words is a candidate to split.


The standard is now surfaced into your context. Do not treat this guidance as your final answer. Proceed to the next step of the skill that invoked you and produce its deliverable.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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/han3162026년 10월 17일 업데이트

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/han3162026년 10월 17일 업데이트

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/han3162026년 10월 17일 업데이트

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/han3162026년 10월 17일 업데이트

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/han3162026년 10월 17일 업데이트

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/han3162026년 10월 17일 업데이트

testdouble의 스킬 모두 보기

이 스킬의 문제 신고