Skip to content

Commit 9b00a3b

Browse files
alfonsobriesalfonsobries
committed
chore: install ai conventions
1 parent 6478cae commit 9b00a3b

3 files changed

Lines changed: 150 additions & 0 deletions

File tree

‎.claude/ardenthq/core.md‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
<!-- airc v0.3.0 — managed file, do not edit -->
2+
<!-- Local override: CLAUDE.local.md. Per-repo override: below the @imports in CLAUDE.md. Permanent override: PR to https://github.com/ardenthq/airc -->
3+
4+
# Baseline
5+
6+
Shared rules for every repo. Apply to any stack.
7+
8+
## Commits
9+
10+
- Format: [Conventional Commits](https://www.conventionalcommits.org) — `feat:`, `fix:`, `chore:`, `style:`, `refactor:`, `test:`, `docs:`
11+
- Subject line only, ideally under 50 characters
12+
- Human, direct tone. Avoid formal or robotic voice ("this commit introduces…", "this change implements…")
13+
- **Never** add `Co-Authored-By` or any mention of Claude / AI / agents
14+
- **Never** add a description or body — subject only
15+
- Commit incrementally when a logical chunk lands — don't batch everything at the end
16+
- Examples: `feat: scaffold composer package`, `fix: stack detection for inertia`
17+
18+
## Pull Requests
19+
20+
- Always draft (`gh pr create --draft`)
21+
- Base branch: the repo's default
22+
- If the repo has a `.github/PULL_REQUEST_TEMPLATE.md`, fill it in as the PR body and check off the items that apply. `gh pr create` ignores the template unless you pass it yourself — write the filled body to a file and use `--body-file`
23+
- **Never** reference Claude / AI / agents in title, body, branch name, or comments
24+
25+
## Pre-push checks
26+
27+
Standard order before pushing:
28+
29+
1. Formatter → 2. Linter → 3. Static analysis → 4. Tests
30+
31+
Exact commands are repo-defined (see the repo's `CLAUDE.md` / `composer.json` / `package.json`). If the formatter modifies files, commit those changes before pushing so CI doesn't kick back automated `style:` cleanup commits.
32+
33+
**Mid-task (recommendation):** for long tasks, run only affected/new checks during the work; defer the full suite to the end. For short tasks, skip intermediate runs. Don't run checks repeatedly mid-work — once at completion is usually enough.
34+
35+
## Security
36+
37+
- Never commit `.env`, credentials, tokens, or any secret
38+
- Flag any new dependency as suspect before adding it (typosquatting, unknown maintainer, etc.)
39+
- No destructive operations (`force-push`, branch deletion, history rewrite, `git reset --hard`, `rm -rf`) without explicit confirmation from the dev
40+
- For external tools (CI, pastebins, gists): consider whether uploaded content could be sensitive — it may be cached or indexed even if later deleted
41+
42+
## Code style
43+
44+
- Follow existing patterns before introducing new ones
45+
- Reuse existing components/helpers before writing new ones
46+
- No comments unless explaining a non-obvious **why** (a hidden constraint, a subtle invariant, a workaround for a specific bug)
47+
- Well-named identifiers > a comment explaining the "what"
48+
- **Don't document changes in comments.** Comments describe the code as it is, not how it got there:
49+
- ❌ `// moved from backend to frontend`
50+
- ❌ `// renamed from foo to bar`
51+
- ❌ `// replaces the previous logic that used X`
52+
- ❌ `// added for issue #123`
53+
- ✅ omit the comment — git log / PR tells the story
54+
- Don't reference callers or temporal context: no `// used by X`, `// for the Y flow`, `// added in sprint Z`
55+
56+
## Claude reply style
57+
58+
- Concise. Skip the obvious.
59+
- End-of-turn summary: one or two sentences — what changed, what's next.
60+
- No long essays, no unnecessary disclaimers, no "sure, happy to help…"
61+
62+
## Overrides
63+
64+
- Personal override: create `CLAUDE.local.md` (gitignored)
65+
- Per-repo override: add rules below the `@imports` in this repo's `CLAUDE.md`
66+
- Permanent shared override: PR against the upstream guidelines repo

‎.gitignore‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -15,3 +15,7 @@ dist/
1515
venv
1616
venv/
1717
.venv/
18+
19+
# airc
20+
CLAUDE.local.md
21+
.claude/settings.local.json

‎CLAUDE.md‎

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
@.claude/ardenthq/core.md
2+
# python-crypto - ARK Blockchain Cryptography
3+
4+
## Project Overview
5+
6+
Python cryptography library for the ARK blockchain. Handles transaction building, serialization/deserialization, identity management (addresses, public/private keys, WIF), message signing/verification, and Schnorr signatures.
7+
8+
## Tech Stack
9+
10+
- **Language**: Python
11+
- **Crypto**: coincurve (libsecp256k1 bindings), base58, binary-helpers
12+
- **Testing**: pytest + pytest-cov
13+
- **Linting**: flake8 (+ flake8-import-order, flake8-print, flake8-quotes)
14+
15+
## Directory Structure
16+
17+
- `crypto/` - Main package
18+
- `configuration/` - Fee and network configuration
19+
- `fee.py` - Fee management (get/set fees per transaction type)
20+
- `network.py` - Network configuration (get/set active network)
21+
- `constants.py` - Transaction types, type groups, HTLC expiration types
22+
- `exceptions.py` - Custom exceptions
23+
- `identity/` - Identity utilities
24+
- `address.py` - Address derivation from passphrase/public key/private key
25+
- `private_key.py` - Private key from passphrase/hex
26+
- `public_key.py` - Public key from passphrase/hex
27+
- `wif.py` - WIF (Wallet Import Format) encoding
28+
- `networks/` - Network presets (devnet, mainnet, testnet)
29+
- `schnorr/` - Schnorr signature implementation
30+
- `transactions/` - Transaction handling
31+
- `builder/` - Transaction builders (one per type): transfer, vote, delegate_registration, delegate_resignation, multi_payment, multi_signature_registration, second_signature_registration, ipfs, htlc_lock, htlc_claim, htlc_refund
32+
- `serializer.py` / `serializers/` - Transaction serialization (one per type)
33+
- `deserializer.py` / `deserializers/` - Transaction deserialization (one per type)
34+
- `transaction.py` - Transaction data class
35+
- `utils/` - Utilities
36+
- `message.py` - Message signing/verification
37+
- `slot.py` - Time slot calculations
38+
- `tests/` - Tests mirroring crypto/ structure
39+
- `Makefile` - `make test` and `make lint`
40+
41+
## Key Patterns
42+
43+
- **Transaction builders** extend `BaseTransactionBuilder` in `builder/base.py`, set `transaction_type` and build transaction objects
44+
- **Serializers/Deserializers** extend base classes, one per transaction type
45+
- **Identity** functions derive addresses/keys from passphrases using Schnorr
46+
- **Network config** is global — set via `set_network()`, read via `get_network()`
47+
- **Fee config** is global — set via `set_fee()`, read via `get_fee()`
48+
49+
## Branches
50+
51+
- Base branch: `feat/mainsail` (always use this as base for PRs)
52+
- **Always create a new branch** from `feat/mainsail` before starting any task
53+
- Branch names follow conventional commit prefixes: `feat/`, `fix/`, `chore/`, `refactor/`, `style/`, `docs/`, `test/`
54+
- Use short, descriptive kebab-case names after the prefix
55+
56+
## Testing
57+
58+
- Run tests: `make test` or `pytest -v -s`
59+
- Run lint: `make lint` or `flake8 .`
60+
- **100% code coverage is required** — CI enforces `--cov-fail-under=100`
61+
- Flake8 config: `max-line-length = 100` (in `setup.cfg`)
62+
63+
## After completing a task, ALWAYS run these checks (in order)
64+
65+
1. `make lint` - flake8
66+
2. `make test` - pytest (must pass with 100% coverage)
67+
68+
## Commits
69+
70+
- **Commit as you progress** — make commits incrementally as you complete logical chunks of work, don't wait until the end
71+
- Use conventional commits (feat:, fix:, chore:, style:, refactor:, etc.)
72+
- NEVER add Co-Authored-By or any collaborator line
73+
- NEVER add description/body to commits, ONLY the subject line
74+
- Keep commit messages SHORT — ideally under 50 chars, never long
75+
- Write commit messages naturally like a human would, not overly polished or perfect. Quick and casual is fine, minor typos are ok
76+
- Examples of good commit messages:
77+
- `feat: add wallet search endpoint`
78+
- `fix: wrong query param encoding`
79+
- `chore: update deps`
80+
- `refactor: extract shared pagination logic`

0 commit comments

Comments
 (0)