[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M719PRYZFEMGC842DHMFMEH0":3,"skill-same:01M719PRYZFEMGC842DHMFMEH0":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":62},"01M719PRYZFEMGC842DHMFMEH0","sdd-apply",null,"Implement tasks following specs and design; supports Strict TDD mode. Trigger: When implementing tasks","Thrasno\u002Fjarvis-ai-devs","Thrasno","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F118975961?v=4","01M719P0RERWBY3CAV9PHJVJ54","01M719P0S376Y4Z6J2VCSS4NHJ",1,"MIT","https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fsdd-apply\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32],"sdd","sdd apply","apply","mode","implementing","design","false","when","tasks","core","trigger","true","implement","programming","tdd","2026-11-10 10:12:30",false,"---\nname: sdd-apply\ndisplay_name: \"SDD Apply\"\ndescription: \"Implement tasks following specs and design; supports Strict TDD mode. Trigger: When implementing tasks\"\ndisable-model-invocation: true\nuser-invocable: false\nlicense: MIT\nscope: core\nmetadata:\n  author: gentleman-programming\n  version: \"3.0\"\n  delegate_only: true\n---\n\n\u003C!-- Synced from https:\u002F\u002Fraw.githubusercontent.com\u002FGentleman-Programming\u002Fgentle-ai\u002Fv1.40.2\u002Finternal\u002Fassets\u002Fskills\u002Fsdd-apply\u002FSKILL.md (tag v1.40.2, commit 660917927b4821f5e540dc8fa501d6bee723222c); adapted for Jarvis\u002FHive runtime semantics. -->\n\n> **ORCHESTRATOR GATE**: If you loaded this skill via the `skill()` tool, you are\n> the ORCHESTRATOR — STOP. Do NOT execute these instructions inline. Delegate to\n> the dedicated `sdd-apply` executor using your platform's delegation primitive.\n> This skill is for EXECUTORS only.\n\n## Executor Override\n\nIf you ARE the `sdd-apply` executor, the gate above does NOT apply to you. Continue with the phase work below. Do NOT delegate. Do NOT call the Skill tool. You are the executor — execute.\n\n## Language Domain Contract\n\nGenerated technical artifacts default to English. Do not inherit the user's conversational language or the active persona's regional voice for SDD artifacts unless the user explicitly requests that artifact language or the project convention requires it.\n\nIf Spanish technical artifacts are explicitly requested, use neutral\u002Fprofessional Spanish unless the user explicitly asks for a regional variant.\n\nPublic\u002Fcontextual comments follow the target context language by default. Explicit user language or tone overrides win; Spanish comments default to neutral\u002Fprofessional Spanish unless the user or target context clearly calls for regional tone.\n\n## Purpose\n\nYou are an implementation executor. You receive specific tasks and implement them by writing actual code. Follow the specs, design, assigned task boundary, and workspace safety contract strictly.\n\n## What You Receive\n\nFrom the orchestrator:\n\n- Change name\n- The specific task(s) to implement (for example, \"Phase 1, tasks 1.1-1.3\")\n- Artifact store mode (`hive | openspec | hybrid | none`)\n- Structured status from `jarvis sdd status \u003Cchange> --json` (schema: `jarvis.sdd-status`): `schemaName`\u002F`schema`, `planningHome`, `changeRoot`, `artifactPaths`, `contextFiles`, `blockedReasons`, `applyState`, task progress, dependency states, `relationships`, `phaseInstructions`, and `actionContext`\n- Preflight decisions for the feature: delivery strategy (`auto-chain | exception-ok`), review budget, chain strategy (or `size:exception`), assigned PR slice when chained, and TDD mode (`strict | standard`)\n\n## Execution and Persistence Contract\n\n> Follow **Section B** (retrieval) and **Section C** (persistence) from `skills\u002F_shared\u002Fsdd-phase-common.md`, using Jarvis\u002FHive terminology.\n\n- **hive**: Read the required artifacts and resolve progress through the dedicated guarded progress API. Search results with multiple candidates are ambiguous; use the status-provided snapshot reference rather than selecting a newest result. `mcp__hive__mem_save` remains for non-progress SDD artifacts only; it is not an apply-progress writer.\n- **openspec**: Read and follow `skills\u002F_shared\u002Fopenspec-convention.md`. Update `tasks.md` with `[x]` marks and use the dedicated progress command for the bounded snapshot\u002Fbatch topology.\n- **hybrid**: Use the dedicated progress command to publish the same immutable evidence batches and guarded snapshot advance to both sides. Update filesystem task checkboxes; do not use a general memory save to bridge divergent progress.\n- **none**: Return progress only. Do not update project artifacts.\n\nBefore selecting a progress backend, resolve or adopt the immutable `project\u002Fchange` binding from status: `hive`, `openspec`, or `hybrid`; `none` is unpersisted. A persisted binding wins over `JARVIS_SDD_STORE_MODE`, including an invalid value. Hive binding is in SQLite, OpenSpec binding is in `openspec\u002Fchanges\u002F{change-name}\u002Fstate.yaml`, and hybrid requires matching copies. Unavailable is not absent; malformed, unsupported, divergent, or protected-progress state blocks fail closed. Planning artifacts cannot choose authority.\n\n## Status and Workspace Guard\n\nBefore reading implementation files or writing code: Apply the Native Status Gate from `_shared\u002Fsdd-phase-common.md` to the forwarded status; run `jarvis sdd status \u003Cchange> --json` yourself only when no status was forwarded; STOP on any gate failure. Gate phase: `sdd-apply`; `dependencies[\"sdd-apply\"]` must be exactly `ready`.\n\n- Read context from `contextFiles` and `artifactPaths` before reading implementation files. Do not assume fixed artifact filenames when status provides paths or Hive topics.\n- Use `applyState.hasProgress` and `applyState.complete` to understand whether prior apply work exists and is complete. `hasProgress` means an apply-progress artifact exists. `complete` means canonical apply-progress is complete and authoritative task checkboxes are all checked; verify-report remains a separate dependency. Do not rename, remove, or invent extra `applyState` values beyond the Jarvis status contract.\n- If all assigned implementation is complete and the validated v2 snapshot coverage agrees with the frozen task manifest and persisted checkboxes, do not edit. Return `success` with `next_recommended: sdd-verify` or `sdd-archive` based on dependency state.\n- Once the gate passes, proceed only on the assigned pending tasks.\n- Use `phaseInstructions` to report the next phase command when returning; do not invent phase routing.\n\n## What to Do\n\n### Step 1: Load Skills\n\nFollow **Section A** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n\n### Step 2: Read Context\n\nBefore writing ANY code:\n\n1. Pass the Native Status Gate (see Status and Workspace Guard) for the assigned work.\n2. Read every applicable artifact path\u002Ftopic from `contextFiles` and `artifactPaths`, using forwarded observation IDs or paths per shared Section B.\n3. Read the specs — understand WHAT the code must do.\n4. Read the design — understand HOW to structure the code.\n5. Read existing code in affected files — understand current patterns.\n6. Check the project's coding conventions from `config.yaml` when available.\n\n#### Step 2a: Enforce Review Workload Decision\n\nBefore implementing, inspect the tasks artifact for `Review Workload Forecast`.\n\nIf the forecast says any of the following:\n\n- `Budget risk: High`\n- `Chained PRs recommended: Yes`\n- `Decision needed before apply: Yes`\n\nThen you MUST confirm the preflight decisions forwarded by the orchestrator resolve the delivery path:\n\n1. **`auto-chain` with a chain strategy**: implement only the assigned work-unit slice, keep scope autonomous, and report the intended PR boundary. Follow the `Chain strategy` from the tasks artifact (`stacked-to-main` or `feature-branch-chain`) for branch targeting.\n2. **`exception-ok` \u002F `size:exception`**: implement the feature as one PR with no further size checks; do not forecast lines or ask about size.\n\nAlso check for `Chain strategy` in the tasks artifact. If present and not `pending`, follow it consistently:\n\n- `stacked-to-main`: each PR targets the previous PR's branch (or `main` after the previous merges).\n- `feature-branch-chain`: PR #1 targets the feature\u002Ftracker branch; later PRs target the immediate previous PR branch. The tracker PR aggregates the feature branch to `main`; child PR diffs must stay focused on only the current work unit and must never target `main` directly.\n\nIf neither delivery decision nor chain strategy is present, STOP before writing code and return `blocked` with: `Preflight decisions missing before apply: the tasks artifact has no resolved size policy or chain strategy. The orchestrator must run the SDD Session Preflight and record the ## SDD Decisions block.`\n\n#### Step 2b: Read Previous Apply-Progress (if exists)\n\nBefore starting work, read `skills\u002F_shared\u002Fapply-progress.md` and use the mode-specific canonical reader: OpenSpec reads the change's canonical `apply-progress.md` snapshot and exactly its referenced `apply-evidence\u002F\u003Cbatch-id>.json` documents; Hive calls `sdd_apply_progress_get` with project and change, then iterates `snapshot.batches` with one `sdd_apply_evidence_get` request per `batch_id`. Validate the snapshot against those batches before using it. Hybrid resolves and independently validates both. Read the current generation, revision, digest, receipt, coverage, and next unpersisted entry; never infer completion from a cumulative observation or a checkbox alone.\n\nContinue only from validated canonical bounded state. Do not merge or rewrite historical evidence. Reconcile current task state against validated coverage, then do not jump to `sdd-verify` until apply progress and task checkboxes agree. The guarded snapshot is the authoritative progress state.\n\n### Step 3: Resolve TDD Mode and Test Command\n\nThe TDD mode forwarded by the orchestrator is the preflight choice for this feature and always wins over cached capabilities. Cached capabilities decide the mode only for legacy launches that forwarded nothing; otherwise they are read only to find the test command.\n\n```\nResolve mode (first match wins):\n├── Prompt contains `STRICT TDD MODE IS ACTIVE` → STRICT TDD MODE\n│   └── Load and follow strict-tdd.md (read the file: skills\u002Fsdd-apply\u002Fstrict-tdd.md)\n├── Prompt contains `TDD MODE: standard` → STANDARD MODE\n│   └── Use Step 4 below; never load strict-tdd.md\n└── Nothing forwarded (legacy launch only)\n    ├── Read cached testing capabilities:\n    │   ├── hive: mcp__hive__mem_search(\"sdd\u002F{project}\u002Ftesting-capabilities\") → mcp__hive__mem_get_observation(id)\n    │   ├── openspec: openspec\u002Fconfig.yaml → strict_tdd_suggestion + detection_reason + testing section\n    │   └── Fallback: check project files directly for a real test command (package.json test script, *_test.go, etc.)\n    ├── Use `strict_tdd_suggestion`; fall back to legacy `strict_tdd` only when the suggestion is absent\n    ├── Suggestion is strict AND a real test command exists → STRICT TDD MODE\n    └── Otherwise → STANDARD MODE\n\nCache the resolved mode for the return summary.\n```\n\n#### Runnable Test Command Gate (Strict TDD Only)\n\nIf Strict TDD Mode is active but no runnable test command exists for the files the assigned tasks touch (for example Deluge code, or a project without a test runner), STOP before the first task and return `blocked` with reason `strict-tdd-unrunnable` and this sentence for the user: `Strict TDD was chosen but these files cannot run under a test runner; choose standard for this feature or provide a test command.` Do not loop writing tests that cannot run, and do not switch to Standard Mode yourself. `[operator]` tasks are executed by the developer and never trigger this gate.\n\n**Key principle**: If Strict TDD Mode is not active, ZERO TDD instructions are loaded. The `strict-tdd.md` module is never read, never processed, never consumes tokens.\n\n#### Hard Gate (Strict TDD Only)\n\nIf Strict TDD Mode is active (from the forwarded TDD mode or, for legacy launches only, self-discovery):\n\n- You MUST record TDD proof as `task_records` in the batch checkpoint, not a Markdown TDD table; the CLI expands each record into structured v2 `EvidenceEntry` values.\n- Each task gets ONE record whose `red` step carries the executed focused failing command and failure summary, whose `green` step carries the passing command and exit code, and whose `triangulate` step is either an executed case or an explicit structural `skip_reason`.\n- Completion coverage may name a task only when its record's evidence actually establishes completion. Do not infer coverage from a narrative table.\n- Record new TDD evidence in the new immutable batch; do not merge or rewrite prior apply-progress evidence. The verify phase rejects missing or incomplete v2 evidence.\n\n**There is no silent fallback.** If you resolved Strict TDD as active, you follow it or you report failure. You do NOT quietly switch to Standard Mode.\n\n### Step 4: Implement Tasks (Standard Workflow)\n\nThis step is used when Strict TDD Mode is NOT active:\n\n```\nFOR EACH TASK:\n├── Read the task description\n├── Read relevant spec scenarios (these are your acceptance criteria)\n├── Read the design decisions (these constrain your approach)\n├── Read existing code patterns (match the project's style)\n├── Confirm every target path is under allowedEditRoots\n├── Write the code\n├── Add the task's `task_records` item (files plus a `verification` step with the command you ran, or only a summary when no command applies); leave the persisted task checkbox unchecked\n└── Note any issues or deviations\n```\n\n### Operator Handoff Tasks\n\nA task marked `[operator]` (for example `- [ ] 2.3 [operator] Upload ...` under `## Operator Handoff`) is executed by the developer, never by you. SDD controls the agent, not the developer: the developer's word in chat is enough.\n\n- **Next pending task is `[operator]`**: Checkpoint any agent work done before the handoff first (Steps 5–6). Then emit the handoff in plain language, one or two sentences saying what to do and which cases to try, return `partial` with reason `operator-handoff`, and STOP. Do not continue with later agent tasks, even when they look independent.\n- **Launched with `OPERATOR_ACK: \u003Ctask-id> — \u003Cdeveloper message>`**: record a `task_records` item `{\"task_id\": \"2.3\", \"operator\": {\"summary\": \"\u003Cdeveloper message>\"}}` through the normal guarded checkpoint, mark the checkbox `[x]` only after `committed`, and resume with the next agent task. The `operator` step carries only the summary: no command, no exit code, and no other step in the same record.\n- **Launched on an unacknowledged `[operator]` task without an ack**: restate the pending handoff in one line and return `partial` with reason `operator-handoff`, asking once whether it is done. That is the only question.\n\nNever ask for screenshots, IDs, or logs, and never verify the step yourself. Never use Zoho MCP servers to check an operator step: they point at our own account, never the client tenant. Strict TDD never applies to `[operator]` tasks.\n\n### Step 5: Persist Progress\n\n**This step is MANDATORY — do NOT skip it.**\n\nCheckpoint ONCE per apply batch, not per task. After every assigned task in the batch is implemented and its evidence is captured, run `jarvis sdd progress checkpoint --root \u003Cchange-root> --request \u003Crequest.json>` a single time. It accepts no positional arguments, plans at most one whole-entry prefix, and commits immutable evidence batches through the guarded writer; every serialized snapshot and batch stays at most 40,000 Unicode runes. Do not use `mcp__hive__mem_save` to write, replace, or recover apply-progress.\n\n##### Canonical v2 checkpoint request\n\nFreeze `tasks` and the `task_records` (the ordered complete entries stream they expand to) before the checkpoint; a continuation reuses them unchanged through a stable base snapshot and cursor. Always send `base` and the expected coordinates from the progress read in Step 2b: they are the optimistic-concurrency guard and are never optional.\n\n| Field | Required value |\n| --- | --- |\n| `project`, `change` | Canonical project and change identifiers. Each protocol identifier is 1–64 characters matching `[A-Za-z0-9][A-Za-z0-9._-]{0,63}`. |\n| `tasks` | The ordered task list parsed from the same frozen `tasks.md`: each item is `{id, text, path}`. `id` and normalized text determine `task_manifest_sha256`; do not manufacture, reorder, or edit tasks. |\n| `base` | `null` for the initial generation; otherwise the exact resolved v2 snapshot from the progress read. |\n| `expected_generation`, `expected_revision`, `expected_digest` | Coordinates of `base`; use zero values and an empty digest only for an initial snapshot. |\n| `task_records` | One record per task this batch covers: `task_id`, `files`, optional `completes` (default `true`), and only the steps that actually ran — `red`, `green`, `triangulate`, `refactor`, `verification` — each `{command, exit_code, summary}`, or a lone `operator` step `{summary}` carrying the developer's acknowledgement of an `[operator]` task; `triangulate` may instead be `{skip_reason}`. Completion rides on the last step that ran (a `skip_reason` triangulation did not run), and that step must pass. |\n| `entry_index`, `entry_id` | `0` with `entry_id` omitted for a new stream; `entry_index: 0` fills the first expanded entry ID. A continuation uses exactly the pair `next.instruction` names. |\n\nOmit `request_id`, `batch_id`, and `stream_sha256`: the checkpoint derives them from the request. Explicit `entries` (whole `EvidenceEntry` values with `entry_id`, `task_ids`, `completes_task_ids`, `kind`, `summary`, `command`, `exit_code`, `outcome`, and `files`) remain accepted but are mutually exclusive with `task_records`. `imported` is internal legacy provenance only; callers MUST NOT supply it.\n\nNever invent coverage: a record names only a task this batch implemented and carries only commands that actually ran. `tasks.md` stays the human-visible task state, never a substitute for v2 evidence; a later task edit changes the manifest digest and requires explicit reconciliation, not a continuation.\n\nThe checkpoint `outcome` is one of `committed`, `continuation_required`, `evidence_item_too_large`, `snapshot_capacity_exhausted`, `stream_preflight_required`, and `checkpoint_consolidation_required`, or a typed conflict, invalid, blocked, or recovery response. Every response carries `next: {action, instruction}`. After the command, follow `next.action` and `next.instruction` only: `continue_stream` is yours to rerun now with the returned cursor (the orchestrator does not relaunch for it); each rerun must advance the cursor, and if it does not, STOP and return `blocked`; `done` and `continue_tasks` end this batch's checkpointing, and every `stop_*` action ends the phase with `code` and `recovery` reported verbatim. Fail closed: if the response has no `next`, or its action is not one named here or in Recovery, STOP and return `blocked` with the raw `outcome`, `code`, and `recovery`. Do not emit free-form lifecycle markers: the validated v2 snapshot status and referenced batches are authoritative.\n\n#### Recovery\n\nRare paths still follow `next`; these notes only name what it covers.\n\n- `run_upgrade_continuation` (`legacy_upgrade_required`): a historical v2 snapshot serialized an explicit all-zero continuation group. Run `jarvis sdd progress upgrade-continuation --root \u003Cchange-root> --request \u003Crequest.json>` with the same request, then rerun the checkpoint from the upgraded snapshot. A legacy Markdown artifact needs no step: its first checkpoint imports it and keeps the legacy source authoritative until that guarded commit succeeds.\n- `stop_consolidate` (`stream_preflight_required`, `checkpoint_consolidation_required`): combine pending evidence into fewer, larger records before binding a new stream. Never modify records for an active frozen continuation.\n- `stop_new_change` (`snapshot_capacity_exhausted`): checkpoint frequency cannot repair a full reference set; stop with apply partial and carry the uncovered task IDs into a new SDD change. A committed `warning` is an early capacity signal: do not start new tiny streams.\n- `retry_identical` (transport loss, `lock_busy`, partial hybrid recovery): retry at most twice; if it still does not commit, STOP and report `code` and `recovery`. Preserve the existing hybrid receipt and rerun the identical request, so the same request ID, batch ID, base, cursor, and byte-identical payload replay. A partial recovery may replay or revalidate the exact request against both backends through their idempotent contracts before accepting acknowledgements. A complete receipt returns without replay. Never change the payload, identity, or authority, and never rewrite confirmed progress.\n- `stop_blocked` (`project_mismatch`): stored progress is signed under a different project than the effective project key. Nothing was written. STOP and report `code` and `recovery`; never re-sign, copy, or rewrite progress under another project key.\n- The low-level `advance` remains a recovery\u002Fcompatibility primitive for an already planned batch and snapshot. Do not ask `advance`, HTTP, or MCP to select prefixes or plan capacity.\n\n### Step 6: Mark Tasks Complete\n\nOnce the batch checkpoint (including any `continue_stream` reruns) has returned `committed`, update the persisted tasks artifact in one edit: change `- [ ]` to `- [x]` for exactly the tasks the committed snapshot coverage names, and nothing else. Never mark a task `[x]` without committed coverage.\n\n```markdown\n## Phase 1: Foundation\n\n- [x] 1.1 Create `internal\u002Fauth\u002Fmiddleware.go` with JWT validation\n- [x] 1.2 Add `AuthConfig` struct to `internal\u002Fconfig\u002Fconfig.go`\n- [ ] 1.3 Add auth routes to `internal\u002Fserver\u002Fserver.go`  ← still pending\n```\n\n### Step 7: Return Summary\n\nBefore returning, re-read the persisted tasks artifact and confirm every task you report as completed is marked `[x]` there. If the artifact still shows a completed task as `- [ ]`, fix the checkbox before returning. Do not report `Ready for verify` while completed work is only reflected in internal todos or apply-progress.\n\nReturn to the orchestrator:\n\n```markdown\n## Implementation Progress\n\n**Change**: {change-name}\n**Mode**: {Strict TDD | Standard}\n\n### Completed Tasks\n- [x] {task 1.1 description}\n- [x] {task 1.2 description}\n\n### Files Changed\n| File | Action | What Was Done |\n|------|--------|---------------|\n| `path\u002Fto\u002Ffile.ext` | Created | {brief description} |\n| `path\u002Fto\u002Fother.ext` | Modified | {brief description} |\n\n{IF Strict TDD Mode → include the safety-net baseline and each task's RED\u002FGREEN\u002FTRIANGULATE\u002FREFACTOR outcomes from strict-tdd.md}\n\n### Deviations from Design\n{List any places where the implementation deviated from design.md and why. If none, say \"None — implementation matches design.\"}\n\n### Issues Found\n{List any problems discovered during implementation. If none, say \"None.\"}\n\n### Remaining Tasks\n- [ ] {next task}\n- [ ] {next task}\n\n### Workload \u002F PR Boundary\n- Mode: {single PR | chained PR slice | stacked PR slice | size:exception}\n- Current work unit: {unit name or \"N\u002FA\"}\n- Boundary: {what this apply batch starts from and ends with}\n- Estimated review budget impact: {brief note}\n\n### Status\n{N}\u002F{total} tasks complete. {Ready for next batch \u002F Ready for verify \u002F Waiting for operator task X \u002F Blocked by X}\n```\n\n## Rules\n\n- ALWAYS read specs before implementing — specs are your acceptance criteria\n- ALWAYS follow the design decisions — do not freelance a different approach\n- ALWAYS match existing code patterns and conventions in the project\n- STOP on any Native Status Gate failure; do not infer readiness from conversation alone\n- In `openspec` mode, mark tasks complete in `tasks.md` only after the guarded checkpoint commits matching task coverage\n- Before returning, re-read the persisted tasks artifact and ensure completed tasks are visibly marked `[x]`; internal todos are not completion evidence\n- If you discover the design is wrong or incomplete, NOTE IT in your return summary — do not silently deviate\n- If a task is blocked by something unexpected, STOP and report back\n- If workload forecast requires a decision and none was provided, STOP before writing code\n- When applying a chained\u002Fstacked PR slice, keep the batch autonomous: one deliverable scope, verification included, and clear rollback boundary\n- When applying `size:exception`, state it explicitly in apply-progress and the return summary\n- NEVER implement tasks that were not assigned to you\n- Skill loading is handled in Step 1 — follow any loaded skills strictly when writing code\n- Apply any `rules.apply` from `openspec\u002Fconfig.yaml`\n- If Strict TDD Mode is active (Step 3), load `strict-tdd.md` and follow its cycle INSTEAD of Step 4\n- When Strict TDD is active, the `strict-tdd.md` module's rules OVERRIDE Step 4 entirely\n- Return envelope per **Section D** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n","\u003C!-- Synced from https:\u002F\u002Fraw.githubusercontent.com\u002FGentleman-Programming\u002Fgentle-ai\u002Fv1.40.2\u002Finternal\u002Fassets\u002Fskills\u002Fsdd-apply\u002FSKILL.md (tag v1.40.2, commit 660917927b4821f5e540dc8fa501d6bee723222c); adapted for Jarvis\u002FHive runtime semantics. -->\n\n> **ORCHESTRATOR GATE**: If you loaded this skill via the `skill()` tool, you are\n> the ORCHESTRATOR — STOP. Do NOT execute these instructions inline. Delegate to\n> the dedicated `sdd-apply` executor using your platform's delegation primitive.\n> This skill is for EXECUTORS only.\n\n## Executor Override\n\nIf you ARE the `sdd-apply` executor, the gate above does NOT apply to you. Continue with the phase work below. Do NOT delegate. Do NOT call the Skill tool. You are the executor — execute.\n\n## Language Domain Contract\n\nGenerated technical artifacts default to English. Do not inherit the user's conversational language or the active persona's regional voice for SDD artifacts unless the user explicitly requests that artifact language or the project convention requires it.\n\nIf Spanish technical artifacts are explicitly requested, use neutral\u002Fprofessional Spanish unless the user explicitly asks for a regional variant.\n\nPublic\u002Fcontextual comments follow the target context language by default. Explicit user language or tone overrides win; Spanish comments default to neutral\u002Fprofessional Spanish unless the user or target context clearly calls for regional tone.\n\n## Purpose\n\nYou are an implementation executor. You receive specific tasks and implement them by writing actual code. Follow the specs, design, assigned task boundary, and workspace safety contract strictly.\n\n## What You Receive\n\nFrom the orchestrator:\n\n- Change name\n- The specific task(s) to implement (for example, \"Phase 1, tasks 1.1-1.3\")\n- Artifact store mode (`hive | openspec | hybrid | none`)\n- Structured status from `jarvis sdd status \u003Cchange> --json` (schema: `jarvis.sdd-status`): `schemaName`\u002F`schema`, `planningHome`, `changeRoot`, `artifactPaths`, `contextFiles`, `blockedReasons`, `applyState`, task progress, dependency states, `relationships`, `phaseInstructions`, and `actionContext`\n- Preflight decisions for the feature: delivery strategy (`auto-chain | exception-ok`), review budget, chain strategy (or `size:exception`), assigned PR slice when chained, and TDD mode (`strict | standard`)\n\n## Execution and Persistence Contract\n\n> Follow **Section B** (retrieval) and **Section C** (persistence) from `skills\u002F_shared\u002Fsdd-phase-common.md`, using Jarvis\u002FHive terminology.\n\n- **hive**: Read the required artifacts and resolve progress through the dedicated guarded progress API. Search results with multiple candidates are ambiguous; use the status-provided snapshot reference rather than selecting a newest result. `mcp__hive__mem_save` remains for non-progress SDD artifacts only; it is not an apply-progress writer.\n- **openspec**: Read and follow `skills\u002F_shared\u002Fopenspec-convention.md`. Update `tasks.md` with `[x]` marks and use the dedicated progress command for the bounded snapshot\u002Fbatch topology.\n- **hybrid**: Use the dedicated progress command to publish the same immutable evidence batches and guarded snapshot advance to both sides. Update filesystem task checkboxes; do not use a general memory save to bridge divergent progress.\n- **none**: Return progress only. Do not update project artifacts.\n\nBefore selecting a progress backend, resolve or adopt the immutable `project\u002Fchange` binding from status: `hive`, `openspec`, or `hybrid`; `none` is unpersisted. A persisted binding wins over `JARVIS_SDD_STORE_MODE`, including an invalid value. Hive binding is in SQLite, OpenSpec binding is in `openspec\u002Fchanges\u002F{change-name}\u002Fstate.yaml`, and hybrid requires matching copies. Unavailable is not absent; malformed, unsupported, divergent, or protected-progress state blocks fail closed. Planning artifacts cannot choose authority.\n\n## Status and Workspace Guard\n\nBefore reading implementation files or writing code: Apply the Native Status Gate from `_shared\u002Fsdd-phase-common.md` to the forwarded status; run `jarvis sdd status \u003Cchange> --json` yourself only when no status was forwarded; STOP on any gate failure. Gate phase: `sdd-apply`; `dependencies[\"sdd-apply\"]` must be exactly `ready`.\n\n- Read context from `contextFiles` and `artifactPaths` before reading implementation files. Do not assume fixed artifact filenames when status provides paths or Hive topics.\n- Use `applyState.hasProgress` and `applyState.complete` to understand whether prior apply work exists and is complete. `hasProgress` means an apply-progress artifact exists. `complete` means canonical apply-progress is complete and authoritative task checkboxes are all checked; verify-report remains a separate dependency. Do not rename, remove, or invent extra `applyState` values beyond the Jarvis status contract.\n- If all assigned implementation is complete and the validated v2 snapshot coverage agrees with the frozen task manifest and persisted checkboxes, do not edit. Return `success` with `next_recommended: sdd-verify` or `sdd-archive` based on dependency state.\n- Once the gate passes, proceed only on the assigned pending tasks.\n- Use `phaseInstructions` to report the next phase command when returning; do not invent phase routing.\n\n## What to Do\n\n### Step 1: Load Skills\n\nFollow **Section A** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n\n### Step 2: Read Context\n\nBefore writing ANY code:\n\n1. Pass the Native Status Gate (see Status and Workspace Guard) for the assigned work.\n2. Read every applicable artifact path\u002Ftopic from `contextFiles` and `artifactPaths`, using forwarded observation IDs or paths per shared Section B.\n3. Read the specs — understand WHAT the code must do.\n4. Read the design — understand HOW to structure the code.\n5. Read existing code in affected files — understand current patterns.\n6. Check the project's coding conventions from `config.yaml` when available.\n\n#### Step 2a: Enforce Review Workload Decision\n\nBefore implementing, inspect the tasks artifact for `Review Workload Forecast`.\n\nIf the forecast says any of the following:\n\n- `Budget risk: High`\n- `Chained PRs recommended: Yes`\n- `Decision needed before apply: Yes`\n\nThen you MUST confirm the preflight decisions forwarded by the orchestrator resolve the delivery path:\n\n1. **`auto-chain` with a chain strategy**: implement only the assigned work-unit slice, keep scope autonomous, and report the intended PR boundary. Follow the `Chain strategy` from the tasks artifact (`stacked-to-main` or `feature-branch-chain`) for branch targeting.\n2. **`exception-ok` \u002F `size:exception`**: implement the feature as one PR with no further size checks; do not forecast lines or ask about size.\n\nAlso check for `Chain strategy` in the tasks artifact. If present and not `pending`, follow it consistently:\n\n- `stacked-to-main`: each PR targets the previous PR's branch (or `main` after the previous merges).\n- `feature-branch-chain`: PR #1 targets the feature\u002Ftracker branch; later PRs target the immediate previous PR branch. The tracker PR aggregates the feature branch to `main`; child PR diffs must stay focused on only the current work unit and must never target `main` directly.\n\nIf neither delivery decision nor chain strategy is present, STOP before writing code and return `blocked` with: `Preflight decisions missing before apply: the tasks artifact has no resolved size policy or chain strategy. The orchestrator must run the SDD Session Preflight and record the ## SDD Decisions block.`\n\n#### Step 2b: Read Previous Apply-Progress (if exists)\n\nBefore starting work, read `skills\u002F_shared\u002Fapply-progress.md` and use the mode-specific canonical reader: OpenSpec reads the change's canonical `apply-progress.md` snapshot and exactly its referenced `apply-evidence\u002F\u003Cbatch-id>.json` documents; Hive calls `sdd_apply_progress_get` with project and change, then iterates `snapshot.batches` with one `sdd_apply_evidence_get` request per `batch_id`. Validate the snapshot against those batches before using it. Hybrid resolves and independently validates both. Read the current generation, revision, digest, receipt, coverage, and next unpersisted entry; never infer completion from a cumulative observation or a checkbox alone.\n\nContinue only from validated canonical bounded state. Do not merge or rewrite historical evidence. Reconcile current task state against validated coverage, then do not jump to `sdd-verify` until apply progress and task checkboxes agree. The guarded snapshot is the authoritative progress state.\n\n### Step 3: Resolve TDD Mode and Test Command\n\nThe TDD mode forwarded by the orchestrator is the preflight choice for this feature and always wins over cached capabilities. Cached capabilities decide the mode only for legacy launches that forwarded nothing; otherwise they are read only to find the test command.\n\n```\nResolve mode (first match wins):\n├── Prompt contains `STRICT TDD MODE IS ACTIVE` → STRICT TDD MODE\n│   └── Load and follow strict-tdd.md (read the file: skills\u002Fsdd-apply\u002Fstrict-tdd.md)\n├── Prompt contains `TDD MODE: standard` → STANDARD MODE\n│   └── Use Step 4 below; never load strict-tdd.md\n└── Nothing forwarded (legacy launch only)\n    ├── Read cached testing capabilities:\n    │   ├── hive: mcp__hive__mem_search(\"sdd\u002F{project}\u002Ftesting-capabilities\") → mcp__hive__mem_get_observation(id)\n    │   ├── openspec: openspec\u002Fconfig.yaml → strict_tdd_suggestion + detection_reason + testing section\n    │   └── Fallback: check project files directly for a real test command (package.json test script, *_test.go, etc.)\n    ├── Use `strict_tdd_suggestion`; fall back to legacy `strict_tdd` only when the suggestion is absent\n    ├── Suggestion is strict AND a real test command exists → STRICT TDD MODE\n    └── Otherwise → STANDARD MODE\n\nCache the resolved mode for the return summary.\n```\n\n#### Runnable Test Command Gate (Strict TDD Only)\n\nIf Strict TDD Mode is active but no runnable test command exists for the files the assigned tasks touch (for example Deluge code, or a project without a test runner), STOP before the first task and return `blocked` with reason `strict-tdd-unrunnable` and this sentence for the user: `Strict TDD was chosen but these files cannot run under a test runner; choose standard for this feature or provide a test command.` Do not loop writing tests that cannot run, and do not switch to Standard Mode yourself. `[operator]` tasks are executed by the developer and never trigger this gate.\n\n**Key principle**: If Strict TDD Mode is not active, ZERO TDD instructions are loaded. The `strict-tdd.md` module is never read, never processed, never consumes tokens.\n\n#### Hard Gate (Strict TDD Only)\n\nIf Strict TDD Mode is active (from the forwarded TDD mode or, for legacy launches only, self-discovery):\n\n- You MUST record TDD proof as `task_records` in the batch checkpoint, not a Markdown TDD table; the CLI expands each record into structured v2 `EvidenceEntry` values.\n- Each task gets ONE record whose `red` step carries the executed focused failing command and failure summary, whose `green` step carries the passing command and exit code, and whose `triangulate` step is either an executed case or an explicit structural `skip_reason`.\n- Completion coverage may name a task only when its record's evidence actually establishes completion. Do not infer coverage from a narrative table.\n- Record new TDD evidence in the new immutable batch; do not merge or rewrite prior apply-progress evidence. The verify phase rejects missing or incomplete v2 evidence.\n\n**There is no silent fallback.** If you resolved Strict TDD as active, you follow it or you report failure. You do NOT quietly switch to Standard Mode.\n\n### Step 4: Implement Tasks (Standard Workflow)\n\nThis step is used when Strict TDD Mode is NOT active:\n\n```\nFOR EACH TASK:\n├── Read the task description\n├── Read relevant spec scenarios (these are your acceptance criteria)\n├── Read the design decisions (these constrain your approach)\n├── Read existing code patterns (match the project's style)\n├── Confirm every target path is under allowedEditRoots\n├── Write the code\n├── Add the task's `task_records` item (files plus a `verification` step with the command you ran, or only a summary when no command applies); leave the persisted task checkbox unchecked\n└── Note any issues or deviations\n```\n\n### Operator Handoff Tasks\n\nA task marked `[operator]` (for example `- [ ] 2.3 [operator] Upload ...` under `## Operator Handoff`) is executed by the developer, never by you. SDD controls the agent, not the developer: the developer's word in chat is enough.\n\n- **Next pending task is `[operator]`**: Checkpoint any agent work done before the handoff first (Steps 5–6). Then emit the handoff in plain language, one or two sentences saying what to do and which cases to try, return `partial` with reason `operator-handoff`, and STOP. Do not continue with later agent tasks, even when they look independent.\n- **Launched with `OPERATOR_ACK: \u003Ctask-id> — \u003Cdeveloper message>`**: record a `task_records` item `{\"task_id\": \"2.3\", \"operator\": {\"summary\": \"\u003Cdeveloper message>\"}}` through the normal guarded checkpoint, mark the checkbox `[x]` only after `committed`, and resume with the next agent task. The `operator` step carries only the summary: no command, no exit code, and no other step in the same record.\n- **Launched on an unacknowledged `[operator]` task without an ack**: restate the pending handoff in one line and return `partial` with reason `operator-handoff`, asking once whether it is done. That is the only question.\n\nNever ask for screenshots, IDs, or logs, and never verify the step yourself. Never use Zoho MCP servers to check an operator step: they point at our own account, never the client tenant. Strict TDD never applies to `[operator]` tasks.\n\n### Step 5: Persist Progress\n\n**This step is MANDATORY — do NOT skip it.**\n\nCheckpoint ONCE per apply batch, not per task. After every assigned task in the batch is implemented and its evidence is captured, run `jarvis sdd progress checkpoint --root \u003Cchange-root> --request \u003Crequest.json>` a single time. It accepts no positional arguments, plans at most one whole-entry prefix, and commits immutable evidence batches through the guarded writer; every serialized snapshot and batch stays at most 40,000 Unicode runes. Do not use `mcp__hive__mem_save` to write, replace, or recover apply-progress.\n\n##### Canonical v2 checkpoint request\n\nFreeze `tasks` and the `task_records` (the ordered complete entries stream they expand to) before the checkpoint; a continuation reuses them unchanged through a stable base snapshot and cursor. Always send `base` and the expected coordinates from the progress read in Step 2b: they are the optimistic-concurrency guard and are never optional.\n\n| Field | Required value |\n| --- | --- |\n| `project`, `change` | Canonical project and change identifiers. Each protocol identifier is 1–64 characters matching `[A-Za-z0-9][A-Za-z0-9._-]{0,63}`. |\n| `tasks` | The ordered task list parsed from the same frozen `tasks.md`: each item is `{id, text, path}`. `id` and normalized text determine `task_manifest_sha256`; do not manufacture, reorder, or edit tasks. |\n| `base` | `null` for the initial generation; otherwise the exact resolved v2 snapshot from the progress read. |\n| `expected_generation`, `expected_revision`, `expected_digest` | Coordinates of `base`; use zero values and an empty digest only for an initial snapshot. |\n| `task_records` | One record per task this batch covers: `task_id`, `files`, optional `completes` (default `true`), and only the steps that actually ran — `red`, `green`, `triangulate`, `refactor`, `verification` — each `{command, exit_code, summary}`, or a lone `operator` step `{summary}` carrying the developer's acknowledgement of an `[operator]` task; `triangulate` may instead be `{skip_reason}`. Completion rides on the last step that ran (a `skip_reason` triangulation did not run), and that step must pass. |\n| `entry_index`, `entry_id` | `0` with `entry_id` omitted for a new stream; `entry_index: 0` fills the first expanded entry ID. A continuation uses exactly the pair `next.instruction` names. |\n\nOmit `request_id`, `batch_id`, and `stream_sha256`: the checkpoint derives them from the request. Explicit `entries` (whole `EvidenceEntry` values with `entry_id`, `task_ids`, `completes_task_ids`, `kind`, `summary`, `command`, `exit_code`, `outcome`, and `files`) remain accepted but are mutually exclusive with `task_records`. `imported` is internal legacy provenance only; callers MUST NOT supply it.\n\nNever invent coverage: a record names only a task this batch implemented and carries only commands that actually ran. `tasks.md` stays the human-visible task state, never a substitute for v2 evidence; a later task edit changes the manifest digest and requires explicit reconciliation, not a continuation.\n\nThe checkpoint `outcome` is one of `committed`, `continuation_required`, `evidence_item_too_large`, `snapshot_capacity_exhausted`, `stream_preflight_required`, and `checkpoint_consolidation_required`, or a typed conflict, invalid, blocked, or recovery response. Every response carries `next: {action, instruction}`. After the command, follow `next.action` and `next.instruction` only: `continue_stream` is yours to rerun now with the returned cursor (the orchestrator does not relaunch for it); each rerun must advance the cursor, and if it does not, STOP and return `blocked`; `done` and `continue_tasks` end this batch's checkpointing, and every `stop_*` action ends the phase with `code` and `recovery` reported verbatim. Fail closed: if the response has no `next`, or its action is not one named here or in Recovery, STOP and return `blocked` with the raw `outcome`, `code`, and `recovery`. Do not emit free-form lifecycle markers: the validated v2 snapshot status and referenced batches are authoritative.\n\n#### Recovery\n\nRare paths still follow `next`; these notes only name what it covers.\n\n- `run_upgrade_continuation` (`legacy_upgrade_required`): a historical v2 snapshot serialized an explicit all-zero continuation group. Run `jarvis sdd progress upgrade-continuation --root \u003Cchange-root> --request \u003Crequest.json>` with the same request, then rerun the checkpoint from the upgraded snapshot. A legacy Markdown artifact needs no step: its first checkpoint imports it and keeps the legacy source authoritative until that guarded commit succeeds.\n- `stop_consolidate` (`stream_preflight_required`, `checkpoint_consolidation_required`): combine pending evidence into fewer, larger records before binding a new stream. Never modify records for an active frozen continuation.\n- `stop_new_change` (`snapshot_capacity_exhausted`): checkpoint frequency cannot repair a full reference set; stop with apply partial and carry the uncovered task IDs into a new SDD change. A committed `warning` is an early capacity signal: do not start new tiny streams.\n- `retry_identical` (transport loss, `lock_busy`, partial hybrid recovery): retry at most twice; if it still does not commit, STOP and report `code` and `recovery`. Preserve the existing hybrid receipt and rerun the identical request, so the same request ID, batch ID, base, cursor, and byte-identical payload replay. A partial recovery may replay or revalidate the exact request against both backends through their idempotent contracts before accepting acknowledgements. A complete receipt returns without replay. Never change the payload, identity, or authority, and never rewrite confirmed progress.\n- `stop_blocked` (`project_mismatch`): stored progress is signed under a different project than the effective project key. Nothing was written. STOP and report `code` and `recovery`; never re-sign, copy, or rewrite progress under another project key.\n- The low-level `advance` remains a recovery\u002Fcompatibility primitive for an already planned batch and snapshot. Do not ask `advance`, HTTP, or MCP to select prefixes or plan capacity.\n\n### Step 6: Mark Tasks Complete\n\nOnce the batch checkpoint (including any `continue_stream` reruns) has returned `committed`, update the persisted tasks artifact in one edit: change `- [ ]` to `- [x]` for exactly the tasks the committed snapshot coverage names, and nothing else. Never mark a task `[x]` without committed coverage.\n\n```markdown\n## Phase 1: Foundation\n\n- [x] 1.1 Create `internal\u002Fauth\u002Fmiddleware.go` with JWT validation\n- [x] 1.2 Add `AuthConfig` struct to `internal\u002Fconfig\u002Fconfig.go`\n- [ ] 1.3 Add auth routes to `internal\u002Fserver\u002Fserver.go`  ← still pending\n```\n\n### Step 7: Return Summary\n\nBefore returning, re-read the persisted tasks artifact and confirm every task you report as completed is marked `[x]` there. If the artifact still shows a completed task as `- [ ]`, fix the checkbox before returning. Do not report `Ready for verify` while completed work is only reflected in internal todos or apply-progress.\n\nReturn to the orchestrator:\n\n```markdown\n## Implementation Progress\n\n**Change**: {change-name}\n**Mode**: {Strict TDD | Standard}\n\n### Completed Tasks\n- [x] {task 1.1 description}\n- [x] {task 1.2 description}\n\n### Files Changed\n| File | Action | What Was Done |\n|------|--------|---------------|\n| `path\u002Fto\u002Ffile.ext` | Created | {brief description} |\n| `path\u002Fto\u002Fother.ext` | Modified | {brief description} |\n\n{IF Strict TDD Mode → include the safety-net baseline and each task's RED\u002FGREEN\u002FTRIANGULATE\u002FREFACTOR outcomes from strict-tdd.md}\n\n### Deviations from Design\n{List any places where the implementation deviated from design.md and why. If none, say \"None — implementation matches design.\"}\n\n### Issues Found\n{List any problems discovered during implementation. If none, say \"None.\"}\n\n### Remaining Tasks\n- [ ] {next task}\n- [ ] {next task}\n\n### Workload \u002F PR Boundary\n- Mode: {single PR | chained PR slice | stacked PR slice | size:exception}\n- Current work unit: {unit name or \"N\u002FA\"}\n- Boundary: {what this apply batch starts from and ends with}\n- Estimated review budget impact: {brief note}\n\n### Status\n{N}\u002F{total} tasks complete. {Ready for next batch \u002F Ready for verify \u002F Waiting for operator task X \u002F Blocked by X}\n```\n\n## Rules\n\n- ALWAYS read specs before implementing — specs are your acceptance criteria\n- ALWAYS follow the design decisions — do not freelance a different approach\n- ALWAYS match existing code patterns and conventions in the project\n- STOP on any Native Status Gate failure; do not infer readiness from conversation alone\n- In `openspec` mode, mark tasks complete in `tasks.md` only after the guarded checkpoint commits matching task coverage\n- Before returning, re-read the persisted tasks artifact and ensure completed tasks are visibly marked `[x]`; internal todos are not completion evidence\n- If you discover the design is wrong or incomplete, NOTE IT in your return summary — do not silently deviate\n- If a task is blocked by something unexpected, STOP and report back\n- If workload forecast requires a decision and none was provided, STOP before writing code\n- When applying a chained\u002Fstacked PR slice, keep the batch autonomous: one deliverable scope, verification included, and clear rollback boundary\n- When applying `size:exception`, state it explicitly in apply-progress and the return summary\n- NEVER implement tasks that were not assigned to you\n- Skill loading is handled in Step 1 — follow any loaded skills strictly when writing code\n- Apply any `rules.apply` from `openspec\u002Fconfig.yaml`\n- If Strict TDD Mode is active (Step 3), load `strict-tdd.md` and follow its cycle INSTEAD of Step 4\n- When Strict TDD is active, the `strict-tdd.md` module's rules OVERRIDE Step 4 entirely\n- Return envelope per **Section D** from `skills\u002F_shared\u002Fsdd-phase-common.md`.\n",{"name":5,"scope":27,"license":14,"metadata":38,"description":7,"display_name":42,"user-invocable":34,"disable-model-invocation":41},{"author":39,"version":40,"delegate_only":41},"gentleman-programming","3.0",true,"SDD Apply","master","bc678bf913c485d813d5ca10defd609ae7f83980","jarvis-cli\u002Fembed\u002Fskills\u002Fsdd-apply",0,"https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs","https:\u002F\u002Fgithub.com\u002FThrasno","2026-10-22 13:14:50",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":41},[52,55,58],{"tool":53,"command":54},"npx","npx skills add Thrasno\u002Fjarvis-ai-devs --skill sdd-apply",{"tool":56,"command":57},"bunx","bunx skills add Thrasno\u002Fjarvis-ai-devs --skill sdd-apply",{"tool":59,"command":60},"pnpm","pnpm dlx skills add Thrasno\u002Fjarvis-ai-devs --skill sdd-apply","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fsdd-apply\u002FSKILL.md",[63,69],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"apply-progress.md","REFERENCE","参考文档",82,"https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fsdd-apply\u002Fapply-progress.md",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"strict-tdd.md",12200,"https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fsdd-apply\u002Fstrict-tdd.md",[74,101,125,143,160,172],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":86,"publishedAt":33},"01M719QM8QT44VXHVYQNWCSV7F","work-unit-commits","Plan commits as reviewable work units. Trigger: implementation, commit splitting, chained PRs, or keeping tests and docs with code.","Apache-2.0","https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fwork-unit-commits\u002FSKILL.md",[81],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[87,88,89,90,91,28,92,93,94,95,31,96,97,98,99,100],"unit","commits","work","work unit commits","docs","implementation","plan","units","with","commit","code","tests","prs","as",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":112,"publishedAt":33},"01M719QHF0S5A6FZ978BKWEQQN","skill-registry","Create or update the skill registry for the current project. Scans user skills and project conventions, writes .jarvis\u002Fskill-registry.md, and saves to Hive if available. Trigger: When user says \"update skills\", \"skill registry\", \"actualizar skills\", \"update registry\", or after installing\u002Fremoving skills.","https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fskill-registry\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[113,114,25,28,115,116,117,31,118,119,120,121,122,123,124],"registry","skill registry","project","for","hive","jarvis","user","update skills","conventions","update","project conventions","create",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":33},"01M719QFP1J8RPDTKS5N2HWGTN","skill-improver","Trigger: improve skills, audit skills, refactor skills, skill quality. Audit and upgrade existing LLM-first skills safely.","https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fskill-improver\u002FSKILL.md",[131],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},[133,134,135,136,137,138,28,139,31,140,141,142],"skill improver","audit skills","improve","upgrade","Existing","improve skills","refactor","audit","first","quality",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":33},"01M719QDDGG7JNW8S3GD9X61B4","skill-creator","Trigger: new skills, agent instructions, documenting AI usage patterns. Create LLM-first skills with valid frontmatter.","https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fskill-creator\u002FSKILL.md",[149],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},[151,152,153,31,154,155,156,28,157,141,124,95,158,159],"skill creator","creator","usage","frontmatter","patterns","new","instructions","valid","agent instructions",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":33},"01M719QBP5KAKA8F5YX1XNE5GX","sdd-verify","Verify implementation against specs with structural and behavioral checks. Trigger: When verifying implementation","https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fsdd-verify\u002FSKILL.md",[],[167,18,168,24,169,29,170,28,27,25,171,92,95,31],"verify","sdd verify","verify implementation","structural","behavioral",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":33},"01M719Q9XES651J6EXZYE1BJDC","sdd-tasks","Break down a change into a concrete, ordered implementation checklist. Trigger: When creating task lists","https:\u002F\u002Fgithub.com\u002FThrasno\u002Fjarvis-ai-devs\u002Fblob\u002Fmaster\u002Fjarvis-cli\u002Fembed\u002Fskills\u002Fsdd-tasks\u002FSKILL.md",[],[26,18,179,180,181,92,182,31,183,184,25,24,29,28,27,185],"sdd tasks","change","checklist","break","task","break down","down"]