@kleber.mottajr/juninho 1.1.0 → 1.2.0

package/dist/templates/skills.js

@@ -6,22 +6,52 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.writeSkills = writeSkills;
 const fs_1 = require("fs");
 const path_1 = __importDefault(require("path"));
-function writeSkills(projectDir) {
+const project_types_js_1 = require("../project-types.js");
+function writeSkills(projectDir, projectType = "node-nextjs", isKotlin = false) {
     const skillsDir = path_1.default.join(projectDir, ".opencode", "skills");
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.test-writing", "SKILL.md"), TEST_WRITING);
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.page-creation", "SKILL.md"), PAGE_CREATION);
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.api-route-creation", "SKILL.md"), API_ROUTE_CREATION);
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.server-action-creation", "SKILL.md"), SERVER_ACTION_CREATION);
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.schema-migration", "SKILL.md"), SCHEMA_MIGRATION);
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.agents-md-writing", "SKILL.md"), AGENTS_MD_WRITING);
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.domain-doc-writing", "SKILL.md"), DOMAIN_DOC_WRITING);
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.principle-doc-writing", "SKILL.md"), PRINCIPLE_DOC_WRITING);
-    (0, fs_1.writeFileSync)(path_1.default.join(skillsDir, "j.shell-script-writing", "SKILL.md"), SHELL_SCRIPT_WRITING);
+    const config = project_types_js_1.PROJECT_TYPE_REGISTRY[projectType];
+    // Create skill directories and write only the skills for this project type
+    const skillWriters = {
+        "j.test-writing": () => testWriting(projectType, isKotlin),
+        "j.page-creation": () => PAGE_CREATION,
+        "j.api-route-creation": () => API_ROUTE_CREATION,
+        "j.server-action-creation": () => SERVER_ACTION_CREATION,
+        "j.schema-migration": () => SCHEMA_MIGRATION,
+        "j.agents-md-writing": () => AGENTS_MD_WRITING,
+        "j.domain-doc-writing": () => DOMAIN_DOC_WRITING,
+        "j.principle-doc-writing": () => PRINCIPLE_DOC_WRITING,
+        "j.shell-script-writing": () => SHELL_SCRIPT_WRITING,
+    };
+    for (const skill of config.skills) {
+        const writer = skillWriters[skill];
+        if (!writer)
+            continue;
+        const skillDir = path_1.default.join(skillsDir, skill);
+        if (!(0, fs_1.existsSync)(skillDir)) {
+            (0, fs_1.mkdirSync)(skillDir, { recursive: true });
+        }
+        (0, fs_1.writeFileSync)(path_1.default.join(skillDir, "SKILL.md"), writer());
+    }
 }
-// ─── Test Writing ────────────────────────────────────────────────────────────
-const TEST_WRITING = `---
-name: j.test-writing
-description: Write focused unit and integration tests following project conventions
+// ─── Test Writing (parameterized by type) ──────────────────────────────────
+function testWriting(projectType, isKotlin) {
+    switch (projectType) {
+        case "node-nextjs":
+        case "node-generic":
+            return TEST_WRITING_NODE;
+        case "python":
+            return TEST_WRITING_PYTHON;
+        case "go":
+            return TEST_WRITING_GO;
+        case "java":
+            return isKotlin ? TEST_WRITING_KOTLIN : TEST_WRITING_JAVA;
+        case "generic":
+            return TEST_WRITING_GENERIC;
+    }
+}
+const TEST_WRITING_NODE = `---
+name: j.test-writing
+description: Write focused unit and integration tests following project conventions
 # Optional: uncomment to enable Playwright MCP for E2E tests
 # mcp:
 #   playwright:
@@ -61,12 +91,12 @@ describe("ComponentName / functionName", () => {
 })
 \`\`\`
 
-### 3. Coverage requirements
-- Happy path: at least 1 test
-- Error cases: test each distinct error path
-- Edge cases: empty inputs, boundary values, null/undefined
-- Prefer tests related to the changed files before running the full suite
-- Do NOT test implementation details — test behavior
+### 3. Coverage requirements
+- Happy path: at least 1 test
+- Error cases: test each distinct error path
+- Edge cases: empty inputs, boundary values, null/undefined
+- Prefer tests related to the changed files before running the full suite
+- Do NOT test implementation details — test behavior
 
 ### 4. Mock strategy
 - Mock external dependencies (APIs, DB, file system)
@@ -96,15 +126,501 @@ it("should handle async operation", async () => {
 - \`expect.assertions(0)\` — always assert something
 - Tests that depend on order of execution
 `;
-// ─── Page Creation ────────────────────────────────────────────────────────────
-const PAGE_CREATION = `---
-name: j.page-creation
-description: Create Next.js App Router pages with correct patterns
----
-
-# Skill: Page Creation
-
-This is a stack-specific skill. Only apply it when the project actually uses Next.js App Router patterns.
+const TEST_WRITING_PYTHON = `---
+name: j.test-writing
+description: Write focused unit and integration tests using pytest
+---
+
+# Skill: Test Writing (Python)
+
+## When this skill activates
+Writing or editing \`test_*.py\` or \`*_test.py\` files.
+
+## Required Steps
+
+### 1. Read the implementation first
+Before writing any test, read the file being tested. Understand:
+- What it does (not what you think it does)
+- Its dependencies and side effects
+- Error cases and edge conditions
+
+### 2. Test structure
+Follow the AAA pattern with pytest:
+\`\`\`python
+class TestFunctionName:
+    """Tests for function_name."""
+
+    def test_happy_path(self):
+        # Arrange
+        input_data = ...
+
+        # Act
+        result = function_name(input_data)
+
+        # Assert
+        assert result == expected
+
+    def test_when_invalid_input(self):
+        with pytest.raises(ValueError, match="specific message"):
+            function_name(invalid_input)
+\`\`\`
+
+Or functional style:
+\`\`\`python
+def test_function_does_expected_thing():
+    # Arrange
+    input_data = ...
+
+    # Act
+    result = function_name(input_data)
+
+    # Assert
+    assert result == expected
+\`\`\`
+
+### 3. Coverage requirements
+- Happy path: at least 1 test
+- Error cases: test each distinct error path with \`pytest.raises\`
+- Edge cases: empty inputs, boundary values, None
+- Prefer tests related to the changed files before running the full suite
+
+### 4. Mock strategy
+- Use \`unittest.mock.patch\` or \`pytest-mock\` fixtures
+- Mock external dependencies (APIs, DB, file system)
+- Do NOT mock the module under test
+\`\`\`python
+from unittest.mock import patch, MagicMock
+
+def test_with_mock(mocker):
+    mock_service = mocker.patch("module.ExternalService")
+    mock_service.return_value.fetch.return_value = {"data": "value"}
+
+    result = my_function()
+    assert result == expected
+\`\`\`
+
+### 5. Fixtures
+Use pytest fixtures for reusable setup:
+\`\`\`python
+@pytest.fixture
+def sample_user():
+    return User(name="Test", email="test@example.com")
+
+def test_user_display(sample_user):
+    assert sample_user.display_name == "Test"
+\`\`\`
+
+### 6. Naming conventions
+- File: \`test_{module}.py\` or \`{module}_test.py\`
+- Class: \`TestClassName\`
+- Function: \`test_{what_it_does}\` or \`test_when_{condition}_then_{outcome}\`
+
+## Anti-patterns to avoid
+- \`assert True\` — meaningless assertion
+- Testing private methods (\`_method\`) directly
+- Tests that depend on execution order
+- Mocking the module under test
+- Using \`time.sleep\` in tests
+`;
+const TEST_WRITING_GO = `---
+name: j.test-writing
+description: Write focused unit and integration tests using Go testing
+---
+
+# Skill: Test Writing (Go)
+
+## When this skill activates
+Writing or editing \`*_test.go\` files.
+
+## Required Steps
+
+### 1. Read the implementation first
+Before writing any test, read the file being tested. Understand:
+- What it does (not what you think it does)
+- Its dependencies and side effects
+- Error cases and edge conditions
+
+### 2. Test structure
+Use table-driven tests with \`t.Run\`:
+\`\`\`go
+func TestFunctionName(t *testing.T) {
+    tests := []struct {
+        name     string
+        input    InputType
+        expected OutputType
+        wantErr  bool
+    }{
+        {
+            name:     "happy path",
+            input:    validInput,
+            expected: expectedOutput,
+        },
+        {
+            name:    "invalid input returns error",
+            input:   invalidInput,
+            wantErr: true,
+        },
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            result, err := FunctionName(tt.input)
+
+            if tt.wantErr {
+                if err == nil {
+                    t.Fatal("expected error, got nil")
+                }
+                return
+            }
+            if err != nil {
+                t.Fatalf("unexpected error: %v", err)
+            }
+            if result != tt.expected {
+                t.Errorf("got %v, want %v", result, tt.expected)
+            }
+        })
+    }
+}
+\`\`\`
+
+### 3. Coverage requirements
+- Happy path: at least 1 test case
+- Error cases: test each distinct error path
+- Edge cases: nil inputs, zero values, empty slices
+- Use \`t.Parallel()\` for independent subtests
+
+### 4. Mock strategy
+- Use interfaces for dependency injection
+- Create mock implementations in test files
+- For HTTP, use \`httptest.NewServer\`
+- For DB, use test containers or in-memory implementations
+
+### 5. Test helpers
+\`\`\`go
+func setupTestDB(t *testing.T) *DB {
+    t.Helper()
+    db := NewTestDB()
+    t.Cleanup(func() { db.Close() })
+    return db
+}
+\`\`\`
+
+### 6. Naming conventions
+- File: \`{package}_test.go\` in the same package
+- Function: \`TestFunctionName\`, \`TestType_Method\`
+- Subtests: descriptive names in \`t.Run("when condition", ...)\`
+
+## Anti-patterns to avoid
+- Using \`t.Log\` instead of assertions
+- Testing unexported functions from external packages
+- Using global state between tests
+- Not using \`t.Helper()\` in helper functions
+`;
+const TEST_WRITING_JAVA = `---
+name: j.test-writing
+description: Write focused unit and integration tests using JUnit 5
+---
+
+# Skill: Test Writing (Java/JUnit 5)
+
+## When this skill activates
+Writing or editing \`*Test.java\`, \`*Tests.java\`, or \`*IT.java\` files.
+
+## Required Steps
+
+### 1. Read the implementation first
+Before writing any test, read the file being tested. Understand:
+- What it does (not what you think it does)
+- Its dependencies and side effects
+- Error cases and edge conditions
+
+### 2. Test structure
+Follow the AAA pattern with JUnit 5:
+\`\`\`java
+@DisplayName("FunctionName")
+class FunctionNameTest {
+
+    @Nested
+    @DisplayName("when valid input")
+    class WhenValidInput {
+
+        @Test
+        @DisplayName("should return expected result")
+        void shouldReturnExpectedResult() {
+            // Arrange
+            var input = createValidInput();
+
+            // Act
+            var result = functionName(input);
+
+            // Assert
+            assertThat(result).isEqualTo(expected);
+        }
+    }
+
+    @Nested
+    @DisplayName("when invalid input")
+    class WhenInvalidInput {
+
+        @Test
+        @DisplayName("should throw IllegalArgumentException")
+        void shouldThrowException() {
+            assertThatThrownBy(() -> functionName(invalidInput))
+                .isInstanceOf(IllegalArgumentException.class)
+                .hasMessageContaining("specific message");
+        }
+    }
+}
+\`\`\`
+
+### 3. Coverage requirements
+- Happy path: at least 1 test
+- Error cases: test each distinct error path
+- Edge cases: null inputs, empty collections, boundary values
+- Use \`@ParameterizedTest\` for multiple inputs
+
+### 4. Mock strategy (Mockito)
+- Mock external dependencies
+- Do NOT mock the class under test
+\`\`\`java
+@ExtendWith(MockitoExtension.class)
+class ServiceTest {
+
+    @Mock
+    private Repository repository;
+
+    @InjectMocks
+    private Service service;
+
+    @Test
+    void shouldReturnData() {
+        when(repository.findById(1L)).thenReturn(Optional.of(entity));
+
+        var result = service.getData(1L);
+
+        assertThat(result).isNotNull();
+        verify(repository).findById(1L);
+    }
+}
+\`\`\`
+
+### 5. Naming conventions
+- File: \`{ClassName}Test.java\` in \`src/test/java/\`
+- Class: \`{ClassName}Test\`
+- Method: \`should{ExpectedBehavior}\` or \`should{Action}When{Condition}\`
+- Use \`@DisplayName\` for readable test names
+
+## Anti-patterns to avoid
+- \`assertTrue(true)\` — meaningless assertion
+- Testing private methods via reflection
+- \`@SuppressWarnings\` in tests
+- Tests that depend on execution order
+- Not using \`@ExtendWith(MockitoExtension.class)\`
+`;
+const TEST_WRITING_KOTLIN = `---
+name: j.test-writing
+description: Write focused unit and integration tests using JUnit 5 with Kotlin idioms
+---
+
+# Skill: Test Writing (Kotlin/JUnit 5)
+
+## When this skill activates
+Writing or editing \`*Test.kt\`, \`*Tests.kt\`, or \`*IT.kt\` files.
+
+## Required Steps
+
+### 1. Read the implementation first
+Before writing any test, read the file being tested. Understand:
+- What it does (not what you think it does)
+- Its dependencies and side effects
+- Error cases and edge conditions
+
+### 2. Test structure
+Follow the AAA pattern with JUnit 5 and Kotlin idioms:
+\`\`\`kotlin
+@DisplayName("FunctionName")
+class FunctionNameTest {
+
+    @Nested
+    @DisplayName("when valid input")
+    inner class WhenValidInput {
+
+        @Test
+        @DisplayName("should return expected result")
+        fun \`should return expected result\`() {
+            // Arrange
+            val input = createValidInput()
+
+            // Act
+            val result = functionName(input)
+
+            // Assert
+            assertThat(result).isEqualTo(expected)
+        }
+    }
+
+    @Nested
+    @DisplayName("when invalid input")
+    inner class WhenInvalidInput {
+
+        @Test
+        fun \`should throw IllegalArgumentException\`() {
+            assertThatThrownBy { functionName(invalidInput) }
+                .isInstanceOf(IllegalArgumentException::class.java)
+                .hasMessageContaining("specific message")
+        }
+    }
+}
+\`\`\`
+
+### 3. Kotlin-specific patterns
+- Use backtick method names for readable test names: \`fun \\\`should do something\\\`()\`
+- Use \`assertThrows<ExceptionType>\` from JUnit 5 Kotlin extensions
+- Prefer \`shouldBe\`, \`shouldThrow\` if using Kotest assertions
+- Use data classes for test fixtures
+- Use \`@ParameterizedTest\` with \`@MethodSource\` for multiple inputs
+
+\`\`\`kotlin
+@ParameterizedTest
+@MethodSource("invalidInputs")
+fun \`should reject invalid input\`(input: String) {
+    assertThrows<ValidationException> {
+        validate(input)
+    }
+}
+
+companion object {
+    @JvmStatic
+    fun invalidInputs() = listOf("", " ", "invalid@chars")
+}
+\`\`\`
+
+### 4. Mock strategy (Mockito-Kotlin or MockK)
+\`\`\`kotlin
+// Using MockK (preferred for Kotlin)
+class ServiceTest {
+
+    private val repository = mockk<Repository>()
+    private val service = Service(repository)
+
+    @Test
+    fun \`should return data\`() {
+        every { repository.findById(1L) } returns Optional.of(entity)
+
+        val result = service.getData(1L)
+
+        assertThat(result).isNotNull
+        verify { repository.findById(1L) }
+    }
+}
+\`\`\`
+
+Or with Mockito-Kotlin:
+\`\`\`kotlin
+@ExtendWith(MockitoExtension::class)
+class ServiceTest {
+
+    @Mock
+    lateinit var repository: Repository
+
+    @InjectMocks
+    lateinit var service: Service
+
+    @Test
+    fun \`should return data\`() {
+        whenever(repository.findById(1L)).thenReturn(Optional.of(entity))
+
+        val result = service.getData(1L)
+
+        assertThat(result).isNotNull
+        verify(repository).findById(1L)
+    }
+}
+\`\`\`
+
+### 5. Spring Boot test patterns
+\`\`\`kotlin
+@SpringBootTest
+@ActiveProfiles("test")
+class IntegrationTest {
+
+    @Autowired
+    lateinit var service: MyService
+
+    @MockkBean  // or @MockBean for Mockito
+    lateinit var externalClient: ExternalClient
+
+    @Test
+    fun \`should integrate correctly\`() {
+        every { externalClient.fetch() } returns listOf(data)
+        val result = service.process()
+        assertThat(result).hasSize(1)
+    }
+}
+\`\`\`
+
+### 6. Naming conventions
+- File: \`{ClassName}Test.kt\` in \`src/test/kotlin/\`
+- Class: \`{ClassName}Test\`
+- Method: backtick names for readability
+- Use \`@DisplayName\` or \`@Nested\` for grouping
+
+## Anti-patterns to avoid
+- \`assertTrue(true)\` — meaningless assertion
+- Testing private methods via reflection
+- Not using \`inner class\` with \`@Nested\` (required in Kotlin)
+- Using Java-style mock setup instead of Kotlin DSL
+- Not cleaning up coroutine test scopes in coroutine tests
+- Ignoring \`runTest {}\` for suspend function tests
+`;
+const TEST_WRITING_GENERIC = `---
+name: j.test-writing
+description: Write focused unit and integration tests following AAA pattern
+---
+
+# Skill: Test Writing (Generic)
+
+## When this skill activates
+Writing or editing test files in any language.
+
+## Required Steps
+
+### 1. Read the implementation first
+Before writing any test, read the file being tested.
+
+### 2. Test structure
+Follow the AAA (Arrange-Act-Assert) pattern:
+- **Arrange**: set up test data and dependencies
+- **Act**: call the function/method under test
+- **Assert**: verify the result matches expectations
+
+### 3. Coverage requirements
+- Happy path: at least 1 test
+- Error cases: test each distinct error path
+- Edge cases: empty inputs, boundary values, null/nil/None
+
+### 4. Mock strategy
+- Mock external dependencies (APIs, DB, file system)
+- Do NOT mock the module under test
+
+### 5. Naming conventions
+- Test names should describe the expected behavior
+- Group related tests logically
+
+## Anti-patterns to avoid
+- Meaningless assertions
+- Testing implementation details instead of behavior
+- Tests that depend on execution order
+`;
+// ─── Non-test skills (unchanged) ─────────────────────────────────────────────
+const PAGE_CREATION = `---
+name: j.page-creation
+description: Create Next.js App Router pages with correct patterns
+---
+
+# Skill: Page Creation
+
+This is a stack-specific skill. Only apply it when the project actually uses Next.js App Router patterns.
 
 ## When this skill activates
 Creating or editing \`app/**/page.tsx\` or \`app/**/layout.tsx\` files.
@@ -176,15 +692,14 @@ Always create companion files:
 - Missing loading states
 - Not handling error boundaries
 `;
-// ─── API Route Creation ───────────────────────────────────────────────────────
-const API_ROUTE_CREATION = `---
-name: j.api-route-creation
-description: Create Next.js App Router API routes with correct patterns
----
-
-# Skill: API Route Creation
-
-This is a stack-specific skill. Only apply it when the project actually uses Next.js App Router routes.
+const API_ROUTE_CREATION = `---
+name: j.api-route-creation
+description: Create Next.js App Router API routes with correct patterns
+---
+
+# Skill: API Route Creation
+
+This is a stack-specific skill. Only apply it when the project actually uses Next.js App Router routes.
 
 ## When this skill activates
 Creating or editing \`app/api/**/*.ts\` route files.
@@ -272,15 +787,14 @@ const CreateSchema = z.object({
 - Missing input validation
 - Returning 200 for errors
 `;
-// ─── Server Action Creation ───────────────────────────────────────────────────
-const SERVER_ACTION_CREATION = `---
-name: j.server-action-creation
-description: Create Next.js Server Actions with correct patterns
----
-
-# Skill: Server Action Creation
-
-This is a stack-specific skill. Only apply it when the project actually uses Next.js Server Actions.
+const SERVER_ACTION_CREATION = `---
+name: j.server-action-creation
+description: Create Next.js Server Actions with correct patterns
+---
+
+# Skill: Server Action Creation
+
+This is a stack-specific skill. Only apply it when the project actually uses Next.js Server Actions.
 
 ## When this skill activates
 Creating or editing files with \`"use server"\` directive, typically \`actions.ts\` or \`**/actions/*.ts\`.
@@ -361,11 +875,10 @@ export function ExampleForm() {
 - Catching errors silently without logging
 - Forgetting to revalidate affected paths
 `;
-// ─── Schema Migration ─────────────────────────────────────────────────────────
-const SCHEMA_MIGRATION = `---
-name: j.schema-migration
-description: Modify Prisma schema and create migrations safely
----
+const SCHEMA_MIGRATION = `---
+name: j.schema-migration
+description: Modify Prisma schema and create migrations safely
+---
 
 # Skill: Schema Migration
 
@@ -432,152 +945,152 @@ npx tsc --noEmit   # type check
 npm test           # run tests
 \`\`\`
 
-## Anti-patterns
-- Renaming columns without a migration step (data loss)
-- Adding required columns without defaults to non-empty tables
-- Forgetting to run \`prisma generate\` after schema changes
-- Not updating TypeScript types after schema changes
+## Anti-patterns
+- Renaming columns without a migration step (data loss)
+- Adding required columns without defaults to non-empty tables
+- Forgetting to run \`prisma generate\` after schema changes
+- Not updating TypeScript types after schema changes
 `;
-const AGENTS_MD_WRITING = `---
-name: j.agents-md-writing
-description: Write strong AGENTS.md files with local rules, commands, and boundaries
----
-
-# Skill: AGENTS.md Writing
-
-## When this skill activates
-Creating or editing any \`AGENTS.md\` file.
-
-## Goal
-Write an agent-facing operating manual for the current directory only.
-
-## Required Sections
-- Project or directory purpose
-- Build, lint, and test commands that actually work here
-- File layout and ownership boundaries
-- Local coding conventions and pitfalls
-- Review and verification expectations
-
-## Rules
-- Keep the root \`AGENTS.md\` concise and high-signal
-- Make nested \`AGENTS.md\` files additive, not repetitive
-- Prefer concrete commands over vague guidance
-- Separate business rules from technical principles:
-  - \`AGENTS.md\` = how to work in this area
-  - \`docs/domain/*\` = business behavior
-  - \`docs/principles/*\` = cross-cutting technical patterns
-
-## Good patterns
-- Include exact commands such as \`npm test -- foo\` or \`./gradlew test --tests \"...\"\`
-- Call out invariants, ownership boundaries, and high-blast-radius files
-- Mention generated files, migrations, or release steps when relevant
-
-## Anti-patterns
-- Dumping generic style advice with no repository specifics
-- Repeating the same commands in every nested file
-- Mixing business flows into technical instructions
-- Writing aspirational rules that are not enforced anywhere
+const AGENTS_MD_WRITING = `---
+name: j.agents-md-writing
+description: Write strong AGENTS.md files with local rules, commands, and boundaries
+---
+
+# Skill: AGENTS.md Writing
+
+## When this skill activates
+Creating or editing any \`AGENTS.md\` file.
+
+## Goal
+Write an agent-facing operating manual for the current directory only.
+
+## Required Sections
+- Project or directory purpose
+- Build, lint, and test commands that actually work here
+- File layout and ownership boundaries
+- Local coding conventions and pitfalls
+- Review and verification expectations
+
+## Rules
+- Keep the root \`AGENTS.md\` concise and high-signal
+- Make nested \`AGENTS.md\` files additive, not repetitive
+- Prefer concrete commands over vague guidance
+- Separate business rules from technical principles:
+  - \`AGENTS.md\` = how to work in this area
+  - \`docs/domain/*\` = business behavior
+  - \`docs/principles/*\` = cross-cutting technical patterns
+
+## Good patterns
+- Include exact commands such as \`npm test -- foo\` or \`./gradlew test --tests "..."\`
+- Call out invariants, ownership boundaries, and high-blast-radius files
+- Mention generated files, migrations, or release steps when relevant
+
+## Anti-patterns
+- Dumping generic style advice with no repository specifics
+- Repeating the same commands in every nested file
+- Mixing business flows into technical instructions
+- Writing aspirational rules that are not enforced anywhere
 `;
-const DOMAIN_DOC_WRITING = `---
-name: j.domain-doc-writing
-description: Write business-domain documentation that stays aligned with code
----
-
-# Skill: Domain Doc Writing
-
-## When this skill activates
-Creating or editing files under \`docs/domain/\`.
-
-## Goal
-Document how the business domain works now, not how the code is implemented internally.
-
-## Required Structure
-- Domain summary
-- Rules and invariants
-- Inputs, outputs, and state transitions when relevant
-- Edge cases and operational limits
-- Source of truth references to the key code files
-
-## Sync marker pattern
-At the top of a generated or refreshed section, prefer a marker like:
-
-\`<!-- juninho:sync source=src/payments/service.ts hash=abc123 -->\`
-
-Use the marker to indicate which code file justified the current documentation.
-
-## Rules
-- Write in present tense
-- Prefer user-visible behavior and business meaning
-- Cite key files that justify each rule
-- Update \`docs/domain/INDEX.md\` when adding or renaming a domain doc
-
-## Anti-patterns
-- Explaining framework internals instead of business behavior
-- Copying raw code into the document
-- Leaving undocumented edge cases discovered during implementation
+const DOMAIN_DOC_WRITING = `---
+name: j.domain-doc-writing
+description: Write business-domain documentation that stays aligned with code
+---
+
+# Skill: Domain Doc Writing
+
+## When this skill activates
+Creating or editing files under \`docs/domain/\`.
+
+## Goal
+Document how the business domain works now, not how the code is implemented internally.
+
+## Required Structure
+- Domain summary
+- Rules and invariants
+- Inputs, outputs, and state transitions when relevant
+- Edge cases and operational limits
+- Source of truth references to the key code files
+
+## Sync marker pattern
+At the top of a generated or refreshed section, prefer a marker like:
+
+\`<!-- juninho:sync source=src/payments/service.ts hash=abc123 -->\`
+
+Use the marker to indicate which code file justified the current documentation.
+
+## Rules
+- Write in present tense
+- Prefer user-visible behavior and business meaning
+- Cite key files that justify each rule
+- Update \`docs/domain/INDEX.md\` when adding or renaming a domain doc
+
+## Anti-patterns
+- Explaining framework internals instead of business behavior
+- Copying raw code into the document
+- Leaving undocumented edge cases discovered during implementation
 `;
-const PRINCIPLE_DOC_WRITING = `---
-name: j.principle-doc-writing
-description: Write technical principle docs with rationale, rules, and examples
----
-
-# Skill: Principle Doc Writing
-
-## When this skill activates
-Creating or editing files under \`docs/principles/\`.
-
-## Goal
-Capture cross-cutting engineering guidance that multiple modules should follow.
-
-## Required Structure
-- Problem this principle solves
-- Rule set (do / avoid)
-- Rationale and trade-offs
-- Canonical examples in this repository
-- Related files or tooling that enforce the rule
-
-## Sync marker pattern
-For generated sections, prefer a marker like:
-
-\`<!-- juninho:sync source=src/api/client.ts hash=def456 -->\`
-
-## Rules
-- Keep principles technical, reusable, and stack-aware
-- Reference concrete files or commands when possible
-- Register or update the keyword mapping in \`docs/principles/manifest\`
-- Distinguish principle docs from domain docs and \`AGENTS.md\`
-
-## Anti-patterns
-- Repeating business requirements here
-- Writing slogans with no enforcement or examples
-- Documenting obsolete patterns without marking them deprecated
+const PRINCIPLE_DOC_WRITING = `---
+name: j.principle-doc-writing
+description: Write technical principle docs with rationale, rules, and examples
+---
+
+# Skill: Principle Doc Writing
+
+## When this skill activates
+Creating or editing files under \`docs/principles/\`.
+
+## Goal
+Capture cross-cutting engineering guidance that multiple modules should follow.
+
+## Required Structure
+- Problem this principle solves
+- Rule set (do / avoid)
+- Rationale and trade-offs
+- Canonical examples in this repository
+- Related files or tooling that enforce the rule
+
+## Sync marker pattern
+For generated sections, prefer a marker like:
+
+\`<!-- juninho:sync source=src/api/client.ts hash=def456 -->\`
+
+## Rules
+- Keep principles technical, reusable, and stack-aware
+- Reference concrete files or commands when possible
+- Register or update the keyword mapping in \`docs/principles/manifest\`
+- Distinguish principle docs from domain docs and \`AGENTS.md\`
+
+## Anti-patterns
+- Repeating business requirements here
+- Writing slogans with no enforcement or examples
+- Documenting obsolete patterns without marking them deprecated
 `;
-const SHELL_SCRIPT_WRITING = `---
-name: j.shell-script-writing
-description: Write robust shell automation for project workflows and hooks
----
-
-# Skill: Shell Script Writing
-
-## When this skill activates
-Creating or editing shell scripts, especially in \`.opencode/scripts/\`, \`scripts/\`, or git hooks.
-
-## Required Steps
-1. Start with \`#!/bin/sh\` unless bash-only features are required
-2. Use \`set -e\` and quote every variable expansion that can contain spaces
-3. Resolve and \`cd\` to the project root before running project commands
-4. Prefer delegating to project scripts (\`npm run ...\`, \`make ...\`, \`./gradlew ...\`) over embedding large command logic
-5. Print short, actionable failure messages
-
-## Preferred patterns
-- Detect staged files once and reuse them
-- Support project-specific overrides before framework defaults
-- Keep hook scripts fast; full-suite checks belong outside the pre-commit path
-
-## Anti-patterns
-- Hardcoding one stack when multiple fallback commands are possible
-- Running the full test suite inside pre-commit by default
-- Using unquoted file lists or unsafe globbing
-- Mixing environment bootstrapping with small hook utilities
+const SHELL_SCRIPT_WRITING = `---
+name: j.shell-script-writing
+description: Write robust shell automation for project workflows and hooks
+---
+
+# Skill: Shell Script Writing
+
+## When this skill activates
+Creating or editing shell scripts, especially in \`.opencode/scripts/\`, \`scripts/\`, or git hooks.
+
+## Required Steps
+1. Start with \`#!/bin/sh\` unless bash-only features are required
+2. Use \`set -e\` and quote every variable expansion that can contain spaces
+3. Resolve and \`cd\` to the project root before running project commands
+4. Prefer delegating to project scripts (\`npm run ...\`, \`make ...\`, \`./gradlew ...\`) over embedding large command logic
+5. Print short, actionable failure messages
+
+## Preferred patterns
+- Detect staged files once and reuse them
+- Support project-specific overrides before framework defaults
+- Keep hook scripts fast; full-suite checks belong outside the pre-commit path
+
+## Anti-patterns
+- Hardcoding one stack when multiple fallback commands are possible
+- Running the full test suite inside pre-commit by default
+- Using unquoted file lists or unsafe globbing
+- Mixing environment bootstrapping with small hook utilities
 `;
 //# sourceMappingURL=skills.js.map