SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsjira-impl-logger

jira-impl-logger

Coding & development

View repository

Updated 10-16 02:39

About this skill

JIRA Implementation Logger

Role

You record what was implemented for a task as a structured comment on the JIRA issue. The log is searchable via JIRA's query and serves as the canonical knowledge base for "what exists already" — future engineers and AI agents should grep JIRA (via the Atlassian MCP) before creating new code.

You are invoked by the executor (task-executor / sprint-executor) once per completed task, or directly if someone needs to backfill a log.

Why JIRA and not repo files: Repo implementation logs tend to decay or duplicate the git log. JIRA comments are already the system of record for work done, are searchable, and link naturally to the ticket's full context (description, review, status, sprint).

Inputs

  • Ticket key (e.g., TI-101)
  • Summary — one-line description of what was implemented
  • Files created — list of paths
  • Files modified — list of paths
  • Statistics — linesAdded, linesRemoved (from git diff --shortstat)
  • Artifacts — structured data about what was built (see schema below)
  • Commit hash(es) — for back-reference
  • Optional: docs backend — docs: confluence | notion (from workflow-config) enables the docs mirror, plus the Impl Logs dataset id

Artifact Schema

Structured data, adapted from spec-workflow-mcp. Each artifact type (apiEndpoints, components, functions, classes, integrations, dataModels, pipelineStages) is optional — include the ones relevant to this task.

The schema is defined once, shared verbatim across all four impl-loggers — see prompts/coding/templates/impl-log-artifact-schema.md.

Workflow

Step 1 — Validate inputs

  • Confirm ticket exists (Atlassian MCP getJiraIssue)
  • Confirm at least one artifact category is provided — empty artifacts is a failure mode
  • Confirm files lists are non-empty (a task that created/modified no files is suspicious)

If inputs are thin, ask the caller for more detail before posting. A sparse log is worse than no log — it pollutes search results.

Step 2 — Render the comment

Use the template at prompts/coding/templates/jira-impl-log-template.md. Structure:

## Implementation Log — {ticket-key}

**Summary:** {one-line summary}
**Commit:** {hash} — {commit message first line}
**Date:** {ISO date}

### Files
- Created: {file1}, {file2}
- Modified: {file3}, {file4}
- Stats: +{linesAdded} / -{linesRemoved} across {N} files

### Artifacts

#### API Endpoints
| Method | Path | Purpose | Location |
| ... | ... | ... | ... |

#### Components
| Name | Type | Purpose | Location | Props |

#### Functions
| Name | Purpose | Location | Signature | Exported |

#### Classes
| Name | Purpose | Location | Methods | Exported |

#### Integrations
| Description | Frontend | Backend | Data flow |

#### Data Models
...

#### Pipeline Stages
...

### Searchable Keywords
{comma-separated list of class/function/endpoint names for JIRA full-text search}

Step 3 — Post comment

Use mcp__Atlassian__addCommentToJiraIssue with the rendered markdown.

Step 4 — Label ticket

Add label impl-logged to the ticket via editJiraIssue. This lets dashboards filter tickets that have logs vs. those still missing them.

Step 5 — Mirror to the docs surface (when a docs backend is configured)

If docs (confluence | notion) is configured, also publish the log to the docs surface via the docs adapter's publishRecord (skills/feature-spec-author/references/docs-adapter.md):

  • docs=notion → a row in the Impl Logs database; body = the rendered markdown.
  • docs=confluence → append the rendered log to the Impl Logs page (or a row in its table macro).
  • If the Impl Logs dataset doesn't exist yet, do not silently skip — tell the caller to provision it via confluence-space-manager / notion-workspace-manager. The JIRA comment (Step 3) is the system of record regardless.

Step 6 — Return

Return to caller:

  • JIRA comment URL
  • Confirmation that ticket is labelled
  • Docs mirror URL (if mirrored)

Why Structured Artifacts Matter

Future AI agents will query the JIRA comments via the Atlassian MCP (searchJiraIssuesUsingJql with text search) before writing new code. Incomplete logs produce duplicate endpoints, duplicate components, duplicate helpers.

Minimum quality bar:

  • If the task created an API endpoint, apiEndpoints MUST be populated
  • If the task created a UI component, components MUST be populated
  • If the task created a class, classes MUST be populated
  • A pure refactor (no new API surface) may have empty artifacts but MUST explain in summary: "Refactor only — no new public surface"

Backfilling Logs

If invoked on a closed ticket that never got a log:

  1. Read the ticket description and commits referenced
  2. git log --follow and git show to identify files and stats
  3. Infer artifacts from the diff (grep for def , class , @app.route, React component exports)
  4. Offer the draft log to the user for confirmation before posting

What This Skill Does NOT Do

  • Does not evaluate code quality (that's clean-code-reviewer)
  • Does not close the JIRA ticket (that's the executor)
  • Does not write logs to the repo (deliberately — JIRA is the log surface)
  • Does not add commits or run tests

References

Feedback

If the user corrects this skill's output due to a misinterpretation or missing rule in the skill itself (not a one-off preference), invoke skill-feedback to capture structured feedback and optionally post a GitHub issue.

If skill-feedback is not installed, ask the user: "This looks like a skill defect. Would you like to install the skill-feedback skill to report it?" If the user declines, continue without feedback capture.