coding-standards
- Repo stars 0
- Author repo skills-registry
name: coding-standards description: Use when writing or reviewing code in any language. Covers typed-language rules (TypeScript, Python, Go), naming conventions, file organisation, error handling, import ordering, and universal quality rules. Read project conventions first to identify the stack, then apply only the relevant language sections.
Coding Standards
Before reviewing, read
copilot-instructions.md/AGENTS.md/CLAUDE.mdto identify the project's language, framework, and version. Adapt stack-specific rules accordingly.
Typed Language Rules (apply only when project uses the language)
TypeScript
- Strict mode required — never disable
strict: true - No
anywithout comment explaining why unavoidable - No
@ts-ignorewithout comment - Use
unknown+ narrowing instead ofanywhen type genuinely unknown interfacefor object shapes;typefor unions, intersections, utilities- All exported functions: explicit return type annotations
Python
- Type hints required on all function signatures (
def fn(x: int) -> str:) - No
# type: ignorewithout explanatory comment - Use
T | None(Python 3.10+) orOptional[T]— no implicitNonereturns - Use
dataclassesorpydanticfor structured data shapes
Go
- All errors must be checked — never discard with
_unless intentional + commented - Exported identifiers must have doc comments
- No
interface{}/anywithout justification - Prefer table-driven tests; use
errors.Is/errors.Asfor error checking
Naming Conventions
| Thing | Convention | Example |
|---|---|---|
| UI components / classes | PascalCase | UserCard, NoteEditor |
| Utility / helper files | kebab-case | sync-messages.ts, format-date.py |
| Variables and functions | camelCase | activeUser, loadData() |
| Module-level constants | UPPER_SNAKE_CASE | MAX_RETRIES |
| Type / interface names | PascalCase | UserSchema, ApiResponse |
| Route / endpoint files | Follow framework convention | +page.server.ts, router.py |
File Organisation
- Group by feature/domain, not by type
- One exported component per file
- Target under 400 lines per file; split larger files by concern
- Before creating a new file, check if logic fits in an existing module
Error Handling
- Never empty
catchblocks — re-throw, log, or return structured error - Server errors: log with context server-side; return safe message to client (no stack traces, no internal paths)
- API routes: return appropriate HTTP status codes with structured error body
- Validate all user input at system boundaries before use
Security (non-negotiable)
- No hardcoded secrets, credentials, or API keys — use environment variables
- Parameterized queries only — never interpolate user input into SQL/queries
- Sanitize user-controlled HTML before rendering (DOMPurify or equivalent)
- Never return stack traces or internal paths to the client
Import Ordering
Groups separated by a blank line:
- External packages / standard library
- Framework internals
- Internal path aliases
- Relative imports
Code Quality
- Functions under 50 lines, single responsibility
- No dead code, unused imports, or commented-out blocks in commits
- No logic repeated at 3+ call sites without extraction into a named helper
- Comment the why, not the what
What Never to Do
- No syntax from the wrong framework version — check project conventions
- No untyped code where the language supports type annotations
- No hardcoded environment-specific values
- No deprecated APIs without a migration comment
<!-- tomevault:4.0:skill_md:2026-05-22 -->Source: AshenDulsanka/agent-arche — distributed by TomeVault.
- Fluxly category
- AI
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 88 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @tomevault-io · no license declared
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Plug-and-play
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Python >=3.10
- Detected file/system behavior
-
- Read-only
- Env read
- Detected network behavior
- Local-only
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. TypeScript Strict mode required — never disable strict: true No any without comment explaining why unavoidable
Thing · Convention · Example UI components / classes · PascalCase · UserCard, NoteEditor Utility / helper files · kebab-case · sync-messages.ts, format-date.py
Group by feature/domain, not by type One exported component per file Target under 400 lines per file; split larger files by concern
Never empty catch blocks — re-throw, log, or return structured error Server errors: log with context server-side; return safe message to client (no stack traces, no internal paths) API routes: return appropriate HTTP status codes with structured error body
No hardcoded secrets, credentials, or API keys — use environment variables Parameterized queries only — never interpolate user input into SQL/queries Sanitize user-controlled HTML before rendering (DOMPurify or equivalent)
Groups separated by a blank line: External packages / standard library Framework internals
---
name: coding-standards
description: Use when writing or reviewing code in any language. Covers typed-language rules (TypeScript, Python, Go), naming conventions, file organisation, error handling, import ordering, and universal quality rules. Read project conventions first to identify the stack, then apply only the relevant language sections.
---
# Coding Standards
> Before reviewing, read `copilot-instructions.md` / `AGENTS.md` / `CLAUDE.md` to identify the project's language, framework, and version. Adapt stack-specific rules accordingly.
## Typed Language Rules (apply only when project uses the language)
**TypeScript**
- Strict mode required — never disable `strict: true`
- No `any` without comment explaining why unavoidable
- No `@ts-ignore` without comment
- Use `unknown` + narrowing instead of `any` when type genuinely unknown
- `interface` for object shapes; `type` for unions, intersections, utilities
- All exported functions: explicit return type annotations
**Python**
- Type hints required on all function signatures (`def fn(x: int) -> str:`)
- No `# type: ignore` without explanatory comment
- Use `T | None` (Python 3.10+) or `Optional[T]` — no implicit `None` returns
- Use `dataclasses` or `pydantic` for structured data shapes
**Go**
- All errors must be checked — never discard with `_` unless intentional + commented
- Exported identifiers must have doc comments
- No `interface{}` / `any` without justification
- Prefer table-driven tests; use `errors.Is`/`errors.As` for error checking
## Naming Conventions
| Thing | Convention | Example |
|-------|-----------|---------|
| UI components / classes | PascalCase | `UserCard`, `NoteEditor` |
| Utility / helper files | kebab-case | `sync-messages.ts`, `format-date.py` |
… Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Typed Language Rules (apply only when project uses the language) → Naming Conventions → File Organisation → Error Handling → Security (non-negotiable) → Import Ordering
terms -> TypeScript · Python · Go · --- name: coding-standards description: Use when writing or reviewing code in any language. · > Before reviewing, read copilot-instructions.md / AGENTS.md / CLAUDE.md to identify the project's language, framework, and version. · Groups separated by a blank line: 1. · --- > Source: [AshenDulsanka/agent-arche](https://github.com/AshenDulsanka/agent-arche) — distributed by [TomeVault](https://tomevault.io).
files/cmd -> copilot-instructions.md · AGENTS.md · CLAUDE.md · strict: true · any · @ts-ignore · unknown · interface
body sha256 -> 56b188a90b31
Decide Fit First
Design Intent
How To Use It
Boundaries And Review