admin-56: add Claude Code actions and project files

.github/workflows/claude-code-review.yml

@@ -0,0 +1,42 @@
+name: Claude Auto Review
+on:
+  pull_request:
+    branches:
+      - develop
+    types: [opened, reopened]
+
+jobs:
+  review:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+      id-token: write
+    steps:
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        with:
+          fetch-depth: 1
+
+      - uses: anthropics/claude-code-action@3ac52d0da9f8ec9ca7b4dc23bb477e36ef9c77a9
+        with:
+          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+
+            Please review this pull request with a focus on:
+            - Code quality and best practices
+            - Potential bugs or issues
+            - Security implications
+            - Performance considerations
+            - Make sure the jira ticket id is in the pr name and the branch name
+            - Use the CLAUDE.md file at the root of the repository for guidelines
+
+            Note: The PR branch is already checked out in the current working directory.
+
+            Use `gh pr comment` for top-level feedback.
+            Use `mcp__github_inline_comment__create_inline_comment` (with `confirmed: true`) to highlight specific code issues.
+            Only post GitHub comments - don't submit review text as messages.
+
+          claude_args: |
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

.github/workflows/claude-pr-description.yml

@@ -0,0 +1,82 @@
+name: Claude PR Description
+
+on:
+  pull_request:
+    branches:
+      - develop
+      - master
+    types: [opened, reopened]
+
+jobs:
+  claude-pr-description:
+    if: |
+      github.event.pull_request.body == null ||
+       github.event.pull_request.body == '' ||
+       contains(github.event.pull_request.body, '<short imperative title>')
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+      issues: read
+      id-token: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        with:
+          fetch-depth: 0
+
+      - name: Generate PR description
+        uses: anthropics/claude-code-action@3ac52d0da9f8ec9ca7b4dc23bb477e36ef9c77a9
+        with:
+          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+          prompt: |
+            You are a staff software engineer writing a GitHub pull request description.
+
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+
+            Analyse every file changed in this PR and write a clear, structured description.
+
+            Rules:
+            - Extract the Jira ticket from the branch name
+              (e.g. `hub-234-my-feature` -> ticket is `HUB-234`).
+              If no ticket is found, use `[JIRA-XXX]` as a placeholder.
+            - The title line must start with the Jira ticket: `## [HUB-234] Short title`.
+            - "Summary" bullets must explain the *why*, not just list file names.
+            - "Changes in detail" should have one sub-section per logical change group,
+              not one per file.
+            - "Test plan" must list concrete, checkable steps a reviewer can follow.
+            - Never mention internal file paths in the Summary - save those for
+              "Changes in detail".
+            - Be concise: aim for a description a reviewer can read in under 2 minutes.
+
+            Generate the PR body in the following format and then update the PR using
+            `gh pr edit ${{ github.event.pull_request.number }} --body "<generated body>"`.
+
+            Format:
+            ## [JIRA-XXX] <short imperative title>
+
+            ## Summary
+            - <bullet: what changed and why>
+            - <bullet: what changed and why>
+            - <bullet: what changed and why>
+
+            ## Changes in detail
+
+            ### `<logical group name>` (<new|updated|fixed>)
+            <1-2 sentences explaining the change, referencing file/function names where useful>
+
+            ### `<logical group name>` (<new|updated|fixed>)
+            <1-2 sentences>
+
+            ## Test plan
+            - [ ] <concrete step>
+            - [ ] <concrete step>
+            - [ ] <concrete step>
+
+            ## Related
+            <!-- Ticket, dependent PRs -->
+
+          claude_args: |
+            --allowedTools "Bash(gh pr edit:*),Bash(gh pr view:*),Bash(gh pr diff:*)"

CLAUDE.md

@@ -0,0 +1,38 @@
+# CLAUDE.md
+
+## Project overview
+
+Core Lightning — Lightning Network node implementation in C. Spec-compliant, modular daemon architecture.
+
+## Common commands
+
+```bash
+./configure          # Configure build
+make                 # Build
+make check           # Run tests
+make install         # Install
+make clean           # Clean build artifacts
+```
+
+## Code conventions
+
+- **Formatting**: follow existing style (tabs for indentation, K&R braces)
+- **Naming**: `snake_case` for functions/variables, `SCREAMING_SNAKE_CASE` for macros/constants
+- **Memory management**: use `tal` memory pools (project-wide convention); all allocations must have a parent context
+- **Error handling**: return error codes; log with the project's logging macros
+- **Modules**: each plugin/daemon in its own subdirectory with `Makefile`
+- **Never use**: raw `malloc`/`free` (use `tal`/`tal_free`), unbounded `strcpy`/`strcat` (use length-bounded variants)
+
+## Git conventions
+
+- **Commit messages**: subject line ≤ 72 chars; body explains *why* not *what*; reference issue numbers
+- **Branch naming**: feature branches from `master`
+- **Main branch**: `master`
+
+## What to watch out for
+
+- This is consensus-critical code — behavior must match the BOLT specs exactly
+- Any change to protocol-level logic requires cross-implementation test validation
+- Memory leaks can be catastrophic in long-running daemons — always verify `tal` ownership
+- Never log secrets (private keys, preimages, node keys)
+- Review cryptographic changes with extra care — side-channel attacks are a real concern

pull_request_template.md

@@ -0,0 +1,22 @@
+## [JIRA-XXX] <short imperative title>
+
+## Summary
+    - <bullet: what changed and why>
+    - <bullet: what changed and why>
+    - <bullet: what changed and why>
+
+## Changes in detail
+
+### `<logical group name>` (<new|updated|fixed>)
+    <1-2 sentences explaining the change, referencing file/function names where useful>
+
+### `<logical group name>` (<new|updated|fixed>)
+    <1-2 sentences>
+
+## Test plan
+    - [ ] <concrete step>
+    - [ ] <concrete step>
+    - [ ] <concrete step>
+
+## Related
+    <!-- Ticket, dependent PRs -->