@khanhspring/forge-module 1.0.0

package/bin/install.js

@@ -0,0 +1,30 @@
+#!/usr/bin/env node
+
+import { cpSync, mkdirSync } from 'fs';
+import { join, dirname } from 'path';
+import { homedir } from 'os';
+import { fileURLToPath } from 'url';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const ROOT = join(__dirname, '..');
+const SKILLS_DIR = join(homedir(), '.claude', 'skills');
+
+const SKILLS = [
+  'forge-contract-test',
+  'forge-done',
+  'forge-implement',
+  'forge-init',
+  'forge-tasks',
+];
+
+console.log('Installing @forge-workflow/module skills...\n');
+
+mkdirSync(SKILLS_DIR, { recursive: true });
+
+for (const skill of SKILLS) {
+  cpSync(join(ROOT, skill), join(SKILLS_DIR, skill), { recursive: true, force: true });
+  console.log(`  ✓ ${skill}`);
+}
+
+console.log(`\nInstalled to ${SKILLS_DIR}`);
+console.log('Restart Claude Code, then run /forge-init in your module repo.');

package/forge-contract-test/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: "forge-contract-test"
+description: "Outputs the specmatic test command to verify the running service against its contracts. If test output is pasted as argument, analyzes each failure with endpoint, mismatch type, and a one-line fix."
+argument-hint: "Paste specmatic test failure output to analyze, or leave empty to get the test command"
+compatibility: "Requires module repo with .forge/module.json; service must be running at test_base_url for live testing"
+metadata:
+  author: "forge-workflow"
+  source: "module-skills/forge-contract-test/SKILL.md"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Forge Contract Test
+
+Run or analyze Specmatic contract tests for this module.
+
+## Pre-check
+- Read `.forge/module.json` for `contract_glob` and `test_base_url`.
+  If missing, say "Run forge-init to set up this module repo first."
+
+## If $ARGUMENTS is empty — Output the test command
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Contract Tests: {module}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Make sure your server is running at {test_base_url}, then run:
+
+  specmatic test \
+    --contract "{contract_glob}" \
+    --testBaseURL {test_base_url}
+
+Contracts under test:
+{list files matching contract_glob}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## If $ARGUMENTS contains test output — Analyze failures
+
+For each failure, provide:
+1. Which endpoint failed (method + path)
+2. What the mismatch is (missing field / wrong type / wrong status code / unexpected field)
+3. Where to fix it in the implementation (specific file/method if determinable from stack)
+4. One-line fix suggestion
+
+Format:
+```
+❌ POST /api/v1/users/register
+   Issue: Response missing required field `createdAt` (string, date-time)
+   Fix: Add `createdAt` to the RegisterResponse DTO and include it in the response
+
+❌ GET /api/v1/users/{id}
+   Issue: Returns 200 when user not found — contract expects 404
+   Fix: Add a not-found check before returning the response
+```
+
+## Rule
+Never suggest changing the contract to fix a failing test.
+If the contract looks wrong: "Raise this in the spec repo — don't work around it here."

package/forge-done/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: "forge-done"
+description: "Confirms all tasks for this module are complete and generates the module repo commit message. Module repo only — run /forge-close in the spec repo afterward to mark tasks done there."
+argument-hint: "Feature slug (e.g. 'user-registration')"
+compatibility: "Requires module repo with .forge/module.json and an initialized specs/ git submodule"
+metadata:
+  author: "forge-workflow"
+  source: "module-skills/forge-done/SKILL.md"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Forge Done — Module Repo
+
+Close out the implementation side of a feature: confirm all tasks are complete
+and generate the module repo commit message.
+
+This skill owns the module repo only. Updating task checkboxes in the spec repo
+is handled separately by `/forge-close` in the spec repo.
+
+---
+
+## Pre-check
+
+- Read `.forge/module.json` for `module` and `spec_submodule_path`.
+  If missing, say "Run `/forge-init` to set up this module repo first."
+- Feature slug from $ARGUMENTS. If empty, ask: "Which feature are you done with?"
+
+---
+
+## Step 1 — Read task list (read-only from submodule)
+
+Read `{spec_submodule_path}/features/{slug}/tasks.md`.
+Find the `### {module}` section. Extract all tasks with their checkbox state.
+
+If `tasks.md` is missing:
+> "No tasks file found at `specs/features/{slug}/tasks.md`.
+> Run `/forge-tasks {slug}` in the spec repo first."
+
+Note: the submodule is read-only — task checkboxes cannot be updated from here.
+That is handled by `/forge-close` in the spec repo.
+
+---
+
+## Step 2 — Confirm completion
+
+Show the task list:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Tasks: {module} / {feature-slug}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+- [x] TASK-1 [api] POST /users/register endpoint
+- [ ] TASK-2 [feat] Password hashing + validation
+- [x] TASK-3 [test] Unit tests for UserService
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+- All already ticked in submodule → note it and proceed.
+- Some unticked → ask: "Are these actually finished? Say **yes** to proceed or tell me what's still in progress."
+
+Wait for confirmation before continuing.
+
+---
+
+## Step 3 — Generate commit message
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Commit message
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+feat({module}): implement {feature-slug}
+
+- TASK-1: {title}
+- TASK-2: {title}
+- TASK-3: {title}
+
+Spec:     specs/features/{slug}/spec.md
+Tasks:    specs/features/{slug}/tasks.md
+Contract: specs/contracts/{module}/{slug}.yaml
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+Then remind:
+> "Once committed and pushed, go to the spec repo and run:
+> `/forge-close {slug} {module}`
+> to mark your tasks as done and check if the feature is fully complete."

package/forge-implement/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: "forge-implement"
+description: "Researches existing codebase patterns, clears ambiguities one at a time, challenges implementation concerns, then guides task-by-task implementation scoped to this module. No code written until plan is confirmed."
+argument-hint: "Feature slug (e.g. 'user-registration')"
+compatibility: "Requires module repo with .forge/module.json and an initialized specs/ git submodule"
+metadata:
+  author: "forge-workflow"
+  source: "module-skills/forge-implement/SKILL.md"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Forge Implement
+
+Understand the feature fully before writing a single line of code. Research existing
+patterns, surface ambiguities, flag conflicts — then implement with confidence.
+
+<HARD-GATE>
+Do NOT write any code, create any files, or modify any existing files until you have
+presented the Implementation Plan and the user has explicitly confirmed it.
+</HARD-GATE>
+
+---
+
+## Pre-check
+
+- Read `.forge/module.json` — if missing, say "Run `/forge-init` to set up this module repo first."
+- Get `module`, `spec_submodule_path`, `test_base_url`, `contract_glob` from module.json.
+- Feature slug from $ARGUMENTS.
+  - If empty, scan `{spec_submodule_path}/features/*/tasks.md` for `### {module}` sections,
+    list features with pending tasks, ask which to implement.
+- Check `git submodule status` — if specs/ is out of date, say:
+  > "Your specs submodule may be out of date. Run `git submodule update --remote specs` first, or continue with the current version?"
+
+---
+
+## Step 1 — Load & Research Context
+
+Load the feature documents silently:
+- `{spec_submodule_path}/features/{slug}/spec.md` — requirements and flows
+- `{spec_submodule_path}/features/{slug}/tasks.md` — task list for this module
+
+If `tasks.md` is missing → stop: "No tasks found. Run `/forge-tasks {slug}` in the spec repo first."
+
+**Determine which contract(s) apply to this module:**
+- Look for an own-module contract: `{spec_submodule_path}/contracts/{module}/{slug}.yaml`.
+- **If it exists** → this module *provides* the API. Use it as the source of truth for the
+  endpoints you implement.
+- **If it does NOT exist** (typical for frontend/consumer modules) → scan
+  `{spec_submodule_path}/contracts/*/{slug}.yaml` for sibling contracts. These are the APIs
+  this module *consumes*. Report:
+  > "No contract for `{module}` — this module consumes APIs from: {list backend modules}.
+  > I'll use their contracts as the integration source of truth."
+- If no contract exists anywhere for this feature → note it and continue with spec + tasks only.
+
+Then research the existing codebase — do this before asking any questions:
+
+1. **Read `CLAUDE.md`** — note architectural principles, conventions, and forbidden patterns.
+2. **Find similar existing endpoints** — look for controllers/routes with similar patterns to what the contract defines. Note how they're structured.
+3. **Find existing service/repository patterns** — how are services and data access layers organized in this codebase?
+4. **Find existing test patterns** — how are unit and integration tests structured? What test utilities exist?
+5. **Find existing error handling** — how does this service return errors? Does it match the `ApiError` schema (`shared/api-error.yaml`) in the contract — `code`, `message`, `traceId`, `details[]`?
+6. **Find existing auth/middleware** — how is authentication enforced on existing endpoints?
+
+Report findings before asking questions:
+
+> "Before we start, here's what I found in the codebase:
+> - Existing pattern: {e.g. 'Controllers use @RestController with @RequestMapping, services are injected via constructor'}
+> - Test pattern: {e.g. 'Integration tests use @SpringBootTest with TestContainers'}
+> - Error handling: {e.g. 'GlobalExceptionHandler returns ApiError with code + message + traceId — matches contract'}
+> - Auth: {e.g. 'JwtAuthFilter applied to all /api/v1/** routes via SecurityConfig'}
+> - Potential conflict: {any mismatch found — or 'None found'}
+>
+> I'll follow these patterns in the implementation."
+
+---
+
+## Step 2 — Clarifying Questions (one at a time)
+
+Ask questions ONE at a time. Only ask about things that are genuinely ambiguous or
+missing — do not ask about things already answered by the spec, contract, or codebase.
+
+Areas to clarify if unclear:
+
+- **Ambiguous acceptance criteria** — any task AC that could be implemented multiple ways
+- **Missing dependencies** — e.g. "TASK-3 requires sending an email but I don't see an email service in the codebase — is this in scope or should it be stubbed?"
+- **Conflicting patterns** — e.g. "The contract uses snake_case field names but all existing DTOs use camelCase — which should we follow?"
+- **Task ordering** — if task dependencies aren't obvious from the task list
+- **Data ownership** — if the feature touches data owned by another module, how should that be accessed?
+
+If a question cannot be answered without research outside this conversation, use the
+research flag pattern:
+
+> "🔍 **Research needed:** {what needs to be found out — e.g. 'whether the payment service supports idempotency keys'}
+> Want to (a) pause and check, (b) proceed with an assumption, or (c) flag it and move on?"
+
+If all tasks and the contract are clear, skip this step and say so.
+
+---
+
+## Step 3 — Challenge Round
+
+Before presenting the plan, flag at least 2 implementation concerns specific to what
+you've read. These should be real conflicts or risks, not generic warnings.
+
+> "Before I lay out the plan, a couple of things to flag:
+>
+> **[Concern 1]:** {e.g. 'The contract requires `createdAt` as date-time in the response,
+> but the existing User entity doesn't have this field — we'll need to add it or compute it.
+> Does that sound right?'}
+>
+> **[Concern 2]:** {e.g. 'TASK-2 (password hashing) and TASK-1 (register endpoint) are listed
+> independently, but TASK-1 depends on TASK-2 being done first. I'll do TASK-2 first — agreed?'}
+>
+> How should these be handled?"
+
+Wait for resolution before presenting the plan.
+
+---
+
+## Step 4 — Implementation Plan & Gate
+
+Present the full plan and wait for confirmation before writing any code:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Implementation Plan: {Feature Name}
+Module: {module}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+TASKS (in order)
+  1. TASK-2 [feat] Password hashing + validation
+     → {implementation approach}
+  2. TASK-1 [api]  POST /users/register endpoint
+     → {implementation approach, files to touch}
+  3. TASK-3 [test] Unit tests for UserService
+     → {what will be tested}
+
+KEY DECISIONS
+  - {pattern chosen and why, e.g. 'Following existing constructor injection pattern'}
+  - {any assumption recorded}
+
+FILES TO TOUCH
+  - {file path} — {what changes}
+  - {file path} — {what changes}
+
+CONTRACT  ({provide | consume})
+  {METHOD} {path} — {key fields to implement, or to send/expect when consuming}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+End with:
+> "Does this plan look right? Say **yes** to start, or tell me what to change."
+
+Do NOT write any code until the user confirms.
+
+---
+
+## Step 5 — Implement Task by Task
+
+Work through tasks in the agreed order. For each task:
+
+- State which task you're starting: "Starting TASK-2: {title}"
+- Use the contract YAML for exact field names, types, and response shapes
+- Follow the patterns found in Step 1 — no new patterns unless discussed
+- Write tests alongside the implementation, not after
+- When a task is done, confirm: "TASK-2 done. Moving to TASK-1 — ready?"
+
+If a new ambiguity surfaces mid-implementation:
+> "Unexpected: {what came up}. I'd suggest {option A} or {option B}. Which do you prefer?"
+Wait for the answer before continuing.
+
+---
+
+## Rules
+- Contract is the source of truth for API shape — never change it to fix a failing test
+- When **providing** an API: match the contract's request/response exactly
+- When **consuming** an API (frontend/client): send requests and parse responses exactly as the
+  consumed contract defines — treat its shapes as fixed, code defensively against its error responses
+- If the contract looks wrong: "This looks like a contract issue — raise a PR in the spec repo"
+- Only implement tasks under `### {module}` in tasks.md — flag any cross-module work
+- Follow existing codebase patterns found in Step 1 — consistency over personal preference
+- No code before the user confirms the plan in Step 4
+
+## Parallel FE+BE Flow (mention when relevant)
+If a consumer module needs the API before the provider has built it:
+> "The provider's contract at `specs/contracts/{backend-module}/{slug}.yaml` fully defines the
+> API — you can build and test against it (e.g. a stub server) before the backend is ready."

package/forge-init/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: "forge-init"
+description: "One-time initialization for a Forge module repo (backend or frontend). Researches existing repo state, then walks through setup conversationally one question at a time before writing any files."
+argument-hint: "Optional: module name to skip the first prompt"
+compatibility: "Run once in a module repo before any other forge skills. Safe to re-run — never overwrites existing files."
+when_to_use: >
+  ALWAYS activate when any of the following occur:
+  - User says init, initialize, setup, set up, bootstrap, configure + repo/forge/project
+  - User says "set this up", "get this started", "prepare this repo"
+  - No .forge/module.json exists AND user wants to start implementing specs
+  - User says "this is a new module repo" (or "service repo" / "code repo") or "add forge to this project"
+  Do NOT activate if .forge/module.json already exists — repo is already initialized.
+metadata:
+  author: "forge-workflow"
+  source: "module-skills/forge-init/SKILL.md"
+user-invocable: true
+disable-model-invocation: false
+---
+
+# Forge Init — Module Repo
+
+Initialize this repo as a Forge module repo (one module — backend or frontend).
+Research what's already in the codebase first, then ask one question at a time —
+pre-filling anything already detectable. Write all files in one go after confirmation.
+
+## Pre-check
+If `.forge/module.json` already exists → say "Module repo already initialized." and stop.
+
+---
+
+## Step 1 — Research existing repo state
+
+Before asking anything, silently scan the repo and note:
+
+1. **Stack detection** — does `pom.xml`, `build.gradle`, `package.json`, `go.mod`, `requirements.txt`, or similar exist? What versions are declared?
+2. **Port detection** — is a port configured in `application.yml`, `application.properties`, `.env`, `.env.example`, or `docker-compose.yml`?
+3. **Submodule** — does `specs/` already exist as a directory or submodule?
+4. **CI** — does `.github/workflows/` already exist? Any contract test workflow present?
+5. **Existing CLAUDE.md** — already has project context written?
+
+Report findings before asking anything:
+
+> "Here's what I found in this repo:
+> - Stack: {detected stack — or 'not detected'}
+> - Port: {detected port — or 'not found in config'}
+> - specs/ submodule: {exists / not present}
+> - GitHub Actions: {exists / not present}
+>
+> I'll use these as defaults — just confirm or correct as we go."
+
+---
+
+## Step 2 — Questions (one at a time)
+
+Ask one question per message. Wait for the answer before asking the next.
+Where research already gives a confident answer, present it as a default to confirm
+rather than asking from scratch.
+
+**Q1 — Module name**
+> "What's the module name for this repo?
+> _(Must exactly match a `name` entry in the spec repo's `.forge/project.json`)_"
+
+Do not suggest a default — module names must be exact matches. Warn clearly:
+> "This name must match exactly. A mismatch will break `/forge-implement` and `/forge-done`."
+
+**Q2 — Module description**
+> "What does this module do? (one sentence)"
+
+**Q3 — Spec repo URL**
+
+If `specs/` already exists:
+> "I see a `specs/` directory already — is that the spec repo submodule? (yes/no)
+> If yes, what's the remote URL? (run `git remote -v` in `specs/` if unsure)"
+
+If not:
+> "What's the spec repo URL? (it will be added as a git submodule at `specs/`)"
+
+**Q4 — Port**
+
+If port was detected in Step 1:
+> "I found port `{port}` in your config — is that the right local dev port? (yes / enter different port)"
+
+If not detected:
+> "What port does this module run on locally?"
+
+**Q5 — Tech stack**
+
+If stack was detected in Step 1:
+> "Looks like this is a `{detected stack}` module — is that right? Anything to add?"
+
+If not detected:
+> "What's the tech stack? (e.g. 'Spring Boot 3, Java 21' or 'React, TypeScript')"
+
+**Q6 — Principles**
+> "What are the key architectural principles for this module?
+> _(e.g. 'stateless', 'no business logic in controllers', 'repository pattern for DB access')
+> Say 'none yet' to skip._"
+
+**Q7 — Conventions**
+> "Any coding conventions the team follows in this repo?
+> _(e.g. 'constructor injection only', 'all public methods must have unit tests', 'no magic strings')
+> Say 'none yet' to skip._"
+
+**Q8 — Never**
+> "Anything developers should never do in this codebase?
+> _(e.g. 'no direct DB calls from the API layer', 'never change a contract to fix a failing test')
+> Say 'none yet' to skip._"
+
+**Q9 — GitHub Actions CI**
+
+If `.github/workflows/` already exists with a contract test:
+> "I see a CI workflow already exists — skip adding another? (yes to skip)"
+
+If not present:
+> "Add a GitHub Actions contract test workflow? (yes/no)"
+> _(Backend modules that serve an API benefit most; a frontend that only consumes can skip.)_
+
+---
+
+## Step 3 — Preview & gate
+
+Show a full preview of everything that will be created or run:
+
+```
+Ready to initialize. Here's what I'll do:
+
+{if specs/ not present}
+  git submodule add {spec-repo-url} specs
+  git submodule update --init --recursive
+
+.forge/module.json
+  module:         {module-name}
+  test_base_url:  http://localhost:{port}
+  contract_glob:  specs/contracts/{module-name}/*.yaml
+
+CLAUDE.md
+  Module:       {module-name}
+  Description:  {description}
+  Stack:        {stack}  Port: {port}
+  Principles:   {list or "none yet"}
+  Conventions:  {list or "none yet"}
+  Never:        {list or "none yet"}
+
+{if yes} .github/workflows/contract-test.yml
+.gitignore  ← append Forge entries
+```
+
+End with:
+> "Does this look right? Say **yes** to initialize, or tell me what to change."
+
+Wait for confirmation. Do not write files or run git commands before the user says yes.
+
+---
+
+## Step 4 — Write files
+
+Run (if specs/ not already present):
+```bash
+git submodule add {spec-repo-url} specs
+git submodule update --init --recursive
+```
+
+Write `.forge/module.json`:
+```json
+{
+  "module": "{module-name}",
+  "spec_submodule_path": "specs",
+  "specmatic_version": "2.x",
+  "test_base_url": "http://localhost:{port}",
+  "contract_glob": "specs/contracts/{module-name}/*.yaml"
+}
+```
+
+Write `CLAUDE.md`:
+```markdown
+# {module-name}
+
+{description}
+
+**Stack:** {stack}
+**Port:** {port}
+
+## Forge Workflow
+1. `/forge-tasks`         — see all pending tasks for this module
+2. `/forge-implement`     — implement a feature task by task
+3. `/forge-contract-test` — run Specmatic contract tests
+4. `/forge-done`          — confirm tasks done + generate commit message
+5. (then in the spec repo) `/forge-close {slug} {module}` — mark tasks done there
+
+## Spec repo
+Linked via git submodule at `specs/`.
+Run `git submodule update --remote specs` before starting a new feature,
+and again after `/forge-close` is run in the spec repo to sync task status.
+
+## Principles
+{list each as a bullet — or "None defined yet."}
+
+## Conventions
+{list each as a bullet — or "None defined yet."}
+
+## Never
+{list each as a bullet — or "None defined yet."}
+```
+
+If GitHub Actions was requested, write `.github/workflows/contract-test.yml`:
+```yaml
+name: Contract Tests
+on: [push, pull_request]
+jobs:
+  contract-test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          submodules: recursive
+      - name: Run contract tests
+        run: |
+          specmatic test \
+            --contract "specs/contracts/{module-name}/*.yaml" \
+            --testBaseURL ${{ env.SERVICE_URL }}
+```
+
+Append to `.gitignore` if not present:
+```
+# Forge
+.forge/secrets
+```
+
+Run `git status` and confirm:
+> "Module repo initialized. Run `/forge-tasks` to see what needs to be built."
+
+---
+
+## Rules
+- One question per message — never ask multiple questions at once
+- Never write files or run git commands before the user says yes in Step 3
+- Never overwrite existing files
+- All written files must be complete — no unfilled placeholders
+- `module` in module.json must exactly match the name in the spec repo's project.json
+- If the user provides multiple answers in one message, accept them gracefully and move forward

package/forge-tasks/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: "forge-tasks"
+description: "Lists all tasks assigned to this module across every feature, with completion status, by scanning the spec submodule. Module repo task dashboard."
+argument-hint: ""
+compatibility: "Requires module repo with .forge/module.json and an initialized specs/ git submodule"
+metadata:
+  author: "forge-workflow"
+  source: "module-skills/forge-tasks/SKILL.md"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Forge Tasks — Module Repo
+
+Show all tasks assigned to this module across all features.
+
+## Pre-check
+- Read `.forge/module.json` for `module` and `spec_submodule_path`.
+  If missing: "Run `/forge-init` to set up this module repo first."
+- If `specs/` is not initialized: suggest `git submodule update --init --recursive`
+- Optionally suggest `git submodule update --remote specs` to get the latest task status.
+
+## Steps
+
+Scan `{spec_submodule_path}/features/*/tasks.md` → find `### {module}` sections → extract tasks
+with their checkbox state and the parent feature's `Status`.
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Tasks for: {module}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Feature: user-registration  [Open]
+- [ ] TASK-1 [api] POST /users/register endpoint
+- [ ] TASK-2 [feat] Password hashing + validation
+- [x] TASK-3 [test] Unit tests for UserService
+
+Feature: user-profile  [Open]
+- [ ] TASK-5 [api] GET /users/{id} endpoint
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+2 features  ·  4 remaining  ·  1 done
+```
+
+If no tasks reference this module across any feature:
+> "No tasks found for `{module}`. Either no feature targets this module yet, or the specs
+> submodule is out of date — try `git submodule update --remote specs`."
+
+After showing: "Tell me which feature to implement, or run `/forge-implement {slug}`."

package/package.json

@@ -0,0 +1,19 @@
+{
+  "name": "@khanhspring/forge-module",
+  "version": "1.0.0",
+  "description": "Forge module repo skills for Claude Code — implement, contract-test, done, and more",
+  "type": "module",
+  "bin": {
+    "forge-module": "bin/install.js"
+  },
+  "files": [
+    "bin",
+    "forge-contract-test",
+    "forge-done",
+    "forge-implement",
+    "forge-init",
+    "forge-tasks"
+  ],
+  "keywords": ["claude-code", "skills", "ai", "workflow", "microservices"],
+  "license": "MIT"
+}