wormclaude 1.0.12 → 1.0.14

package/dist/tools.js

@@ -11,6 +11,9 @@ import { runAgentLoop } from './agent.js';
 import { tasks } from './tasks.js';
 import { getMcpToolSchemas, callMcpTool } from './mcp.js';
 import { getSkills, getSkill, buildSkillPrompt } from './skills.js';
+import { getExcludedTools } from './extensions.js';
+import { checkCommand } from './cmdsec.js';
+import * as Diff from 'diff';
 import * as computer from './computer.js';
 // Agent/alt-agent araçlarının backend'e ulaşması için config. cli.tsx başlangıçta
 // setToolConfig ile aynı (mutable) config nesnesini verir → /config değişiklikleri görülür.
@@ -516,7 +519,9 @@ const computerToolSchemas = [
 ];
 export function allToolSchemas() {
     const sk = skillToolSchema();
-    return [...toolSchemas, ...computerToolSchemas, ...getMcpToolSchemas(), ...(sk ? [sk] : [])];
+    const all = [...toolSchemas, ...computerToolSchemas, ...getMcpToolSchemas(), ...(sk ? [sk] : [])];
+    const excluded = new Set(getExcludedTools());
+    return excluded.size ? all.filter((t) => !excluded.has(t.function.name)) : all;
 }
 const TOOL_META = {
     Read: { readOnly: true, concurrencySafe: true },
@@ -599,6 +604,17 @@ async function execOne(call, hooks) {
     if (planMode && !isReadOnly(call.name)) {
         return { ok: false, output: 'Plan modunda — yazma/komut engellendi. Önce ExitPlanMode ile planı onaylat.', args };
     }
+    // 3.5) Komut güvenliği (Bash/PowerShell) — cmdsec: deny→blokla, allow→izinsiz, confirm→izin akışı
+    if ((call.name === 'Bash' || call.name === 'PowerShell') && args && args.command) {
+        const chk = checkCommand(String(args.command));
+        if (chk.decision === 'deny') {
+            return { ok: false, output: `⛔ Güvenlik: komut engellendi — ${chk.reason || 'tehlikeli komut'}`, args };
+        }
+        if (chk.decision === 'allow') {
+            const res = await executeTool(call.name, args);
+            return { ...res, args };
+        }
+    }
     // 4) İzin (gerekiyorsa)
     if (needsPermission(call.name) && hooks?.confirm) {
         const decision = await hooks.confirm(call, args);
@@ -761,6 +777,23 @@ const TYPE_EXT = {
     sh: ['sh', 'bash', 'zsh'],
 };
 // ── Executor ──────────────────────────────────────────────────────────────────
+// Edit/Write icin +/- satir ozeti (Diff paketiyle).
+function diffStat(oldStr, newStr) {
+    try {
+        let added = 0, removed = 0;
+        for (const part of Diff.diffLines(oldStr || '', newStr || '')) {
+            const n = part.count || (part.value ? part.value.split('\n').filter(Boolean).length : 0);
+            if (part.added)
+                added += n;
+            else if (part.removed)
+                removed += n;
+        }
+        return (added || removed) ? `  (+${added} -${removed})` : '';
+    }
+    catch {
+        return '';
+    }
+}
 export async function executeTool(name, args) {
     try {
         if (name === 'See') {
@@ -874,9 +907,16 @@ export async function executeTool(name, args) {
             if (fs.existsSync(fp) && !readFiles.has(norm(fp)))
                 return { ok: false, output: 'Error: existing file must be read first. Use the Read tool before overwriting.' };
             fs.mkdirSync(path.dirname(path.resolve(fp)), { recursive: true });
-            fs.writeFileSync(fp, args.content ?? '');
+            const _wnew = args.content ?? '';
+            const _wold = (() => { try {
+                return fs.readFileSync(fp, 'utf8');
+            }
+            catch {
+                return '';
+            } })();
+            fs.writeFileSync(fp, _wnew);
             readFiles.add(norm(fp));
-            return { ok: true, output: `Wrote ${fp} (${(args.content || '').length} chars)` };
+            return { ok: true, output: `Wrote ${fp} (${_wnew.length} chars)${diffStat(_wold, _wnew)}` };
         }
         if (name === 'Edit') {
             const fp = args.file_path;
@@ -897,9 +937,10 @@ export async function executeTool(name, args) {
                     ok: false,
                     output: `Error: old_string is not unique (${count} matches). Provide more surrounding context or set replace_all: true.`,
                 };
+            const _ebefore = c;
             c = args.replace_all ? c.split(oldStr).join(newStr) : c.replace(oldStr, newStr);
             fs.writeFileSync(fp, c);
-            return { ok: true, output: `Edited ${fp}${args.replace_all ? ` (${count} occurrences)` : ''}` };
+            return { ok: true, output: `Edited ${fp}${args.replace_all ? ` (${count} occurrences)` : ''}${diffStat(_ebefore, c)}` };
         }
         if (name === 'Glob') {
             const base = args.path || process.cwd();

package/extensions/code-review/README.md

@@ -0,0 +1,22 @@
+# Code Review Extension
+
+Automated code review assistant. Each command reviews the current uncommitted diff by default, or a path you name.
+
+## Commands
+
+- `/review:security` - Security-focused review (injection, XSS, access control, secrets, SSRF, deps…)
+- `/review:performance` - Performance review (complexity, N+1 queries, I/O, memory, re-renders…)
+- `/review:best-practices` - Code quality review (readability, structure, error handling, tests, docs)
+
+## Installation
+
+```
+wormclaude extensions install --from-registry code-review
+```
+
+Or use `/browse-extensions` in the CLI and select this extension.
+
+## Notes
+
+- Reviews are read-only by default — they report findings with `file:line` evidence and concrete fixes; they don't change code unless you ask.
+- If the project has `code_styleguides/`, `/review:best-practices` holds the code to those guides.

package/extensions/code-review/commands/review/best-practices.toml

@@ -0,0 +1,15 @@
+description = "Review the current changes or a path for code quality and best practices"
+prompt = """
+Review for code quality and adherence to best practices. Default scope: the uncommitted diff (`git diff HEAD`); otherwise the path the user names. If `code_styleguides/` exists, hold the code to it.
+
+Check, with file:line evidence:
+- Readability & naming: clear intent, consistent style, no dead/commented-out code.
+- Structure: DRY, single-responsibility, sensible module boundaries, low coupling.
+- Error handling: errors checked (not swallowed), meaningful messages, no bare catches.
+- Types & contracts: types/annotations present and honest; no `any`-style escape hatches.
+- Tests: meaningful coverage for new logic and edge/failure cases.
+- Docs: public functions/types documented per project convention.
+- Conventions: matches the surrounding code and the project's style guides.
+
+For each issue: location, why it matters, and a concrete suggestion. Distinguish must-fix from nice-to-have. Be constructive and specific. Read/analyze only unless asked to change code.
+"""

package/extensions/code-review/commands/review/performance.toml

@@ -0,0 +1,14 @@
+description = "Performance-focused review of the current changes or a given path"
+prompt = """
+Perform a performance review. Default scope: the uncommitted diff (`git diff HEAD`); otherwise the path the user names.
+
+Look for, with file:line evidence:
+- Algorithmic complexity: needless O(n^2)+ loops, repeated work that could be cached/memoized.
+- Database: N+1 queries, missing indexes, SELECT *, unbounded result sets, queries in loops.
+- I/O & network: synchronous/blocking calls on hot paths, missing batching, chatty requests.
+- Memory: leaks, large allocations, retaining references, loading whole files when streaming would do.
+- Frontend: unnecessary re-renders, large bundles, unoptimized images, layout thrashing.
+- Concurrency: lock contention, blocking the event loop.
+
+For each issue: location, why it's slow, the realistic impact, and a concrete fix (with a code sketch where useful). Prioritize by expected impact. Do not micro-optimize where it doesn't matter — call that out too. Read/analyze only unless asked to change code.
+"""

package/extensions/code-review/commands/review/security.toml

@@ -0,0 +1,16 @@
+description = "Security-focused review of the current changes or a given path"
+prompt = """
+Perform a security review. Default scope: the uncommitted diff (`git diff HEAD`); if the repo is clean or the user names a path, review that path instead.
+
+Look for, and prove each finding with file:line:
+- Injection: SQL, command, SSTI, LDAP/NoSQL.
+- XSS / missing output encoding; dangerous innerHTML/render.
+- Broken access control: IDOR, missing authz, security-by-obscurity.
+- Auth/session: weak tokens, broken JWT verification, plaintext/weak password storage.
+- Secrets committed in code or config.
+- Path traversal, unsafe file ops, unsafe deserialization.
+- SSRF, open redirect, CORS misconfiguration.
+- Vulnerable/outdated dependencies.
+
+For each finding give: location, class, severity (Critical/High/Medium/Low), real-world impact, and a concrete secure fix. Be precise — back every claim with code. End with a short prioritized summary. This is read/analyze only; do not change code unless asked.
+"""

package/extensions/code-review/wormclaude-extension.json

@@ -0,0 +1,6 @@
+{
+  "name": "code-review",
+  "version": "1.0.0",
+  "description": "Automated code review: security, performance, and best-practices passes.",
+  "contextFileName": "README.md"
+}

package/extensions/conductor/README.md

@@ -0,0 +1,250 @@
+# Conductor Extension for wormclaude CLI
+
+The Conductor extension enables Context-Driven Development (CDD) - a structured approach to software development that emphasizes clear specifications, systematic planning, and rigorous execution tracking.
+
+## Overview
+
+Conductor provides a spec-driven workflow that guides you through:
+1. **Context** - Understanding the problem and requirements
+2. **Spec & Plan** - Creating detailed specifications and implementation plans
+3. **Implement** - Following the plan with strict adherence to workflow
+
+## Installation
+
+```bash
+wormclaude extensions install ./path/to/conductor
+```
+
+Or copy this example to your extensions directory:
+
+```bash
+cp -r packages/cli/src/commands/extensions/examples/conductor ~/.wormclaude/extensions/
+```
+
+## Commands
+
+### `/conductor:setup`
+Initialize a new project with Conductor workflow files.
+
+**Usage:**
+
+```
+/conductor:setup
+```
+
+**What it creates:**
+- `plan.md` - Project plan with phases and tasks
+- `tech-stack.md` - Technology decisions and architecture
+- `product.md` - Product specification and requirements
+- `product-guidelines.md` - Design and development guidelines
+- `workflow.md` - Development workflow and processes
+- `code_styleguides/` - Language-specific style guides
+- `.wormclaudeignore` - Files to exclude from wormclaude context
+
+### `/conductor:newTrack`
+Create a new development track (feature/bug fix) with planning.
+
+**Usage:**
+
+```
+/conductor:newTrack
+```
+
+**What it does:**
+- Analyzes current project state
+- Creates detailed implementation plan
+- Sets up tracking structure
+- Guides through specification process
+
+### `/conductor:implement`
+Work on the current track following Conductor workflow.
+
+**Usage:**
+
+```
+/conductor:implement
+```
+
+**What it does:**
+- Enforces Test-Driven Development (TDD)
+- Tracks task progress in `plan.md`
+- Manages git commits with detailed notes
+- Handles phase completion and checkpointing
+- Ensures quality gates are met
+
+### `/conductor:status`
+Show current project status and progress.
+
+**Usage:**
+
+```
+/conductor:status
+```
+
+**What it shows:**
+- Current phase and tasks
+- Completed work with commit references
+- Quality metrics and coverage
+- Next steps and recommendations
+
+### `/conductor:revert`
+Revert changes using git-aware rollback.
+
+**Usage:**
+
+```
+/conductor:revert
+```
+
+**What it does:**
+- Safely reverts to previous checkpoints
+- Handles track, phase, or task-level rollbacks
+- Preserves git history and notes
+- Updates plan.md accordingly
+
+## Workflow Overview
+
+### 1. Project Setup
+
+```bash
+# Initialize new project with Conductor
+/conductor:setup
+
+# Review and customize generated files
+# - Edit product.md with your requirements
+# - Update tech-stack.md with your technology choices
+# - Customize workflow.md for your team
+```
+
+### 2. Development Cycle
+
+```bash
+# Start new feature/track
+/conductor:newTrack
+
+# Work on implementation
+/conductor:implement
+
+# Check progress
+/conductor:status
+
+# Revert if needed
+/conductor:revert
+```
+
+### 3. Quality Gates
+Every task must pass:
+- ✅ All tests pass
+- ✅ Code coverage >80%
+- ✅ Follows style guidelines
+- ✅ Documentation updated
+- ✅ Security review (if applicable)
+
+## Key Features
+
+### Test-Driven Development
+- Enforces Red-Green-Refactor cycle
+- Requires failing tests before implementation
+- Tracks coverage metrics
+- Integrates with project test frameworks
+
+### Git Integration
+- Automatic commit tracking
+- Detailed git notes for audit trail
+- Phase checkpointing
+- Safe rollback capabilities
+
+### Progress Tracking
+- Task status in `plan.md`
+- Commit SHA tracking
+- Phase completion markers
+- Quality gate verification
+
+### Template System
+- Project templates for common setups
+- Code style guides for multiple languages
+- Workflow templates adaptable to any tech stack
+- Product specification templates
+
+## File Structure
+
+After setup, your project will have:
+
+```
+project/
+├── plan.md                    # Main project plan
+├── tech-stack.md             # Technology decisions
+├── product.md                # Product specification
+├── product-guidelines.md     # Design guidelines
+├── workflow.md               # Development workflow
+├── .wormclaudeignore           # wormclaude exclusions
+└── code_styleguides/         # Style guides
+    ├── general.md
+    ├── javascript.md
+    ├── typescript.md
+    ├── python.md
+    └── go.md
+```
+
+## Best Practices
+
+### Planning
+- Keep tasks small and specific
+- Write clear acceptance criteria
+- Update tech-stack.md before implementation
+- Review product.md regularly
+
+### Implementation
+- Follow TDD strictly (Red-Green-Refactor)
+- Commit frequently with descriptive messages
+- Update plan.md as you complete tasks
+- Run quality checks before marking tasks complete
+
+### Team Collaboration
+- Use consistent commit message format
+- Review and update workflow.md together
+- Share code style guidelines
+- Conduct regular retrospectives
+
+## Customization
+
+### Adapting Templates
+The templates in `templates/` can be customized:
+- Modify `workflow.md` for your team's process
+- Update style guides for your coding standards
+- Customize `product.md` template for your domain
+- Add new templates as needed
+
+### Project-Specific Setup
+- Update `.wormclaudeignore` for your project structure
+- Modify quality gates in workflow.md
+- Adapt testing requirements
+- Customize deployment processes
+
+## Troubleshooting
+
+### Common Issues
+
+**Q: Tests are failing during implementation**
+A: This is expected in TDD. Write failing tests first (Red), then implement to make them pass (Green), then refactor.
+
+**Q: Can't find previous checkpoint**
+A: Use `/conductor:status` to see available checkpoints, or check git notes with `git notes list`.
+
+**Q: Quality gates are too strict**
+A: Customize the quality requirements in `workflow.md` to match your project needs.
+
+**Q: Extension commands not working**
+A: Ensure the extension is properly installed with `wormclaude extensions list`.
+
+## Contributing
+
+To improve the Conductor extension:
+1. Fork the repository
+2. Make your changes
+3. Test with real projects
+4. Submit a pull request
+
+## License
+
+This extension follows the same license as wormclaude CLI.

package/extensions/conductor/commands/conductor/implement.toml

@@ -0,0 +1,15 @@
+description = "Work the current track: TDD, task tracking, quality gates, and commits"
+prompt = """
+Implement the next available task on the current Conductor track, following the workflow in `workflow.md`.
+
+For the next `[ ]` task in `plan.md` (in order):
+1. Mark it `[~]` (in progress) in `plan.md`.
+2. Mirror the task's steps into TodoWrite so progress is visible.
+3. If the project has tests (or the task warrants them), write the failing test FIRST and confirm it fails for the right reason.
+4. Implement the minimum code to satisfy the task and make the test pass. Follow the project's conventions and `code_styleguides/`. Read a file before you Edit it.
+5. Verify: run the project's build, lint, type-check, and tests (find the real commands from README/manifest — never assume). Do a quick functional check.
+6. If the implementation deviated from `tech-stack.md`, update it with a dated note.
+7. When the task passes the quality gates in `workflow.md`, mark it `[x]` in `plan.md`. If the user asked to commit, stage the related changes and commit with a clear conventional message.
+
+Then stop and report what you completed and what the next task is. Do NOT silently work the whole plan at once — one task per invocation unless the user says otherwise.
+"""

package/extensions/conductor/commands/conductor/newTrack.toml

@@ -0,0 +1,16 @@
+description = "Start a new development track (feature/bug fix) with a planned set of phases and tasks"
+prompt = """
+Start a new Conductor development track for the work described by the user.
+
+Steps:
+1. Read `product.md`, `tech-stack.md`, and `plan.md` if they exist (run `/conductor:setup` first if they do not).
+2. Clarify the goal: restate the feature/fix in one or two sentences. Ask one sharp question ONLY if a critical detail is missing; otherwise proceed with reasonable assumptions and note them.
+3. Break the work into phases, and each phase into small, specific, testable tasks with clear acceptance criteria.
+4. Append the new track to `plan.md` using checkboxes:
+   - `[ ]` not started, `[~]` in progress, `[x]` done.
+   - Group tasks under phase headings.
+5. If the approach changes the tech stack, update `tech-stack.md` with a dated note BEFORE implementing.
+6. Summarize the track and tell the user to run `/conductor:implement` to begin.
+
+Use the Write/Edit tools to update plan.md. Keep tasks small enough to finish and verify individually.
+"""

package/extensions/conductor/commands/conductor/revert.toml

@@ -0,0 +1,14 @@
+description = "Safely roll back the last task or phase using git, and update the plan"
+prompt = """
+Help the user safely revert recent Conductor work.
+
+Steps:
+1. Run `git status` and `git log --oneline -n 10` to show the recent commits and current state.
+2. Ask the user (or infer from their request) the rollback scope: the last TASK, the last PHASE, or a specific commit.
+3. Propose the exact git command(s) you would run (e.g. `git revert <sha>` to keep history, or `git reset --hard <sha>` only if the user explicitly wants to discard). Prefer `git revert` (non-destructive) by default. Explain the impact before running anything.
+4. Only after the user confirms, perform the rollback.
+5. Update `plan.md` to reflect the reverted task/phase status (change `[x]`/`[~]` back to `[ ]` as appropriate).
+6. Confirm the final state with `git status`.
+
+NEVER discard uncommitted work or force-reset without explicit confirmation. Never push.
+"""

package/extensions/conductor/commands/conductor/setup.toml

@@ -0,0 +1,16 @@
+description = "Initialize the project for Context-Driven Development (plan, specs, workflow, style guides)"
+prompt = """
+You are setting up Context-Driven Development (CDD) for the CURRENT project.
+
+Steps:
+1. Explore the repo: Read the package manifest (package.json, requirements.txt, go.mod, pyproject.toml, Cargo.toml, etc.) and a few key files to detect the language, framework, and purpose.
+2. Read the template files in this extension's `templates/` directory (Read them — do not invent their contents).
+3. Create these files in the PROJECT ROOT, adapting each template to THIS project. Use the Write tool for each, one call per file:
+   - `plan.md`, `tech-stack.md`, `product.md`, `product-guidelines.md`, `workflow.md`, `.wormclaudeignore`
+   - `code_styleguides/` — copy only the guides relevant to the detected stack, and always include `general.md`.
+4. Fill `tech-stack.md` and `product.md` with what you actually inferred from the repo; leave clearly-marked TODOs where you genuinely cannot tell.
+5. Do NOT overwrite an existing file without saying so — if one exists, skip it and note it.
+6. Finish with a short summary of what was created and tell the user the next step is `/conductor:newTrack`.
+
+Keep going until all files are created. Be concise in your final report.
+"""

package/extensions/conductor/commands/conductor/status.toml

@@ -0,0 +1,15 @@
+description = "Show the current track status: phases, tasks, progress, and next steps"
+prompt = """
+Report the current Conductor status.
+
+Steps:
+1. Read `plan.md`. If it does not exist, tell the user to run `/conductor:setup` and `/conductor:newTrack`.
+2. Summarize:
+   - Current phase and which task is in progress (`[~]`).
+   - Completed tasks (`[x]`) and how many remain (`[ ]`), as a simple progress count.
+   - If commit SHAs or checkpoints are recorded in plan.md, list the most recent ones.
+3. If a test/coverage report is easy to obtain (e.g. the project has a coverage script), you MAY run it and report the number — otherwise skip it.
+4. End with a clear recommended next step (usually `/conductor:implement`).
+
+This is a READ-ONLY status report — do not modify any files.
+"""

package/extensions/conductor/templates/.wormclaudeignore

@@ -0,0 +1,37 @@
+# Files and directories WormClaude should ignore for project context.
+# Same glob style as .gitignore.
+
+# Dependencies
+node_modules/
+vendor/
+.venv/
+venv/
+__pycache__/
+
+# Build output
+dist/
+build/
+out/
+target/
+.next/
+coverage/
+
+# Logs & temp
+*.log
+.DS_Store
+tmp/
+.cache/
+
+# Secrets (never load into context)
+.env
+.env.*
+*.pem
+*.key
+
+# Large/binary assets
+*.zip
+*.tar.gz
+*.mp4
+*.png
+*.jpg
+*.pdf

package/extensions/conductor/templates/code_styleguides/go.md

@@ -0,0 +1,48 @@
+# Effective Go Style Guide Summary
+
+This document summarizes key rules and best practices from the official "Effective Go" guide for writing idiomatic Go code.
+
+## 1. Formatting
+- **gofmt**: All Go code must be formatted with `gofmt` (or `go fmt`). This is a non-negotiable, automated standard.
+- **Indentation**: Use tabs for indentation (gofmt handles this).
+- **Line Length**: Go has no strict line length limit. Let gofmt handle line wrapping.
+
+## 2. Naming
+- **MixedCaps**: Use `MixedCaps` or `mixedCaps` for multi-word names. Do not use underscores.
+- **Exported vs. Unexported**: Names starting with an uppercase letter are exported (public). Names starting with a lowercase letter are not exported (private).
+- **Package Names**: Short, concise, single-word, lowercase names.
+- **Getters**: Do not name getters with a `Get` prefix. A getter for a field named `owner` should be named `Owner()`.
+- **Interface Names**: One-method interfaces are named by the method name plus an `-er` suffix (e.g., `Reader`, `Writer`).
+
+## 3. Control Structures
+- **if**: No parentheses around the condition. Braces are mandatory. Can include an initialization statement (e.g., `if err := file.Chmod(0664); err != nil`).
+- **for**: Go's only looping construct. Unifies `for` and `while`. Use `for...range` to iterate over slices, maps, strings, and channels.
+- **switch**: More general than in C. Cases do not fall through by default (use `fallthrough` explicitly). Can be used without an expression to function as a cleaner if-else-if chain.
+
+## 4. Functions
+- **Multiple Returns**: Functions can return multiple values. This is the standard way to return a result and an error (e.g., `value, err`).
+- **Named Result Parameters**: Return parameters can be named. This can make code clearer and more concise.
+- **defer**: Schedules a function call to be run immediately before the function executing `defer` returns. Use it for cleanup tasks like closing files.
+
+## 5. Data
+- **new vs. make**:
+  - `new(T)`: Allocates memory for a new item of type T, zeroes it, and returns a pointer (`*T`).
+  - `make(T, ...)`: Creates and initializes slices, maps, and channels only. Returns an initialized value of type T (not a pointer).
+- **Slices**: The preferred way to work with sequences. They are more flexible than arrays.
+- **Maps**: Use the "comma ok" idiom to check for the existence of a key: `value, ok := myMap[key]`.
+
+## 6. Interfaces
+- **Implicit Implementation**: A type implements an interface by implementing its methods. No `implements` keyword is needed.
+- **Small Interfaces**: Prefer many small interfaces over one large one. The standard library is full of single-method interfaces (e.g., `io.Reader`).
+
+## 7. Concurrency
+- **Share Memory By Communicating**: This is the core philosophy. Do not communicate by sharing memory; instead, share memory by communicating.
+- **Goroutines**: Lightweight, concurrently executing functions. Start one with the `go` keyword.
+- **Channels**: Typed conduits for communication between goroutines. Use `make` to create them.
+
+## 8. Errors
+- **error type**: The built-in `error` interface is the standard way to handle errors.
+- **Explicit Error Handling**: Do not discard errors with the blank identifier (`_`). Check for errors explicitly.
+- **panic**: Reserved for truly exceptional, unrecoverable situations. Generally, libraries should not panic.
+
+Source: Effective Go

package/extensions/conductor/templates/code_styleguides/html-css.md

@@ -0,0 +1,49 @@
+# Google HTML/CSS Style Guide Summary
+
+This document summarizes key rules and best practices from the Google HTML/CSS Style Guide.
+
+## 1. General Rules
+- **Protocol**: Use HTTPS for all embedded resources.
+- **Indentation**: Indent by 2 spaces. Do not use tabs.
+- **Capitalization**: Use only lowercase for all code (element names, attributes, selectors, properties).
+- **Trailing Whitespace**: Remove all trailing whitespace.
+- **Encoding**: Use UTF-8 (without a BOM). Specify `<meta charset="utf-8">` in HTML.
+
+## 2. HTML Style Rules
+- **Document Type**: Use `<!doctype html>`.
+- **HTML Validity**: Use valid HTML.
+- **Semantics**: Use HTML elements according to their intended purpose (e.g., use `<p>` for paragraphs, not for spacing).
+- **Multimedia Fallback**: Provide `alt` text for images and transcripts/captions for audio/video.
+- **Separation of Concerns**: Strictly separate structure (HTML), presentation (CSS), and behavior (JavaScript). Link to CSS and JS from external files.
+- **type Attributes**: Omit `type` attributes for stylesheets (`<link>`) and scripts (`<script>`).
+
+## 3. HTML Formatting Rules
+- **General**: Use a new line for every block, list, or table element, and indent its children.
+- **Quotation Marks**: Use double quotation marks (`""`) for attribute values.
+
+## 4. CSS Style Rules
+- **CSS Validity**: Use valid CSS.
+- **Class Naming**: Use meaningful, generic names. Separate words with a hyphen (`-`).
+  - Good: `.video-player`, `.site-navigation`
+  - Bad: `.vid`, `.red-text`
+- **ID Selectors**: Avoid using ID selectors for styling. Prefer class selectors.
+- **Shorthand Properties**: Use shorthand properties where possible (e.g., `padding`, `font`).
+- **0 and Units**: Omit units for 0 values (e.g., `margin: 0;`).
+- **Leading 0s**: Always include leading 0s for decimal values (e.g., `font-size: 0.8em;`).
+- **Hexadecimal Notation**: Use 3-character hex notation where possible (e.g., `#fff`).
+- **!important**: Avoid using `!important`.
+
+## 5. CSS Formatting Rules
+- **Declaration Order**: Alphabetize declarations within a rule.
+- **Indentation**: Indent all block content.
+- **Semicolons**: Use a semicolon after every declaration.
+- **Spacing**:
+  - Use a space after a property name's colon (`font-weight: bold;`).
+  - Use a space between the last selector and the opening brace (`.foo {`).
+  - Start a new line for each selector and declaration.
+- **Rule Separation**: Separate rules with a new line.
+- **Quotation Marks**: Use single quotes (`''`) for attribute selectors and property values (e.g., `[type='text']`).
+
+BE CONSISTENT. When editing code, match the existing style.
+
+Source: Google HTML/CSS Style Guide