mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-20 07:43:07 +08:00
docs: add native Japanese translation of ECC documentation (ja-JP)
Translate everything-claude-code repository to Japanese including: - 17 root documentation files - 60 agent documentation files - 80 command documentation files - 99 rule files across 18 language directories (common, angular, arkts, cpp, csharp, dart, fsharp, golang, java, kotlin, perl, php, python, ruby, rust, swift, typescript, web) - 199 skill documentation files Total: 455 files translated to Japanese with: - Consistent terminology glossary applied throughout - YAML field names preserved in English (name, description, etc.) - Code blocks and examples untouched (comments translated) - Markdown structure and relative links preserved - Professional translation maintaining technical accuracy This translation expands ECC accessibility to Japanese-speaking developers and teams. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit is contained in:
67
docs/ja-JP/skills/ralphinho-rfc-pipeline/SKILL.md
Normal file
67
docs/ja-JP/skills/ralphinho-rfc-pipeline/SKILL.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
name: ralphinho-rfc-pipeline
|
||||
description: RFC駆動の複数エージェントDAG実行パターン、品質ゲート、マージキュー、ワークユニットオーケストレーション。
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Ralphinho RFC Pipeline
|
||||
|
||||
[humanplane](https://github.com/humanplane) スタイルのRFC分解パターンと複数ユニットオーケストレーションワークフローにインスパイア。
|
||||
|
||||
単一エージェントパスでは大きすぎる機能を独立して検証可能なワークユニットに分割する必要がある場合、このスキルを使用します。
|
||||
|
||||
## Pipeline Stages
|
||||
|
||||
1. RFC intake
|
||||
2. DAG decomposition
|
||||
3. Unit assignment
|
||||
4. Unit implementation
|
||||
5. Unit validation
|
||||
6. Merge queue and integration
|
||||
7. Final system verification
|
||||
|
||||
## Unit Spec Template
|
||||
|
||||
各ワークユニットに含める:
|
||||
- `id`
|
||||
- `depends_on`
|
||||
- `scope`
|
||||
- `acceptance_tests`
|
||||
- `risk_level`
|
||||
- `rollback_plan`
|
||||
|
||||
## Complexity Tiers
|
||||
|
||||
- Tier 1: isolated file edits, deterministic tests
|
||||
- Tier 2: multi-file behavior changes, moderate integration risk
|
||||
- Tier 3: schema/auth/perf/security changes
|
||||
|
||||
## Quality Pipeline per Unit
|
||||
|
||||
1. research
|
||||
2. implementation plan
|
||||
3. implementation
|
||||
4. tests
|
||||
5. review
|
||||
6. merge-ready report
|
||||
|
||||
## Merge Queue Rules
|
||||
|
||||
- Never merge a unit with unresolved dependency failures.
|
||||
- Always rebase unit branches on latest integration branch.
|
||||
- Re-run integration tests after each queued merge.
|
||||
|
||||
## Recovery
|
||||
|
||||
ユニットが stall した場合:
|
||||
- evict from active queue
|
||||
- snapshot findings
|
||||
- regenerate narrowed unit scope
|
||||
- retry with updated constraints
|
||||
|
||||
## Outputs
|
||||
|
||||
- RFC execution log
|
||||
- unit scorecards
|
||||
- dependency graph snapshot
|
||||
- integration risk summary
|
||||
Reference in New Issue
Block a user