Skip to content

context.md

Latest commit

 

History

History
88 lines (64 loc) · 4.78 KB

context.md

File metadata and controls

88 lines (64 loc) · 4.78 KB
Raw

Tasks

Task-workdir skills receive that directory explicitly, except $init-task-workdir, which resolves its new target from an explicit task id and slug.

Operation bindings

When an active task resolves, supply the applicable skill or operation with concrete content or paths for applicable bindings:

  • 010-task-brief.md -> requirements input
  • 030-solution-brief.md or 030-implementation-design.md -> design-context input
  • todo.md -> progress input or progress output
  • 020-code-anchors.md -> existing code-anchors input or code-anchors output
  • 020-api-current.* -> current API-description input or output
  • 030-api-new.* -> target API-description or API-contract input or output
  • 030-test-cases-new.md -> existing cases input or designed-case output

Resolve only bindings relevant to the requested operation. Pass each resolved content value or concrete path directly as a semantic input or caller-authorized output destination. Generic skills do not infer these mappings.

Work State

When an active task resolves, maintain <task-dir>/work-state.md as the current continuation checkpoint.

After required context loading and before task investigation or other substantive work for a request that requires mutations, create it if absent and record a concise, concrete Current objective. After meaningful mutating work, update it before finishing the request, including after partial work.

Rewrite it to describe the latest useful continuation state rather than appending an execution journal. Update or clear Current objective, record the resulting current state and last materially completed work, and include the immediate next point, unresolved blockers, relevant verification commands and results, and concrete paths or execution state only when useful for resumption.

Do not update it for purely read-only work. Do not duplicate requirements or solution/design content, and keep the boundary todo.md = planned/completed task work and work-state.md = current execution/handoff state.

Task Memory

Task memory is stored under ./devlog relative to the repository root.

Active task memory directories use the <task-num> or <task-num>-<slug> naming pattern.

Completed and paused tasks live under done and on-hold respectively.

Unless the prompt explicitly says otherwise, add new task documentation and context files to the task directory.

File Codes

Each file in a task directory should have a filename prefix that identifies its artifact type:

  • 010 - task statement. Requirements in brief form, additional resources with examples, datasets, and similar inputs.
  • 020 - current-state description. Artifacts that describe the current state, such as current API, current test cases, current architecture, and similar context.
  • 030 - target-state description. Artifacts that describe the target solution, such as the solution brief, target API, new test cases, target architecture, and similar design context. Keep 030-solution-brief.md at the overall solution direction and system-level tradeoffs. Keep 030-implementation-design.md as the current accumulated design across later increments. Structure it by implementation level, not by increment, test case, or kind of code. Use only applicable non-empty sections, in this order:
    • Data model. Include a nested persistence model only when the used framework cannot map the correct domain model cleanly.
    • REST API. Include nested input and output DTOs when applicable.
    • Component diagram as a UML object diagram of runtime objects.
    • Operation call-structure diagram.
    • TestApi. When a selected case requires new design, update only the applicable sections and do not name or narrate the case or increment. Add only newly required design instead of moving existing task content into the artifact.
  • 040 - implementation working files.

Standard Task Files

Every new task should have these standard files:

  • 010-task-brief.md - task statement.
  • 030-solution-brief.md - brief for the overall solution direction.
  • work-state.md - current continuation checkpoint.
  • todo.md - list of completed and pending subtasks.

Existing tasks without work-state.md remain valid; create it when work state first needs to be persisted.

Depending on the task type and nature, a task may also have:

  • 020-code-anchors.md - links to relevant source-code files. Target source files to change, example files, tests for the changed code, files for adding new tests, and similar code anchors.
  • 020-api-current.md - current REST API in humanistic-api/v1 format.
  • 020-test-cases-current.md - current relevant test cases.
  • 030-api-new.adoc - target REST API.
  • 030-test-cases-new.md - new test cases.
  • 030-implementation-design.md - current accumulated implementation design structured by the implementation levels above.