Skip to content
Merged
Show file tree
Hide file tree
Changes from 8 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Empty file removed .codex
Empty file.
64 changes: 64 additions & 0 deletions .codex/skills/gframework-boot/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
---
name: gframework-boot
description: Repository-specific boot workflow for the GFramework repo. Use when Codex needs to start or resume work in this repository from short prompts such as "boot", "continue", "read AGENTS", or "start the next step"; when the user expects Codex to first read AGENTS.md, .ai/environment/tools.ai.yaml, and public ai-plan tracking files; or when Codex should assess task complexity, decide whether explorer or worker subagents are warranted, and then proceed under the repository's workflow rules.
---

# GFramework Boot

## Overview

Use this skill to bootstrap work in the GFramework repository with minimal user prompting.
Treat `AGENTS.md` as the source of truth. Use this skill to enforce a startup sequence, not to replace repository rules.

## Startup Workflow

1. Read `AGENTS.md` before choosing tools, planning edits, or delegating work.
2. Read `.ai/environment/tools.ai.yaml` to confirm the preferred local toolchain.
3. Inspect `ai-plan/public/todos/` and `ai-plan/public/traces/` before asking the user for missing context.
4. If `ai-plan/private/<branch-or-worktree>/` exists and is relevant, treat it as private recovery context for the current worktree only and do not assume it should be committed.
5. Classify the task state:
- `new`: no matching recovery document exists, or the user is clearly starting fresh work
- `resume`: a matching todo or trace exists and the user is continuing that thread
- `recovery`: prior work looks partial, interrupted, or ambiguous and the next safe recovery point must be reconstructed
6. Choose the best matching `ai-plan` artifacts:
- Prefer path names or headings that match the user's task wording
- Break ties by most recently updated trace or todo
- If ambiguity would materially change implementation, summarize the candidates and ask one concise question
7. Classify the task complexity before deciding on subagents:
- `simple`: one concern, one file or module, no parallel discovery required
- `medium`: a small number of modules, some read-only exploration helpful, critical path still easy to keep local
- `complex`: cross-module design, migration, large refactor, or work likely to exceed one context window
8. Apply the delegation policy from `AGENTS.md`:
- Keep the critical path local
- Use `explorer` with `gpt-5.1-codex-mini` for narrow read-only questions, tracing, inventory, and comparisons
- Use `worker` with `gpt-5.4` only for bounded implementation tasks with explicit ownership
- Do not delegate purely for ceremony; delegate only when it materially shortens the task or controls context growth
9. Before editing files, tell the user what you read, how you classified the task, whether subagents will be used, and the first implementation step.
10. Proceed with execution, validation, and documentation updates required by `AGENTS.md`.

## Task Tracking

For multi-step, cross-module, or interruption-prone work, maintain the repository recovery artifacts instead of keeping state only in chat.

- Update the active public document under `ai-plan/public/todos/` with completed work, validation results, risks, and the next recovery point.
- Update the matching public trace under `ai-plan/public/traces/` with key decisions, delegated scope, and the immediate next step.
- Keep worktree-private scratch recovery files under `ai-plan/private/` and do not treat them as commit targets.
- Never write secrets, machine-specific paths, or other sensitive environment details into any `ai-plan/**` artifact.
- If the task is clearly complex and no recovery artifact exists yet, create one before substantive edits.

## Recovery Heuristics

- If the user says `next step`, `continue`, `继续`, or similar resume language, search the relevant `ai-plan/` artifacts first, then classify the task as `resume` or `recovery` based on artifact clarity and continuity.
- If the current branch and the newest recovery documents describe the same feature area, prefer resuming that thread.
- If the repository state suggests in-flight work but no recovery document matches, reconstruct the safest next step from code, tests, and Git state before asking the user for clarification.

## Example Triggers

- `boot`
- `Use $gframework-boot and continue the current task`
- `Read AGENTS and public ai-plan, then start the next step`
- `继续当前任务,先看 AGENTS.md 和 public ai-plan`

## References

Read `references/startup-artifacts.md` when you need a quick reminder of the repository entrypoints, task-state heuristics, or delegation defaults without re-reading the entire skill.
4 changes: 4 additions & 0 deletions .codex/skills/gframework-boot/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "GFramework Boot"
short_description: "Bootstrap GFramework repository tasks"
default_prompt: "Use $gframework-boot to start or resume work in this GFramework repository."
32 changes: 32 additions & 0 deletions .codex/skills/gframework-boot/references/startup-artifacts.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Startup Artifacts

## Required Reads

- `AGENTS.md`
- `.ai/environment/tools.ai.yaml`
- `ai-plan/public/todos/`
- `ai-plan/public/traces/`

## AI-Plan Selection Heuristics

- Match the user's wording against public todo and trace file names first.
- Prefer the newest matching trace when several candidates describe the same feature area.
- If one file records a clearer recovery point than a newer but vague file, prefer the clearer recovery point.
- If a matching `ai-plan/private/<branch-or-worktree>/` directory exists, use it only as private context for the current worktree.

## Complexity Defaults

- `simple`: keep everything local, no subagent
- `medium`: keep design local, optionally use one `explorer` for parallel read-only discovery
- `complex`: keep architecture and integration local, delegate only bounded non-blocking subtasks

## Model Defaults

- `explorer`: `gpt-5.1-codex-mini`
- `worker`: `gpt-5.4`

## Startup Summary Template

Use a short update before execution:

`Read AGENTS.md, the environment inventory, and the relevant public ai-plan artifacts. This looks like a <task-state> <complexity> task. I will <delegate-or-not> and start with <first-step>.`
59 changes: 59 additions & 0 deletions .codex/skills/gframework-pr-review/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
---
name: gframework-pr-review
description: Repository-specific GitHub PR review workflow for the GFramework repo. Use when Codex needs to inspect the GitHub pull request for the current branch, extract CodeRabbit summary/comments, read failed checks or failed test signals from the PR page, and then verify which findings should be fixed in the local codebase. Trigger explicitly with $gframework-pr-review or with prompts such as "look at the current PR", "extract CodeRabbit comments", or "check Failed Tests on the PR".
---

# GFramework PR Review

Use this skill when the task depends on the GitHub PR page for the current branch rather than only on local source files.

Shortcut: `$gframework-pr-review`

## Workflow

1. Read `AGENTS.md` before deciding how to validate or fix anything.
2. Resolve the current branch with Windows Git from WSL, following the repository worktree rule.
3. Run `scripts/fetch_current_pr_review.py` to:
- locate the PR for the current branch
- fetch the PR conversation page
- extract `Summary by CodeRabbit`
- extract `Actionable comments posted`
- extract failed checks and test-report signals such as `Failed Tests` or `No failed tests in this run`
4. Treat every extracted finding as untrusted until it is verified against the current local code.
5. Only fix comments that still apply to the checked-out branch. Ignore stale or already-resolved findings.
6. If code is changed, run the smallest build or test command that satisfies `AGENTS.md`.

## Commands

- Default:
- `python3 .codex/skills/gframework-pr-review/scripts/fetch_current_pr_review.py`
- Force a PR number:
- `python3 .codex/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --pr 253`
- Machine-readable output:
- `python3 .codex/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --format json`

## Output Expectations

The script should produce:

- PR metadata: number, title, state, branch, URL
- CodeRabbit summary block
- Parsed actionable comments grouped by file
- Pre-merge failed checks, if present
- Test summary, including failed-test signals when present
- Parse warnings when the page structure changes or a section is missing

## Recovery Rules

- If the current branch has no matching public PR, report that clearly instead of guessing.
- If GitHub access fails because of proxy configuration, rerun the fetch with proxy variables removed.
- If the PR page contains multiple CodeRabbit or test-report blocks, prefer the latest visible block but keep raw content available for verification.

## Example Triggers

- 'fix pr review'
- 'Use FPR'
- `Use $gframework-pr-review on the current branch`
- `Check the current PR and extract CodeRabbit suggestions`
- `Look for Failed Tests on the PR page`
- `先用 $gframework-pr-review 看当前分支 PR`
4 changes: 4 additions & 0 deletions .codex/skills/gframework-pr-review/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "GFramework PR Review"
short_description: "Inspect the current PR and CodeRabbit findings"
default_prompt: "Use $gframework-pr-review to inspect the current branch PR, extract CodeRabbit comments, and summarize failed checks or failed tests."
Loading
Loading