k16shikano

name	cognitive-rhythm-writing
description	説明的な文章に緩急を設計するための規範。緩急を装飾ではなく認知モードの切替（観察→逡巡→断定→再観察）と未回収の緊張の管理として扱い、文の拍、段落の密度波形、節の入り方、緩みと駄文の判別、執筆後の機械的な点検手順を定める。読み物として読ませたい章・記事・解説文を生成するとき、または「密度はあるが平坦でおもしろくない」文章を診断・修正するときに使用する。

認知リズムを生むための日本語ライティング規範

密度の高い文章が退屈になるのは、情報が多いからではなく、全文が同じ認知モードで書かれているからである。 この規範は、読者の認知モード（観察する、迷う、確信する、確かめ直す）を意図的に切り替え、常に「続きを読む理由」を維持することで、読み進める推進力を作る。

voluntas

name	apple-container
description	Apple Silicon Mac で動く軽量 Linux コンテナランタイム `container` (1.1.0) の利用者向けリファレンス。`container run`、`container build`、`container image pull/push`、`container machine`、ボリューム・ネットワーク・DNS・設定ファイルなど、日常的なコマンドの使い方を網羅する。`container` コマンドの使い方やトラブルシューティングに関する質問で使用する。

apple-container（container CLI）

Apple 製の container ツールは、Linux コンテナを 軽量 VM 1 つ = コンテナ 1 個 の方式で Mac 上に起動するランタイム。OCI 互換イメージを使うため Docker / podman で作ったイメージがそのまま動く。リポジトリは apple/container。

このスキルは container 1.1.0 用かつ利用者向け。ソースコードの修正やビルド方法ではなく、container コマンドを使う側の知識を扱う。

k16shikano

name	japanese-tech-writing
description	日本語の技術文書・書籍原稿の文章規範。整形（一文一行、引用ブロック、脚注、コラム記法）、段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。

日本語技術文書の文章規範

日本語で技術的な原稿（書籍の章、記事、解説文）を書く・推敲するときは、以下の規範に従う。

整形

Maharshi-Pandya

You are an assistant that engages in extremely thorough, self-questioning reasoning. Your approach mirrors human stream-of-consciousness thinking, characterized by continuous exploration, self-doubt, and iterative analysis.

## Core Principles

1. EXPLORATION OVER CONCLUSION
- Never rush to conclusions
- Keep exploring until a solution emerges naturally from the evidence
- If uncertain, continue reasoning indefinitely
- Question every assumption and inference

yuheiy

{
  "sizing": {
    "0_5_": {
      "value": "0.125rem",
      "type": "sizing"
    },
    "1_": {
      "value": "0.25rem",
      "type": "sizing"
    },

Jaid

ESLint rules

The ESM standard is considered stable in NodeJS and well supported by a lot of modern JavaScript tools.

ESLint does a good job validating and fixing ESM code (as long as you don't use top-level await, coming in ESLint v8). Make sure to enable the latest ECMA features in the ESLint config.

• .eslint.json

{

ndavison

import requests
import yaml
import re
import json
import time
import logging
import sys
from argparse import ArgumentParser

sindresorhus

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

1. Use ESM yourself. (preferred)
   Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
2. If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
3. Stay on the existing version of the package until you can move to ESM.

qoomon

Conventional Commit Messages

See how a minor change to your commit message style can make a difference.

git commit -m"<type>(<optional scope>): <description>" \
  -m"<optional body>" \
  -m"<optional footer>"

jakub-g

<script> async, defer, async defer, module, nomodule, src, inline - the cheat sheet

With the addition of ES modules, there's now no fewer than 24 ways to load your JS code: (inline|not inline) x (defer|no defer) x (async|no async) x (type=text/javascript | type=module | nomodule) -- and each of them is subtly different.

This document is a comparison of various ways the <script> tags in HTML are processed depending on the attributes set.

If you ever wondered when to use inline <script async type="module"> and when <script nomodule defer src="...">, you're in the good place!

Note that this article is about <script>s inserted in the HTML; the behavior of <script>s inserted at runtime is slightly different - see Deep dive into the murky waters of script loading by Jake Archibald (2013)