SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsconversation-context-export

conversation-context-export

General & other

View repository

Updated 10-16 07:23

About this skill

Dialogue context export procedure

Write out the development context shared through the conversation (goals, intentions, design decisions, constraints, etc.) to .dev/contexts/{サニタイズ済みブランチ名}.md . If a PR exists, also post it as a PR comment.

Purpose

This file is used in the following situations:

  • Review of the PR description: An AI cross-checks a human-written PR description against the implementation context and points out errors or insufficient explanations
  • AI-vs-AI bug hunting on feature PRs: Briefing material for the defense-side AI to understand the design intent
  • Continuing development in a new session: Take over the context from the previous session
  • Sharing via PR comments: If a PR exists, also post it as a comment so that other workers and sanity-review can reference it directly

Procedure

1. Get the metadata

Run the following with the Bash tool:

git branch --show-current && git rev-parse --short HEAD && gh pr view --json number -q .number

Get the branch name, source commit, and PR number. For Updated at, enter the current date and time (YYYY-MM-DD HH:mm:ss).

  • If a PR exists, get its number and enter it in the PR field of the metadata
  • If the command errors out (no PR created), enter "no PR created at export time"

Sanitizing the branch name

When using the branch name as a filename, replace the following characters with - :

/ \ : * ? " < > |

Example: dependabot/npm_and_yarn/feed-5.2.0 → dependabot-npm_and_yarn-feed-5.2.0

In the following steps, the sanitized branch name is referred to as the "sanitized branch name".

Determining the output directory

Decide the output destination according to the git worktree situation.

Run git worktree list with the Bash tool to determine whether the current working tree is the main worktree (the repository's own working tree) or a linked worktree. If working in a worktree, also determine the path of the main worktree.

If working in the main tree, set the output directory to .dev/contexts/ .

If working in a worktree, confirm the output destination with the AskUserQuestion tool:

  • Output to the main tree: Set the output directory to {main treeのパス}/.dev/contexts/ . Local files remain even if the worktree is discarded
  • Output to the current worktree: Set the output directory to .dev/contexts/ Assume

In the following steps, the determined path is referred to as the "output directory".

2. Check for existing files

{出力先ディレクトリ}/{サニタイズ済みブランチ名}.md Check whether already exists.

If it exists, read it with the Read tool. Next, determine whether that file is one that I exported within this conversation (same session), or one written out by another session (different session) .

  • Same session: This file was written out by me within this conversation using the Write tool
  • Different session: Anything else (written out by an AI from a previous session or another AI)

Based on this determination, apply the "Existing File Update Rules" in Step 3.

3. Exporting the context

Read TEMPLATE.md located in the same directory as this SKILL.md, and create the file according to its structure.

If the output destination directory does not exist, create it.

Write out to {出力先ディレクトリ}/{サニタイズ済みブランチ名}.md using the Write tool.

4. Posting to PR comments

If the PR number could not be obtained in Step 1 (the PR has not been created), skip this procedure.

4-1. Get repository information and the current GitHub user

Execute the following with the Bash tool:

gh repo view --json owner,name -q '.owner.login + "/" + .name' && gh api user -q .login

The first line is the repository's {owner}/{repo}, and the second line is the current GitHub username.

4-2. Search for existing dialogue context comments

Execute the following with the Bash tool to search the PR comment list for dialogue context comments. Only target comments that begin with the TEMPLATE.md heading format # {ブランチ名} 対話コンテキスト :

gh api repos/{owner}/{repo}/issues/{PR番号}/comments --paginate -q '.[] | select(.body | startswith("# {ブランチ名} 対話コンテキスト")) | {id: .id, login: .user.login}'

{ブランチ名} Embed the current branch name (before sanitization) intostartswith . By checking for an exact match of the heading line with

, exclude unrelated comments that merely contain the string "dialogue context". If multiple are found, prioritize your own comments as the target. If there are multiple comments of your own, use the most recent one. If there are no comments of your own and only comments from other users, target the most recent one.

4-3. Determining and executing the post

Branch as follows according to the search results. Use the method of reading the comment body from a file to avoid shell escaping issues.

If no existing comment is found

Post a new comment:

gh pr comment {PR番号} --body-file "{出力先ディレクトリ}/{サニタイズ済みブランチ名}.md"
If an existing comment is found and the poster is yourself

Update the existing comment:

gh api repos/{owner}/{repo}/issues/comments/{コメントID} --method PATCH -F "body=@{出力先ディレクトリ}/{サニタイズ済みブランチ名}.md"
If an existing comment is found and the poster is another user

Since another user's comment cannot be edited due to permissions, present the following options using the AskUserQuestion tool:

  • Post as a separate comment: gh pr comment Post a new comment with
  • Skip the GitHub post: Finish with only the export to the local file

4-4. Reporting the result

When posting or updating is completed, report the URL of the PR comment to the user. If skipped, report that fact.

Guidelines for export content

Content to focus on

  • Accurate description of implementation behavior: Describe at the level of "it behaves this way for this input" rather than "it behaves this way"
  • Rejected alternatives and their reasons: Decisions that humans tend to later wonder "why didn't we do this?"
  • Discovered constraints and pitfalls: Information to prevent the next worker from falling into the same trap

Content that can be thin

  • Things obvious from reading the code (function names used, list of changed files, etc.)

"What not to write" rules for each section

  • Design policy: Do not write the reasons for choosing configuration values that are clear from reading the code/config (e.g., file naming, env version selection)
  • Newly confirmed facts: Do not write impressions, reflections on how things proceeded, or stories of hardship. Only facts that affect future decision-making
  • Pitfalls requiring caution: Write constraints (unchangeable facts) under "Discovered constraints". Write positive discoveries under "Newly confirmed facts"

Guidelines for distinguishing between sections

Boundary between "Design policy" and "Rejected alternatives":

  • Design policy = the adopted approach and its rationale
  • Rejected alternatives = approaches considered but not adopted, and their reasons

Boundary between "Discovered constraints" and "Pitfalls requiring caution":

  • Constraints = facts that bind decisions and do not disappear even if the worker is careful
  • Pitfalls = accidents that can be avoided through procedures or approach if known

Rules for updating existing files

Re-export within the same session

  • Fully regenerate based on the entire context of the conversation
  • Do not be bound by the contents of existing files. The current understanding is authoritative

When updating records from another session

Respect the records of prior sessions as "predecessors' discoveries".

  • In principle, keep existing items
  • Add newly discovered information
  • Corrections/deletions are allowed only when actually retested/verified and disproven through one's own work. Do not delete based on inference alone
  • If an item is clearly misclassified, it may be moved between sections (the content is preserved)
  • If inferring a change in intent, policy, or scope judgment, confirm with the user

Common rules

  • Files always represent the currently correct state. Do not leave strikethroughs or change history (leave history to git)
  • Exported by accumulates contributor names: Preserve the Exported by entries remaining in both the local file and the existing PR comment body, and append your own entry if it is not present. Even when fully regenerating via "re-export within the same session", keep the names of past contributors

Related skills

  • conversation-context-import: A skill that loads the saved dialogue context. Use it when continuing development in a new session or when reviewing a feature PR.
  • sanity-review: A skill that creates a PR review report. It loads the dialogue context posted in PR comments and uses it for the review.