diff --git a/.github/workflows/markdown_lint.yml b/.github/workflows/markdown_lint.yml index 93caa32..3f43cdf 100644 --- a/.github/workflows/markdown_lint.yml +++ b/.github/workflows/markdown_lint.yml @@ -1,28 +1,35 @@ -name: Markdown Lint +name: Validate Markdown and PR naming on: - push: + pull_request: branches: - main - pull_request: - # Also trigger on ready_for_review to run when a PR changes from draft to ready - types: [opened, reopened, synchronize, ready_for_review] + paths: + - "**.md" + types: + - opened + - synchronize + - reopened + - ready_for_review jobs: - lint: + checks: + if: github.event.pull_request.draft == false runs-on: ubuntu-latest - if: ${{ github.event_name != 'pull_request' || !github.event.pull_request.draft }} steps: - uses: actions/checkout@v4 - - name: Install rumdl pre-compiled binary - run: | - # Define the URL for the latest Linux binary - DOWNLOAD_URL="https://github.com/rvben/rumdl/releases/download/v0.0.185/rumdl-v0.0.185-x86_64-unknown-linux-gnu.tar.gz" - # Use curl to download the archive and tar to extract it - curl -sL $DOWNLOAD_URL | tar -xz -C /usr/local/bin/ + - uses: holdex/github-actions/.github/actions/base/checkout@main + with: + ref: 05eefbf2dfd772dbb2c12b9985d21ac24c5da0e5 + + - uses: ./.holdex-actions/.github/actions/base/setup-runtime + with: + package-manager: bun - # Ensure the binary is executable and in the PATH - chmod +x /usr/local/bin/rumdl - - name: Lint Markdown - run: rumdl check --output-format github . + - uses: ./.holdex-actions/.github/actions/composed/pr-checks + with: + run-prettier: false + run-markdown: true + run-commits: true + package-manager: bun diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..d6b130c --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.claude/settings.local.json diff --git a/docs/ADVOCACY.md b/docs/ADVOCACY.md index 100bb9e..c86fcba 100644 --- a/docs/ADVOCACY.md +++ b/docs/ADVOCACY.md @@ -18,26 +18,28 @@ immediately update your GitHub, LinkedIn, and X profiles to reflect your role. Exclusively promote Holdex in your bio while employed—no other brands or links. Checklist: -| Attribute | Requirement | -|-----------|-------------| -| Name | First name only. | -| Bio | Role at Holdex (e.g., "Full-stack Engineer at @holdex"). | -| Company | @holdex | -| Location | localhost | -| Time | Uncheck; hide current time. | -| Email | Empty. | -| Social Link: X | | -| Social Link: website | | -| Social Link: LinkedIn | | -| Pinned Repositories | Holdex-related only. | -| Overview | In a public self-repo, create README.md stating your role, contributions, enthusiasm for Holdex, and links to Holdex website and GitHub org. | +| Attribute | Requirement | +| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | +| Name | First name only. | +| Bio | Role at Holdex (e.g., "Full-stack Engineer at @holdex"). | +| Company | @holdex | +| Location | localhost | +| Time | Uncheck; hide current time. | +| Email | Empty. | +| Social Link: X | | +| Social Link: website | | +| Social Link: LinkedIn | | +| Pinned Repositories | Holdex-related only. | +| Overview | In a public self-repo, create README.md stating your role, contributions, enthusiasm for Holdex, and links to Holdex website and GitHub org. | ### LinkedIn Profile Add Holdex as your current experience in the "Experience" section. Use this mandatory description: -> Holdex is the premier partner for institutions pioneering DeFi & RWAs. Hong Kong-based since 2016, we turn bold visions into secure, scalable blockchain solutions—driving adoption with unmatched expertise. +> Holdex is the premier partner for institutions pioneering DeFi & RWAs. Hong +> Kong-based since 2016, we turn bold visions into secure, scalable blockchain +> solutions—driving adoption with unmatched expertise. ### X (Twitter) Profile diff --git a/docs/APPLICATION_SUCCESS.md b/docs/APPLICATION_SUCCESS.md index df952c8..8988ceb 100644 --- a/docs/APPLICATION_SUCCESS.md +++ b/docs/APPLICATION_SUCCESS.md @@ -3,7 +3,8 @@ We have received your application and will begin reviewing it soon. > [!NOTE] -> As much as we love to be fast, we are taking our time to reply to each one of you and it's not always immediate. Thank you for understanding. +> As much as we love to be fast, we are taking our time to reply to each one of +> you and it's not always immediate. Thank you for understanding. ## What's next for me? diff --git a/docs/COMPENSATION.md b/docs/COMPENSATION.md index 24aafc8..6b99fa7 100644 --- a/docs/COMPENSATION.md +++ b/docs/COMPENSATION.md @@ -13,18 +13,18 @@ deliver independently. ## Levels & Core Skills -| Level | Key Traits & Expectations | Team Culture | Goals | Problems & Solutions | -|-------|---------------------------|--------------|-------|----------------------| -| **Entry** | Student mindset: Bug-free. Execute tasks. Research. Learn fast. Communicate clearly. Take feedback. | Follow [principles](https://holdex.io/c/learn/principles) & [GitHub rules](https://holdex.io/c/learn/github-strategy). | Understand goals. | Solve, estimate, research, present. Help juniors. | -| **Intermediate** | Confident executor: Solve complex problems. Lead small parts. Help Entry. Strong opinions. | Follow principles. Remind team. | Break into problems. Research solutions. | Identify real problems. Break down. Prioritize. Review juniors. | -| **Lead** | Project owner: Run full projects. Delegate. Coach team. Align with business. Inspire. | Coach others. Lead in projects. | Set timelines. Ensure delivery. | Delegate. Distribute to best fit. | -| **Partner** | Big-picture leader: Own multiple projects. Shape strategy. Say no when needed. Grow culture. | Improve rules/values. | Define business goals & priorities. | (All above + strategic input) | +| Level | Key Traits & Expectations | Team Culture | Goals | Problems & Solutions | +| ---------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | --------------------------------------------------------------- | +| **Entry** | Student mindset: Bug-free. Execute tasks. Research. Learn fast. Communicate clearly. Take feedback. | Follow [principles](https://holdex.io/c/learn/principles) & [GitHub rules](https://holdex.io/c/learn/github-strategy). | Understand goals. | Solve, estimate, research, present. Help juniors. | +| **Intermediate** | Confident executor: Solve complex problems. Lead small parts. Help Entry. Strong opinions. | Follow principles. Remind team. | Break into problems. Research solutions. | Identify real problems. Break down. Prioritize. Review juniors. | +| **Lead** | Project owner: Run full projects. Delegate. Coach team. Align with business. Inspire. | Coach others. Lead in projects. | Set timelines. Ensure delivery. | Delegate. Distribute to best fit. | +| **Partner** | Big-picture leader: Own multiple projects. Shape strategy. Say no when needed. Grow culture. | Improve rules/values. | Define business goals & priorities. | (All above + strategic input) | ## Growth Path -| Level | Focus | -|-------|-------| -| **Entry** | Learn → Execute → Ask | -| **Intermediate** | Solve → Teach → Lead small | -| **Lead** | Own → Delegate → Coach | -| **Partner** | Strategize → Scale → Say No | +| Level | Focus | +| ---------------- | --------------------------- | +| **Entry** | Learn → Execute → Ask | +| **Intermediate** | Solve → Teach → Lead small | +| **Lead** | Own → Delegate → Coach | +| **Partner** | Strategize → Scale → Say No | diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 9ed671b..ac1aa20 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -8,7 +8,8 @@ approachable and respectful. If you are a permanent contributor, read our [Principles](./PRINCIPLES.md). > [!TIP] -> You can use [Wizard Browser Extension](https://chromewebstore.google.com/detail/wizard-browser-extension/gibcadmedmabfnfbolimcndljcopbhep) to simplify some of the workflows described in these Guidelines. +> You can use [Wizard Browser Extension][1] to simplify some of the workflows +> described in these Guidelines. ## Getting started @@ -19,7 +20,9 @@ There are three core contribution pillars: 1. **Solution** – the actual deliverable which resolves the problem > [!NOTE] -> In this guide you will get an overview of the contribution workflow: from finding a Goal, identifying a Problem, and the process of delivering your solutions. +> In this guide you will get an overview of the contribution workflow: from +> finding a Goal, identifying a Problem, and the process of delivering your +> solutions. ### Goal @@ -36,7 +39,8 @@ Each Goal description must include Specs (a Google Document with commenting permissions) and an ETA. > [!NOTE] -> A Goal is represented as a GitHub issue in the relevant repository and has the following naming pattern: `Goal: [statement]`. +> A Goal is represented as a GitHub issue in the relevant repository and has the +> following naming pattern: `Goal: [statement]`. > Goals are created and managed by Partner level contributors. #### Communication within Goal issues @@ -68,8 +72,11 @@ Anything that is stopping you - is a “Problem”. A typical question to ask is Sometimes, a Goal already has a few identified problems, but not always. > [!NOTE] -> Once a Problem is identified, we report it as a [GitHub Issue](https://docs.github.com/en/issues) with the following naming pattern: `Problem: [statement]`. -> We’re counting on our contributors to identify problems. Keep a Problem name short (under 65 chars) and crystal clear. +> Once a Problem is identified, we report it as a +> [GitHub Issue](https://docs.github.com/en/issues) with the following naming +> pattern: `Problem: [statement]`. We’re counting on our contributors to +> identify problems. Keep a Problem name short (under 65 chars) and crystal +> clear. Make sure each Problem issue is interlinked with it's Goal issue: @@ -80,6 +87,11 @@ It's essential to maintain clear links between Goals and related Problem issues. This helps everyone stay informed and team members can easily track progress and understand the context. +> [!IMPORTANT] +> Do not post Problem status updates or notifications back into the Goal issue. +> The link between them is sufficient — keep all updates within the Problem +> issue itself. + ### Solution The third pillar of successful contribution is the Solution. @@ -89,7 +101,14 @@ Whether it’s code, design, or marketing material, we expect a lean and clean solution from the contributor. > [!NOTE] -> Solution is presented in GitHub as a [Pull Request (PR)](https://docs.github.com/en/pull-requests) in compliance with [PR Requirements](#pr-requirements). +> Solution is presented in GitHub as a +> [Pull Request (PR)](https://docs.github.com/en/pull-requests) in compliance +> with [PR Requirements](#pr-requirements). + +> [!IMPORTANT] +> Do not repost PR notifications or progress updates in the Goal issue. The PR +> is linked to the Problem, which is linked to the Goal — that chain is +> sufficient. Duplicate comments add noise. ### Referencing @@ -116,13 +135,13 @@ See these related items: Avoid simply pasting the URL inline. ```md -Check this out: -Related: -See for details +Check this out: Related: See + for details ``` > [!NOTE] -> The list format improves readability and helps contributors quickly understand the context by showing the referenced issue/PR titles automatically. +> The list format improves readability and helps contributors quickly understand +> the context by showing the referenced issue/PR titles automatically. ## PR Requirements @@ -139,8 +158,10 @@ sign their commits. For detailed instructions on why and how to sign your commits refer to [GitHub's documentation on commit signature verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification). -> [!Note] -> We recommend signing commits using an [SSH key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). Ensure your Git version supports SSH signature verification (Git 2.34 or later). +> [!Note] We recommend signing commits using an +> [SSH key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). +> Ensure your Git version supports SSH signature verification (Git 2.34 or +> later). ## Scoping @@ -172,7 +193,9 @@ The required checks are as follows: ``` > [!NOTE] -> Contributors need to resolve all CI issues before assigning reviewers or requesting a review. Any PR with unresolved CI checks should remain in "draft" status until all issues are fixed. +> Contributors need to resolve all CI issues before assigning reviewers or +> requesting a review. Any PR with unresolved CI checks should remain in "draft" +> status until all issues are fixed. ## Drafting @@ -182,7 +205,8 @@ When starting to work on a Problem, you must: [draft PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests) right away. Do not mark PR as "ready to review" unless you are confident it is ready. -1. [Link opened PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) to the corresponding Problem (issue). +1. [Link opened PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) + to the corresponding Problem (issue). 1. Before marking your PR as ready for review, assign **at least one reviewer** (team or individual). Do not merge without approved review. @@ -209,7 +233,6 @@ Structure the design file with the following markup: - **`(...)`** - Used for grouping related features or components. - **`[...]`** - Indicates a specific state of the page or component, such as a popup or modal state. - - Indentation in the list represents the tree structure or hierarchy, showing how components or features are nested or related. @@ -232,7 +255,8 @@ If there isn't an existing DESIGN.md file: ## Naming > [!NOTE] -> We use PR titles to communicate changes to all stakeholders, including non-technical users. +> We use PR titles to communicate changes to all stakeholders, including +> non-technical users. PR names must be: @@ -272,7 +296,6 @@ A feature isn’t a button, toggle, or handler—it’s Correct:"Filter search results by category" 1. **Describe outcomes, not components**: Wrong: "Fix API error handling" → Correct:"Gracefully recover from connection errors" - 1. **Use user action verbs**: _View, Play, Customize, Save_, etc. ### Before Submitting, Ask @@ -288,7 +311,11 @@ Once your PR is ready, assign reviewers and mark it as "ready to review." But before that, report the time you have spent on it. > [!NOTE] -> When contributing, it's essential to report time accurately, including all stages of development (planning, implementation, QA). We encourage opening a PR at the start of your work, even during the planning or investigation phase. Programming and designing isn't just about writing code or creating designs; it also involves planning (40%) and QA (20-30%). +> When contributing, it's essential to report time accurately, including all +> stages of development (planning, implementation, QA). We encourage opening a +> PR at the start of your work, even during the planning or investigation phase. +> Programming and designing isn't just about writing code or creating designs; +> it also involves planning (40%) and QA (20-30%). ### Reviewing PRs @@ -314,3 +341,7 @@ thorough in your QA - reviewers are not QA team members but are there for a final safety check. We expect contributors to deliver bug-free software, understanding that perfection is an ideal. Stand firm in your solutions and avoid unnecessary revisions based on subjective feedback. + +--- + +[1]: https://chromewebstore.google.com/detail/wizard-browser-extension/gibcadmedmabfnfbolimcndljcopbhep diff --git a/docs/LEAVE_POLICY.md b/docs/LEAVE_POLICY.md index f7c5232..15f3758 100644 --- a/docs/LEAVE_POLICY.md +++ b/docs/LEAVE_POLICY.md @@ -5,14 +5,14 @@ described below or directly in the signed agreement. > [!IMPORTANT] > In case of conflict between the signed agreement and scheduler, the signed -agreement terms prevail. +> agreement terms prevail. ## How Many Days Do You Get? -| Your Service Time | Paid Days per Year | Can Carry Over | Can Get Paid When Leaving | -|-------------------------|--------------------|----------------|---------------------------| -| 0 – 6 months | 0 days | – | – | -| 6 months and more | 14 days | Max 3 days | Max 5 days | +| Your Service Time | Paid Days per Year | Can Carry Over | Can Get Paid When Leaving | +| ----------------- | ------------------ | -------------- | ------------------------- | +| 0 – 6 months | 0 days | – | – | +| 6 months and more | 14 days | Max 3 days | Max 5 days | These 14 days cover **everything**: vacation, personal days, sick days, and public holidays. @@ -27,8 +27,8 @@ See the [Leave Request guide](https://wizard.holdex.io/docs/leave-request). ## Money Rules – Super Simple -| Situation | What You Get / Lose | -|-----------------------------------|--------------------------------------------------------------------------------------| -| You leave the company | Up to 5 unused paid days are paid out → `monthly rate ÷ 30 × days` | -| You have leftover days at year end| Max 3 paid days move to next year. The rest disappear. | -| You take unpaid leave | Money is deducted → `monthly rate ÷ 30 × unpaid days` | +| Situation | What You Get / Lose | +| ---------------------------------- | ------------------------------------------------------------------ | +| You leave the company | Up to 5 unused paid days are paid out → `monthly rate ÷ 30 × days` | +| You have leftover days at year end | Max 3 paid days move to next year. The rest disappear. | +| You take unpaid leave | Money is deducted → `monthly rate ÷ 30 × unpaid days` | diff --git a/docs/PRINCIPLES.md b/docs/PRINCIPLES.md index 941a2f9..9d3a067 100644 --- a/docs/PRINCIPLES.md +++ b/docs/PRINCIPLES.md @@ -26,16 +26,16 @@ ## Do This | Not That -| ✅ **Do** | ❌ **Don’t** | -|----------|-------------| +| ✅ **Do** | ❌ **Don’t** | +| ------------------------- | ----------------------- | | Solve what moves the goal | Work on low-value tasks | -| Own it end-to-end | Pass the buck | -| Test your work | Expect others to QA | -| Leave clear updates | Vanish without trace | +| Own it end-to-end | Pass the buck | +| Test your work | Expect others to QA | +| Leave clear updates | Vanish without trace | --- -## ⏰ Core Hours +## ⏰ Core Hours **2–6 PM HKT** — Be online. Rest is flexible. diff --git a/docs/TRIAL.md b/docs/TRIAL.md index 6249013..7168bad 100644 --- a/docs/TRIAL.md +++ b/docs/TRIAL.md @@ -5,7 +5,7 @@ can only be observed during the trial period. Skills such as the ability to figure things out on your own, judgemental skills, decision-making, and async collaboration are part of our internal culture and what we aim for. -Across the whole engineering, our team operates the following way: +Across the whole engineering, our team operates the following way: 1. lead engineers contribute to defining business Goals along with the Partners and Stakeholders diff --git a/settings.json b/settings.json new file mode 100644 index 0000000..9a6a529 --- /dev/null +++ b/settings.json @@ -0,0 +1,20 @@ +{ + "lsp": { + "rumdl": { + "binary": { + "path": "rumdl", + "arguments": ["server"] + } + } + }, + "languages": { + "Markdown": { + "language_servers": ["rumdl", "!markdown-language-server"], + "format_on_save": { + "language_server": { + "name": "rumdl" + } + } + } + } +}