strict-spec-driven (dsh-strict-spec)

strict-spec-driven

English | 中文

Documentation: Quick Start · Architecture · Architecture Quickstart · UI Design Quickstart · Roadmap Quick Start · Roadmap Guide · AGENTS

strict-spec-driven is a YAML-first spec-driven development workflow. It provides the spec-driven lifecycle (propose → apply → verify → skill-driven code review → archive) with Agent Skills integration, converting workflow artifacts — specs, changes, roadmap, tasks, questions — into strict YAML schemas enforced by deterministic scripts.

SKILL.md files remain Markdown because that is the Agent Skills packaging format requirement. What changes is the artifact format those skills generate and consume.

Directory Structure

Directory	Role
.strict-spec-driven/	Active strict workflow state
.strict-spec-driven/changes/	Active change directories
.strict-spec-driven/changes/archive/	Archived changes
.strict-spec-driven/roadmap/	Strict YAML roadmap artifacts
.strict-spec-driven/roadmap/planned-changes/	Preferred standalone roadmap work-item files
.strict-spec-driven/specs/	Strict YAML main spec files
templates/strict-spec-driven/schemas/	Bundled strict YAML schema files
examples/strict-spec-driven/	Repository reference minimal valid YAML examples
templates/strict-spec-driven/scaffold/	Scaffold templates used by init and propose
skills/	Strict skill packages (strict-spec-* and strict-roadmap-*)
src/	TypeScript CLI source
dist/	Compiled output (generated by build)

This repository keeps a single active workflow directory, .strict-spec-driven/. A .spec-driven/ directory is only relevant as migration input for other projects that still use the legacy Markdown workflow — see Migration Boundaries. This repository completed that migration and retains no root .spec-driven/ directory.

Upgrading

The nine single-command roadmap skills were merged into one parameterized skill, and /strict-roadmap-reorder was then split back out because it is invoked often enough to earn a dedicated entry point. /strict-roadmap-pause, /strict-roadmap-resume, /strict-roadmap-defer, /strict-roadmap-refine, /strict-roadmap-move, /strict-roadmap-reopen, /strict-roadmap-archive, and /strict-roadmap-sync no longer exist as skill packages, and no alias package forwards them, so an invocation of one of those slash commands now fails rather than silently doing the right thing.

The five skills /strict-spec-sop, /strict-spec-harness-init, /strict-spec-harness-session, /strict-spec-migrate, and /strict-spec-propose-from-roadmap were removed the same way. The sop-* commands and migrate are unchanged — they keep their names, arguments, and behavior, so those capabilities remain available through strict-spec-cli — and roadmap-backed proposals are scaffolded by /strict-roadmap-recommend when the next change is chosen across the whole roadmap, or by /strict-spec-propose when the request names one milestone.

Each retired roadmap name is now an explicit operation of one skill, except reorder, which has its own skill again:

Retired slash command	Replacement
/strict-roadmap-pause	/strict-roadmap-transition pause
/strict-roadmap-resume	/strict-roadmap-transition resume
/strict-roadmap-defer	/strict-roadmap-transition defer
/strict-roadmap-refine	/strict-roadmap-transition refine
/strict-roadmap-reorder	/strict-roadmap-reorder (its own skill again)
/strict-roadmap-move	/strict-roadmap-transition move
/strict-roadmap-reopen	/strict-roadmap-transition reopen
/strict-roadmap-archive	/strict-roadmap-transition archive
/strict-roadmap-sync	/strict-roadmap-transition sync

The underlying CLI commands are unchanged: roadmap-pause, roadmap-sync, and the rest keep their names and arguments. Only the skill packaging changed.

The harness capability was removed entirely, because declaring, starting, stopping, and logging project services lies outside a spec-driven workflow tool. The harness-edit, harness-infer, harness-doctor, harness-plan, harness-start, harness-stop, harness-status, harness-logs, harness-scripts, and harness-session commands are no longer registered and fail as unknown commands; init no longer scaffolds harness.yaml; and the MCP server no longer offers harness tools, the strict://harness/declaration resource, or the strict_harness_investigation prompt. No command reads the files an earlier version left behind, so .strict-spec-driven/harness.yaml, .strict-spec-driven/harness-sessions/, and generated scripts/harness-* wrappers can be deleted by hand.

If you installed the skills before this change, reinstall them so the retired packages are removed from your skill directory and the merged one is present:

bun run install-strict-skills

Strict Command Surface

CLI: strict-spec-driven

Subcommands available after bun run build (or via installed node dist/strict-spec-cli.js):

Subcommand	Purpose
init	Scaffold .strict-spec-driven/ in a project
propose <name>	Create a new strict change scaffold
apply <name>	Complete the next pending task in a change
verify <name>	Validate a change's artifacts and task completion
archive <name>	Merge delta specs and move change to archive
ship <name>	Read archived change summary for git commit handoff
migrate	Convert .spec-driven/ bootstrap state to .strict-spec-driven/
list	Report active and archived changes
modify [<name>]	List editable artifact paths for a change
cancel <name>	Remove an active change (archived changes are protected)
maintenance	Run configured repository maintenance checks
roadmap-status	Validate and report strict roadmap state
roadmap-overview	Print a human-readable roadmap overview table
roadmap-sync [--fix-names]	Reconcile and regenerate strict roadmap index; --fix-names renames misnamed planned-change files to canonical names
roadmap-generate milestone	Create or update a strict roadmap milestone through structured named arguments
roadmap-generate planned-change	Create or update a standalone planned-change artifact at its canonical CLI-computed filename
validate-skills	Validate strict skill packaging metadata and command symlinks
schema-list	List bundled strict schema asset keys
schema-show <name>	Print a bundled strict schema asset
sample-list	List bundled strict YAML sample asset keys
sample-show <name>	Print a bundled strict YAML sample asset
template-list	List bundled template and schema asset keys
template-show <key>	Print a bundled template or schema asset

Installation

Run install.sh on Unix-like hosts or install.ps1 on Windows. The installer installs the strict skills package and the strict-spec-cli command, and bootstraps its own dependencies: bun is installed automatically when missing, project dependencies are installed with bun install when node_modules is absent, and the global skills CLI runs through bunx.

On Unix-like hosts, install.sh installs strict-spec-cli via npm install -g . when npm/Node is available and the npm global prefix is writable — the command lands in npm's global bin directory (already on PATH), so it is usable immediately with no PATH edits and no large native executable. When npm is unavailable, or npm install -g . fails on permissions (a system-managed global prefix that would need sudo), it falls back to building a native strict-spec-cli executable into a user-level bin directory (~/.local/bin by default, or $STRICT_SPEC_BIN_DIR / $XDG_BIN_HOME). On a successful npm install it also removes any native executable left by a prior fallback install, so only one strict-spec-cli resolves on PATH.

On Windows, install.ps1 installs strict-spec-cli via npm install -g . when npm/Node is available — the command lands in npm's global bin directory (already on PATH), so it is usable immediately in any terminal with no PATH edits. When npm is unavailable, it falls back to building a native strict-spec-cli executable and placing it in a user-level bin directory; in that case it adds the bin directory to the current user's PATH by default, so open a new terminal before invoking strict-spec-cli by name outside the installer session. Use -NoPathUpdate to skip PATH changes, or -KeepPathOnUninstall to leave the PATH entry in place when uninstalling.

Both installers also remove the skills this repository has retired. Installing only ever adds packages, so upgrading over an older checkout used to leave every deleted skill on the machine, still offering a slash command that no longer resolves. The retired names are recorded in retired-skills.json — they cannot be derived from a name prefix, because some retired packages predate the current naming families — and each install hands that list to the skills CLI, which removes them from every agent directory it manages. Uninstalling names both the packaged and the retired skills for the same reason: given no names, the skills CLI opens an interactive selection menu, which a non-interactive session answers with nothing at all.

Skills: strict-spec-*, strict-roadmap-*, and strict-scene-*

Skills are Agent Skills packages installed via install.sh. Invoke them in Claude Code using their slash-command names:

Strict spec workflow skills (strict-spec-*):

Slash command	Purpose
/strict-spec-init	Initialize strict workflow in a project
/strict-spec-propose	Propose a new change, standalone or scoped to a named roadmap milestone
/strict-spec-apply	Implement tasks in a change
/strict-spec-verify	Verify a change is complete
/strict-spec-review	Evidence-based code-quality review of a change
/strict-spec-archive	Archive a completed change
/strict-spec-auto	End-to-end automated change lifecycle
/strict-spec-ship	Ship an archived change via git commit
/strict-spec-brainstorm	Brainstorm a change idea before proposing
/strict-spec-modify	Modify an existing change's artifacts
/strict-spec-spec-edit	Edit main spec files directly
/strict-spec-sync-specs	Synchronize specs with code drift
/strict-spec-design	Author or refresh the design system artifact and render DESIGN.md
/strict-spec-design-sync	Reconcile the design system artifact with UI code drift
/strict-spec-maintenance	Run repository maintenance workflow

Strict roadmap skills (strict-roadmap-*):

Slash command	Purpose
/strict-roadmap-recommend	Recommend the next planned change from the roadmap
/strict-roadmap-review	Review one incomplete roadmap milestone and apply fixes
/strict-roadmap-plan	Create or restructure the roadmap
/strict-roadmap-transition	Perform one roadmap state transition: pause, resume, defer, refine, move, reopen, archive, or sync
/strict-roadmap-reorder	Change one active milestone's position in roadmap order

Strict scene skills (strict-scene-*):

Slash command	Purpose
/strict-scene-edit	Author or correct a scene: actors, preconditions, main flow, exception flows, and each step's coverage

The roadmap docs describe the preferred split-file collaboration model: keep milestone files and INDEX.yaml low churn, store day-to-day roadmap work in .strict-spec-driven/roadmap/planned-changes/, rerun roadmap-sync after merges or archive handoff, and treat external tracker references as optional context rather than required source of truth.

Standalone planned-change files use a canonical, CLI-owned filename: <milestone-id>-<planned-change-id>.yaml (when the planned-change id already starts with the milestone id, the prefix is not duplicated). Filename order is semantically meaningful — roadmap-recommend selects the first eligible planned change in filename order — so an active planned-change file with a non-canonical basename is a blocking validation diagnostic in roadmap-status and roadmap-sync (archived planned-change files are exempt). Create and update planned-change artifacts through roadmap-generate planned-change, which computes the filename itself, and repair misnamed legacy files with roadmap-sync --fix-names; never pick planned-change filenames by hand.

Requirement Interrogation

Every path that starts from a human request — /strict-spec-brainstorm, /strict-spec-propose, /strict-spec-bugfix, /strict-spec-auto — interrogates the need before the change-intake gate interrogates the solution. It runs first because a well-scoped change built against a misread need is still the wrong change.

Requirement answers are never taken from repository evidence. Code shows what the system does; it cannot show what a person wants. Only the requester's own words — including what they already said in the request — or replayed roadmap planned-change and milestone detail may answer them.

The first generate <change-name> questions ... invocation seeds five canonical questions into questions.yaml as open entries, so a newly authored change is blocked until they are answered:

Question id	Asks	A sufficient answer contains
requirement-problem	What is concretely going wrong today, and for whom?	Who is affected, what they do today instead, and how often — without naming a feature
requirement-outcome	What observable difference proves it is solved?	What a person will see or no longer have to do, checkable from outside the system
requirement-trigger	Why now — what forced this?	The concrete event, deadline, incident, or cost, or an honest statement that nothing forced it
requirement-non-goals	What must explicitly not change?	The nearby behavior that must survive untouched, and who relies on it
requirement-interpretation	Which reading is intended?	The intended reading stated plainly enough to rule the others out

Each seeded entry carries its own explanation — why it is asked, what a sufficient answer contains, a worked example, and what the answer changes — so answering does not require prior knowledge of this workflow.

Answers are recorded with attribution. --answered-by human and --answered-by roadmap satisfy the gate; --answered-by assumption records that the agent supplied the answer without human confirmation and blocks ready until a human decides:

strict-spec-cli generate <change-name> questions --resolve requirement-problem \
  --answer "..." --answered-by human

ready emits requirement_intake diagnostics and exits non-zero while any canonical question is missing, still open, answered by assumption, or resolved with no attribution at all. No questions-generator flag removes requirement-kind entries.

Enforcement splits into three layers, and it is worth being clear about which is which:

Layer	Mechanism	Guarantees
CLI	first questions authoring, ready diagnostics	The questions exist, are answered, and carry attribution
Skills	The asking technique in the four skill prompts, enforced by validate-skills	The questions are asked one at a time, carrying a concrete guess, explained before they are posed, with pushback that states its reason
Neither	—	Whether the agent genuinely interrogated. This is judgment and cannot be checked; recording answered_by: assumption makes an evasion visible rather than preventing it

Scene-First Requirement Routing

Requirement interrogation establishes the need. Scene-first routing establishes the situation the need occurs in, and it runs between the two gates above and below, because a requirement set written without it has holes that are invisible in the requirements themselves.

/strict-spec-propose, /strict-spec-brainstorm, and /strict-spec-auto ask four questions in every proposal, whatever the change turns out to be: who acts and what each actor does, what must already be true before the main flow begins, what happens step by ordered step when nothing goes wrong, and what can go wrong, what triggers each exception flow, and what happens then. An author asked for requirements immediately skips all four and never notices, because nothing in a requirement records the question that was never asked.

The scene is mandatory as a question and optional as an artifact. When the change touches user-observable behavior, the scene is written down — as a delta scene under the change, before the delta spec, so each requirement is derived from a flow step rather than recalled. When the change is purely technical — a refactor, build or test tooling, repository maintenance, an architecture constraint, a script, or skill guidance — there is no actor flow to describe, and the skill records why no scene applies instead of inventing one.

Every flow step declares either the requirements that cover it or an explicit reason it is deliberately covered by none, and one step may name covering requirements across several spec areas. Once a change carries a delta scene, ready and verify exit non-zero on a step naming neither, and the diagnostic names the runnable command that records the coverage:

strict-spec-cli scene-status --scene <scene-id>
strict-spec-cli generate <change-name> delta-scene --target-scene <scene-id> \
  --operation MODIFIED --step <step-id> --action "..." \
  --covered-by <spec-id>:<requirement-id>

Checking is triggered by the presence of a scene, never by the presence of a spec. A project that records no scene sees no new diagnostic and no new required field, so adopting scenes is incremental and upgrading the CLI is not a breaking change. Scenes live under .strict-spec-driven/scenes/<area>/, are edited outside a change with /strict-scene-edit, and are merged into that store by archive when a change carries delta scenes.

Change Intake Question Gate

Proposal-oriented skills run a short change-intake gate after the requirement interrogation above and before implementation. They first answer the checklist from available evidence: the active request, roadmap planned-change details, strict specs, technical standards, existing change artifacts, repository search results, and deterministic CLI output. If that evidence answers the checklist, the workflow does not ask the human again.

The checklist covers what is changing, why it matters, what is included, what is left out, what existing behavior must stay the same, where the work likely lives, how it will be proven, relevant risks or dependencies, and which technical rules apply.

When a required answer is still missing after discovery, the skill records an entry in questions.yaml.open with concrete context, impact, and a recommended answer or options. Implementation handoff intentionally stops while questions.yaml.open contains required entries; the answers must be resolved into questions.yaml.resolved before /strict-spec-auto or /strict-spec-apply continues.

Human-facing question text, context, recommendations, options, and summaries use .strict-spec-driven/config.yaml preferred_human_language unless the active user message asks for a different language. Stable technical values such as question ids, artifact fields, schema names, command names, and file paths remain language-neutral identifiers.

MCP Server: strict-spec-driven-mcp

The built package also includes a local MCP server for MCP-compatible clients. It is a stdio-only integration and always requires an explicit project root:

{
  "mcpServers": {
    "strict-spec-driven": {
      "command": "node",
      "args": [
        "/path/to/strict-spec-driven/dist/scripts/strict-spec-driven-mcp.js",
        "--project",
        "/path/to/your/project"
      ]
    }
  }
}

Registering the server with mcp-install

Instead of editing client config by hand, the mcp-install command builds the package and registers the server into supported clients:

strict-spec-cli mcp-install --client claude-code --client codex --scope project
strict-spec-cli mcp-install --client all --project /path/to/your/project
strict-spec-cli mcp-install --client json --config ./.mcp.json

• --client accepts claude-code, codex, opencode, copilot, json, or all, and may be repeated. all expands to the four named clients; json is opt-in because it requires an explicit --config path.
• claude-code and codex are registered through their official CLIs (claude mcp add, codex mcp add); when that CLI is not on PATH the client is skipped with a diagnostic rather than hand-writing its config.
• opencode (mcp key), copilot (.vscode/mcp.json servers key), and json (mcpServers key, written to --config) are merged idempotently in each client's native format, preserving existing entries.
• --scope selects project (default) or user config targets, --project sets the registered project root (defaults to the current directory), and --name overrides the entry name (default strict-spec-driven).

The MCP server preserves the CLI and Agent Skills as the authoritative workflow implementation. It exposes strict workflow artifacts as resources, delegates tools to the strict CLI under the configured project root, and provides prompts that guide existing strict skills.

Representative resources:

• strict://workflow/state
• strict://changes/{change}/proposal
• strict://specs/{specId}
• strict://roadmap/planned-changes/{plannedChangeId}

Representative read-only request: ask the MCP client to check strict workflow status. The expected tool call is check_workflow_state, which delegates to strict-spec-cli check-workflow-state and does not mutate project files.

Representative prompt request: ask for strict_review_change with { "change": "my-change" } to get review guidance that keeps verification, direct code review, and complete regression evidence in the workflow.

Mutating tools require explicit confirmation. Every mutating tool enforces a server-side gate: the call must include confirm: true, or the MCP server refuses it with a confirmation-required diagnostic and never invokes the strict CLI. Tools such as propose_change, generate_change_artifact, mark_next_task_complete, roadmap_sync, and archive_change write strict workflow state. archive_change is release-class because it merges specs and reconciles roadmap state, and cancel_change is destructive because it permanently deletes an active change. Tool failures (invalid input, missing confirmation, or a non-zero delegated command) are returned as MCP protocol errors while still carrying the diagnostic JSON envelope.

Template resources are enumerable: an MCP client can list resources to discover the concrete strict:// URIs for existing changes, specs, roadmap milestones, planned changes, and tech standards instead of having to know each identifier in advance.

CLI-Only YAML Authoring

CLI code owns YAML shape and filesystem mutation for every repository-owned strict artifact. A supported AI workflow expresses each creation, update, named-entry removal, and whole-artifact deletion through the owning strict CLI command with named semantic arguments; it never supplies raw YAML payloads, heredocs, temporary payload files, arbitrary output paths, or direct file edits. Read-only YAML inspection is always allowed, and humans keep full manual autonomy — the policy governs AI mutation workflows, not people.

The canonical statement of the protocol is emitted by the CLI itself:

strict-spec-cli yaml-authoring-protocol
strict-spec-cli yaml-authoring-protocol <artifact-kind>

Its seven ordered steps:

1. Read the owning command's machine-readable help — <owning-command> --help --json. Help is the contract; a remembered flag is not.
2. Resolve the target artifact's schema — schema-list, then schema-show <schema-key>.
3. Inspect the registered minimal example — sample-list, then sample-show <example-key>. The example is read-only reference, never copied into place as a starting file.
4. Translate confirmed facts into documented named arguments — every value must trace to the request, the schema, or repository evidence.
5. Execute the owning command with those arguments.
6. Inspect the structured result and changed paths — a result reporting incompleteness is a successful write with more work to do, not a failure to retry.
7. Run the artifact's validation command — which catches cross-file consequences a single mutation's own result cannot report.

The protocol ends with one boundary: when a required command, argument, or artifact kind is unavailable, stop and report the missing capability — the operation that could not be completed, the artifact kind and target, the missing command or argument, and the discovery commands already consulted. There is no fallback; an unavailable command is a reason to stop, not a reason to improvise.

Discover the full mutation surface per artifact family with yaml-surface-list and yaml-surface-show <kind>, which report each family's supported operations, owning commands, refused operations, and cross-file effects. Artifact writes are lazy and atomic: the first successful generate call creates the change container and artifact together, no placeholder files are ever written, and a rejected write leaves pre-existing state untouched.

Schema and Example Assets

Bundled strict YAML schema files live under templates/strict-spec-driven/schemas/. Minimal valid examples live under examples/strict-spec-driven/ as repository reference assets. These are separate from .strict-spec-driven/ workflow state.

The schema registry at templates/strict-spec-driven/schemas/schema-registry.yaml indexes all supported strict artifact families.

The CLI also embeds bundled schema and scaffold assets so installed skills do not need a per-skill templates symlink. Agents can inspect embedded contracts with:

strict-spec-cli schema-list
strict-spec-cli schema-show change-proposal
strict-spec-cli sample-show change-proposal
strict-spec-cli template-show scaffold/config.yaml

Shared Schema Cache

On startup, every strict-spec-driven CLI command (except --help/-h) and the MCP server export the bundled schema files and strict YAML sample files to a shared on-disk cache at ~/.strict-spec-schemas/, so agents can resolve an artifact's schema_file path and schema example_ref paths against one well-known root without per-project templates or examples directories. The cache holds the schema files under templates/strict-spec-driven/schemas/, the sample files under examples/strict-spec-driven/, and a manifest.yaml recording the exported version; it is refreshed automatically when bundled schemas or samples change or a cached file is missing or modified, and it is always safe to delete — the next run recreates it. Set the STRICT_SPEC_SCHEMA_CACHE_DIR environment variable to relocate the cache root. If the cache cannot be written, the command continues with bundled assets and prints a warning naming the resolved cache path. An artifact's declared schema_file path resolves beneath this cache root, and a schema's example_ref paths resolve beneath the cached examples tree; installed skills never assume a source-repository templates or examples directory.

Standard Operating Procedures

Schema-validated standard operating procedures live under .strict-spec-driven/sops/ and are CLI-owned YAML. Author and maintain them through named arguments — sop-create for a new procedure (--title, --category, --purpose, --trigger, steps, roles, escalations, exceptions), sop-edit for field and named-entry updates and removals, and sop-validate to validate one or all procedures against the SOP schema. Inspect read-only with sop-list, sop-show, sop-category-list, and sop-category-show; discover the artifact contract with schema-show sop and schema-show sop-category.

strict-spec-cli sop-create --title "Release rollback" --category release \
  --purpose "..." --trigger "..." --scope-in "..." --success "..." \
  --prerequisite "..." --exception-condition "..." --exception-handling "..." \
  --step-id assess --step-actor operator --step-action "..." --step-expected "..."
strict-spec-cli sop-edit <sop-id> --step-id verify --step-actor operator \
  --step-action "..." --step-expected "..."
strict-spec-cli sop-validate

Each category enforces its own required sections — sop-category-show <id> names them before you author.

Migration Boundaries

The strict-spec-cli migrate subcommand converts supported legacy .spec-driven/ Markdown artifacts into .strict-spec-driven/ YAML artifacts. The source .spec-driven/ directory is not modified. Unsupported or ambiguous legacy shapes are reported as manual follow-up items in the migration report.

After migration, .strict-spec-driven/ is the active workflow state. .spec-driven/ remains as bootstrap or legacy history and is not treated as a valid strict workflow target.

dsh Document Viewer Plugin

plugins/dsh-strict-spec/ holds dsh-plugin-strict-spec, a read-only DeepSeek Harness plugin that browses a workspace's .strict-spec-driven/ documents in the web client and the Desktop app. See its README for the one-command install from npm (dsh plugin --profile web add dsh-plugin-strict-spec), the link: and locally packed tarball development paths, and the supported dsh releases. The package is published to npm under the Apache-2.0 license.

Self-Hosting Status

This repository is self-hosted on the strict workflow. .strict-spec-driven/ is the single active workflow state, containing the active strict specs, roadmap, and change history. Migration from the legacy .spec-driven/ workflow is complete, and no root .spec-driven/ directory is retained.

Development

Prerequisites: Bun is the runtime and package manager (the installer installs it automatically when missing). Node.js is only needed for the node-based commands (bun run validate-skills, the MCP server) — not for installation.

Build:

bun run build

Compiles src/ to dist/ via TypeScript and copies templates/ and scripts/ into dist/.

Test:

bun test/run.ts

Runs the test suite against compiled dist/ output.

Git hooks (one-time per clone):

git config core.hooksPath .githooks

Enables the pre-commit freshness gate: commits touching bundle inputs (src/, templates/, package.json, bun.lock) are rebuilt and rejected when the committed dist/scripts bundles or src/embedded-templates.ts are stale, since git-dependency consumers install the pre-built bundles as committed.

Validate skills:

bun run validate-skills

Validates all strict skill packages for metadata, command references, and required command script access.

Conventions:

• Use a structured YAML parser — never ad-hoc string processing for core artifact data.
• Spec changes should be reflected in .strict-spec-driven/specs/ before implementation.
• Run bun run build && bun test/run.ts after any source change.
• Read existing code before modifying it; implement only what the current task requires.