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

compound

This skill should be used when the user says "/compound", "compound this", "document learnings", "save what we learned", or after completing a PR. Extracts knowledge from PR context and saves to docs/learnings/.

インストール方法を見る

含まれるファイル(3)

  • SKILL.md4.1 KB
  • references/problem-types.md2.8 KB
  • templates/LEARNING_TEMPLATE.md520 B

SKILL.md(原文)

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

Compound Skill

Extracts knowledge from PR context and saves structured documentation to docs/learnings/.

Workflow

Phase 1: Context Collection

  1. Identify PR number/branch

    • Use PR number if provided as argument
    • Otherwise, find PR from current branch: gh pr view --json number,body,title
    • If no PR exists: Prompt user to enter PR number directly or confirm proceeding without PR
  2. Extract Plan path

    • Find Plan path pattern in PR body: .hoyeon/specs/{name}/PLAN.md
    • Regex: \.hoyeon/specs/[^/]+/PLAN\.md
    • If no Plan path found: Prompt user to enter spec name directly or select from .hoyeon/specs/ directory listing
  3. Derive Context path

    • Extract spec name from Plan path
    • Context directory: .hoyeon/specs/{name}/context/
  4. Parallel collection (run following commands simultaneously, skip if files don't exist)

    # Context files (treat as empty if not found)
    cat .hoyeon/specs/{name}/context/learnings.json 2>/dev/null || echo ""
    cat .hoyeon/specs/{name}/context/decisions.md 2>/dev/null || echo ""
    cat .hoyeon/specs/{name}/context/issues.json 2>/dev/null || echo ""
    
    # PR comments and reviews (collect as JSON for stability)
    gh pr view {pr_number} --json comments,reviews
    

Error Handling:

  • If no context files exist AND no PR comments → Notify user and request manual input
  • At least 1 source required to proceed with document generation

Phase 2: Knowledge Extraction & Classification

2.1 Extract Valuable Feedback from PR Comments

Criteria for valuable feedback:

  • Code improvement suggestions
  • Bug/issue identification
  • Pattern/best practice mentions
  • "This would be better" type advice
  • Comments left with approval

Filter out:

  • Simple questions ("What is this?")
  • Confirmation requests ("Is this correct?")
  • Approval-only comments ("LGTM", "Approved")
  • Bot comments

Extraction keywords:

  • "suggest", "recommend", "better", "instead"
  • "pattern", "practice", "convention"
  • "issue", "bug", "fix"
  • "learned", "TIL", "note"

Extracted information:

  • author
  • body
  • file_path (if inline comment)
  • created_at

2.2 Analyze Context Files

FilePurpose
learnings.jsonStructured learnings
decisions.mdDecision rationale
issues.jsonStructured issues

2.3 Synthesize

  1. Assess documentation value from collected sources
  2. Check for duplicates: Search docs/learnings/
  3. Classify problem type - Refer to references/problem-types.md (relative to this skill directory)
  4. Generate tags

Phase 3: Document Generation

  1. Generate YAML frontmatter

    pr_number: {PR_NUMBER}
    date: {YYYY-MM-DD}
    problem_type: {TYPE}
    tags: [{TAGS}]
    plan_path: {PLAN_PATH}
    
  2. Write document using template

    • Template location: templates/LEARNING_TEMPLATE.md (relative to this skill directory)
    • Read template and substitute placeholders
  3. Determine filename

    • Format: {YYYY-MM-DD}-{short-title}.md
    • Example: 2024-01-15-api-error-handling.md
  4. Save

    • Path: docs/learnings/{filename}.md
  5. Add cross-references (if related documents exist)

    • Add new document link to Related section of existing documents

Usage Examples

# Specify PR number
/compound 123

# Use PR from current branch
/compound

Output

Outputs the created document path and summary:

Created: docs/learnings/2024-01-15-api-error-handling.md

Summary:
- Problem Type: error-handling
- Tags: api, typescript, validation
- Sources: learnings.json, 2 PR comments

<!-- TODO: Future extensions --> <!-- - [ ] Session ID based user feedback collection --> <!-- - [ ] CLAUDE.md auto-update suggestions --> <!-- - [ ] Detect existing document UPDATEs --> <!-- - [ ] Auto-categorization by problem_type (docs/solutions/{type}/) -->

レビュー

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

同じリポジトリのスキル

概要と使いどころ

Analyze an open-source project from What/Why perspective (not how-it's-implemented). Use when the user says "/analyze-oss", "분석해줘 이 오픈소스", "이 레포 뭐하는거야", "analyze this repo", "what does X do", "이거 왜 쓰는거야", "이 라이브러리 분석", provides a GitHub URL and wants understanding, or asks to deeply understand an OSS project's purpose, value, target users, and usage flow. Clones the repo to ~/opensource-analysis/<repo-name>/ (git pull if already exists), dispatches parallel subagents per analysis lens, then synthesizes a What/Why-focused report in chat. Supports optional user-specific follow-up questions.

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

team-attention/hoyeon1732026年5月21日 更新

blueprint

無料

"/blueprint", "blueprint", "task graph", "contract derivation", "execution plan", "plan tasks from requirements", "contract-first planning" Turn requirements.md into an executable blueprint (plan.json + contracts.md). Five phases: Contracts → Tasks → Journeys → Verify Plan → Commit. Sits between /specify and /execute. Scope-adaptive (greenfield → bugfix). Uses hoyeon-cli (plan.json only; requirements.md is read as-is via Read tool).

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

team-attention/hoyeon1732026年5月21日 更新

Recon-first browser automation. Orchestrator explores the site first via chromux, saves a guide file with insights, then delegates execution to browser-explorer agent. Use when: "/browser-work", "브라우저 작업", "사이트에서 해줘", "웹에서 해줘", "LinkedIn에서", "크롬으로", "browser task", "automate this site".

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

team-attention/hoyeon1732026年5月21日 更新

bugfix

無料

Root cause based one-shot bug fix. debugger diagnosis → requirements.md generation → /execute. /bugfix "error description" Full investigation pipeline: debugger + gap-analyzer + standard verify. QA suggestion after successful fix.

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

team-attention/hoyeon1732026年5月21日 更新

check

無料

This skill should be used when the user wants to verify their changes before pushing, or update the project's rule checklists. Phase 1: validate changed files against .hoyeon/rules/ checklists and report PASS/WARN. Phase 2 (conditional): propose rule additions when unmatched patterns are detected. Essential before git push. Trigger phrases: "check", "checklist", "verify changes", "what did I miss", "pre-push check", "cascading changes", "any more changes needed", "update checklist", "update rules", "rules update", "체크", "체크리스트", "변경 확인", "빠뜨린 거 없나", "push 전 확인", "뭐 더 건드려야 해?", "연쇄 변경 확인", "규칙 갱신".

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

team-attention/hoyeon1732026年5月21日 更新

clarify

無料

"/clarify", "clarify this", "keep asking until clear", "remove ambiguity", "clarify requirements", "clarify design", "clarify the plan", "질문 계속해", "모호한 게 없게", "명확해질 때까지", "계속 물어봐", "Q&A로 정리", "질문답변 기록", "요구사항 명확화", "설계 명확화". Relentless ambiguity-resolution interview that records Q&A under .hoyeon/clarify/<topic>/ and hands off to specify/blueprint/docs when clear.

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

team-attention/hoyeon1732026年5月21日 更新

team-attention のスキルをすべて見る

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