No skill writes an entity into a GitHub issue body or an Azure DevOps work item

Open
  • Is something wrong?
#117 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
markdown, python
Domain
documentation, tooling

Research direction

Start with the three living-doc-create-* skills under agentic/.claude/skills/*/SKILL.md and the draft format they emit into validate_entity.py and catalog.json, then compare with living-doc-scenario-creator and living-doc-pageobject-scan, which already write canonical headers for .feature files. The first step is a design decision: whether the layer renders ## Parent Feature and ## Acceptance Criteria issue bodies itself or relies on a per-project Storage Profile template. Done means that decision is recorded and a rendering skill or step exists with an eval.

Written by the indexing model from the issue text.

Description

type:tech-debt
Description of Technical Debt

The three living-doc-create-* skills emit a JSON draft, the input to validate_entity.py and catalog.json. Canon
text is written only for .feature files: living-doc-scenario-creator writes the User Story and Functionality
headers, and living-doc-pageobject-scan the UI Feature header. For a project documented in GitHub Issues or Azure
DevOps, turning the draft into the canonical issue-body layout (## Parent Feature, ## Acceptance Criteria,
## Feature Dependencies …) is left to the agent's generic "store per the Storage Profile" rule. That matters most for
API Features: only an issue-backed project can document one, so no skill can author a feature_dependencies target.

Impact of Technical Debt
  • An issues- or Azure DevOps-documented project gets no help writing its entities in the canonical layout.
Category

Architecture / Design

Priority

Low - Nice to have

Proposed Solution

Decide first: does the layer render issue bodies itself, or rely on a per-project Storage Profile template? Then a skill (or a create-skill step) renders the canonical layout from the draft, with an eval. The Azure DevOps layout waits for that epic's spike.

Effort Estimate

2-3 days

Dependencies / Related

The Azure DevOps epic.

Additional Context

Measured 2026-11-12 at living-doc 2df73dc. Re-check:

grep -rliE "issue body|## Parent Feature|work item" agentic/.claude/skills/*/SKILL.md finds only incidental mentions.

Dominant language
Python
Stars
0
Forks
0
Avg merge
6h 14m
Merged PRs (30d)
27

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AbsaOSS/living-doc

All issues in AbsaOSS/living-doc

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.