novahiz 0.1.0

package/bundled-skills/flutter-setup-localization/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: flutter-setup-localization
+description: Add `flutter_localizations` and `intl` dependencies, enable "generate true" in `pubspec.yaml`, and create an `l10n.yaml` configuration file. Use when initializing localization support for a new Flutter project.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Tue, 21 Apr 2026 21:27:35 GMT
+---
+# Internationalizing Flutter Applications
+
+## Contents
+- [Core Concepts](#core-concepts)
+- [Setup Workflow](#setup-workflow)
+- [Implementation Workflow](#implementation-workflow)
+- [Advanced Formatting](#advanced-formatting)
+- [Examples](#examples)
+
+## Core Concepts
+Flutter handles internationalization (i18n) and localization (l10n) via the `flutter_localizations` and `intl` packages. The standard approach uses App Resource Bundle (`.arb`) files to define localized strings, which are then compiled into a generated `AppLocalizations` class for type-safe access within the widget tree.
+
+## Setup Workflow
+
+Copy and track this checklist when initializing internationalization in a Flutter project:
+
+- [ ] **Task Progress**
+  - [ ] 1. Add dependencies to `pubspec.yaml`.
+  - [ ] 2. Enable the `generate` flag.
+  - [ ] 3. Create the `l10n.yaml` configuration file.
+  - [ ] 4. Configure `MaterialApp` or `CupertinoApp`.
+
+### 1. Add Dependencies
+Add the required localization packages to the project. Execute the following commands in the terminal:
+```bash
+flutter pub add flutter_localizations --sdk=flutter
+flutter pub add intl:any
+```
+
+Verify your `pubspec.yaml` includes the following under `dependencies`:
+```yaml
+dependencies:
+  flutter:
+    sdk: flutter
+  flutter_localizations:
+    sdk: flutter
+  intl: any
+```
+
+### 2. Enable Code Generation
+Open `pubspec.yaml` and enable the `generate` flag within the `flutter` section to automate localization tasks:
+```yaml
+flutter:
+  generate: true
+```
+
+### 3. Create Configuration File
+Create a new file named `l10n.yaml` in the root directory of the Flutter project. Define the input directory, template file, and output file:
+```yaml
+arb-dir: lib/l10n
+template-arb-file: app_en.arb
+output-localization-file: app_localizations.dart
+synthetic-package: true
+```
+
+### 4. Configure the App Entry Point
+Import the generated localizations and the `flutter_localizations` library in your `main.dart`. Inject the delegates and supported locales into your `MaterialApp` or `CupertinoApp`.
+
+```dart
+import 'package:flutter_localizations/flutter_localizations.dart';
+import 'package:flutter_gen/gen_l10n/app_localizations.dart'; // Adjust path if synthetic-package is false
+
+// ... inside build method
+return MaterialApp(
+  localizationsDelegates: const [
+    AppLocalizations.delegate,
+    GlobalMaterialLocalizations.delegate,
+    GlobalWidgetsLocalizations.delegate,
+    GlobalCupertinoLocalizations.delegate,
+  ],
+  supportedLocales: const [
+    Locale('en'), // English
+    Locale('es'), // Spanish
+  ],
+  home: const MyHomePage(),
+);
+```
+
+## Implementation Workflow
+
+Follow this workflow when adding or modifying localized content.
+
+### 1. Define ARB Files
+*   **If creating NEW content:** Add the base string to the template file (`lib/l10n/app_en.arb`). Include a description for context.
+*   **If EDITING existing content:** Locate the key in all supported `.arb` files and update the values.
+
+```json
+{
+  "helloWorld": "Hello World!",
+  "@helloWorld": {
+    "description": "The conventional newborn programmer greeting"
+  }
+}
+```
+
+Create corresponding files for other locales (e.g., `app_es.arb`):
+```json
+{
+  "helloWorld": "¡Hola Mundo!"
+}
+```
+
+### 2. Generate Localization Classes
+Run the following command to trigger code generation:
+```bash
+flutter pub get
+```
+*Feedback Loop:* Run validator -> review terminal output for ARB syntax errors -> fix missing commas or mismatched placeholders -> re-run `flutter pub get`.
+
+### 3. Consume Localized Strings
+Access the localized strings in your widget tree using `AppLocalizations.of(context)`. Ensure the widget calling this is a descendant of `MaterialApp`.
+
+```dart
+Text(AppLocalizations.of(context)!.helloWorld)
+```
+
+## Advanced Formatting
+
+Use placeholders for dynamic data, plurals, and conditional selects.
+
+### Placeholders
+Define parameters within curly braces and specify their type in the metadata object.
+```json
+"hello": "Hello {userName}",
+"@hello": {
+  "description": "A message with a single parameter",
+  "placeholders": {
+    "userName": {
+      "type": "String",
+      "example": "Bob"
+    }
+  }
+}
+```
+
+### Plurals
+Use the `plural` syntax to handle quantity-based string variations. The `other` case is mandatory.
+```json
+"nWombats": "{count, plural, =0{no wombats} =1{1 wombat} other{{count} wombats}}",
+"@nWombats": {
+  "description": "A plural message",
+  "placeholders": {
+    "count": {
+      "type": "num",
+      "format": "compact"
+    }
+  }
+}
+```
+
+### Selects
+Use the `select` syntax for conditional strings, such as gendered text.
+```json
+"pronoun": "{gender, select, male{he} female{she} other{they}}",
+"@pronoun": {
+  "description": "A gendered message",
+  "placeholders": {
+    "gender": {
+      "type": "String"
+    }
+  }
+}
+```
+
+## Examples
+
+### Complete `l10n.yaml`
+```yaml
+arb-dir: lib/l10n
+template-arb-file: app_en.arb
+output-localization-file: app_localizations.dart
+synthetic-package: true
+use-escaping: true
+```
+
+### Complete Widget Implementation
+```dart
+import 'package:flutter/material.dart';
+import 'package:flutter_gen/gen_l10n/app_localizations.dart';
+
+class GreetingWidget extends StatelessWidget {
+  final String userName;
+  final int notificationCount;
+
+  const GreetingWidget({
+    super.key, 
+    required this.userName, 
+    required this.notificationCount,
+  });
+
+  @override
+  Widget build(BuildContext context) {
+    final l10n = AppLocalizations.of(context)!;
+
+    return Column(
+      children: [
+        Text(l10n.hello(userName)),
+        Text(l10n.nWombats(notificationCount)),
+      ],
+    );
+  }
+}
+```

package/bundled-skills/flutter-use-http-package/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: flutter-use-http-package
+description: Use the `http` package to execute GET, POST, PUT, or DELETE requests. Use when you need to fetch from or send data to a REST API.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Tue, 21 Apr 2026 21:36:42 GMT
+---
+# Implementing Flutter Networking
+
+## Contents
+- [Configuration & Permissions](#configuration--permissions)
+- [Request Execution & Response Handling](#request-execution--response-handling)
+- [Background Parsing](#background-parsing)
+- [Workflow: Executing Network Operations](#workflow-executing-network-operations)
+- [Examples](#examples)
+
+## Configuration & Permissions
+
+Configure the environment and platform-specific permissions required for network access.
+
+1. Add the `http` package dependency via the terminal:
+   ```bash
+   flutter pub add http
+   ```
+2. Import the package in your Dart files:
+   ```dart
+   import 'package:http/http.dart' as http;
+   ```
+3. Configure Android permissions by adding the Internet permission to `android/app/src/main/AndroidManifest.xml`:
+   ```xml
+   <uses-permission android:name="android.permission.INTERNET" />
+   ```
+4. Configure macOS entitlements by adding the network client key to both `macos/Runner/DebugProfile.entitlements` and `macos/Runner/Release.entitlements`:
+   ```xml
+   <key>com.apple.security.network.client</key>
+   <true/>
+   ```
+
+## Request Execution & Response Handling
+
+Execute HTTP operations and map responses to strongly typed Dart objects.
+
+*   **URIs:** Always parse URL strings using `Uri.parse('your_url')`.
+*   **Headers:** Inject authorization and content-type headers via the `headers` parameter map. Use `HttpHeaders.authorizationHeader` for auth tokens.
+*   **Payloads:** For POST and PUT requests, encode the body using `jsonEncode()` from `dart:convert`.
+*   **Status Validation:** Evaluate `response.statusCode`. Treat `200 OK` (GET/PUT/DELETE) and `201 CREATED` (POST) as success. 
+*   **Error Handling:** Throw explicit exceptions for non-success status codes. Never return `null` on failure, as this prevents `FutureBuilder` from triggering its error state and causes infinite loading indicators.
+*   **Deserialization:** Parse the raw string using `jsonDecode(response.body)` and map it to a custom Dart object using a factory constructor (e.g., `fromJson`).
+
+## Background Parsing
+
+Offload expensive JSON parsing to a separate Isolate to prevent UI jank (frame drops).
+
+*   Import `package:flutter/foundation.dart`.
+*   Use the `compute()` function to run the parsing logic in a background isolate.
+*   Ensure the parsing function passed to `compute()` is a top-level function or a static method, as closures or instance methods cannot be passed across isolates.
+
+## Workflow: Executing Network Operations
+
+Use the following checklist to implement and validate network operations.
+
+**Task Progress:**
+- [ ] 1. Define the strongly typed Dart model with a `fromJson` factory constructor.
+- [ ] 2. Implement the network request method returning a `Future<Model>`.
+- [ ] 3. Apply conditional logic based on the operation type:
+  - **If fetching data (GET):** Append query parameters to the URI.
+  - **If mutating data (POST/PUT):** Set `'Content-Type': 'application/json; charset=UTF-8'` and attach the `jsonEncode` body.
+  - **If deleting data (DELETE):** Return an empty model instance on success (`200 OK`).
+- [ ] 4. Validate the `statusCode` and throw an `Exception` on failure.
+- [ ] 5. Integrate the `Future` into the UI using `FutureBuilder`.
+- [ ] 6. Handle `snapshot.hasData`, `snapshot.hasError`, and default to a `CircularProgressIndicator`.
+- [ ] 7. **Feedback Loop:** Run the app -> trigger the network request -> review console for unhandled exceptions -> fix parsing or permission errors.
+
+## Examples
+
+### High-Fidelity Implementation: Fetching and Parsing in the Background
+
+```dart
+import 'dart:async';
+import 'dart:convert';
+import 'dart:io';
+import 'package:flutter/foundation.dart';
+import 'package:flutter/material.dart';
+import 'package:http/http.dart' as http;
+
+// 1. Top-level parsing function for Isolate
+List<Photo> parsePhotos(String responseBody) {
+  final parsed = (jsonDecode(responseBody) as List<Object?>)
+      .cast<Map<String, Object?>>();
+  return parsed.map<Photo>(Photo.fromJson).toList();
+}
+
+// 2. Network execution with background parsing
+Future<List<Photo>> fetchPhotos() async {
+  final response = await http.get(
+    Uri.parse('https://jsonplaceholder.typicode.com/photos'),
+    headers: {
+      HttpHeaders.authorizationHeader: 'Bearer your_token_here',
+      HttpHeaders.acceptHeader: 'application/json',
+    },
+  );
+
+  if (response.statusCode == 200) {
+    // Offload heavy parsing to a background isolate
+    return compute(parsePhotos, response.body);
+  } else {
+    throw Exception('Failed to load photos. Status: ${response.statusCode}');
+  }
+}
+
+// 3. Strongly typed model
+class Photo {
+  final int id;
+  final String title;
+  final String thumbnailUrl;
+
+  const Photo({
+    required this.id,
+    required this.title,
+    required this.thumbnailUrl,
+  });
+
+  factory Photo.fromJson(Map<String, dynamic> json) {
+    return Photo(
+      id: json['id'] as int,
+      title: json['title'] as String,
+      thumbnailUrl: json['thumbnailUrl'] as String,
+    );
+  }
+}
+
+// 4. UI Integration
+class PhotoGallery extends StatefulWidget {
+  const PhotoGallery({super.key});
+
+  @override
+  State<PhotoGallery> createState() => _PhotoGalleryState();
+}
+
+class _PhotoGalleryState extends State<PhotoGallery> {
+  late Future<List<Photo>> _futurePhotos;
+
+  @override
+  void initState() {
+    super.initState();
+    // Initialize Future once to prevent re-fetching on rebuilds
+    _futurePhotos = fetchPhotos();
+  }
+
+  @override
+  Widget build(BuildContext context) {
+    return FutureBuilder<List<Photo>>(
+      future: _futurePhotos,
+      builder: (context, snapshot) {
+        if (snapshot.hasData) {
+          final photos = snapshot.data!;
+          return ListView.builder(
+            itemCount: photos.length,
+            itemBuilder: (context, index) => ListTile(
+              leading: Image.network(photos[index].thumbnailUrl),
+              title: Text(photos[index].title),
+            ),
+          );
+        } else if (snapshot.hasError) {
+          return Center(child: Text('Error: ${snapshot.error}'));
+        }
+        
+        // Default loading state
+        return const Center(child: CircularProgressIndicator());
+      },
+    );
+  }
+}
+```

package/bundled-skills/gate/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: gate
+description: Le gardien du système Novahiz
+---
+
+# Novahiz Gate Skill
+
+Ce skill est OBLIGATOIRE avant et après l'exécution d'une tâche.
+
+1. Appelez l'outil MCP `novahiz_gate`.
+2. Si le Gate échoue (FAIL), résolvez les violations de règles affichées.
+3. Ne procédez JAMAIS à des modifications de code tant que le Gate n'est pas PASS.
+4. Une fois validé, vous pouvez exécuter le plan ou passer au post-task.

package/bundled-skills/graph-colorize/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: graph-colorize
+description: >
+  Color-code the Obsidian graph view by rewriting `.obsidian/graph.json` colorGroups.
+  Use this skill when the user says "color my graph", "color code obsidian", "colorize
+  the graph", "color the graph by tag", "color by category", "highlight visibility
+  in graph", "make the graph colorful", "distinguish tags in graph", or wants nodes
+  in Obsidian's graph view tinted by tag, folder, or visibility. Generates a
+  `colorGroups` array from the vault's actual tags/categories and merges it into the
+  existing graph.json without clobbering other graph settings. Always backs up first.
+---
+
+# Graph Colorize — Color-code the Obsidian Graph View
+
+You are rewriting `$OBSIDIAN_VAULT_PATH/.obsidian/graph.json` so Obsidian's graph view tints nodes by tag, folder, or visibility.
+
+Obsidian stores graph settings in `<vault>/.obsidian/graph.json`. The `colorGroups` array is a list of `{query, color}` pairs; the first matching query wins per node. Queries use Obsidian's search syntax: `tag:#foo`, `path:"concepts"`, `file:foo`, etc. Color is `{"a": 1, "rgb": <packed-int>}` where the int is `(R << 16) | (G << 8) | B`.
+
+## Before You Start
+
+1. **Resolve config** — follow the Config Resolution Protocol in `llm-wiki/SKILL.md` (inline `@name` override → walk up CWD for `.env` → global config → prompt setup). This gives `OBSIDIAN_VAULT_PATH`.
+2. Confirm `$OBSIDIAN_VAULT_PATH/.obsidian/` exists. If it doesn't, the vault has never been opened in Obsidian — tell the user to open the vault once in Obsidian, then re-run.
+3. **Warn the user if Obsidian is likely open**: Obsidian overwrites `graph.json` on close. Tell them to close the vault first, or be ready to reload (Cmd/Ctrl+R) and not touch the graph settings until they reload.
+
+## Step 1: Pick a Mode
+
+Infer the mode from the user's phrasing. If ambiguous, default to **by-tag**.
+
+| User intent | Mode |
+|---|---|
+| "color by tag", "color my graph", "make it colorful" (default) | `by-tag` |
+| "color by folder", "color by category", "color by directory" | `by-category` |
+| "highlight visibility", "show internal/pii in graph", "visibility colors" | `by-visibility` |
+| User provides explicit mapping (`tag:#foo = red`, or JSON blob) | `custom` |
+| "combine tag and visibility" / "both" | `combined` (visibility first, then tag) |
+
+## Step 2: Build the `colorGroups` Array
+
+### Palette (10 distinct, colorblind-friendly colors)
+
+Use in order. If more groups than colors, cycle and add a lightness shift by dividing brightness ~20% via a second pass — or just cap at 10 and tell the user the remaining tags share the "other" color.
+
+| # | Hex | rgb (packed int) | Role |
+|---|---|---|---|
+| 0 | `#4E79A7` | `5142951` | blue |
+| 1 | `#F28E2B` | `15896107` | orange |
+| 2 | `#E15759` | `14767961` | red |
+| 3 | `#76B7B2` | `7780786` | teal |
+| 4 | `#59A14F` | `5873999` | green |
+| 5 | `#EDC948` | `15583048` | yellow |
+| 6 | `#B07AA1` | `11565217` | purple |
+| 7 | `#FF9DA7` | `16751527` | pink |
+| 8 | `#9C755F` | `10253663` | brown |
+| 9 | `#BAB0AC` | `12234924` | gray |
+
+Every color is wrapped as `{"a": 1, "rgb": <int>}`.
+
+### Mode: `by-tag`
+
+1. Glob `$VAULT_PATH/**/*.md` excluding `_archives/`, `_raw/`, `.obsidian/`, `node_modules/`, `index.md`, `log.md`, `_insights.md`.
+2. Parse frontmatter `tags` from each page. Count usage per tag.
+3. **Drop `visibility/*` tags** from the frequency list — they are reserved system tags, handled only in `by-visibility` or `combined` mode.
+4. Take the top 10 tags by usage. If there are fewer than 10 unique tags, use all of them.
+5. For each tag `T` at index `i`: emit `{"query": "tag:#T", "color": palette[i]}`.
+6. Optionally, append a final catch-all entry for untagged pages at the end: `{"query": "-[\"tag\":]", "color": palette[9]}` — **skip** if color slot 9 is already taken by a real tag.
+
+### Mode: `by-category`
+
+Use the seven vault top-level folders in this fixed order so colors are stable across runs:
+
+| Folder | Color index |
+|---|---|
+| `concepts` | 0 (blue) |
+| `entities` | 1 (orange) |
+| `skills` | 2 (red) |
+| `references` | 3 (teal) |
+| `synthesis` | 4 (green) |
+| `projects` | 5 (yellow) |
+| `journal` | 6 (purple) |
+
+Emit one entry per folder that exists AND contains at least one `.md` file. Each entry is:
+
+```json
+{"query": "path:\"<folder>\"", "color": {"a": 1, "rgb": <int>}}
+```
+
+### Mode: `by-visibility`
+
+Emit exactly three entries, in this order (first-match wins, so most restrictive comes first):
+
+1. `visibility/pii` → `#E15759` (red, rgb 14767961)
+2. `visibility/internal` → `#F28E2B` (orange, rgb 15896107)
+3. `visibility/public` → `#59A14F` (green, rgb 5873999)
+
+```json
+{"query": "tag:#visibility/pii", "color": {"a": 1, "rgb": 14767961}}
+```
+
+Pages with no `visibility/` tag remain Obsidian's default color — do not add a catch-all.
+
+### Mode: `combined`
+
+Emit `by-visibility` entries first, then `by-tag` entries. Visibility wins on conflict because it appears first in the list.
+
+### Mode: `custom`
+
+If the user gave explicit mappings, honor them literally. Convert any hex they give (e.g. `#FF00FF`) to packed int using `int(hex_without_hash, 16)`. Wrap each as `{"a": 1, "rgb": <int>}`.
+
+## Step 3: Merge into graph.json (Do Not Clobber)
+
+1. Read the existing `$VAULT_PATH/.obsidian/graph.json`. If it doesn't exist, start from this minimal default:
+
+   ```json
+   {
+     "collapse-filter": true,
+     "search": "",
+     "showTags": false,
+     "showAttachments": false,
+     "hideUnresolved": false,
+     "showOrphans": true,
+     "collapse-color-groups": false,
+     "colorGroups": [],
+     "collapse-display": true,
+     "showArrow": false,
+     "textFadeMultiplier": 0,
+     "nodeSizeMultiplier": 1,
+     "lineSizeMultiplier": 1,
+     "collapse-forces": true,
+     "centerStrength": 0.518713248970312,
+     "repelStrength": 10,
+     "linkStrength": 1,
+     "linkDistance": 250,
+     "scale": 1,
+     "close": true
+   }
+   ```
+
+2. **Back up first**: copy the existing file to `.obsidian/graph.json.backup-<YYYYMMDD-HHMM>` before writing. If a backup from the same minute exists, reuse it — don't pile up duplicates.
+
+3. Replace **only** the `colorGroups` field with your new array. Leave every other field untouched. This preserves the user's zoom, physics, filter, search, and display preferences.
+
+4. Write the file back with the same JSON style as the original (usually compact single-line or 2-space indent — preserve what's there).
+
+## Step 4: Report and Log
+
+Print a summary like:
+
+```
+Graph colorized → .obsidian/graph.json
+  Mode:    by-tag
+  Groups:  7 color assignments
+  Palette: blue, orange, red, teal, green, yellow, purple
+  Backup:  .obsidian/graph.json.backup-20260424-1432
+
+Reload Obsidian (Cmd/Ctrl+R) to see the new colors.
+If Obsidian is currently open, close it first OR reload immediately — Obsidian
+overwrites graph.json on close and can erase these changes.
+```
+
+Append to `$VAULT_PATH/log.md`:
+
+```
+- [TIMESTAMP] GRAPH_COLORIZE mode=<mode> groups=<N> backup=graph.json.backup-<stamp>
+```
+
+## Edge Cases
+
+- **No tags in vault** in `by-tag` mode → fall back to `by-category` and tell the user.
+- **User wants to undo** → restore from the latest `graph.json.backup-*` and note that in `log.md`.
+- **User wants to clear all color groups** → set `colorGroups: []`, back up, log as `GRAPH_COLORIZE mode=clear`.
+- **`.obsidian/` missing** → the vault hasn't been opened in Obsidian yet. Tell the user to open it once, then re-run. Don't create `.obsidian/` yourself — Obsidian populates many files there on first open.
+- **Query syntax gotchas**: folder paths with spaces need quoting (`path:"my folder"`); tags with nested slashes work literally (`tag:#visibility/internal`); don't URL-encode.
+- **Obsidian open during edit**: surface the risk — Obsidian reads graph.json at startup and **rewrites it on close**. If the user is editing live, tell them to close Obsidian first or run the reload (Cmd/Ctrl+R) immediately and avoid opening graph settings before they do.
+
+## Notes
+
+- This is a pure config edit — no page content changes, no frontmatter writes.
+- Re-running is safe: each run creates a new backup, only `colorGroups` is rewritten.
+- If the user has manually curated color groups they want to keep, offer `combined` mode or ask before overwriting.
+- The palette here matches `wiki-export`'s `graph.html` community colors, so the Obsidian graph and the exported visualization look consistent.