obsidian-plugin/murashit_codex-panel
1
0
Fork 0
mirror of https://github.com/murashit/codex-panel.git synced 2026-07-22 17:30:31 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add Codex agent workflow instructions

Browse source
This commit is contained in:
murashit 2026-06-01 22:32:06 +09:00
parent f51aa496fc
commit 422304aa2b
3 changed files with 21 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.agents/skills/codex-panel-app-server-update/SKILL.md
View file

@ -27,5 +27,5 @@ Use this skill when Codex Panel needs to follow Codex CLI or experimental `codex
## Verification
- Run `npm run check` after regenerated bindings or compatibility changes.
- If the change must be reflected in Obsidian, run `npm run build` or `npm run build:prod` and verify the plugin reload path separately.
- If the change must be reflected in Obsidian, run `npm run build` and verify the plugin reload path separately.
- Report the tested Codex CLI version, the generation command used, and any app-server compatibility behavior that changed.

23
.agents/skills/codex-panel-release/SKILL.md
View file

@ -5,29 +5,28 @@ description: Use when preparing, checking, committing, tagging, pushing, or repa
# Codex Panel Release
Use this skill for Codex Panel release work. `docs/release.md` is the public procedure and source of truth for user-facing release commands. This skill adds Codex-facing gates and handling details.
Use this skill when delegating Codex Panel release work to an agent. `docs/release.md` is the public procedure and source of truth for the release command sequence. This skill adds agent-facing gates, review duties, and failure handling.
## Ground Rules
- Read and follow `docs/release.md`; do not maintain a parallel release command sequence here.
- Do not assume local Git hooks exist or ran. Run required verification commands explicitly.
- Do not create GitHub Releases locally with `gh release create`; the tag-triggered GitHub Actions workflow creates or updates the GitHub Release and attaches `main.js`, `manifest.json`, and `styles.css`.
- Do not create GitHub Releases locally with `gh release create`; the tag-triggered GitHub Actions workflow owns release creation and asset attachment.
- Keep internal validation notes, procedural details, and implementation reasoning out of release notes.
- Release notes must be short, public-facing bullets under a single `## Changes` section.
- Release notes must be short, public-facing bullets under the single `## Changes` section required by `docs/release.md`.
## Procedure
## Delegation Procedure
1. Read `docs/release.md`, `package.json`, `manifest.json`, `versions.json`, and existing `.github/release-notes/` files.
2. Identify the target release version and the commit range since the previous released tag.
3. Run `npm run release:prepare -- X.Y.Z`.
3. Follow the preparation step in `docs/release.md`.
4. Draft `.github/release-notes/X.Y.Z.md` from the full diff since the previous released tag, not only the latest commit.
5. Before committing, ask the user to approve the release version, release-note bullets, and included commit range. Do not commit, tag, or push before this approval.
6. Commit only intended release metadata and release notes with `Bump version to X.Y.Z`.
7. Run `npm run release:preflight` after the release commit and before tagging.
8. Tag with `X.Y.Z`, then push `main` and the tag together.
9. Let GitHub Actions create or update the GitHub Release.
5. Before committing, ask the user to approve the release version, release-note bullets, and included commit range.
6. After approval, follow `docs/release.md` for the commit, preflight, tag, and push sequence.
7. After pushing, let GitHub Actions create or update the GitHub Release.
## Failure Handling
- If `release:prepare`, `release:check`, or `release:preflight` fails, fix the cause and rerun the explicit command.
- If the tag-triggered workflow fails before GitHub Release creation, fix the release commit, move the local tag with `jj tag set --allow-move -r main X.Y.Z`, and force-update the remote tag.
- If a release script or preflight fails, fix the cause and rerun the explicit failed command.
- If the tag-triggered workflow fails before GitHub Release creation, use the repair procedure in `docs/release.md`.
- If a GitHub Release already exists or was partially created, inspect the state before taking action; do not assume local asset upload is the right recovery path.

9
AGENTS.md Normal file
View file

@ -0,0 +1,9 @@
This repository contains the Codex Panel Obsidian plugin. Use the tracked docs as the source of truth: `README.md` for user-facing behavior, `docs/development.md` for development workflow, and `docs/release.md` for releases.
Jujutsu is the recommended local change-management workflow when available.
## Working Rules
- Follow the documented ownership and source layout boundaries.
- Do not hand-edit generated app-server bindings.
- Keep internal validation notes and reasoning out of public release notes.