📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: Jetski/Cortex + Gemini Integration Guide
|
||||
description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,969+ skills."
|
||||
description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,987+ skills."
|
||||
---
|
||||
|
||||
# Jetski/Cortex + Gemini: safe integration with 1,969+ skills
|
||||
# Jetski/Cortex + Gemini: safe integration with 1,987+ skills
|
||||
|
||||
> **Custom-host integration:** This guide documents a low-level, direct-manifest lazy loader for Jetski/Cortex and similar hosts. For Codex or Claude Code, the recommended path is [AAS Core](../users/aas-core.md), which provides neutral, deterministic catalog retrieval and validates exact agent-selected IDs through a bounded, read-only MCP server.
|
||||
|
||||
@@ -25,7 +25,7 @@ Never do:
|
||||
- concatenate all `SKILL.md` content into a single system prompt;
|
||||
- re-inject the entire library for **every** request.
|
||||
|
||||
With 1,969+ skills, this approach fills the context window before user messages are even added, causing truncation.
|
||||
With 1,987+ skills, this approach fills the context window before user messages are even added, causing truncation.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ This example shows one way to integrate **agentic-awesome-skills** with a Jetski
|
||||
- How to enforce a **maximum number of skills per turn** via `maxSkillsPerTurn`.
|
||||
- How to choose whether to **truncate or error** when too many skills are requested via `overflowBehavior`.
|
||||
|
||||
This pattern avoids context overflow when you have 1,969+ skills installed.
|
||||
This pattern avoids context overflow when you have 1,987+ skills installed.
|
||||
|
||||
Manifest contract references:
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ npm run merge:batch -- --prs 450,449,446,451
|
||||
|
||||
Add `--poll-seconds <n>` if you want a slower or faster status loop while checks settle.
|
||||
|
||||
If a PR changes canonical `SKILL.md` content or its allowlisted supporting assets/references/resources, first review the exact current head commit, then attest to that immutable revision:
|
||||
If a PR changes any tracked file under a canonical `skills/<skill-id>/**` subtree, review the entire affected subtree at the exact current head commit, then attest to that immutable revision:
|
||||
|
||||
```bash
|
||||
npm run merge:batch -- --prs 450 --reviewed-head <40-character-head-sha>
|
||||
@@ -34,7 +34,7 @@ Use `--dry-run` to exercise local classification without approving a run or merg
|
||||
- recompute changed-skill evidence with evaluator code materialized from the trusted `main` commit
|
||||
- reject incomplete evidence coverage, deterministic quality/security/provenance regressions, and base/head drift
|
||||
- for external PRs, poll for asynchronously-created fork runs and approve only runs waiting on `action_required` when every path, mode, object, size, and workflow identity is allowlisted
|
||||
- for same-repository maintainer PRs, allow repository-wide source changes while still enforcing trusted changed-skill evidence, exact-head review, required checks, branch protection, and immutable PR identity
|
||||
- for sensitive same-repository source changes, allow the guarded exception only when the PR author is the repository owner and the exact full head SHA is attested; collaborator-authored sensitive changes fail closed under the external safety policy
|
||||
- wait for the latest required checks bound to the exact head SHA
|
||||
- call GitHub's immediate squash-merge endpoint and continue only when it reports `merged: true`
|
||||
- pull the protected `main`; its trusted workflow opens a canonical-sync bot PR for generated artifacts and contributor credits when needed
|
||||
@@ -48,7 +48,7 @@ Use `--dry-run` to exercise local classification without approving a run or merg
|
||||
|
||||
- conflict resolution on the PR branch
|
||||
- manual judgment for risky skill changes
|
||||
- semantic review when the distinct `manual-review-required` check is present
|
||||
- semantic review when the distinct `manual-review-required` check is present; the review fingerprint covers the complete nearest skill directory, including nested examples, scripts, lockfiles, references, and assets
|
||||
- README community-source audits when the source metadata is ambiguous
|
||||
- fork-only edge cases that require contributor coordination outside GitHub permissions
|
||||
- base-branch drift: stale evidence is discarded and the batch must be rerun
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
# Merging Pull Requests
|
||||
|
||||
**Policy: we always Merge PRs on GitHub so contributors get credit. We never Close a PR after integrating their work locally.**
|
||||
**Policy: every accepted PR is merged through `npm run merge:batch`, which uses GitHub's protected squash-merge endpoint so contributors get credit. We never push an integration directly to `main` or close a PR after copying its work.**
|
||||
|
||||
## Always merge via GitHub
|
||||
|
||||
- Use the GitHub UI **"Squash and merge"** for every accepted PR.
|
||||
- Use `npm run merge:batch -- --prs <PR_NUMBER>` for every accepted PR; do not substitute the GitHub UI or a raw `gh pr merge` command.
|
||||
- The PR must show as **Merged**, not Closed. That way the contributor appears in the repo’s contribution graph and the PR is clearly linked to the merge commit.
|
||||
- Do **not** integrate a PR by squashing locally, pushing to `main`, and then closing the PR. That would show "Closed" and the contributor would not get proper credit.
|
||||
- Before merging, require the normal PR checks from [`.github/workflows/ci.yml`](../../.github/workflows/ci.yml) to be green. If the PR touches `SKILL.md`, also require the separate [`skill-review` workflow](../../.github/workflows/skill-review.yml) to pass.
|
||||
- For PRs that touch `SKILL.md` or risky guidance, require a real manual logic review in addition to the automated checks. Confirm the instructions, failure modes, and `risk:` label make sense before merging.
|
||||
- Before merging, require the normal PR checks from [`.github/workflows/ci.yml`](../../.github/workflows/ci.yml) to be green. If the PR changes anything under `skills/**` or `plugins/**/skills/**`, also require a truthful outcome from the separate [`skill-review` workflow](../../.github/workflows/skill-review.yml).
|
||||
- For any tracked change under a canonical `skills/<skill-id>/**` subtree, inspect the complete skill directory and require a real manual logic review in addition to the automated checks. Confirm instructions, bundled files, failure modes, provenance, and `risk:` label before attesting the exact full head SHA.
|
||||
- For ordered multi-PR maintainer batches, use [Merge Batch](merge-batch.md) as the operational shortcut and keep this document as the policy reference.
|
||||
|
||||
## If the PR has merge conflicts
|
||||
|
||||
Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use "Squash and merge" on GitHub.
|
||||
Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use `merge:batch`.
|
||||
|
||||
### Generated files policy
|
||||
|
||||
@@ -38,10 +38,10 @@ Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use "Sq
|
||||
`git add .` then `git commit -m "chore: merge main to resolve conflicts"` (or leave the default merge message).
|
||||
5. **Push to the same branch the PR is from**
|
||||
If the PR is from the contributor’s fork branch (e.g. `sraphaz:feat/uncle-bob-craft`), you need push access to that branch. Options:
|
||||
- **Preferred:** Ask the contributor to merge `main` into their branch, fix conflicts, and push; then you use "Squash and merge" on GitHub.
|
||||
- **Preferred:** Ask the contributor to merge `main` into their branch, fix conflicts, and push; then use `merge:batch`.
|
||||
- If you have a way to push to their branch (e.g. they gave you permission, or the branch is in this repo), push:
|
||||
`git push origin pr-<PR_NUMBER>:feat/uncle-bob-craft` (replace with the actual branch name from the PR).
|
||||
6. **On GitHub:** The PR should now be mergeable. Click **"Squash and merge"**. The PR will show as **Merged**.
|
||||
6. **Run the guarded merge:** Once the PR is mergeable, use `npm run merge:batch -- --prs <PR_NUMBER> [--reviewed-head <40-character-head-sha>]`. The PR will show as **Merged**.
|
||||
|
||||
### If the contributor resolves conflicts
|
||||
|
||||
@@ -58,23 +58,19 @@ git commit -m "chore: merge main to resolve conflicts"
|
||||
git push origin <their-branch>
|
||||
```
|
||||
|
||||
Then you use **"Squash and merge"** on GitHub. The PR will be **Merged**, not Closed.
|
||||
Then use the guarded `merge:batch` command. The PR will be **Merged**, not Closed.
|
||||
|
||||
## Rare exception: local squash (avoid if possible)
|
||||
## No local-integration exception
|
||||
|
||||
Only if merging via GitHub is not possible (e.g. contributor unreachable and you must integrate their work, or a one-off batch), you may squash locally and push to `main`. In that case:
|
||||
|
||||
1. Add a **Co-authored-by** line to the squash commit so the contributor is still credited (see [GitHub: Creating a commit with multiple authors](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors)).
|
||||
2. Close the PR with a comment explaining why it was integrated locally and that attribution is in the commit.
|
||||
3. Prefer to avoid this pattern in the future so PRs can be **Merged** normally.
|
||||
If `merge:batch` cannot prove the immutable PR tuple, required checks, branch protection, or exact review evidence, stop and repair the PR or workflow. Never integrate locally, push directly to `main`, or replace the guarded command with a raw merge.
|
||||
|
||||
## Summary
|
||||
|
||||
| Goal | Action |
|
||||
|-----------------------------|------------------------------------------------------------------------|
|
||||
| Give contributors credit | Always use **Squash and merge** on GitHub so the PR shows **Merged**. |
|
||||
| PR has conflicts | Resolve on the PR branch (you or the contributor), then **Squash and merge**. |
|
||||
| Never | Integrate locally and then **Close** the PR without merging. |
|
||||
| Give contributors credit | Use `merge:batch` so GitHub records the protected squash merge. |
|
||||
| PR has conflicts | Resolve on the PR branch, then run `merge:batch`. |
|
||||
| Never | Push an integration directly to `main`, use a raw merge, or close the PR after copying its work. |
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -63,9 +63,9 @@ A successful `manual-review-required` check means only that the requirement was
|
||||
|
||||
A real merge also requires effective server-side protection for `main`: the four exact GitHub-Actions-owned checks (`pr-policy`, `pr-evidence`, `source-validation`, and `artifact-preview`), strict up-to-date enforcement, pull-request-only changes, administrator enforcement, no applicable ruleset bypass actors, and no merge queue. If that enforcement cannot be proven, `merge:batch` refuses non-dry-run operation. Base drift is never retried with stale evidence; the batch must be rerun from the new tuple. Pre-existing auto-merge state is rejected, and the immediate GitHub merge endpoint must return `merged: true` before post-merge work begins.
|
||||
|
||||
Same-repository maintainer PRs may legitimately change repository-wide policy, tooling, workflows, or documentation, so the fork content allowlist does not apply to them. They remain bound to the protected branch, trusted-base evidence evaluator, exact PR/base/head tuple, semantic-review requirements, and required checks. Missing or mismatched head-repository identity is treated as external and therefore fails closed under the fork allowlist.
|
||||
Sensitive same-repository PRs may use the repository-wide source exception only when the PR author is the repository owner and the maintainer attests the exact full head SHA. Collaborator-authored sensitive PRs do not inherit trust from branch location and fail closed under the external safety policy. Every accepted PR remains bound to the protected branch, trusted-base evidence evaluator, exact PR/base/head tuple, semantic-review requirements, and required checks. Missing or mismatched head-repository identity is treated as external.
|
||||
|
||||
For canonical `SKILL.md` or allowlisted supporting skill-content changes, the maintainer supplies `--reviewed-head <full-sha>`. A stale, abbreviated, or mismatched SHA fails closed. The Skill Review check itself is required only for `SKILL.md` changes because that workflow is path-filtered; support-only changes still require the exact-SHA human attestation.
|
||||
For any tracked change under a canonical `skills/<skill-id>/**` subtree, the maintainer supplies `--reviewed-head <full-sha>`. A stale, abbreviated, or mismatched SHA fails closed. Skill Review triggers for `skills/**` and `plugins/**/skills/**`, and its reusable result is keyed by the complete nearest skill-directory fingerprint, so nested examples, scripts, lockfiles, references, assets, and other bundled files cannot bypass semantic review.
|
||||
|
||||
Deletions, copies, ambiguous moves, and all canonical skill-content changes remain manual-only in this stage even when deterministic evidence contains no regression. A passing ratchet is not semantic approval and never makes a skill eligible for automatic merge.
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ Use this as a diagnostic signal. It is useful for spotting legacy quality debt,
|
||||
- Add the release entry to [`CHANGELOG.md`](../../CHANGELOG.md).
|
||||
- Confirm `README.md` reflects the current version and generated counts.
|
||||
- Confirm Credits & Sources, contributors, and support links are still correct.
|
||||
- If PR or CI workflow behavior changed during the cycle, confirm maintainer and contributor docs mention the active checks (for example the `skill-review` workflow for `SKILL.md` pull requests).
|
||||
- If PR or CI workflow behavior changed during the cycle, confirm maintainer and contributor docs mention the active checks (for example the `skill-review` workflow for any change under `skills/**` or `plugins/**/skills/**`).
|
||||
- If maintainers changed declared risk labels during the cycle, confirm that each change has semantic review evidence rather than lexical inference.
|
||||
|
||||
5. Prepare the protected release PR:
|
||||
@@ -75,7 +75,7 @@ Prerelease versions use the same protected flow, for example `15.0.0-rc.1`. They
|
||||
npm run release:publish -- X.Y.Z
|
||||
```
|
||||
|
||||
This command proves local `main` equals protected `origin/main` and the exact squash commit of the merged `release/vX.Y.Z` PR, checks that no canonical-sync PR or release-state drift remains, creates or reuses the matching local/remote tag safely, and creates the GitHub release object from the matching `CHANGELOG.md` section. SemVer prereleases are marked as GitHub prereleases. It never pushes `main` directly and can be retried after a partial tag/release failure.
|
||||
This command requires exactly one merged release PR from the same repository, authored by the repository owner, with base `main`, exact title `chore: release vX.Y.Z`, and head branch `release/vX.Y.Z`. Zero or multiple candidates fail closed; the command never chooses the newest approximate match. It then proves local `main` equals protected `origin/main` and that PR's exact squash commit, checks that no canonical-sync PR or release-state drift remains, creates or reuses the matching local/remote tag safely, and creates the GitHub release object from the matching `CHANGELOG.md` section. SemVer prereleases are marked as GitHub prereleases. It never pushes `main` directly and can be retried after a partial tag/release failure.
|
||||
|
||||
7. Publish to npm if needed:
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ Preferred homepage:
|
||||
Preferred social preview:
|
||||
|
||||
- lead with `AAS Core` and the profile → stack → plan flow;
|
||||
- present `1,969+ Agentic Skills` as supporting catalog evidence, not a second product;
|
||||
- present `1,987+ Agentic Skills` as supporting catalog evidence, not a second product;
|
||||
- mention Codex and Claude as the current Core agent path, with broader host compatibility as distribution support;
|
||||
- avoid dense text and tiny logos that disappear in social cards.
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ The update process refreshes:
|
||||
- Canonical skills index (`skills_index.json`)
|
||||
- Compatibility mirror (`data/skills_index.json`)
|
||||
- Web app skills data (`apps\web-app\public\skills.json`)
|
||||
- All 1,969+ skills from the skills directory
|
||||
- All 1,987+ skills from the skills directory
|
||||
|
||||
## When to Update
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ AAS MCP does not scan the repository and does not decide which skills are best.
|
||||
> **Release boundary:** AAS Core landed after release 14.6.0. Use an exact Core-capable release rather than an unreviewed moving tag.
|
||||
|
||||
```bash
|
||||
npm exec --yes --ignore-scripts --package=agentic-awesome-skills@15.1.0 -- aas mcp configure \
|
||||
npm exec --yes --ignore-scripts --package=agentic-awesome-skills@15.3.0 -- aas mcp configure \
|
||||
--host codex \
|
||||
--scope user \
|
||||
--config /absolute/path/to/codex/config.toml \
|
||||
@@ -45,6 +45,12 @@ Use `--host claude` with the appropriate absolute Claude MCP configuration path
|
||||
|
||||
Configuration is explicit and integrity-bound. AAS installs or reuses an exact content-addressed runtime, verifies it, and changes only its managed MCP configuration section. Restart the host if it does not reload MCP configuration automatically.
|
||||
|
||||
### Native Windows and Codex
|
||||
|
||||
Native Windows 10 and 11 with Node.js 22 are supported preview targets for the Codex user-scoped adapter, including the Codex CLI `0.144.x` configuration shape. Use absolute Windows paths for `--config`, `--cache-root`, and, when replacing an existing configuration, `--backup-dir`.
|
||||
|
||||
During preview, AAS checks the ownership of the configuration parent directory (normally `%USERPROFILE%\.codex`) and the existing `config.toml` with PowerShell `Get-Acl`; it does not inspect the cache DACL at that stage and does not invoke `icacls`. `AAS_ADAPTER_WINDOWS_ACL_FAILED` now reports the inspected `path`, ACL `phase`, exit `status`, and a bounded diagnostic. An unresolved inherited ACE name is treated as untrusted ACL data rather than crashing identity translation. If preview still fails, use those fields to inspect the named configuration path, not the cache, and do not add `--approve` until preview returns `approvalRequired` with an `approvalDigest`.
|
||||
|
||||
## Quick path
|
||||
|
||||
1. Run the exact-version MCP configuration command above, review its approval digest, and repeat it with `--approve <approval-digest>`.
|
||||
|
||||
@@ -1062,4 +1062,4 @@ Found a skill that should be in a bundle? Or want to create a new bundle? [Open
|
||||
|
||||
---
|
||||
|
||||
_Last updated: June 2026 | Total Skills: 1,969+ | Total Bundles: 58_
|
||||
_Last updated: June 2026 | Total Skills: 1,987+ | Total Bundles: 58_
|
||||
|
||||
@@ -17,7 +17,7 @@ Configure AAS Core for Claude Code, describe the task and constraints, let Claud
|
||||
- It lets Claude search the verified local catalog without loading the full library into context.
|
||||
- It preserves Claude's exact selection without using metadata as an eligibility gate.
|
||||
- It keeps MCP discovery read-only and CLI changes approval-gated.
|
||||
- It includes 1,969+ skills instead of a narrow single-domain starter pack.
|
||||
- It includes 1,987+ skills instead of a narrow single-domain starter pack.
|
||||
- It supports the standard `.claude/skills/` path and the Claude Code plugin marketplace flow.
|
||||
- It also ships generated bundle plugins so teams can install focused packs like `Essentials` or `Security Developer` from the marketplace metadata.
|
||||
- It includes onboarding docs, bundles, and workflows so new users do not need to guess where to begin.
|
||||
|
||||
@@ -231,6 +231,8 @@ npx agentic-awesome-skills
|
||||
|
||||
If you have an older clone created around the removed symlink workaround, reinstall into a fresh directory or rerun `npx agentic-awesome-skills`.
|
||||
|
||||
For AAS Core MCP configuration, native Windows 10 and 11 with Node.js 22 are supported preview targets. A preview failure with `AAS_ADAPTER_WINDOWS_ACL_FAILED` refers to the Codex/Claude configuration directory or file checked with PowerShell `Get-Acl`, not the AAS cache and not `icacls`. Read the returned `path`, `phase`, `status`, and bounded diagnostic; correct the named configuration-path ownership problem, then rerun preview. Never add `--approve` before an approval digest is produced. See the [AAS Core Windows notes](aas-core.md#native-windows-and-codex).
|
||||
|
||||
### I hit a truncation or context crash loop on Windows. How do I recover?
|
||||
|
||||
If Antigravity or a Jetski/Cortex-based host keeps reopening into:
|
||||
|
||||
@@ -12,7 +12,7 @@ Install into the Gemini skills path, then ask Gemini to apply one skill at a tim
|
||||
|
||||
- It installs directly into the expected Gemini skills path.
|
||||
- It includes both core software engineering skills and deeper agent/LLM-oriented skills.
|
||||
- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,969+ files.
|
||||
- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,987+ files.
|
||||
- It is useful whether you want a broad internal skill library or a single repo to test many workflows quickly.
|
||||
|
||||
## Install Gemini CLI Skills
|
||||
|
||||
@@ -18,7 +18,7 @@ Kiro is AWS's agentic AI IDE that combines:
|
||||
|
||||
Kiro's agentic capabilities are enhanced by skills that provide:
|
||||
|
||||
- **Domain expertise** across 1,969+ specialized areas
|
||||
- **Domain expertise** across 1,987+ specialized areas
|
||||
- **Best practices** from Anthropic, OpenAI, Google, Microsoft, and AWS
|
||||
- **Workflow automation** for common development tasks
|
||||
- **AWS-specific patterns** for serverless, infrastructure, and cloud architecture
|
||||
|
||||
@@ -39,7 +39,7 @@ If you came in through a **Claude Code** or **Codex** plugin instead of AAS Core
|
||||
|
||||
When you ran `npx agentic-awesome-skills` or cloned the repository, you:
|
||||
|
||||
✅ **Downloaded 1,969+ skill files** to your computer (default: `~/.agents/skills/`; or a custom path like `~/.agent/skills/` if you used `--path`)
|
||||
✅ **Downloaded 1,987+ skill files** to your computer (default: `~/.agents/skills/`; or a custom path like `~/.agent/skills/` if you used `--path`)
|
||||
✅ **Made them available** to your AI assistant
|
||||
❌ **Did NOT enable them all automatically** (they're just sitting there, waiting)
|
||||
|
||||
@@ -231,7 +231,7 @@ Let's actually use a skill right now. Follow these steps:
|
||||
|
||||
## Direct-install Step 5: Pick Skills Manually
|
||||
|
||||
Don't try to use all 1,969+ skills at once. Here's a sensible approach:
|
||||
Don't try to use all 1,987+ skills at once. Here's a sensible approach:
|
||||
|
||||
If you want a tool-specific starting point before choosing skills, use:
|
||||
|
||||
@@ -362,7 +362,7 @@ Usually no, but if your AI doesn't recognize a skill:
|
||||
|
||||
### "Can I load all skills into the model at once?"
|
||||
|
||||
No. Even though you have 1,969+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
|
||||
No. Even though you have 1,987+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
|
||||
|
||||
The intended pattern is:
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ agentic-awesome-skills/
|
||||
├── 📄 CONTRIBUTING.md ← Contributor workflow
|
||||
├── 📄 CATALOG.md ← Full generated catalog
|
||||
│
|
||||
├── 📁 skills/ ← 1,969+ skills live here
|
||||
├── 📁 skills/ ← 1,987+ skills live here
|
||||
│ │
|
||||
│ ├── 📁 brainstorming/
|
||||
│ │ └── 📄 SKILL.md ← Skill definition
|
||||
@@ -53,7 +53,7 @@ agentic-awesome-skills/
|
||||
│ │ └── 📁 2d-games/
|
||||
│ │ └── 📄 SKILL.md ← Nested skills also supported
|
||||
│ │
|
||||
│ └── ... (1,969+ total)
|
||||
│ └── ... (1,987+ total)
|
||||
│
|
||||
├── 📁 apps/
|
||||
│ └── 📁 web-app/ ← Interactive browser
|
||||
@@ -106,7 +106,7 @@ agentic-awesome-skills/
|
||||
|
||||
```
|
||||
┌─────────────────────────┐
|
||||
│ 1,969+ SKILLS │
|
||||
│ 1,987+ SKILLS │
|
||||
└────────────┬────────────┘
|
||||
│
|
||||
┌────────────────────────┼────────────────────────┐
|
||||
@@ -207,7 +207,7 @@ If you want a workspace-style manual install instead, cloning into `.agent/skill
|
||||
│ ├── 📁 brainstorming/ │
|
||||
│ ├── 📁 stripe-integration/ │
|
||||
│ ├── 📁 react-best-practices/ │
|
||||
│ └── ... (1,969+ total) │
|
||||
│ └── ... (1,987+ total) │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user