{"owner":"gogf","repo":"gf","hasSkills":true,"totalSkillsCount":6,"totalTokensCount":9365,"categories":["anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/gf-review/SKILL.md",".agents/skills/git-commit-push/SKILL.md",".agents/skills/openspec-explore/SKILL.md",".agents/skills/git-worktree/SKILL.md",".agents/skills/openspec-propose/SKILL.md",".agents/skills/gf-feedback/SKILL.md"],"skills":{".agents/skills/gf-review/SKILL.md":"---\nname: gf-review\ndescription: >-\n Code and specification review for OpenSpec workflow. Triggers automatically after /opsx:apply\n task completion, after /gf-feedback task completion, and before /opsx:archive. Use when\n user requests code review, spec compliance check, or when explicitly invoked via /gf-review.\ncompatibility: Requires OpenSpec CLI and GoFrame v2 skill.\n---\n\n# GF Review\n\nStructured code and specification review for the OpenSpec development workflow.\n\n**Spec Source**: `AGENTS.md` is the single source of truth for all review criteria.\n\n\n## When This Skill Activates\n\n**Automatic triggers:**\n- After completing each task in `/opsx:apply`\n- After completing each task in `/gf-feedback`\n- Before executing `/opsx:archive`\n\n**Manual trigger:**\n- User explicitly requests: \"review this code\", \"check spec compliance\", \"/gf-review\"\n\n\n## Review Workflow\n\n### 1. Identify Scope\n\nDetermine what needs to be reviewed:\n\n1. **After task completion** — Review files modified/created by the completed task\n2. **Before archive** — Review all changes in the current OpenSpec change\n3. **Manual invocation** — Ask user to specify scope or use current change\n\n**Mandatory scope collection rules:**\n\n1. Start with repository status, not `git diff` alone:\n ```bash\n git status --short\n git ls-files --others --exclude-standard\n ```\n2. Treat **all tracked and untracked changes** as review candidates, including:\n - staged files\n - unstaged files\n - untracked files shown as `??`\n - untracked directories shown as `?? path/`\n3. When `git status --short` reports an untracked directory, expand it to concrete files before review:\n ```bash\n find -type f\n # Or prefer:\n rg --files \n ```\n4. If the task ran generators such as `make ctrl`, `make dao`, codegen scripts, or produced new test files, explicitly include the generated untracked files in review scope even if they do not appear in `git diff`.\n5. `git diff` may be used only as a secondary narrowing aid after status collection. It is **never sufficient by itself** for review scope definition.\n\nRun `openspec status --change \"\" --json` to understand the current change state.\n\n### 2. Load Specifications\n\nRead `AGENTS.md` to load all specifications. This is the single source of truth.\n\n### 3. Backend Code Review\n\n**Trigger**: Changes to files under `apps/lina-core` directory\n\n1. Invoke `goframe-v2` skill for GoFrame framework conventions\n2. Check against `AGENTS.md` backend code specifications\n\n### 4. RESTful API Review\n\n**Trigger**: Any API endpoint changes\n\nCheck against `AGENTS.md` API design specifications.\n\n### 5. Project Specification Review\n\n**Trigger**: Any implementation changes\n\nCheck against `AGENTS.md` architecture design specifications and code development specifications.\n\n### 6. SQL Review\n\n**Trigger**: New or modified files under `apps/lina-core/manifest/sql/`、`apps/lina-core/manifest/sql/mock-data/`、`apps/lina-plugins/**/manifest/sql/` or SQL snippets embedded in related delivery docs\n\nCheck against `AGENTS.md` SQL file management specifications, at minimum covering:\n1. File naming, versioning, and single-iteration single-file rules\n2. Seed DML vs mock data separation\n3. **Idempotent execution safety** — SQL must be safe to run multiple times without duplicate-object errors or duplicate seed data; verify use of `IF [NOT] EXISTS`, `IF EXISTS`, `INSERT IGNORE`, or equivalent safe re-entry patterns\n4. **Seed write style compliance** — delivered SQL must reject `INSERT ... ON DUPLICATE KEY UPDATE` and reject explicit writes to `AUTO_INCREMENT` `id` columns in seed/mock/install data\n5. Whether schema/data changes still match the current change scope and deployment path\n\n### 7. Unit Test Review\n\n**Trigger**: New or modified Go implementation files, or new/modified Go unit test files matching `*_test.go`\n\nCheck at minimum:\n1. Behavior-changing Go code includes focused unit coverage in the same package, preferably by extending existing `*_z_unit*_test.go` or `*_test.go`\n2. Tests assert the changed logic directly instead of relying on broad workflow-level coverage when a package-level test is sufficient\n3. Verification uses targeted `go test ./path/to/pkg -run TestName` during development and package-level `go test ./path/to/pkg` for regression\n\n### 8. Generate Review Report\n\n```markdown\n## GF Review Report\n\n**Change:** \n**Scope:** \n**Files Reviewed:** \n**Scope Source:** `git status --short` + `git ls-files --others --exclude-standard` + task/change context\n\n### Backend Code Review\n✓ All checks passed / ⚠ N issues found\n\n### RESTful API Review\n✓ All endpoints compliant / ⚠ N violations found\n\n### Project Spec Review\n✓ Compliant with AGENTS.md / ⚠ N violations found\n\n### SQL Review\n✓ No SQL changes / ✓ SQL changes compliant / ⚠ N SQL issues found\n\n### Unit Test Review\n✓ Unit tests are focused and sufficient / ⚠ N issues found\n\n### Summary\n- **Critical:** N (must fix before archive)\n- **Warnings:** N (recommended to fix)\n\n### Recommended Actions\n1. [Specific action with AGENTS.md reference]\n```\n\n\n## Issue Severity\n\n| Level | Behavior |\n|-------|----------|\n| **Critical** | Block archive, must fix |\n| **Warning** | Show but allow proceed |\n\n\n## Integration Points\n\n| Workflow Step | Behavior |\n|---------------|----------|\n| `/opsx:apply` task done | Review, offer to fix issues before next task |\n| `/gf-feedback` task done | Review, fix before marking complete |\n| `/opsx:archive` | Review all changes, block on critical issues |\n\n\n## Guardrails\n\n- **AGENTS.md is the single source of truth** — All spec references point to it\n- Only check categories relevant to changed files\n- Scope identification MUST include untracked files and expanded untracked directories; never rely on `git diff` alone\n- Behavior-changing Go code without focused unit tests is a review finding unless the author documents why tests are not applicable\n- Don't block on warnings — only critical issues block archive\n- Include file paths and line numbers in issue reports\n- Offer to fix issues automatically when straightforward\n",".agents/skills/git-commit-push/SKILL.md":"---\nname: git-commit-push\ndescription: Review the current git working tree, generate a commit message from the actual diff using the repository's commit or PR-title convention, commit all current changes on the active branch, and push that branch to `origin`. Use this whenever the user asks to \"commit\", \"push\", \"commit and push\", \"generate a commit message\", \"commit the current changes\", or wants the current branch changes sent upstream without hand-writing the git commands.\n---\n\n# Git Commit Push\n\nInspect the current repository changes, derive a concise commit subject that matches the repository convention, commit every current modification on the active branch, and push that branch to `origin`.\n\nThis skill is for execution, not just advice. When it triggers, actually run the git workflow unless the repository state makes that unsafe or impossible.\n\n## When To Use\n\n- The user asks you to commit the current changes, with or without asking for push\n- The user wants you to write the commit message from the diff instead of inventing one up front\n- The user mentions the repo's PR or commit naming convention and wants you to follow it\n- The user says things like \"commit the current branch\", \"help me commit\", \"commit and push\", \"generate a commit message and push\", or \"send these changes to origin\"\n\n## Core Behavior\n\n1. Confirm you are inside a Git repository and detect the active branch with `git branch --show-current`.\n2. Inspect the working tree before committing:\n - `git status --short --branch`\n - `git diff --stat`\n - `git diff --cached --stat`\n - `git diff -- . ':(exclude)package-lock.json'` or narrower path filters only when needed for readability\n3. If the repository contains `.github/PULL_REQUEST_TEMPLATE.MD`, read it and treat its PR-title rules as the default commit-subject convention.\n4. Generate a commit subject from the actual changed files and diff content, not from the user prompt alone.\n5. Stage every current modification on the branch with `git add -A`.\n6. Commit once with the generated message.\n7. Push the current branch to `origin` with `git push origin `.\n\n## Commit Message Rules\n\nThe commit message is formatted as follows: `[optional scope]: ` For example, `fix(os/gtime): fix time zone issue`\n + `` is mandatory and can be one of `fix`, `feat`, `build`, `ci`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`\n + `fix`: Used when a bug has been fixed.\n + `feat`: Used when a new feature has been added.\n + `build`: Used for modifications to the project build system, such as changes to dependencies, external interfaces, or upgrading Node version.\n + `ci`: Used for modifications to continuous integration processes, such as changes to Travis, Jenkins workflow configurations.\n + `docs`: Used for modifications to documentation, such as changes to README files, API documentation, etc.\n + `style`: Used for changes to code style, such as adjustments to indentation, spaces, blank lines, etc.\n + `refactor`: Used for code refactoring, such as changes to code structure, variable names, function names, without altering functionality.\n + `perf`: Used for performance optimization, such as improving code performance, reducing memory usage, etc.\n + `test`: Used for modifications to test cases, such as adding, deleting, or modifying test cases for code.\n + `chore`: Used for modifications to non-business-related code, such as changes to build processes or tool configurations.\n + After ``, specify the affected package name or scope in parentheses, for example, `(os/gtime)`.\n + The part after the colon uses the verb tense + phrase that completes the blank in\n + Lowercase verb after the colon\n + No trailing period\n + Keep the title as short as possible. ideally under 76 characters or shorter\n+ If there is a corresponding issue, add either `fixes #1234` (the latter if this is not a complete fix) to this comment\n\n### Examples\n#### Commit message with description and breaking change footer\n```\nfeat: allow provided config object to extend other configs\nBREAKING CHANGE: `extends` key in config file is now used for extending other config files\n```\n\n#### Commit message with ! to draw attention to breaking change\n```\nfeat!: send an email to the customer when a product is shipped\n```\n\n#### Commit message with scope and ! to draw attention to breaking change\n```\nfeat(api)!: send an email to the customer when a product is shipped\n```\n\n#### Commit message with both ! and BREAKING CHANGE footer\n```\nfeat!: drop support for Node 6\nBREAKING CHANGE: use JavaScript features not available in Node 6.\n```\n\n#### Commit message with no body\n```\ndocs: correct spelling of CHANGELOG\n```\n\n#### Commit message with scope\n```\nfeat(lang): add Polish language\n```\n\n#### Commit message with multi-paragraph body and multiple footers\n```\nfix: prevent racing of requests\n\nIntroduce a request id and a reference to latest request. Dismiss\nincoming responses other than from latest request.\n\nRemove timeouts which were used to mitigate the racing issue but are\nobsolete now.\n\nReviewed-by: Z\nRefs: #123\n```\n\n## Execution Rules\n\n- Commit all current tracked and untracked changes in the working tree, because this skill is for \"commit the current state\" requests\n- If there are no changes, say so clearly and stop before commit or push\n- If `git branch --show-current` is empty, explain that `HEAD` is detached and stop unless the user explicitly asks you to commit from detached `HEAD`\n- Never use `--force`, `--force-with-lease`, or history-rewriting commands unless the user explicitly asks\n- If push fails because the remote branch moved, report the exact failure and stop instead of auto-rebasing or auto-merging\n- Do not silently drop files from the commit unless the user asked to exclude them\n\n## Suggested Command Flow\n\n```bash\ngit status --short --branch\ngit diff --stat\ngit diff --cached --stat\ntest -f .github/PULL_REQUEST_TEMPLATE.MD && sed -n '1,220p' .github/PULL_REQUEST_TEMPLATE.MD\nbranch_name=$(git branch --show-current)\ngit add -A\ngit commit -m \"\"\ngit push origin \"$branch_name\"\n```\n\nInspect `git diff --cached` again after staging if the pre-stage diff was noisy or if untracked files materially change the scope.\n\n## Output Contract\n\nWhen you use this skill:\n\n- Tell the user which branch you committed\n- Provide the final commit subject you used\n- Mention that you staged all current changes\n- Report the push target as `origin/`\n- If commit or push did not happen, explain exactly why\n\n## Example\n\nUser request:\n\n```text\nGenerate a commit message that follows this repository's convention, then commit and push the current branch\n```\n\nExpected behavior:\n\n- Inspect the repo status and diff\n- Generate a conventional subject from the real changes\n- Run one commit for the whole current working tree\n- Push the active branch to `origin`\n",".agents/skills/openspec-explore/SKILL.md":"---\nname: openspec-explore\ndescription: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.2.0\"\n---\n\nEnter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.\n\n**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.\n\n**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.\n\n\n## The Stance\n\n- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script\n- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.\n- **Visual** - Use `mermaid` for architecture diagrams, flowcharts, and similar visuals. If you need line breaks inside `mermaid`, use `
` instead of `\\n`. ASCII box-drawing is allowed only when mermaid is a poor fit, and those blocks must stay in English.\n- **Adaptive** - Follow interesting threads, pivot when new information emerges\n- **Patient** - Don't rush to conclusions, let the shape of the problem emerge\n- **Grounded** - Explore the actual codebase when relevant, don't just theorize\n\n\n## What You Might Do\n\nDepending on what the user brings, you might:\n\n**Explore the problem space**\n- Ask clarifying questions that emerge from what they said\n- Challenge assumptions\n- Reframe the problem\n- Find analogies\n\n**Investigate the codebase**\n- Map existing architecture relevant to the discussion\n- Find integration points\n- Identify patterns already in use\n- Surface hidden complexity\n\n**Compare options**\n- Brainstorm multiple approaches\n- Build comparison tables\n- Sketch tradeoffs\n- Recommend a path (if asked)\n\n**Visualize**\n\nUse `mermaid` for system diagrams, state machines, data flows, and architecture sketches:\n\n```mermaid\nflowchart LR\n A[\"State A\"] --> B[\"State B\"]\n```\n\n**Surface risks and unknowns**\n- Identify what could go wrong\n- Find gaps in understanding\n- Suggest spikes or investigations\n\n\n## OpenSpec Awareness\n\nYou have full context of the OpenSpec system. Use it naturally, don't force it.\n\n### Check for context\n\nAt the start, quickly check what exists:\n```bash\nopenspec list --json\n```\n\nThis tells you:\n- If there are active changes\n- Their names, schemas, and status\n- What the user might be working on\n\n### When no change exists\n\nThink freely. When insights crystallize, you might offer:\n\n- \"This feels solid enough to start a change. Want me to create a proposal?\"\n- Or keep exploring - no pressure to formalize\n\n### When a change exists\n\nIf the user mentions a change or you detect one is relevant:\n\n1. **Read existing artifacts for context**\n - `openspec/changes//proposal.md`\n - `openspec/changes//design.md`\n - `openspec/changes//tasks.md`\n - etc.\n\n2. **Reference them naturally in conversation**\n - \"Your design mentions using Redis, but we just realized SQLite fits better...\"\n - \"The proposal scopes this to premium users, but we're now thinking everyone...\"\n\n3. **Offer to capture when decisions are made**\n\n | Insight Type | Where to Capture |\n |--------------|------------------|\n | New requirement discovered | `specs//spec.md` |\n | Requirement changed | `specs//spec.md` |\n | Design decision made | `design.md` |\n | Scope changed | `proposal.md` |\n | New work identified | `tasks.md` |\n | Assumption invalidated | Relevant artifact |\n\n Example offers:\n - \"That's a design decision. Capture it in design.md?\"\n - \"This is a new requirement. Add it to specs?\"\n - \"This changes scope. Update the proposal?\"\n\n4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.\n\n\n## What You Don't Have To Do\n\n- Follow a script\n- Ask the same questions every time\n- Produce a specific artifact\n- Reach a conclusion\n- Stay on topic if a tangent is valuable\n- Be brief (this is thinking time)\n\n\n## Handling Different Entry Points\n\n**User brings a vague idea:**\n\n> User: I'm thinking about adding real-time collaboration\n\nReal-time collab is a big space. Let me think about this...\n\n```mermaid\nflowchart LR\n A[\"Awareness
Presence\"] --> B[\"Coordination
Cursors\"] --> C[\"Sync
CRDT\"]\n```\n\nWhere's your head at?\n\n**User brings a specific problem:**\n\n> User: The auth system is a mess\n\nAfter reading the codebase:\n\n```mermaid\nflowchart TD\n G[\"Google OAuth\"] --> S[Session]\n GH[\"GitHub OAuth\"] --> S\n E[\"Email Magic\"] --> S\n S --> P[Perms]\n```\n\nI see three tangles. Which one's burning?\n\n**User is stuck mid-implementation:**\n\n> User: `/opsx:explore add-auth-system`\n> The OAuth integration is more complex than expected\n\nAfter reading change artifacts: you're on task 4, \"Implement OAuth flow\". Trace what's involved, explore options, then ask whether to update the design or add a spike task.\n\n**User wants to compare options:**\n\n> User: Should we use Postgres or SQLite?\n\nGeneric answer is boring. What's the context?\n\n> User: A CLI tool that tracks local dev environments\n\nThat changes everything.\n\n| | `SQLite` | `Postgres` |\n| --- | --- | --- |\n| Deployment | embedded | needs server |\n| Offline | yes | no |\n| Single file | yes | no |\n\n`SQLite`. Not even close. Unless... is there a sync component?\n\n\n## Ending Discovery\n\nThere's no required ending. Discovery might:\n\n- **Flow into a proposal**: \"Ready to start? I can create a change proposal.\"\n- **Result in artifact updates**: \"Updated design.md with these decisions\"\n- **Just provide clarity**: User has what they need, moves on\n- **Continue later**: \"We can pick this up anytime\"\n\nWhen it feels like things are crystallizing, you might summarize:\n\n```\n## What We Figured Out\n\n**The problem**: [crystallized understanding]\n\n**The approach**: [if one emerged]\n\n**Open questions**: [if any remain]\n\n**Next steps** (if ready):\n- Create a change proposal\n- Keep exploring: just keep talking\n```\n\nBut this summary is optional. Sometimes the thinking IS the value.\n\n\n## Guardrails\n\n- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.\n- **Don't fake understanding** - If something is unclear, dig deeper\n- **Don't rush** - Discovery is thinking time, not task time\n- **Don't force structure** - Let patterns emerge naturally\n- **Don't auto-capture** - Offer to save insights, don't just do it\n- **Do visualize** - A good mermaid diagram is worth many paragraphs\n- **Do explore the codebase** - Ground discussions in reality\n- **Do question assumptions** - Including the user's and your own\n",".agents/skills/git-worktree/SKILL.md":"---\nname: git-worktree\ndescription: Create and actively use an isolated git worktree for the user's task, then continue the task inside that new directory. Use this whenever the user asks for a separate worktree, isolated checkout, clean branch directory, safer parallel changes, or a fresh workspace to avoid unrelated local edits.\n---\n\n# Git Worktree\n\nCreate a dedicated `git worktree` for the current task, then keep working inside that new directory instead of the original checkout.\n\nThis skill is about execution, not just advice. When it triggers, actually create the worktree unless the repository state makes that impossible.\n\nDo not introduce helper scripts for this skill. Use direct `git` and shell commands inline.\n\n## When To Use\n\n- The user explicitly asks for a new `git worktree`, independent branch directory, or isolated workspace\n- The current checkout contains unrelated local changes and isolation is the safest way forward\n- The user wants parallel work on multiple tasks without stashing or disturbing the original worktree\n- The user says things like \"create a separate branch folder\", \"open a fresh worktree\", \"use a clean checkout\", or \"work in an isolated workspace\"\n\n## Core Rule\n\nAfter creating the worktree, treat the new path as the active working directory for the rest of the task.\n\nIn any agent environment, \"enter the directory\" means:\n\n- Run subsequent commands against the new worktree path\n- Apply all edits under that worktree path\n- Do not keep using the original checkout by accident\n- Confirm the handoff by running at least one follow-up command in the new worktree\n\nNever claim you \"switched\" unless your subsequent actions actually target the new `worktree_path`.\n\nIf your environment supports a per-command working directory, use it for every later command. If it does not, prefix later commands with an explicit `cd && ...`.\n\n## Name Derivation\n\n- Derive a short ASCII kebab-case task slug from the user's real task, such as `login-timeout-fix` or `user-export`\n- Do not use generic names like `git-worktree`, `new-worktree`, or `task` unless the request is too vague\n- If the request is mostly non-ASCII or no good slug is obvious, fall back to `task-$(date +%Y%m%d-%H%M%S)`\n- Default branch prefix is `worktree/`\n- Default worktree directory is a sibling of the repository root, named `-`\n\n## Default Workflow\n\n1. Inspect the repository context from the current checkout:\n - `git rev-parse --show-toplevel`\n - `git branch --show-current`\n - `git status --short`\n - `git worktree list --porcelain`\n2. Decide a task slug yourself using the rules above\n3. Build branch and path names inline, then create the worktree with direct shell commands like:\n\n ```bash\n repo_root=$(git rev-parse --show-toplevel)\n repo_name=$(basename \"$repo_root\")\n parent_dir=$(dirname \"$repo_root\")\n source_branch=$(git -C \"$repo_root\" branch --show-current)\n if [ -n \"$source_branch\" ]; then\n source_ref=\"$source_branch\"\n else\n source_ref=\"HEAD@$(git -C \"$repo_root\" rev-parse --short HEAD)\"\n fi\n\n slug=\"\"\n base_branch=\"worktree/$slug\"\n branch_name=\"$base_branch\"\n base_path=\"$parent_dir/$repo_name-$slug\"\n worktree_path=\"$base_path\"\n index=2\n\n while git -C \"$repo_root\" show-ref --verify --quiet \"refs/heads/$branch_name\" || [ -e \"$worktree_path\" ]; do\n branch_name=\"${base_branch}-$index\"\n worktree_path=\"${base_path}-$index\"\n index=$((index + 1))\n done\n\n git -C \"$repo_root\" worktree add -b \"$branch_name\" \"$worktree_path\" HEAD\n ```\n\n4. Immediately verify the handoff inside the new worktree, for example:\n\n ```bash\n pwd\n git status --short --branch\n ```\n\n These verification commands must run against `worktree_path`.\n\n5. Announce the new active path briefly, then continue the main task there\n6. For the remainder of the task, use `worktree_path` as the working directory for every relevant command or edit operation\n\n## Behavior Rules\n\n- Default base ref is `HEAD` from the current checkout so uncommitted local changes are not dragged into the new worktree\n- If a branch name or path already exists, auto-increment it instead of failing\n- If you are already inside a non-default worktree and the user still wants another isolated workspace, create a new one from the current `HEAD`\n- If the directory is not a Git repository, explain that clearly and do not pretend a worktree was created\n- If worktree creation succeeds, continue the user's actual task instead of stopping at setup\n- If worktree creation fails because of filesystem permissions, request the minimal approval needed and retry\n\n## Uncommitted Change Policy\n\nThe safe default is isolation from uncommitted changes.\n\n- If the source checkout is dirty, still create the new worktree from `HEAD` unless the user explicitly asks to carry local edits over\n- Do not silently stash, reset, or move the user's existing changes\n- If the user wants local edits copied into the new worktree, use an explicit flow such as a temporary commit, patch, or cherry-pick, and say what you are doing\n\n## Output Contract\n\nWhen you use this skill:\n\n- Tell the user which branch and directory were created\n- Make it clear that subsequent work is now happening inside that path\n- Mention the source ref and whether the original checkout was dirty when that context matters\n- Do not stop after setup if the user asked for additional work; continue the task in the new worktree\n\n## Example\n\nUser request:\n\n```text\nCreate a separate worktree for this task and then start implementing it.\n```\n\nExpected behavior:\n\n- Inspect current repo status\n- Create a new `worktree/...` branch and sibling directory with direct `git worktree` commands\n- Switch all following commands to that directory\n- Continue the requested implementation there\n\n## Cleanup\n\nOnly remove a worktree when the user asks or when cleanup is clearly part of the task.\n\nBefore cleanup:\n\n- Check status in the worktree you created\n- Make sure you are removing the correct path\n- Never remove the user's original checkout\n",".agents/skills/openspec-propose/SKILL.md":"---\nname: openspec-propose\ndescription: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.2.0\"\n---\n\nPropose a new change - create the change and generate all artifacts in one step.\n\nI'll create a change with artifacts:\n- proposal.md (what & why)\n- design.md (how)\n- tasks.md (implementation steps)\n\nWhen ready to implement, run /opsx:apply\n\n\n**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.\n\n**Steps**\n\n1. **If no clear input provided, ask what they want to build**\n\n Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:\n > \"What change do you want to work on? Describe what you want to build or fix.\"\n\n From their description, derive a kebab-case name (e.g., \"add user authentication\" → `add-user-auth`).\n\n **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.\n\n2. **Create the change directory**\n ```bash\n openspec new change \"\"\n ```\n This creates a scaffolded change at `openspec/changes//` with `.openspec.yaml`.\n\n3. **Get the artifact build order**\n ```bash\n openspec status --change \"\" --json\n ```\n Parse the JSON to get:\n - `applyRequires`: array of artifact IDs needed before implementation (e.g., `[\"tasks\"]`)\n - `artifacts`: list of all artifacts with their status and dependencies\n\n4. **Create artifacts in sequence until apply-ready**\n\n Use the **TodoWrite tool** to track progress through the artifacts.\n\n Loop through artifacts in dependency order (artifacts with no pending dependencies first):\n\n a. **For each artifact that is `ready` (dependencies satisfied)**:\n - Get instructions:\n ```bash\n openspec instructions --change \"\" --json\n ```\n - The instructions JSON includes:\n - `context`: Project background (constraints for you - do NOT include in output)\n - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)\n - `template`: The structure to use for your output file\n - `instruction`: Schema-specific guidance for this artifact type\n - `outputPath`: Where to write the artifact\n - `dependencies`: Completed artifacts to read for context\n - Read any completed dependency files for context\n - Create the artifact file using `template` as the structure\n - Apply `context` and `rules` as constraints - but do NOT copy them into the file\n - Show brief progress: \"Created \"\n\n b. **Continue until all `applyRequires` artifacts are complete**\n - After creating each artifact, re-run `openspec status --change \"\" --json`\n - Check if every artifact ID in `applyRequires` has `status: \"done\"` in the artifacts array\n - Stop when all `applyRequires` artifacts are done\n\n c. **If an artifact requires user input** (unclear context):\n - Use **AskUserQuestion tool** to clarify\n - Then continue with creation\n\n5. **Show final status**\n ```bash\n openspec status --change \"\"\n ```\n\n**Output**\n\nAfter completing all artifacts, summarize:\n- Change name and location\n- List of artifacts created with brief descriptions\n- What's ready: \"All artifacts created! Ready for implementation.\"\n- Prompt: \"Run `/opsx:apply` or ask me to implement to start working on the tasks.\"\n\n**Artifact Creation Guidelines**\n\n- Follow the `instruction` field from `openspec instructions` for each artifact type\n- The schema defines what each artifact should contain - follow it\n- Read dependency artifacts for context before creating new ones\n- Use `template` as the structure for your output file - fill in its sections\n- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file\n - Do NOT copy ``, ``, `` blocks into the artifact\n - These guide what you write, but should never appear in the output\n\n**Guardrails**\n- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)\n- Always read dependency artifacts before creating a new one\n- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum\n- If a change with that name already exists, ask if user wants to continue it or create a new one\n- Verify each artifact file exists after writing before proceeding to next\n",".agents/skills/gf-feedback/SKILL.md":"---\nname: gf-feedback\ndescription: >-\n Track, fix, verify, and test any bugs, improvements, or gaps reported against an OpenSpec change.\n MUST use this skill whenever user reports problems, defects, issues, bugs, or gaps related to\n existing implementations, even if they don't explicitly say \"feedback\" or mention OpenSpec.\ncompatibility: Requires openspec CLI, Go toolchain, and gf-review skill.\n---\n\n# Feedback: Structured Fix, Verification & Test Coverage Loop\n\nWhen users discover bugs or improvement points after implementation, this skill captures those issues, organizes them into a traceable task list in `tasks.md`, systematically fixes and verifies each one, and ensures every behavior-changing fix is covered by focused unit tests.\n\n**Core principles:**\n1. **Spec is the source of truth** — Spec-level changes require spec update before task recording\n2. **Write it down first, then fix it** — Every issue gets recorded before any code change\n3. **Every fix deserves a test** — Behavior-changing code changes require unit test coverage in the affected package\n\n\n## Workflow\n\n### 1. Identify Target Change\n\n**CRITICAL:** \n1. Always append to existing active changes. Only create new change when none exist.\n2. An **active change** is any change directory that still exists directly under `openspec/changes/` and has **not** been moved into `openspec/changes/archive/`. Do **not** treat `status: complete`, all tasks checked off, or similar completion signals as \"inactive\" until archive actually happens.\n3. Regardless of whether the feedback content is related to the main functionality of the current active iteration, it MUST be appended to the current active iteration. This ensures all changes are tracked in a single change record for unified management and archiving.\n\n```bash\nopenspec list --json\n# Or: ls openspec/changes/ | grep -v archive\n```\n\nWhen the two signals disagree, prefer the filesystem rule:\n\n- If a change directory still exists under `openspec/changes/` and is not inside `archive/`, it is active.\n- `openspec list --json` may still report such a change as `status: complete`; that only means implementation tasks are done, **not** that the change is inactive.\n- Only archived changes under `openspec/changes/archive/` are inactive.\n\n| Active Changes | Action |\n|----------------|--------|\n| None | Create new change (see below) |\n| One | Auto-select it, announce and proceed |\n| Multiple | Ask user to select from list |\n\n**When multiple active changes exist:**\n```\nMultiple active changes detected. Which change should this feedback be appended to?\n\n1. config-management — System config CRUD management\n2. user-auth — User authentication enhancement\n\nPlease select 1 or 2:\n```\n\n**When no active change exists:**\n1. Derive kebab-case name from feedback (e.g., \"fix-menu-circular-ref\")\n2. If name exists, append suffix (\"-2\")\n3. Create: `openspec new change \"\"`\n4. Generate minimal `proposal.md` (one paragraph summarizing context)\n5. Skip `design.md` for pure bug fixes unless architectural changes needed\n\nAnnounce: \"Applying feedback fixes to change: ****\"\n\n\n### 2. Read Current Context\n\n| File | Purpose |\n|------|---------|\n| `tasks.md` | Task structure, naming conventions, numbering |\n| `design.md` | Architectural context |\n| `proposal.md` | Feature scope and intent |\n| `specs/` | Delta spec definitions |\n\n```bash\n# Locate existing unit tests in the impacted package before adding a new one\nrg --files | rg '_test\\\\.go$'\n```\n\n\n### 3. Analyze and Organize Issues\n\nFor each reported issue:\n\n**Classify by type:**\n- **bug** — Incorrect behavior, code doesn't match spec\n- **missing** — Feature incomplete, gaps in implementation\n- **ux** — UX improvement, no spec change needed\n- **test-gap** — Missing test coverage only\n\n**Classify by spec impact:**\n\n| Level | Definition | Action |\n|-------|------------|--------|\n| **implementation** | Spec is correct, code is wrong | Fix code only |\n| **spec-level** | Requirement missing/incomplete/changed | Update spec first, then fix |\n| **internal** | No user-observable change | Fix code, test optional |\n\n**Group related issues** — Same root cause → single task with multiple verification points.\n\n\n### 4. Update Delta Specs (for Spec-Level Issues Only)\n\nFor spec-level issues, update specs **before** recording tasks:\n\n1. Identify affected capability: `specs//spec.md`\n2. Apply delta operation:\n\n```markdown\n\n### Requirement: Parent Selector Circular Prevention\nThe system SHALL disable the current menu and all its descendants in the parent selector\nto prevent circular references.\n\n#### Scenario: Edit menu with children\nWHEN user edits a menu that has child menus\nTHEN the parent selector SHALL disable the current menu and all descendant menus\n\n\n### Requirement: Import Error Handling\nThe system SHALL display error messages when import fails.\n**MODIFIED:** Error messages SHALL include row number, field name, and validation failure reason.\n\n\n### Requirement: Legacy Import Format\nThe system SHALL support legacy CSV format.\n**REMOVED:** This format is no longer supported.\n**Migration:** Use the new CSV format with header row.\n```\n\n\n### 5. Write Task List to tasks.md\n\nAppend a **Feedback section** to `tasks.md`:\n\n```markdown\n## Feedback\n\n- [ ] **FB-1**: Parent selector allows circular references in menu edit\n- [ ] **FB-2**: Import error messages lack row and field details\n- [ ] **FB-3**: No test coverage for reset password feature\n```\n\n**Numbering:** Sequential `FB-1`, `FB-2`, etc. Continue from last number if section exists.\n\n**One line per task** — No sub-fields. Analysis happens during fix phase.\n\n**Confirm with user** before writing to file.\n\n**Test coverage planning (internal):**\n- Behavior-changing code change → Unit test required\n- Internal-only optimization → Unit test optional unless logic risk increased\n- Prefer extending the nearest `*_z_unit*_test.go` or `*_test.go` in the same package\n\n\n### 6. Execute Fixes (Loop)\n\nFor each task:\n\n**a. Announce:** `## Fixing FB-X: `\n\n**b. Investigate** — Read source files, confirm root cause\n\n**c. Implement** — Minimal, focused fix following existing patterns\n\n**d. Write/update unit tests** — Prefer the affected package's existing `*_z_unit*_test.go` or `*_test.go` files and keep assertions focused on the changed logic\n\n**e. Assess Impact Scope (MANDATORY)**\n\nAfter implementing, identify regression risk:\n\n| Change Type | Map To Tests |\n|-------------|--------------|\n| Package-level logic | Targeted test for changed function/method + package regression tests |\n| Shared utility | Utility package unit tests + highest-value dependent package tests already covering reuse |\n| DB/DAO logic | DAO/model package unit tests with focused fixtures, mocks, or test helpers |\n| Public API validation | Handler/service package unit tests that assert the changed validation path |\n| Refactor without behavior change | Existing package tests that prove behavior parity |\n\n```bash\n# Example: Find unit tests related to a changed symbol or package\nrg -l \"GenDao|gdao\" . -g '*_test.go'\n```\n\nAnnounce:\n```\n### Impact Analysis for FB-X\n- Modified: cmd/gf/internal/cmd/gendao/gendao.go\n- Affected package: cmd/gf/internal/cmd/gendao\n- Unit tests: cmd/gf/internal/cmd/gendao/gendao_test.go\n- Regression command: go test ./cmd/gf/internal/cmd/gendao -run 'TestGenDao'\n```\n\n**f. Verify (MANDATORY before marking complete)**\n\n1. Run new/updated unit tests for this task → **must pass**\n2. Run ALL identified package-level regression tests → **must pass**\n3. Only then: mark task `[x]` in tasks.md\n\nIf regression fails:\n- Fix inline if related to current change\n- Add as new FB task if separate issue\n\n**g. Run review** — Invoke `gf-review` skill after completion\n\n\n### 7. Comprehensive Verification\n\nAfter all fixes:\n\n1. Aggregate regression tests from all tasks\n2. Run full set in single pass\n3. Report:\n```\n### Comprehensive Verification Results\n- Total tests: N\n- Passed: N\n- Failed: N (list with details)\n- Regression tests: all passed ✓ / X failures\n```\n\nIf failures → add new FB tasks, loop to Step 6.\n\n\n### 8. Report Completion\n\n```markdown\n## Feedback Complete\n\n**Change:** \n**Issues reported:** X\n**Issues fixed:** Y/X\n**Tests added:** Z unit tests / focused assertions\n**Regression tests run:** R tests across N packages\n**Verification:** all passed / N issues remaining\n\n### Fixed This Session\n- [x] FB-1: ✓ (unit test: TestGenDao_FiltersInvalidTables | package: ./cmd/gf/internal/cmd/gendao ✓)\n- [x] FB-2: <title> ✓ (unit test: existing package coverage extended | package: ./cmd/gf/internal/cmd ✓)\n\n### Remaining (if any)\n- [ ] FB-3: <title> — blocked by <reason>\n```\n\n\n## Edge Cases\n\n| Situation | Handling |\n|-----------|----------|\n| Single issue | Still follow full workflow |\n| Missing test cases only | Classify as test-gap, implement tests |\n| Fix reveals more issues | Add as new FB tasks |\n| \"Bug\" is actually feature request | Re-classify as spec-level, update specs first |\n| Unit test not feasible (docs/spec only) | Note reason explicitly and skip only when no runtime code changes exist |\n| Multiple feedback rounds | All tasks in single Feedback section, sequential numbering |\n\n\n## Guardrails\n\n- **Append to active change if exists** — Never create new change when active ones exist\n- **Specs before tasks for spec-level issues** — Update delta specs first\n- **Write tasks before fixing** — Never code without recording\n- **Confirm task list with user** — User validates analysis\n- **Minimal fixes** — No refactoring beyond issue scope\n- **Behavior-changing fix needs unit test** — No exceptions unless the change is docs/spec only\n- **No green check without green unit tests** — Mark `[x]` only after tests pass\n- **Impact analysis mandatory** — Every fix requires package-level regression test identification\n- **Regression failures block completion** — Must resolve before marking done\n- **Update tasks.md in real time** — Mark complete immediately after verification\n- **Match file language** — Use same language as existing content in target file\n"},"files":{".agents/skills/gf-review/SKILL.md":"---\nname: gf-review\ndescription: >-\n Code and specification review for OpenSpec workflow. Triggers automatically after /opsx:apply\n task completion, after /gf-feedback task completion, and before /opsx:archive. Use when\n user requests code review, spec compliance check, or when explicitly invoked via /gf-review.\ncompatibility: Requires OpenSpec CLI and GoFrame v2 skill.\n---\n\n# GF Review\n\nStructured code and specification review for the OpenSpec development workflow.\n\n**Spec Source**: `AGENTS.md` is the single source of truth for all review criteria.\n\n\n## When This Skill Activates\n\n**Automatic triggers:**\n- After completing each task in `/opsx:apply`\n- After completing each task in `/gf-feedback`\n- Before executing `/opsx:archive`\n\n**Manual trigger:**\n- User explicitly requests: \"review this code\", \"check spec compliance\", \"/gf-review\"\n\n\n## Review Workflow\n\n### 1. Identify Scope\n\nDetermine what needs to be reviewed:\n\n1. **After task completion** — Review files modified/created by the completed task\n2. **Before archive** — Review all changes in the current OpenSpec change\n3. **Manual invocation** — Ask user to specify scope or use current change\n\n**Mandatory scope collection rules:**\n\n1. Start with repository status, not `git diff` alone:\n ```bash\n git status --short\n git ls-files --others --exclude-standard\n ```\n2. Treat **all tracked and untracked changes** as review candidates, including:\n - staged files\n - unstaged files\n - untracked files shown as `??`\n - untracked directories shown as `?? path/`\n3. When `git status --short` reports an untracked directory, expand it to concrete files before review:\n ```bash\n find <path> -type f\n # Or prefer:\n rg --files <path>\n ```\n4. If the task ran generators such as `make ctrl`, `make dao`, codegen scripts, or produced new test files, explicitly include the generated untracked files in review scope even if they do not appear in `git diff`.\n5. `git diff` may be used only as a secondary narrowing aid after status collection. It is **never sufficient by itself** for review scope definition.\n\nRun `openspec status --change \"<name>\" --json` to understand the current change state.\n\n### 2. Load Specifications\n\nRead `AGENTS.md` to load all specifications. This is the single source of truth.\n\n### 3. Backend Code Review\n\n**Trigger**: Changes to files under `apps/lina-core` directory\n\n1. Invoke `goframe-v2` skill for GoFrame framework conventions\n2. Check against `AGENTS.md` backend code specifications\n\n### 4. RESTful API Review\n\n**Trigger**: Any API endpoint changes\n\nCheck against `AGENTS.md` API design specifications.\n\n### 5. Project Specification Review\n\n**Trigger**: Any implementation changes\n\nCheck against `AGENTS.md` architecture design specifications and code development specifications.\n\n### 6. SQL Review\n\n**Trigger**: New or modified files under `apps/lina-core/manifest/sql/`、`apps/lina-core/manifest/sql/mock-data/`、`apps/lina-plugins/**/manifest/sql/` or SQL snippets embedded in related delivery docs\n\nCheck against `AGENTS.md` SQL file management specifications, at minimum covering:\n1. File naming, versioning, and single-iteration single-file rules\n2. Seed DML vs mock data separation\n3. **Idempotent execution safety** — SQL must be safe to run multiple times without duplicate-object errors or duplicate seed data; verify use of `IF [NOT] EXISTS`, `IF EXISTS`, `INSERT IGNORE`, or equivalent safe re-entry patterns\n4. **Seed write style compliance** — delivered SQL must reject `INSERT ... ON DUPLICATE KEY UPDATE` and reject explicit writes to `AUTO_INCREMENT` `id` columns in seed/mock/install data\n5. Whether schema/data changes still match the current change scope and deployment path\n\n### 7. Unit Test Review\n\n**Trigger**: New or modified Go implementation files, or new/modified Go unit test files matching `*_test.go`\n\nCheck at minimum:\n1. Behavior-changing Go code includes focused unit coverage in the same package, preferably by extending existing `*_z_unit*_test.go` or `*_test.go`\n2. Tests assert the changed logic directly instead of relying on broad workflow-level coverage when a package-level test is sufficient\n3. Verification uses targeted `go test ./path/to/pkg -run TestName` during development and package-level `go test ./path/to/pkg` for regression\n\n### 8. Generate Review Report\n\n```markdown\n## GF Review Report\n\n**Change:** <change-name>\n**Scope:** <task-specific / full change>\n**Files Reviewed:** <count>\n**Scope Source:** `git status --short` + `git ls-files --others --exclude-standard` + task/change context\n\n### Backend Code Review\n✓ All checks passed / ⚠ N issues found\n\n### RESTful API Review\n✓ All endpoints compliant / ⚠ N violations found\n\n### Project Spec Review\n✓ Compliant with AGENTS.md / ⚠ N violations found\n\n### SQL Review\n✓ No SQL changes / ✓ SQL changes compliant / ⚠ N SQL issues found\n\n### Unit Test Review\n✓ Unit tests are focused and sufficient / ⚠ N issues found\n\n### Summary\n- **Critical:** N (must fix before archive)\n- **Warnings:** N (recommended to fix)\n\n### Recommended Actions\n1. [Specific action with AGENTS.md reference]\n```\n\n\n## Issue Severity\n\n| Level | Behavior |\n|-------|----------|\n| **Critical** | Block archive, must fix |\n| **Warning** | Show but allow proceed |\n\n\n## Integration Points\n\n| Workflow Step | Behavior |\n|---------------|----------|\n| `/opsx:apply` task done | Review, offer to fix issues before next task |\n| `/gf-feedback` task done | Review, fix before marking complete |\n| `/opsx:archive` | Review all changes, block on critical issues |\n\n\n## Guardrails\n\n- **AGENTS.md is the single source of truth** — All spec references point to it\n- Only check categories relevant to changed files\n- Scope identification MUST include untracked files and expanded untracked directories; never rely on `git diff` alone\n- Behavior-changing Go code without focused unit tests is a review finding unless the author documents why tests are not applicable\n- Don't block on warnings — only critical issues block archive\n- Include file paths and line numbers in issue reports\n- Offer to fix issues automatically when straightforward\n",".agents/skills/git-commit-push/SKILL.md":"---\nname: git-commit-push\ndescription: Review the current git working tree, generate a commit message from the actual diff using the repository's commit or PR-title convention, commit all current changes on the active branch, and push that branch to `origin`. Use this whenever the user asks to \"commit\", \"push\", \"commit and push\", \"generate a commit message\", \"commit the current changes\", or wants the current branch changes sent upstream without hand-writing the git commands.\n---\n\n# Git Commit Push\n\nInspect the current repository changes, derive a concise commit subject that matches the repository convention, commit every current modification on the active branch, and push that branch to `origin`.\n\nThis skill is for execution, not just advice. When it triggers, actually run the git workflow unless the repository state makes that unsafe or impossible.\n\n## When To Use\n\n- The user asks you to commit the current changes, with or without asking for push\n- The user wants you to write the commit message from the diff instead of inventing one up front\n- The user mentions the repo's PR or commit naming convention and wants you to follow it\n- The user says things like \"commit the current branch\", \"help me commit\", \"commit and push\", \"generate a commit message and push\", or \"send these changes to origin\"\n\n## Core Behavior\n\n1. Confirm you are inside a Git repository and detect the active branch with `git branch --show-current`.\n2. Inspect the working tree before committing:\n - `git status --short --branch`\n - `git diff --stat`\n - `git diff --cached --stat`\n - `git diff -- . ':(exclude)package-lock.json'` or narrower path filters only when needed for readability\n3. If the repository contains `.github/PULL_REQUEST_TEMPLATE.MD`, read it and treat its PR-title rules as the default commit-subject convention.\n4. Generate a commit subject from the actual changed files and diff content, not from the user prompt alone.\n5. Stage every current modification on the branch with `git add -A`.\n6. Commit once with the generated message.\n7. Push the current branch to `origin` with `git push origin <current-branch>`.\n\n## Commit Message Rules\n\nThe commit message is formatted as follows: `<type>[optional scope]: <description>` For example, `fix(os/gtime): fix time zone issue`\n + `<type>` is mandatory and can be one of `fix`, `feat`, `build`, `ci`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`\n + `fix`: Used when a bug has been fixed.\n + `feat`: Used when a new feature has been added.\n + `build`: Used for modifications to the project build system, such as changes to dependencies, external interfaces, or upgrading Node version.\n + `ci`: Used for modifications to continuous integration processes, such as changes to Travis, Jenkins workflow configurations.\n + `docs`: Used for modifications to documentation, such as changes to README files, API documentation, etc.\n + `style`: Used for changes to code style, such as adjustments to indentation, spaces, blank lines, etc.\n + `refactor`: Used for code refactoring, such as changes to code structure, variable names, function names, without altering functionality.\n + `perf`: Used for performance optimization, such as improving code performance, reducing memory usage, etc.\n + `test`: Used for modifications to test cases, such as adding, deleting, or modifying test cases for code.\n + `chore`: Used for modifications to non-business-related code, such as changes to build processes or tool configurations.\n + After `<type>`, specify the affected package name or scope in parentheses, for example, `(os/gtime)`.\n + The part after the colon uses the verb tense + phrase that completes the blank in\n + Lowercase verb after the colon\n + No trailing period\n + Keep the title as short as possible. ideally under 76 characters or shorter\n+ If there is a corresponding issue, add either `fixes #1234` (the latter if this is not a complete fix) to this comment\n\n### Examples\n#### Commit message with description and breaking change footer\n```\nfeat: allow provided config object to extend other configs\nBREAKING CHANGE: `extends` key in config file is now used for extending other config files\n```\n\n#### Commit message with ! to draw attention to breaking change\n```\nfeat!: send an email to the customer when a product is shipped\n```\n\n#### Commit message with scope and ! to draw attention to breaking change\n```\nfeat(api)!: send an email to the customer when a product is shipped\n```\n\n#### Commit message with both ! and BREAKING CHANGE footer\n```\nfeat!: drop support for Node 6\nBREAKING CHANGE: use JavaScript features not available in Node 6.\n```\n\n#### Commit message with no body\n```\ndocs: correct spelling of CHANGELOG\n```\n\n#### Commit message with scope\n```\nfeat(lang): add Polish language\n```\n\n#### Commit message with multi-paragraph body and multiple footers\n```\nfix: prevent racing of requests\n\nIntroduce a request id and a reference to latest request. Dismiss\nincoming responses other than from latest request.\n\nRemove timeouts which were used to mitigate the racing issue but are\nobsolete now.\n\nReviewed-by: Z\nRefs: #123\n```\n\n## Execution Rules\n\n- Commit all current tracked and untracked changes in the working tree, because this skill is for \"commit the current state\" requests\n- If there are no changes, say so clearly and stop before commit or push\n- If `git branch --show-current` is empty, explain that `HEAD` is detached and stop unless the user explicitly asks you to commit from detached `HEAD`\n- Never use `--force`, `--force-with-lease`, or history-rewriting commands unless the user explicitly asks\n- If push fails because the remote branch moved, report the exact failure and stop instead of auto-rebasing or auto-merging\n- Do not silently drop files from the commit unless the user asked to exclude them\n\n## Suggested Command Flow\n\n```bash\ngit status --short --branch\ngit diff --stat\ngit diff --cached --stat\ntest -f .github/PULL_REQUEST_TEMPLATE.MD && sed -n '1,220p' .github/PULL_REQUEST_TEMPLATE.MD\nbranch_name=$(git branch --show-current)\ngit add -A\ngit commit -m \"<generated-subject>\"\ngit push origin \"$branch_name\"\n```\n\nInspect `git diff --cached` again after staging if the pre-stage diff was noisy or if untracked files materially change the scope.\n\n## Output Contract\n\nWhen you use this skill:\n\n- Tell the user which branch you committed\n- Provide the final commit subject you used\n- Mention that you staged all current changes\n- Report the push target as `origin/<branch>`\n- If commit or push did not happen, explain exactly why\n\n## Example\n\nUser request:\n\n```text\nGenerate a commit message that follows this repository's convention, then commit and push the current branch\n```\n\nExpected behavior:\n\n- Inspect the repo status and diff\n- Generate a conventional subject from the real changes\n- Run one commit for the whole current working tree\n- Push the active branch to `origin`\n",".agents/skills/openspec-explore/SKILL.md":"---\nname: openspec-explore\ndescription: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.2.0\"\n---\n\nEnter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.\n\n**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.\n\n**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.\n\n\n## The Stance\n\n- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script\n- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.\n- **Visual** - Use `mermaid` for architecture diagrams, flowcharts, and similar visuals. If you need line breaks inside `mermaid`, use `<br/>` instead of `\\n`. ASCII box-drawing is allowed only when mermaid is a poor fit, and those blocks must stay in English.\n- **Adaptive** - Follow interesting threads, pivot when new information emerges\n- **Patient** - Don't rush to conclusions, let the shape of the problem emerge\n- **Grounded** - Explore the actual codebase when relevant, don't just theorize\n\n\n## What You Might Do\n\nDepending on what the user brings, you might:\n\n**Explore the problem space**\n- Ask clarifying questions that emerge from what they said\n- Challenge assumptions\n- Reframe the problem\n- Find analogies\n\n**Investigate the codebase**\n- Map existing architecture relevant to the discussion\n- Find integration points\n- Identify patterns already in use\n- Surface hidden complexity\n\n**Compare options**\n- Brainstorm multiple approaches\n- Build comparison tables\n- Sketch tradeoffs\n- Recommend a path (if asked)\n\n**Visualize**\n\nUse `mermaid` for system diagrams, state machines, data flows, and architecture sketches:\n\n```mermaid\nflowchart LR\n A[\"State A\"] --> B[\"State B\"]\n```\n\n**Surface risks and unknowns**\n- Identify what could go wrong\n- Find gaps in understanding\n- Suggest spikes or investigations\n\n\n## OpenSpec Awareness\n\nYou have full context of the OpenSpec system. Use it naturally, don't force it.\n\n### Check for context\n\nAt the start, quickly check what exists:\n```bash\nopenspec list --json\n```\n\nThis tells you:\n- If there are active changes\n- Their names, schemas, and status\n- What the user might be working on\n\n### When no change exists\n\nThink freely. When insights crystallize, you might offer:\n\n- \"This feels solid enough to start a change. Want me to create a proposal?\"\n- Or keep exploring - no pressure to formalize\n\n### When a change exists\n\nIf the user mentions a change or you detect one is relevant:\n\n1. **Read existing artifacts for context**\n - `openspec/changes/<name>/proposal.md`\n - `openspec/changes/<name>/design.md`\n - `openspec/changes/<name>/tasks.md`\n - etc.\n\n2. **Reference them naturally in conversation**\n - \"Your design mentions using Redis, but we just realized SQLite fits better...\"\n - \"The proposal scopes this to premium users, but we're now thinking everyone...\"\n\n3. **Offer to capture when decisions are made**\n\n | Insight Type | Where to Capture |\n |--------------|------------------|\n | New requirement discovered | `specs/<capability>/spec.md` |\n | Requirement changed | `specs/<capability>/spec.md` |\n | Design decision made | `design.md` |\n | Scope changed | `proposal.md` |\n | New work identified | `tasks.md` |\n | Assumption invalidated | Relevant artifact |\n\n Example offers:\n - \"That's a design decision. Capture it in design.md?\"\n - \"This is a new requirement. Add it to specs?\"\n - \"This changes scope. Update the proposal?\"\n\n4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.\n\n\n## What You Don't Have To Do\n\n- Follow a script\n- Ask the same questions every time\n- Produce a specific artifact\n- Reach a conclusion\n- Stay on topic if a tangent is valuable\n- Be brief (this is thinking time)\n\n\n## Handling Different Entry Points\n\n**User brings a vague idea:**\n\n> User: I'm thinking about adding real-time collaboration\n\nReal-time collab is a big space. Let me think about this...\n\n```mermaid\nflowchart LR\n A[\"Awareness<br/>Presence\"] --> B[\"Coordination<br/>Cursors\"] --> C[\"Sync<br/>CRDT\"]\n```\n\nWhere's your head at?\n\n**User brings a specific problem:**\n\n> User: The auth system is a mess\n\nAfter reading the codebase:\n\n```mermaid\nflowchart TD\n G[\"Google OAuth\"] --> S[Session]\n GH[\"GitHub OAuth\"] --> S\n E[\"Email Magic\"] --> S\n S --> P[Perms]\n```\n\nI see three tangles. Which one's burning?\n\n**User is stuck mid-implementation:**\n\n> User: `/opsx:explore add-auth-system`\n> The OAuth integration is more complex than expected\n\nAfter reading change artifacts: you're on task 4, \"Implement OAuth flow\". Trace what's involved, explore options, then ask whether to update the design or add a spike task.\n\n**User wants to compare options:**\n\n> User: Should we use Postgres or SQLite?\n\nGeneric answer is boring. What's the context?\n\n> User: A CLI tool that tracks local dev environments\n\nThat changes everything.\n\n| | `SQLite` | `Postgres` |\n| --- | --- | --- |\n| Deployment | embedded | needs server |\n| Offline | yes | no |\n| Single file | yes | no |\n\n`SQLite`. Not even close. Unless... is there a sync component?\n\n\n## Ending Discovery\n\nThere's no required ending. Discovery might:\n\n- **Flow into a proposal**: \"Ready to start? I can create a change proposal.\"\n- **Result in artifact updates**: \"Updated design.md with these decisions\"\n- **Just provide clarity**: User has what they need, moves on\n- **Continue later**: \"We can pick this up anytime\"\n\nWhen it feels like things are crystallizing, you might summarize:\n\n```\n## What We Figured Out\n\n**The problem**: [crystallized understanding]\n\n**The approach**: [if one emerged]\n\n**Open questions**: [if any remain]\n\n**Next steps** (if ready):\n- Create a change proposal\n- Keep exploring: just keep talking\n```\n\nBut this summary is optional. Sometimes the thinking IS the value.\n\n\n## Guardrails\n\n- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.\n- **Don't fake understanding** - If something is unclear, dig deeper\n- **Don't rush** - Discovery is thinking time, not task time\n- **Don't force structure** - Let patterns emerge naturally\n- **Don't auto-capture** - Offer to save insights, don't just do it\n- **Do visualize** - A good mermaid diagram is worth many paragraphs\n- **Do explore the codebase** - Ground discussions in reality\n- **Do question assumptions** - Including the user's and your own\n",".agents/skills/git-worktree/SKILL.md":"---\nname: git-worktree\ndescription: Create and actively use an isolated git worktree for the user's task, then continue the task inside that new directory. Use this whenever the user asks for a separate worktree, isolated checkout, clean branch directory, safer parallel changes, or a fresh workspace to avoid unrelated local edits.\n---\n\n# Git Worktree\n\nCreate a dedicated `git worktree` for the current task, then keep working inside that new directory instead of the original checkout.\n\nThis skill is about execution, not just advice. When it triggers, actually create the worktree unless the repository state makes that impossible.\n\nDo not introduce helper scripts for this skill. Use direct `git` and shell commands inline.\n\n## When To Use\n\n- The user explicitly asks for a new `git worktree`, independent branch directory, or isolated workspace\n- The current checkout contains unrelated local changes and isolation is the safest way forward\n- The user wants parallel work on multiple tasks without stashing or disturbing the original worktree\n- The user says things like \"create a separate branch folder\", \"open a fresh worktree\", \"use a clean checkout\", or \"work in an isolated workspace\"\n\n## Core Rule\n\nAfter creating the worktree, treat the new path as the active working directory for the rest of the task.\n\nIn any agent environment, \"enter the directory\" means:\n\n- Run subsequent commands against the new worktree path\n- Apply all edits under that worktree path\n- Do not keep using the original checkout by accident\n- Confirm the handoff by running at least one follow-up command in the new worktree\n\nNever claim you \"switched\" unless your subsequent actions actually target the new `worktree_path`.\n\nIf your environment supports a per-command working directory, use it for every later command. If it does not, prefix later commands with an explicit `cd <worktree_path> && ...`.\n\n## Name Derivation\n\n- Derive a short ASCII kebab-case task slug from the user's real task, such as `login-timeout-fix` or `user-export`\n- Do not use generic names like `git-worktree`, `new-worktree`, or `task` unless the request is too vague\n- If the request is mostly non-ASCII or no good slug is obvious, fall back to `task-$(date +%Y%m%d-%H%M%S)`\n- Default branch prefix is `worktree/`\n- Default worktree directory is a sibling of the repository root, named `<repo-name>-<slug>`\n\n## Default Workflow\n\n1. Inspect the repository context from the current checkout:\n - `git rev-parse --show-toplevel`\n - `git branch --show-current`\n - `git status --short`\n - `git worktree list --porcelain`\n2. Decide a task slug yourself using the rules above\n3. Build branch and path names inline, then create the worktree with direct shell commands like:\n\n ```bash\n repo_root=$(git rev-parse --show-toplevel)\n repo_name=$(basename \"$repo_root\")\n parent_dir=$(dirname \"$repo_root\")\n source_branch=$(git -C \"$repo_root\" branch --show-current)\n if [ -n \"$source_branch\" ]; then\n source_ref=\"$source_branch\"\n else\n source_ref=\"HEAD@$(git -C \"$repo_root\" rev-parse --short HEAD)\"\n fi\n\n slug=\"<task-slug>\"\n base_branch=\"worktree/$slug\"\n branch_name=\"$base_branch\"\n base_path=\"$parent_dir/$repo_name-$slug\"\n worktree_path=\"$base_path\"\n index=2\n\n while git -C \"$repo_root\" show-ref --verify --quiet \"refs/heads/$branch_name\" || [ -e \"$worktree_path\" ]; do\n branch_name=\"${base_branch}-$index\"\n worktree_path=\"${base_path}-$index\"\n index=$((index + 1))\n done\n\n git -C \"$repo_root\" worktree add -b \"$branch_name\" \"$worktree_path\" HEAD\n ```\n\n4. Immediately verify the handoff inside the new worktree, for example:\n\n ```bash\n pwd\n git status --short --branch\n ```\n\n These verification commands must run against `worktree_path`.\n\n5. Announce the new active path briefly, then continue the main task there\n6. For the remainder of the task, use `worktree_path` as the working directory for every relevant command or edit operation\n\n## Behavior Rules\n\n- Default base ref is `HEAD` from the current checkout so uncommitted local changes are not dragged into the new worktree\n- If a branch name or path already exists, auto-increment it instead of failing\n- If you are already inside a non-default worktree and the user still wants another isolated workspace, create a new one from the current `HEAD`\n- If the directory is not a Git repository, explain that clearly and do not pretend a worktree was created\n- If worktree creation succeeds, continue the user's actual task instead of stopping at setup\n- If worktree creation fails because of filesystem permissions, request the minimal approval needed and retry\n\n## Uncommitted Change Policy\n\nThe safe default is isolation from uncommitted changes.\n\n- If the source checkout is dirty, still create the new worktree from `HEAD` unless the user explicitly asks to carry local edits over\n- Do not silently stash, reset, or move the user's existing changes\n- If the user wants local edits copied into the new worktree, use an explicit flow such as a temporary commit, patch, or cherry-pick, and say what you are doing\n\n## Output Contract\n\nWhen you use this skill:\n\n- Tell the user which branch and directory were created\n- Make it clear that subsequent work is now happening inside that path\n- Mention the source ref and whether the original checkout was dirty when that context matters\n- Do not stop after setup if the user asked for additional work; continue the task in the new worktree\n\n## Example\n\nUser request:\n\n```text\nCreate a separate worktree for this task and then start implementing it.\n```\n\nExpected behavior:\n\n- Inspect current repo status\n- Create a new `worktree/...` branch and sibling directory with direct `git worktree` commands\n- Switch all following commands to that directory\n- Continue the requested implementation there\n\n## Cleanup\n\nOnly remove a worktree when the user asks or when cleanup is clearly part of the task.\n\nBefore cleanup:\n\n- Check status in the worktree you created\n- Make sure you are removing the correct path\n- Never remove the user's original checkout\n",".agents/skills/openspec-propose/SKILL.md":"---\nname: openspec-propose\ndescription: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.2.0\"\n---\n\nPropose a new change - create the change and generate all artifacts in one step.\n\nI'll create a change with artifacts:\n- proposal.md (what & why)\n- design.md (how)\n- tasks.md (implementation steps)\n\nWhen ready to implement, run /opsx:apply\n\n\n**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.\n\n**Steps**\n\n1. **If no clear input provided, ask what they want to build**\n\n Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:\n > \"What change do you want to work on? Describe what you want to build or fix.\"\n\n From their description, derive a kebab-case name (e.g., \"add user authentication\" → `add-user-auth`).\n\n **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.\n\n2. **Create the change directory**\n ```bash\n openspec new change \"<name>\"\n ```\n This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.\n\n3. **Get the artifact build order**\n ```bash\n openspec status --change \"<name>\" --json\n ```\n Parse the JSON to get:\n - `applyRequires`: array of artifact IDs needed before implementation (e.g., `[\"tasks\"]`)\n - `artifacts`: list of all artifacts with their status and dependencies\n\n4. **Create artifacts in sequence until apply-ready**\n\n Use the **TodoWrite tool** to track progress through the artifacts.\n\n Loop through artifacts in dependency order (artifacts with no pending dependencies first):\n\n a. **For each artifact that is `ready` (dependencies satisfied)**:\n - Get instructions:\n ```bash\n openspec instructions <artifact-id> --change \"<name>\" --json\n ```\n - The instructions JSON includes:\n - `context`: Project background (constraints for you - do NOT include in output)\n - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)\n - `template`: The structure to use for your output file\n - `instruction`: Schema-specific guidance for this artifact type\n - `outputPath`: Where to write the artifact\n - `dependencies`: Completed artifacts to read for context\n - Read any completed dependency files for context\n - Create the artifact file using `template` as the structure\n - Apply `context` and `rules` as constraints - but do NOT copy them into the file\n - Show brief progress: \"Created <artifact-id>\"\n\n b. **Continue until all `applyRequires` artifacts are complete**\n - After creating each artifact, re-run `openspec status --change \"<name>\" --json`\n - Check if every artifact ID in `applyRequires` has `status: \"done\"` in the artifacts array\n - Stop when all `applyRequires` artifacts are done\n\n c. **If an artifact requires user input** (unclear context):\n - Use **AskUserQuestion tool** to clarify\n - Then continue with creation\n\n5. **Show final status**\n ```bash\n openspec status --change \"<name>\"\n ```\n\n**Output**\n\nAfter completing all artifacts, summarize:\n- Change name and location\n- List of artifacts created with brief descriptions\n- What's ready: \"All artifacts created! Ready for implementation.\"\n- Prompt: \"Run `/opsx:apply` or ask me to implement to start working on the tasks.\"\n\n**Artifact Creation Guidelines**\n\n- Follow the `instruction` field from `openspec instructions` for each artifact type\n- The schema defines what each artifact should contain - follow it\n- Read dependency artifacts for context before creating new ones\n- Use `template` as the structure for your output file - fill in its sections\n- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file\n - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact\n - These guide what you write, but should never appear in the output\n\n**Guardrails**\n- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)\n- Always read dependency artifacts before creating a new one\n- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum\n- If a change with that name already exists, ask if user wants to continue it or create a new one\n- Verify each artifact file exists after writing before proceeding to next\n",".agents/skills/gf-feedback/SKILL.md":"---\nname: gf-feedback\ndescription: >-\n Track, fix, verify, and test any bugs, improvements, or gaps reported against an OpenSpec change.\n MUST use this skill whenever user reports problems, defects, issues, bugs, or gaps related to\n existing implementations, even if they don't explicitly say \"feedback\" or mention OpenSpec.\ncompatibility: Requires openspec CLI, Go toolchain, and gf-review skill.\n---\n\n# Feedback: Structured Fix, Verification & Test Coverage Loop\n\nWhen users discover bugs or improvement points after implementation, this skill captures those issues, organizes them into a traceable task list in `tasks.md`, systematically fixes and verifies each one, and ensures every behavior-changing fix is covered by focused unit tests.\n\n**Core principles:**\n1. **Spec is the source of truth** — Spec-level changes require spec update before task recording\n2. **Write it down first, then fix it** — Every issue gets recorded before any code change\n3. **Every fix deserves a test** — Behavior-changing code changes require unit test coverage in the affected package\n\n\n## Workflow\n\n### 1. Identify Target Change\n\n**CRITICAL:** \n1. Always append to existing active changes. Only create new change when none exist.\n2. An **active change** is any change directory that still exists directly under `openspec/changes/` and has **not** been moved into `openspec/changes/archive/`. Do **not** treat `status: complete`, all tasks checked off, or similar completion signals as \"inactive\" until archive actually happens.\n3. Regardless of whether the feedback content is related to the main functionality of the current active iteration, it MUST be appended to the current active iteration. This ensures all changes are tracked in a single change record for unified management and archiving.\n\n```bash\nopenspec list --json\n# Or: ls openspec/changes/ | grep -v archive\n```\n\nWhen the two signals disagree, prefer the filesystem rule:\n\n- If a change directory still exists under `openspec/changes/` and is not inside `archive/`, it is active.\n- `openspec list --json` may still report such a change as `status: complete`; that only means implementation tasks are done, **not** that the change is inactive.\n- Only archived changes under `openspec/changes/archive/` are inactive.\n\n| Active Changes | Action |\n|----------------|--------|\n| None | Create new change (see below) |\n| One | Auto-select it, announce and proceed |\n| Multiple | Ask user to select from list |\n\n**When multiple active changes exist:**\n```\nMultiple active changes detected. Which change should this feedback be appended to?\n\n1. config-management — System config CRUD management\n2. user-auth — User authentication enhancement\n\nPlease select 1 or 2:\n```\n\n**When no active change exists:**\n1. Derive kebab-case name from feedback (e.g., \"fix-menu-circular-ref\")\n2. If name exists, append suffix (\"-2\")\n3. Create: `openspec new change \"<name>\"`\n4. Generate minimal `proposal.md` (one paragraph summarizing context)\n5. Skip `design.md` for pure bug fixes unless architectural changes needed\n\nAnnounce: \"Applying feedback fixes to change: **<name>**\"\n\n\n### 2. Read Current Context\n\n| File | Purpose |\n|------|---------|\n| `tasks.md` | Task structure, naming conventions, numbering |\n| `design.md` | Architectural context |\n| `proposal.md` | Feature scope and intent |\n| `specs/` | Delta spec definitions |\n\n```bash\n# Locate existing unit tests in the impacted package before adding a new one\nrg --files <pkg-dir> | rg '_test\\\\.go$'\n```\n\n\n### 3. Analyze and Organize Issues\n\nFor each reported issue:\n\n**Classify by type:**\n- **bug** — Incorrect behavior, code doesn't match spec\n- **missing** — Feature incomplete, gaps in implementation\n- **ux** — UX improvement, no spec change needed\n- **test-gap** — Missing test coverage only\n\n**Classify by spec impact:**\n\n| Level | Definition | Action |\n|-------|------------|--------|\n| **implementation** | Spec is correct, code is wrong | Fix code only |\n| **spec-level** | Requirement missing/incomplete/changed | Update spec first, then fix |\n| **internal** | No user-observable change | Fix code, test optional |\n\n**Group related issues** — Same root cause → single task with multiple verification points.\n\n\n### 4. Update Delta Specs (for Spec-Level Issues Only)\n\nFor spec-level issues, update specs **before** recording tasks:\n\n1. Identify affected capability: `specs/<capability>/spec.md`\n2. Apply delta operation:\n\n```markdown\n<!-- ADDED: New requirement -->\n### Requirement: Parent Selector Circular Prevention\nThe system SHALL disable the current menu and all its descendants in the parent selector\nto prevent circular references.\n\n#### Scenario: Edit menu with children\nWHEN user edits a menu that has child menus\nTHEN the parent selector SHALL disable the current menu and all descendant menus\n\n<!-- MODIFIED: Changed requirement (include full original block) -->\n### Requirement: Import Error Handling\nThe system SHALL display error messages when import fails.\n**MODIFIED:** Error messages SHALL include row number, field name, and validation failure reason.\n\n<!-- REMOVED: Deprecated requirement -->\n### Requirement: Legacy Import Format\nThe system SHALL support legacy CSV format.\n**REMOVED:** This format is no longer supported.\n**Migration:** Use the new CSV format with header row.\n```\n\n\n### 5. Write Task List to tasks.md\n\nAppend a **Feedback section** to `tasks.md`:\n\n```markdown\n## Feedback\n\n- [ ] **FB-1**: Parent selector allows circular references in menu edit\n- [ ] **FB-2**: Import error messages lack row and field details\n- [ ] **FB-3**: No test coverage for reset password feature\n```\n\n**Numbering:** Sequential `FB-1`, `FB-2`, etc. Continue from last number if section exists.\n\n**One line per task** — No sub-fields. Analysis happens during fix phase.\n\n**Confirm with user** before writing to file.\n\n**Test coverage planning (internal):**\n- Behavior-changing code change → Unit test required\n- Internal-only optimization → Unit test optional unless logic risk increased\n- Prefer extending the nearest `*_z_unit*_test.go` or `*_test.go` in the same package\n\n\n### 6. Execute Fixes (Loop)\n\nFor each task:\n\n**a. Announce:** `## Fixing FB-X: <issue title>`\n\n**b. Investigate** — Read source files, confirm root cause\n\n**c. Implement** — Minimal, focused fix following existing patterns\n\n**d. Write/update unit tests** — Prefer the affected package's existing `*_z_unit*_test.go` or `*_test.go` files and keep assertions focused on the changed logic\n\n**e. Assess Impact Scope (MANDATORY)**\n\nAfter implementing, identify regression risk:\n\n| Change Type | Map To Tests |\n|-------------|--------------|\n| Package-level logic | Targeted test for changed function/method + package regression tests |\n| Shared utility | Utility package unit tests + highest-value dependent package tests already covering reuse |\n| DB/DAO logic | DAO/model package unit tests with focused fixtures, mocks, or test helpers |\n| Public API validation | Handler/service package unit tests that assert the changed validation path |\n| Refactor without behavior change | Existing package tests that prove behavior parity |\n\n```bash\n# Example: Find unit tests related to a changed symbol or package\nrg -l \"GenDao|gdao\" . -g '*_test.go'\n```\n\nAnnounce:\n```\n### Impact Analysis for FB-X\n- Modified: cmd/gf/internal/cmd/gendao/gendao.go\n- Affected package: cmd/gf/internal/cmd/gendao\n- Unit tests: cmd/gf/internal/cmd/gendao/gendao_test.go\n- Regression command: go test ./cmd/gf/internal/cmd/gendao -run 'TestGenDao'\n```\n\n**f. Verify (MANDATORY before marking complete)**\n\n1. Run new/updated unit tests for this task → **must pass**\n2. Run ALL identified package-level regression tests → **must pass**\n3. Only then: mark task `[x]` in tasks.md\n\nIf regression fails:\n- Fix inline if related to current change\n- Add as new FB task if separate issue\n\n**g. Run review** — Invoke `gf-review` skill after completion\n\n\n### 7. Comprehensive Verification\n\nAfter all fixes:\n\n1. Aggregate regression tests from all tasks\n2. Run full set in single pass\n3. Report:\n```\n### Comprehensive Verification Results\n- Total tests: N\n- Passed: N\n- Failed: N (list with details)\n- Regression tests: all passed ✓ / X failures\n```\n\nIf failures → add new FB tasks, loop to Step 6.\n\n\n### 8. Report Completion\n\n```markdown\n## Feedback Complete\n\n**Change:** <name>\n**Issues reported:** X\n**Issues fixed:** Y/X\n**Tests added:** Z unit tests / focused assertions\n**Regression tests run:** R tests across N packages\n**Verification:** all passed / N issues remaining\n\n### Fixed This Session\n- [x] FB-1: <title> ✓ (unit test: TestGenDao_FiltersInvalidTables | package: ./cmd/gf/internal/cmd/gendao ✓)\n- [x] FB-2: <title> ✓ (unit test: existing package coverage extended | package: ./cmd/gf/internal/cmd ✓)\n\n### Remaining (if any)\n- [ ] FB-3: <title> — blocked by <reason>\n```\n\n\n## Edge Cases\n\n| Situation | Handling |\n|-----------|----------|\n| Single issue | Still follow full workflow |\n| Missing test cases only | Classify as test-gap, implement tests |\n| Fix reveals more issues | Add as new FB tasks |\n| \"Bug\" is actually feature request | Re-classify as spec-level, update specs first |\n| Unit test not feasible (docs/spec only) | Note reason explicitly and skip only when no runtime code changes exist |\n| Multiple feedback rounds | All tasks in single Feedback section, sequential numbering |\n\n\n## Guardrails\n\n- **Append to active change if exists** — Never create new change when active ones exist\n- **Specs before tasks for spec-level issues** — Update delta specs first\n- **Write tasks before fixing** — Never code without recording\n- **Confirm task list with user** — User validates analysis\n- **Minimal fixes** — No refactoring beyond issue scope\n- **Behavior-changing fix needs unit test** — No exceptions unless the change is docs/spec only\n- **No green check without green unit tests** — Mark `[x]` only after tests pass\n- **Impact analysis mandatory** — Every fix requires package-level regression test identification\n- **Regression failures block completion** — Must resolve before marking done\n- **Update tasks.md in real time** — Mark complete immediately after verification\n- **Match file language** — Use same language as existing content in target file\n"},"items":[{"name":"SKILL.md","path":".agents/skills/gf-feedback/SKILL.md","rawUrl":"https://raw.githubusercontent.com/gogf/gf/HEAD/.agents/skills/gf-feedback/SKILL.md","title":"gf-feedback","category":"anthropic-skill","format":"markdown","content":"---\nname: gf-feedback\ndescription: >-\n Track, fix, verify, and test any bugs, improvements, or gaps reported against an OpenSpec change.\n MUST use this skill whenever user reports problems, defects, issues, bugs, or gaps related to\n existing implementations, even if they don't explicitly say \"feedback\" or mention OpenSpec.\ncompatibility: Requires openspec CLI, Go toolchain, and gf-review skill.\n---\n\n# Feedback: Structured Fix, Verification & Test Coverage Loop\n\nWhen users discover bugs or improvement points after implementation, this skill captures those issues, organizes them into a traceable task list in `tasks.md`, systematically fixes and verifies each one, and ensures every behavior-changing fix is covered by focused unit tests.\n\n**Core principles:**\n1. **Spec is the source of truth** — Spec-level changes require spec update before task recording\n2. **Write it down first, then fix it** — Every issue gets recorded before any code change\n3. **Every fix deserves a test** — Behavior-changing code changes require unit test coverage in the affected package\n\n\n## Workflow\n\n### 1. Identify Target Change\n\n**CRITICAL:** \n1. Always append to existing active changes. Only create new change when none exist.\n2. An **active change** is any change directory that still exists directly under `openspec/changes/` and has **not** been moved into `openspec/changes/archive/`. Do **not** treat `status: complete`, all tasks checked off, or similar completion signals as \"inactive\" until archive actually happens.\n3. Regardless of whether the feedback content is related to the main functionality of the current active iteration, it MUST be appended to the current active iteration. This ensures all changes are tracked in a single change record for unified management and archiving.\n\n```bash\nopenspec list --json\n# Or: ls openspec/changes/ | grep -v archive\n```\n\nWhen the two signals disagree, prefer the filesystem rule:\n\n- If a change directory still exists under `openspec/changes/` and is not inside `archive/`, it is active.\n- `openspec list --json` may still report such a change as `status: complete`; that only means implementation tasks are done, **not** that the change is inactive.\n- Only archived changes under `openspec/changes/archive/` are inactive.\n\n| Active Changes | Action |\n|----------------|--------|\n| None | Create new change (see below) |\n| One | Auto-select it, announce and proceed |\n| Multiple | Ask user to select from list |\n\n**When multiple active changes exist:**\n```\nMultiple active changes detected. Which change should this feedback be appended to?\n\n1. config-management — System config CRUD management\n2. user-auth — User authentication enhancement\n\nPlease select 1 or 2:\n```\n\n**When no active change exists:**\n1. Derive kebab-case name from feedback (e.g., \"fix-menu-circular-ref\")\n2. If name exists, append suffix (\"-2\")\n3. Create: `openspec new change \"<name>\"`\n4. Generate minimal `proposal.md` (one paragraph summarizing context)\n5. Skip `design.md` for pure bug fixes unless architectural changes needed\n\nAnnounce: \"Applying feedback fixes to change: **<name>**\"\n\n\n### 2. Read Current Context\n\n| File | Purpose |\n|------|---------|\n| `tasks.md` | Task structure, naming conventions, numbering |\n| `design.md` | Architectural context |\n| `proposal.md` | Feature scope and intent |\n| `specs/` | Delta spec definitions |\n\n```bash\n# Locate existing unit tests in the impacted package before adding a new one\nrg --files <pkg-dir> | rg '_test\\\\.go$'\n```\n\n\n### 3. Analyze and Organize Issues\n\nFor each reported issue:\n\n**Classify by type:**\n- **bug** — Incorrect behavior, code doesn't match spec\n- **missing** — Feature incomplete, gaps in implementation\n- **ux** — UX improvement, no spec change needed\n- **test-gap** — Missing test coverage only\n\n**Classify by spec impact:**\n\n| Level | Definition | Action |\n|-------|------------|--------|\n| **implementation** | Spec is correct, code is wrong | Fix code only |\n| **spec-level** | Requirement missing/incomplete/changed | Update spec first, then fix |\n| **internal** | No user-observable change | Fix code, test optional |\n\n**Group related issues** — Same root cause → single task with multiple verification points.\n\n\n### 4. Update Delta Specs (for Spec-Level Issues Only)\n\nFor spec-level issues, update specs **before** recording tasks:\n\n1. Identify affected capability: `specs/<capability>/spec.md`\n2. Apply delta operation:\n\n```markdown\n<!-- ADDED: New requirement -->\n### Requirement: Parent Selector Circular Prevention\nThe system SHALL disable the current menu and all its descendants in the parent selector\nto prevent circular references.\n\n#### Scenario: Edit menu with children\nWHEN user edits a menu that has child menus\nTHEN the parent selector SHALL disable the current menu and all descendant menus\n\n<!-- MODIFIED: Changed requirement (include full original block) -->\n### Requirement: Import Error Handling\nThe system SHALL display error messages when import fails.\n**MODIFIED:** Error messages SHALL include row number, field name, and validation failure reason.\n\n<!-- REMOVED: Deprecated requirement -->\n### Requirement: Legacy Import Format\nThe system SHALL support legacy CSV format.\n**REMOVED:** This format is no longer supported.\n**Migration:** Use the new CSV format with header row.\n```\n\n\n### 5. Write Task List to tasks.md\n\nAppend a **Feedback section** to `tasks.md`:\n\n```markdown\n## Feedback\n\n- [ ] **FB-1**: Parent selector allows circular references in menu edit\n- [ ] **FB-2**: Import error messages lack row and field details\n- [ ] **FB-3**: No test coverage for reset password feature\n```\n\n**Numbering:** Sequential `FB-1`, `FB-2`, etc. Continue from last number if section exists.\n\n**One line per task** — No sub-fields. Analysis happens during fix phase.\n\n**Confirm with user** before writing to file.\n\n**Test coverage planning (internal):**\n- Behavior-changing code change → Unit test required\n- Internal-only optimization → Unit test optional unless logic risk increased\n- Prefer extending the nearest `*_z_unit*_test.go` or `*_test.go` in the same package\n\n\n### 6. Execute Fixes (Loop)\n\nFor each task:\n\n**a. Announce:** `## Fixing FB-X: <issue title>`\n\n**b. Investigate** — Read source files, confirm root cause\n\n**c. Implement** — Minimal, focused fix following existing patterns\n\n**d. Write/update unit tests** — Prefer the affected package's existing `*_z_unit*_test.go` or `*_test.go` files and keep assertions focused on the changed logic\n\n**e. Assess Impact Scope (MANDATORY)**\n\nAfter implementing, identify regression risk:\n\n| Change Type | Map To Tests |\n|-------------|--------------|\n| Package-level logic | Targeted test for changed function/method + package regression tests |\n| Shared utility | Utility package unit tests + highest-value dependent package tests already covering reuse |\n| DB/DAO logic | DAO/model package unit tests with focused fixtures, mocks, or test helpers |\n| Public API validation | Handler/service package unit tests that assert the changed validation path |\n| Refactor without behavior change | Existing package tests that prove behavior parity |\n\n```bash\n# Example: Find unit tests related to a changed symbol or package\nrg -l \"GenDao|gdao\" . -g '*_test.go'\n```\n\nAnnounce:\n```\n### Impact Analysis for FB-X\n- Modified: cmd/gf/internal/cmd/gendao/gendao.go\n- Affected package: cmd/gf/internal/cmd/gendao\n- Unit tests: cmd/gf/internal/cmd/gendao/gendao_test.go\n- Regression command: go test ./cmd/gf/internal/cmd/gendao -run 'TestGenDao'\n```\n\n**f. Verify (MANDATORY before marking complete)**\n\n1. Run new/updated unit tests for this task → **must pass**\n2. Run ALL identified package-level regression tests → **must pass**\n3. Only then: mark task `[x]` in tasks.md\n\nIf regression fails:\n- Fix inline if related to current change\n- Add as new FB task if separate issue\n\n**g. Run review** — Invoke `gf-review` skill after completion\n\n\n### 7. Comprehensive Verification\n\nAfter all fixes:\n\n1. Aggregate regression tests from all tasks\n2. Run full set in single pass\n3. Report:\n```\n### Comprehensive Verification Results\n- Total tests: N\n- Passed: N\n- Failed: N (list with details)\n- Regression tests: all passed ✓ / X failures\n```\n\nIf failures → add new FB tasks, loop to Step 6.\n\n\n### 8. Report Completion\n\n```markdown\n## Feedback Complete\n\n**Change:** <name>\n**Issues reported:** X\n**Issues fixed:** Y/X\n**Tests added:** Z unit tests / focused assertions\n**Regression tests run:** R tests across N packages\n**Verification:** all passed / N issues remaining\n\n### Fixed This Session\n- [x] FB-1: <title> ✓ (unit test: TestGenDao_FiltersInvalidTables | package: ./cmd/gf/internal/cmd/gendao ✓)\n- [x] FB-2: <title> ✓ (unit test: existing package coverage extended | package: ./cmd/gf/internal/cmd ✓)\n\n### Remaining (if any)\n- [ ] FB-3: <title> — blocked by <reason>\n```\n\n\n## Edge Cases\n\n| Situation | Handling |\n|-----------|----------|\n| Single issue | Still follow full workflow |\n| Missing test cases only | Classify as test-gap, implement tests |\n| Fix reveals more issues | Add as new FB tasks |\n| \"Bug\" is actually feature request | Re-classify as spec-level, update specs first |\n| Unit test not feasible (docs/spec only) | Note reason explicitly and skip only when no runtime code changes exist |\n| Multiple feedback rounds | All tasks in single Feedback section, sequential numbering |\n\n\n## Guardrails\n\n- **Append to active change if exists** — Never create new change when active ones exist\n- **Specs before tasks for spec-level issues** — Update delta specs first\n- **Write tasks before fixing** — Never code without recording\n- **Confirm task list with user** — User validates analysis\n- **Minimal fixes** — No refactoring beyond issue scope\n- **Behavior-changing fix needs unit test** — No exceptions unless the change is docs/spec only\n- **No green check without green unit tests** — Mark `[x]` only after tests pass\n- **Impact analysis mandatory** — Every fix requires package-level regression test identification\n- **Regression failures block completion** — Must resolve before marking done\n- **Update tasks.md in real time** — Mark complete immediately after verification\n- **Match file language** — Use same language as existing content in target file\n","frontmatter":{"name":"gf-feedback","description":"Track, fix, verify, and test any bugs, improvements, or gaps reported against an OpenSpec change. MUST use this skill whenever user reports problems, defects, issues, bugs, or gaps related to existing implementations, even if they don't explicitly say \"feedback\" or mention OpenSpec.","compatibility":"Requires openspec CLI, Go toolchain, and gf-review skill."},"isInternal":false,"tokens":2332,"sizeBytes":10305},{"name":"SKILL.md","path":".agents/skills/gf-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/gogf/gf/HEAD/.agents/skills/gf-review/SKILL.md","title":"gf-review","category":"anthropic-skill","format":"markdown","content":"---\nname: gf-review\ndescription: >-\n Code and specification review for OpenSpec workflow. Triggers automatically after /opsx:apply\n task completion, after /gf-feedback task completion, and before /opsx:archive. Use when\n user requests code review, spec compliance check, or when explicitly invoked via /gf-review.\ncompatibility: Requires OpenSpec CLI and GoFrame v2 skill.\n---\n\n# GF Review\n\nStructured code and specification review for the OpenSpec development workflow.\n\n**Spec Source**: `AGENTS.md` is the single source of truth for all review criteria.\n\n\n## When This Skill Activates\n\n**Automatic triggers:**\n- After completing each task in `/opsx:apply`\n- After completing each task in `/gf-feedback`\n- Before executing `/opsx:archive`\n\n**Manual trigger:**\n- User explicitly requests: \"review this code\", \"check spec compliance\", \"/gf-review\"\n\n\n## Review Workflow\n\n### 1. Identify Scope\n\nDetermine what needs to be reviewed:\n\n1. **After task completion** — Review files modified/created by the completed task\n2. **Before archive** — Review all changes in the current OpenSpec change\n3. **Manual invocation** — Ask user to specify scope or use current change\n\n**Mandatory scope collection rules:**\n\n1. Start with repository status, not `git diff` alone:\n ```bash\n git status --short\n git ls-files --others --exclude-standard\n ```\n2. Treat **all tracked and untracked changes** as review candidates, including:\n - staged files\n - unstaged files\n - untracked files shown as `??`\n - untracked directories shown as `?? path/`\n3. When `git status --short` reports an untracked directory, expand it to concrete files before review:\n ```bash\n find <path> -type f\n # Or prefer:\n rg --files <path>\n ```\n4. If the task ran generators such as `make ctrl`, `make dao`, codegen scripts, or produced new test files, explicitly include the generated untracked files in review scope even if they do not appear in `git diff`.\n5. `git diff` may be used only as a secondary narrowing aid after status collection. It is **never sufficient by itself** for review scope definition.\n\nRun `openspec status --change \"<name>\" --json` to understand the current change state.\n\n### 2. Load Specifications\n\nRead `AGENTS.md` to load all specifications. This is the single source of truth.\n\n### 3. Backend Code Review\n\n**Trigger**: Changes to files under `apps/lina-core` directory\n\n1. Invoke `goframe-v2` skill for GoFrame framework conventions\n2. Check against `AGENTS.md` backend code specifications\n\n### 4. RESTful API Review\n\n**Trigger**: Any API endpoint changes\n\nCheck against `AGENTS.md` API design specifications.\n\n### 5. Project Specification Review\n\n**Trigger**: Any implementation changes\n\nCheck against `AGENTS.md` architecture design specifications and code development specifications.\n\n### 6. SQL Review\n\n**Trigger**: New or modified files under `apps/lina-core/manifest/sql/`、`apps/lina-core/manifest/sql/mock-data/`、`apps/lina-plugins/**/manifest/sql/` or SQL snippets embedded in related delivery docs\n\nCheck against `AGENTS.md` SQL file management specifications, at minimum covering:\n1. File naming, versioning, and single-iteration single-file rules\n2. Seed DML vs mock data separation\n3. **Idempotent execution safety** — SQL must be safe to run multiple times without duplicate-object errors or duplicate seed data; verify use of `IF [NOT] EXISTS`, `IF EXISTS`, `INSERT IGNORE`, or equivalent safe re-entry patterns\n4. **Seed write style compliance** — delivered SQL must reject `INSERT ... ON DUPLICATE KEY UPDATE` and reject explicit writes to `AUTO_INCREMENT` `id` columns in seed/mock/install data\n5. Whether schema/data changes still match the current change scope and deployment path\n\n### 7. Unit Test Review\n\n**Trigger**: New or modified Go implementation files, or new/modified Go unit test files matching `*_test.go`\n\nCheck at minimum:\n1. Behavior-changing Go code includes focused unit coverage in the same package, preferably by extending existing `*_z_unit*_test.go` or `*_test.go`\n2. Tests assert the changed logic directly instead of relying on broad workflow-level coverage when a package-level test is sufficient\n3. Verification uses targeted `go test ./path/to/pkg -run TestName` during development and package-level `go test ./path/to/pkg` for regression\n\n### 8. Generate Review Report\n\n```markdown\n## GF Review Report\n\n**Change:** <change-name>\n**Scope:** <task-specific / full change>\n**Files Reviewed:** <count>\n**Scope Source:** `git status --short` + `git ls-files --others --exclude-standard` + task/change context\n\n### Backend Code Review\n✓ All checks passed / ⚠ N issues found\n\n### RESTful API Review\n✓ All endpoints compliant / ⚠ N violations found\n\n### Project Spec Review\n✓ Compliant with AGENTS.md / ⚠ N violations found\n\n### SQL Review\n✓ No SQL changes / ✓ SQL changes compliant / ⚠ N SQL issues found\n\n### Unit Test Review\n✓ Unit tests are focused and sufficient / ⚠ N issues found\n\n### Summary\n- **Critical:** N (must fix before archive)\n- **Warnings:** N (recommended to fix)\n\n### Recommended Actions\n1. [Specific action with AGENTS.md reference]\n```\n\n\n## Issue Severity\n\n| Level | Behavior |\n|-------|----------|\n| **Critical** | Block archive, must fix |\n| **Warning** | Show but allow proceed |\n\n\n## Integration Points\n\n| Workflow Step | Behavior |\n|---------------|----------|\n| `/opsx:apply` task done | Review, offer to fix issues before next task |\n| `/gf-feedback` task done | Review, fix before marking complete |\n| `/opsx:archive` | Review all changes, block on critical issues |\n\n\n## Guardrails\n\n- **AGENTS.md is the single source of truth** — All spec references point to it\n- Only check categories relevant to changed files\n- Scope identification MUST include untracked files and expanded untracked directories; never rely on `git diff` alone\n- Behavior-changing Go code without focused unit tests is a review finding unless the author documents why tests are not applicable\n- Don't block on warnings — only critical issues block archive\n- Include file paths and line numbers in issue reports\n- Offer to fix issues automatically when straightforward\n","frontmatter":{"name":"gf-review","description":"Code and specification review for OpenSpec workflow. Triggers automatically after /opsx:apply task completion, after /gf-feedback task completion, and before /opsx:archive. Use when user requests code review, spec compliance check, or when explicitly invoked via /gf-review.","compatibility":"Requires OpenSpec CLI and GoFrame v2 skill."},"isInternal":false,"tokens":1402,"sizeBytes":6160},{"name":"SKILL.md","path":".agents/skills/git-commit-push/SKILL.md","rawUrl":"https://raw.githubusercontent.com/gogf/gf/HEAD/.agents/skills/git-commit-push/SKILL.md","title":"git-commit-push","category":"anthropic-skill","format":"markdown","content":"---\nname: git-commit-push\ndescription: Review the current git working tree, generate a commit message from the actual diff using the repository's commit or PR-title convention, commit all current changes on the active branch, and push that branch to `origin`. Use this whenever the user asks to \"commit\", \"push\", \"commit and push\", \"generate a commit message\", \"commit the current changes\", or wants the current branch changes sent upstream without hand-writing the git commands.\n---\n\n# Git Commit Push\n\nInspect the current repository changes, derive a concise commit subject that matches the repository convention, commit every current modification on the active branch, and push that branch to `origin`.\n\nThis skill is for execution, not just advice. When it triggers, actually run the git workflow unless the repository state makes that unsafe or impossible.\n\n## When To Use\n\n- The user asks you to commit the current changes, with or without asking for push\n- The user wants you to write the commit message from the diff instead of inventing one up front\n- The user mentions the repo's PR or commit naming convention and wants you to follow it\n- The user says things like \"commit the current branch\", \"help me commit\", \"commit and push\", \"generate a commit message and push\", or \"send these changes to origin\"\n\n## Core Behavior\n\n1. Confirm you are inside a Git repository and detect the active branch with `git branch --show-current`.\n2. Inspect the working tree before committing:\n - `git status --short --branch`\n - `git diff --stat`\n - `git diff --cached --stat`\n - `git diff -- . ':(exclude)package-lock.json'` or narrower path filters only when needed for readability\n3. If the repository contains `.github/PULL_REQUEST_TEMPLATE.MD`, read it and treat its PR-title rules as the default commit-subject convention.\n4. Generate a commit subject from the actual changed files and diff content, not from the user prompt alone.\n5. Stage every current modification on the branch with `git add -A`.\n6. Commit once with the generated message.\n7. Push the current branch to `origin` with `git push origin <current-branch>`.\n\n## Commit Message Rules\n\nThe commit message is formatted as follows: `<type>[optional scope]: <description>` For example, `fix(os/gtime): fix time zone issue`\n + `<type>` is mandatory and can be one of `fix`, `feat`, `build`, `ci`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`\n + `fix`: Used when a bug has been fixed.\n + `feat`: Used when a new feature has been added.\n + `build`: Used for modifications to the project build system, such as changes to dependencies, external interfaces, or upgrading Node version.\n + `ci`: Used for modifications to continuous integration processes, such as changes to Travis, Jenkins workflow configurations.\n + `docs`: Used for modifications to documentation, such as changes to README files, API documentation, etc.\n + `style`: Used for changes to code style, such as adjustments to indentation, spaces, blank lines, etc.\n + `refactor`: Used for code refactoring, such as changes to code structure, variable names, function names, without altering functionality.\n + `perf`: Used for performance optimization, such as improving code performance, reducing memory usage, etc.\n + `test`: Used for modifications to test cases, such as adding, deleting, or modifying test cases for code.\n + `chore`: Used for modifications to non-business-related code, such as changes to build processes or tool configurations.\n + After `<type>`, specify the affected package name or scope in parentheses, for example, `(os/gtime)`.\n + The part after the colon uses the verb tense + phrase that completes the blank in\n + Lowercase verb after the colon\n + No trailing period\n + Keep the title as short as possible. ideally under 76 characters or shorter\n+ If there is a corresponding issue, add either `fixes #1234` (the latter if this is not a complete fix) to this comment\n\n### Examples\n#### Commit message with description and breaking change footer\n```\nfeat: allow provided config object to extend other configs\nBREAKING CHANGE: `extends` key in config file is now used for extending other config files\n```\n\n#### Commit message with ! to draw attention to breaking change\n```\nfeat!: send an email to the customer when a product is shipped\n```\n\n#### Commit message with scope and ! to draw attention to breaking change\n```\nfeat(api)!: send an email to the customer when a product is shipped\n```\n\n#### Commit message with both ! and BREAKING CHANGE footer\n```\nfeat!: drop support for Node 6\nBREAKING CHANGE: use JavaScript features not available in Node 6.\n```\n\n#### Commit message with no body\n```\ndocs: correct spelling of CHANGELOG\n```\n\n#### Commit message with scope\n```\nfeat(lang): add Polish language\n```\n\n#### Commit message with multi-paragraph body and multiple footers\n```\nfix: prevent racing of requests\n\nIntroduce a request id and a reference to latest request. Dismiss\nincoming responses other than from latest request.\n\nRemove timeouts which were used to mitigate the racing issue but are\nobsolete now.\n\nReviewed-by: Z\nRefs: #123\n```\n\n## Execution Rules\n\n- Commit all current tracked and untracked changes in the working tree, because this skill is for \"commit the current state\" requests\n- If there are no changes, say so clearly and stop before commit or push\n- If `git branch --show-current` is empty, explain that `HEAD` is detached and stop unless the user explicitly asks you to commit from detached `HEAD`\n- Never use `--force`, `--force-with-lease`, or history-rewriting commands unless the user explicitly asks\n- If push fails because the remote branch moved, report the exact failure and stop instead of auto-rebasing or auto-merging\n- Do not silently drop files from the commit unless the user asked to exclude them\n\n## Suggested Command Flow\n\n```bash\ngit status --short --branch\ngit diff --stat\ngit diff --cached --stat\ntest -f .github/PULL_REQUEST_TEMPLATE.MD && sed -n '1,220p' .github/PULL_REQUEST_TEMPLATE.MD\nbranch_name=$(git branch --show-current)\ngit add -A\ngit commit -m \"<generated-subject>\"\ngit push origin \"$branch_name\"\n```\n\nInspect `git diff --cached` again after staging if the pre-stage diff was noisy or if untracked files materially change the scope.\n\n## Output Contract\n\nWhen you use this skill:\n\n- Tell the user which branch you committed\n- Provide the final commit subject you used\n- Mention that you staged all current changes\n- Report the push target as `origin/<branch>`\n- If commit or push did not happen, explain exactly why\n\n## Example\n\nUser request:\n\n```text\nGenerate a commit message that follows this repository's convention, then commit and push the current branch\n```\n\nExpected behavior:\n\n- Inspect the repo status and diff\n- Generate a conventional subject from the real changes\n- Run one commit for the whole current working tree\n- Push the active branch to `origin`\n","frontmatter":{"name":"git-commit-push","description":"Review the current git working tree, generate a commit message from the actual diff using the repository's commit or PR-title convention, commit all current changes on the active branch, and push that branch to `origin`. Use this whenever the user asks to \"commit\", \"push\", \"commit and push\", \"generate a commit message\", \"commit the current changes\", or wants the current branch changes sent upstream without hand-writing the git commands."},"isInternal":false,"tokens":1535,"sizeBytes":6918},{"name":"SKILL.md","path":".agents/skills/git-worktree/SKILL.md","rawUrl":"https://raw.githubusercontent.com/gogf/gf/HEAD/.agents/skills/git-worktree/SKILL.md","title":"git-worktree","category":"anthropic-skill","format":"markdown","content":"---\nname: git-worktree\ndescription: Create and actively use an isolated git worktree for the user's task, then continue the task inside that new directory. Use this whenever the user asks for a separate worktree, isolated checkout, clean branch directory, safer parallel changes, or a fresh workspace to avoid unrelated local edits.\n---\n\n# Git Worktree\n\nCreate a dedicated `git worktree` for the current task, then keep working inside that new directory instead of the original checkout.\n\nThis skill is about execution, not just advice. When it triggers, actually create the worktree unless the repository state makes that impossible.\n\nDo not introduce helper scripts for this skill. Use direct `git` and shell commands inline.\n\n## When To Use\n\n- The user explicitly asks for a new `git worktree`, independent branch directory, or isolated workspace\n- The current checkout contains unrelated local changes and isolation is the safest way forward\n- The user wants parallel work on multiple tasks without stashing or disturbing the original worktree\n- The user says things like \"create a separate branch folder\", \"open a fresh worktree\", \"use a clean checkout\", or \"work in an isolated workspace\"\n\n## Core Rule\n\nAfter creating the worktree, treat the new path as the active working directory for the rest of the task.\n\nIn any agent environment, \"enter the directory\" means:\n\n- Run subsequent commands against the new worktree path\n- Apply all edits under that worktree path\n- Do not keep using the original checkout by accident\n- Confirm the handoff by running at least one follow-up command in the new worktree\n\nNever claim you \"switched\" unless your subsequent actions actually target the new `worktree_path`.\n\nIf your environment supports a per-command working directory, use it for every later command. If it does not, prefix later commands with an explicit `cd <worktree_path> && ...`.\n\n## Name Derivation\n\n- Derive a short ASCII kebab-case task slug from the user's real task, such as `login-timeout-fix` or `user-export`\n- Do not use generic names like `git-worktree`, `new-worktree`, or `task` unless the request is too vague\n- If the request is mostly non-ASCII or no good slug is obvious, fall back to `task-$(date +%Y%m%d-%H%M%S)`\n- Default branch prefix is `worktree/`\n- Default worktree directory is a sibling of the repository root, named `<repo-name>-<slug>`\n\n## Default Workflow\n\n1. Inspect the repository context from the current checkout:\n - `git rev-parse --show-toplevel`\n - `git branch --show-current`\n - `git status --short`\n - `git worktree list --porcelain`\n2. Decide a task slug yourself using the rules above\n3. Build branch and path names inline, then create the worktree with direct shell commands like:\n\n ```bash\n repo_root=$(git rev-parse --show-toplevel)\n repo_name=$(basename \"$repo_root\")\n parent_dir=$(dirname \"$repo_root\")\n source_branch=$(git -C \"$repo_root\" branch --show-current)\n if [ -n \"$source_branch\" ]; then\n source_ref=\"$source_branch\"\n else\n source_ref=\"HEAD@$(git -C \"$repo_root\" rev-parse --short HEAD)\"\n fi\n\n slug=\"<task-slug>\"\n base_branch=\"worktree/$slug\"\n branch_name=\"$base_branch\"\n base_path=\"$parent_dir/$repo_name-$slug\"\n worktree_path=\"$base_path\"\n index=2\n\n while git -C \"$repo_root\" show-ref --verify --quiet \"refs/heads/$branch_name\" || [ -e \"$worktree_path\" ]; do\n branch_name=\"${base_branch}-$index\"\n worktree_path=\"${base_path}-$index\"\n index=$((index + 1))\n done\n\n git -C \"$repo_root\" worktree add -b \"$branch_name\" \"$worktree_path\" HEAD\n ```\n\n4. Immediately verify the handoff inside the new worktree, for example:\n\n ```bash\n pwd\n git status --short --branch\n ```\n\n These verification commands must run against `worktree_path`.\n\n5. Announce the new active path briefly, then continue the main task there\n6. For the remainder of the task, use `worktree_path` as the working directory for every relevant command or edit operation\n\n## Behavior Rules\n\n- Default base ref is `HEAD` from the current checkout so uncommitted local changes are not dragged into the new worktree\n- If a branch name or path already exists, auto-increment it instead of failing\n- If you are already inside a non-default worktree and the user still wants another isolated workspace, create a new one from the current `HEAD`\n- If the directory is not a Git repository, explain that clearly and do not pretend a worktree was created\n- If worktree creation succeeds, continue the user's actual task instead of stopping at setup\n- If worktree creation fails because of filesystem permissions, request the minimal approval needed and retry\n\n## Uncommitted Change Policy\n\nThe safe default is isolation from uncommitted changes.\n\n- If the source checkout is dirty, still create the new worktree from `HEAD` unless the user explicitly asks to carry local edits over\n- Do not silently stash, reset, or move the user's existing changes\n- If the user wants local edits copied into the new worktree, use an explicit flow such as a temporary commit, patch, or cherry-pick, and say what you are doing\n\n## Output Contract\n\nWhen you use this skill:\n\n- Tell the user which branch and directory were created\n- Make it clear that subsequent work is now happening inside that path\n- Mention the source ref and whether the original checkout was dirty when that context matters\n- Do not stop after setup if the user asked for additional work; continue the task in the new worktree\n\n## Example\n\nUser request:\n\n```text\nCreate a separate worktree for this task and then start implementing it.\n```\n\nExpected behavior:\n\n- Inspect current repo status\n- Create a new `worktree/...` branch and sibling directory with direct `git worktree` commands\n- Switch all following commands to that directory\n- Continue the requested implementation there\n\n## Cleanup\n\nOnly remove a worktree when the user asks or when cleanup is clearly part of the task.\n\nBefore cleanup:\n\n- Check status in the worktree you created\n- Make sure you are removing the correct path\n- Never remove the user's original checkout\n","frontmatter":{"name":"git-worktree","description":"Create and actively use an isolated git worktree for the user's task, then continue the task inside that new directory. Use this whenever the user asks for a separate worktree, isolated checkout, clean branch directory, safer parallel changes, or a fresh workspace to avoid unrelated local edits."},"isInternal":false,"tokens":1370,"sizeBytes":6073},{"name":"SKILL.md","path":".agents/skills/openspec-explore/SKILL.md","rawUrl":"https://raw.githubusercontent.com/gogf/gf/HEAD/.agents/skills/openspec-explore/SKILL.md","title":"openspec-explore","category":"anthropic-skill","format":"markdown","content":"---\nname: openspec-explore\ndescription: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.2.0\"\n---\n\nEnter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.\n\n**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.\n\n**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.\n\n\n## The Stance\n\n- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script\n- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.\n- **Visual** - Use `mermaid` for architecture diagrams, flowcharts, and similar visuals. If you need line breaks inside `mermaid`, use `<br/>` instead of `\\n`. ASCII box-drawing is allowed only when mermaid is a poor fit, and those blocks must stay in English.\n- **Adaptive** - Follow interesting threads, pivot when new information emerges\n- **Patient** - Don't rush to conclusions, let the shape of the problem emerge\n- **Grounded** - Explore the actual codebase when relevant, don't just theorize\n\n\n## What You Might Do\n\nDepending on what the user brings, you might:\n\n**Explore the problem space**\n- Ask clarifying questions that emerge from what they said\n- Challenge assumptions\n- Reframe the problem\n- Find analogies\n\n**Investigate the codebase**\n- Map existing architecture relevant to the discussion\n- Find integration points\n- Identify patterns already in use\n- Surface hidden complexity\n\n**Compare options**\n- Brainstorm multiple approaches\n- Build comparison tables\n- Sketch tradeoffs\n- Recommend a path (if asked)\n\n**Visualize**\n\nUse `mermaid` for system diagrams, state machines, data flows, and architecture sketches:\n\n```mermaid\nflowchart LR\n A[\"State A\"] --> B[\"State B\"]\n```\n\n**Surface risks and unknowns**\n- Identify what could go wrong\n- Find gaps in understanding\n- Suggest spikes or investigations\n\n\n## OpenSpec Awareness\n\nYou have full context of the OpenSpec system. Use it naturally, don't force it.\n\n### Check for context\n\nAt the start, quickly check what exists:\n```bash\nopenspec list --json\n```\n\nThis tells you:\n- If there are active changes\n- Their names, schemas, and status\n- What the user might be working on\n\n### When no change exists\n\nThink freely. When insights crystallize, you might offer:\n\n- \"This feels solid enough to start a change. Want me to create a proposal?\"\n- Or keep exploring - no pressure to formalize\n\n### When a change exists\n\nIf the user mentions a change or you detect one is relevant:\n\n1. **Read existing artifacts for context**\n - `openspec/changes/<name>/proposal.md`\n - `openspec/changes/<name>/design.md`\n - `openspec/changes/<name>/tasks.md`\n - etc.\n\n2. **Reference them naturally in conversation**\n - \"Your design mentions using Redis, but we just realized SQLite fits better...\"\n - \"The proposal scopes this to premium users, but we're now thinking everyone...\"\n\n3. **Offer to capture when decisions are made**\n\n | Insight Type | Where to Capture |\n |--------------|------------------|\n | New requirement discovered | `specs/<capability>/spec.md` |\n | Requirement changed | `specs/<capability>/spec.md` |\n | Design decision made | `design.md` |\n | Scope changed | `proposal.md` |\n | New work identified | `tasks.md` |\n | Assumption invalidated | Relevant artifact |\n\n Example offers:\n - \"That's a design decision. Capture it in design.md?\"\n - \"This is a new requirement. Add it to specs?\"\n - \"This changes scope. Update the proposal?\"\n\n4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.\n\n\n## What You Don't Have To Do\n\n- Follow a script\n- Ask the same questions every time\n- Produce a specific artifact\n- Reach a conclusion\n- Stay on topic if a tangent is valuable\n- Be brief (this is thinking time)\n\n\n## Handling Different Entry Points\n\n**User brings a vague idea:**\n\n> User: I'm thinking about adding real-time collaboration\n\nReal-time collab is a big space. Let me think about this...\n\n```mermaid\nflowchart LR\n A[\"Awareness<br/>Presence\"] --> B[\"Coordination<br/>Cursors\"] --> C[\"Sync<br/>CRDT\"]\n```\n\nWhere's your head at?\n\n**User brings a specific problem:**\n\n> User: The auth system is a mess\n\nAfter reading the codebase:\n\n```mermaid\nflowchart TD\n G[\"Google OAuth\"] --> S[Session]\n GH[\"GitHub OAuth\"] --> S\n E[\"Email Magic\"] --> S\n S --> P[Perms]\n```\n\nI see three tangles. Which one's burning?\n\n**User is stuck mid-implementation:**\n\n> User: `/opsx:explore add-auth-system`\n> The OAuth integration is more complex than expected\n\nAfter reading change artifacts: you're on task 4, \"Implement OAuth flow\". Trace what's involved, explore options, then ask whether to update the design or add a spike task.\n\n**User wants to compare options:**\n\n> User: Should we use Postgres or SQLite?\n\nGeneric answer is boring. What's the context?\n\n> User: A CLI tool that tracks local dev environments\n\nThat changes everything.\n\n| | `SQLite` | `Postgres` |\n| --- | --- | --- |\n| Deployment | embedded | needs server |\n| Offline | yes | no |\n| Single file | yes | no |\n\n`SQLite`. Not even close. Unless... is there a sync component?\n\n\n## Ending Discovery\n\nThere's no required ending. Discovery might:\n\n- **Flow into a proposal**: \"Ready to start? I can create a change proposal.\"\n- **Result in artifact updates**: \"Updated design.md with these decisions\"\n- **Just provide clarity**: User has what they need, moves on\n- **Continue later**: \"We can pick this up anytime\"\n\nWhen it feels like things are crystallizing, you might summarize:\n\n```\n## What We Figured Out\n\n**The problem**: [crystallized understanding]\n\n**The approach**: [if one emerged]\n\n**Open questions**: [if any remain]\n\n**Next steps** (if ready):\n- Create a change proposal\n- Keep exploring: just keep talking\n```\n\nBut this summary is optional. Sometimes the thinking IS the value.\n\n\n## Guardrails\n\n- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.\n- **Don't fake understanding** - If something is unclear, dig deeper\n- **Don't rush** - Discovery is thinking time, not task time\n- **Don't force structure** - Let patterns emerge naturally\n- **Don't auto-capture** - Offer to save insights, don't just do it\n- **Do visualize** - A good mermaid diagram is worth many paragraphs\n- **Do explore the codebase** - Ground discussions in reality\n- **Do question assumptions** - Including the user's and your own\n","frontmatter":{"name":"openspec-explore","description":"Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.","license":"MIT","compatibility":"Requires openspec CLI.","metadata":{"author":"openspec","version":"1.0","generatedBy":"1.2.0"}},"isInternal":false,"tokens":1683,"sizeBytes":7200},{"name":"SKILL.md","path":".agents/skills/openspec-propose/SKILL.md","rawUrl":"https://raw.githubusercontent.com/gogf/gf/HEAD/.agents/skills/openspec-propose/SKILL.md","title":"openspec-propose","category":"anthropic-skill","format":"markdown","content":"---\nname: openspec-propose\ndescription: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.2.0\"\n---\n\nPropose a new change - create the change and generate all artifacts in one step.\n\nI'll create a change with artifacts:\n- proposal.md (what & why)\n- design.md (how)\n- tasks.md (implementation steps)\n\nWhen ready to implement, run /opsx:apply\n\n\n**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.\n\n**Steps**\n\n1. **If no clear input provided, ask what they want to build**\n\n Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:\n > \"What change do you want to work on? Describe what you want to build or fix.\"\n\n From their description, derive a kebab-case name (e.g., \"add user authentication\" → `add-user-auth`).\n\n **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.\n\n2. **Create the change directory**\n ```bash\n openspec new change \"<name>\"\n ```\n This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.\n\n3. **Get the artifact build order**\n ```bash\n openspec status --change \"<name>\" --json\n ```\n Parse the JSON to get:\n - `applyRequires`: array of artifact IDs needed before implementation (e.g., `[\"tasks\"]`)\n - `artifacts`: list of all artifacts with their status and dependencies\n\n4. **Create artifacts in sequence until apply-ready**\n\n Use the **TodoWrite tool** to track progress through the artifacts.\n\n Loop through artifacts in dependency order (artifacts with no pending dependencies first):\n\n a. **For each artifact that is `ready` (dependencies satisfied)**:\n - Get instructions:\n ```bash\n openspec instructions <artifact-id> --change \"<name>\" --json\n ```\n - The instructions JSON includes:\n - `context`: Project background (constraints for you - do NOT include in output)\n - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)\n - `template`: The structure to use for your output file\n - `instruction`: Schema-specific guidance for this artifact type\n - `outputPath`: Where to write the artifact\n - `dependencies`: Completed artifacts to read for context\n - Read any completed dependency files for context\n - Create the artifact file using `template` as the structure\n - Apply `context` and `rules` as constraints - but do NOT copy them into the file\n - Show brief progress: \"Created <artifact-id>\"\n\n b. **Continue until all `applyRequires` artifacts are complete**\n - After creating each artifact, re-run `openspec status --change \"<name>\" --json`\n - Check if every artifact ID in `applyRequires` has `status: \"done\"` in the artifacts array\n - Stop when all `applyRequires` artifacts are done\n\n c. **If an artifact requires user input** (unclear context):\n - Use **AskUserQuestion tool** to clarify\n - Then continue with creation\n\n5. **Show final status**\n ```bash\n openspec status --change \"<name>\"\n ```\n\n**Output**\n\nAfter completing all artifacts, summarize:\n- Change name and location\n- List of artifacts created with brief descriptions\n- What's ready: \"All artifacts created! Ready for implementation.\"\n- Prompt: \"Run `/opsx:apply` or ask me to implement to start working on the tasks.\"\n\n**Artifact Creation Guidelines**\n\n- Follow the `instruction` field from `openspec instructions` for each artifact type\n- The schema defines what each artifact should contain - follow it\n- Read dependency artifacts for context before creating new ones\n- Use `template` as the structure for your output file - fill in its sections\n- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file\n - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact\n - These guide what you write, but should never appear in the output\n\n**Guardrails**\n- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)\n- Always read dependency artifacts before creating a new one\n- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum\n- If a change with that name already exists, ask if user wants to continue it or create a new one\n- Verify each artifact file exists after writing before proceeding to next\n","frontmatter":{"name":"openspec-propose","description":"Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.","license":"MIT","compatibility":"Requires openspec CLI.","metadata":{"author":"openspec","version":"1.0","generatedBy":"1.2.0"}},"isInternal":false,"tokens":1043,"sizeBytes":4642}],"systemPromptSnippet":"<yakaai_skills repo=\"gogf/gf\">\n<!-- File: .agents/skills/gf-feedback/SKILL.md (Tokens: ~2332 | Category: anthropic-skill) -->\n---\nname: gf-feedback\ndescription: >-\n Track, fix, verify, and test any bugs, improvements, or gaps reported against an OpenSpec change.\n MUST use this skill whenever user reports problems, defects, issues, bugs, or gaps related to\n existing implementations, even if they don't explicitly say \"feedback\" or mention OpenSpec.\ncompatibility: Requires openspec CLI, Go toolchain, and gf-review skill.\n---\n\n# Feedback: Structured Fix, Verification & Test Coverage Loop\n\nWhen users discover bugs or improvement points after implementation, this skill captures those issues, organizes them into a traceable task list in `tasks.md`, systematically fixes and verifies each one, and ensures every behavior-changing fix is covered by focused unit tests.\n\n**Core principles:**\n1. **Spec is the source of truth** — Spec-level changes require spec update before task recording\n2. **Write it down first, then fix it** — Every issue gets recorded before any code change\n3. **Every fix deserves a test** — Behavior-changing code changes require unit test coverage in the affected package\n\n\n## Workflow\n\n### 1. Identify Target Change\n\n**CRITICAL:** \n1. Always append to existing active changes. Only create new change when none exist.\n2. An **active change** is any change directory that still exists directly under `openspec/changes/` and has **not** been moved into `openspec/changes/archive/`. Do **not** treat `status: complete`, all tasks checked off, or similar completion signals as \"inactive\" until archive actually happens.\n3. Regardless of whether the feedback content is related to the main functionality of the current active iteration, it MUST be appended to the current active iteration. This ensures all changes are tracked in a single change record for unified management and archiving.\n\n```bash\nopenspec list --json\n# Or: ls openspec/changes/ | grep -v archive\n```\n\nWhen the two signals disagree, prefer the filesystem rule:\n\n- If a change directory still exists under `openspec/changes/` and is not inside `archive/`, it is active.\n- `openspec list --json` may still report such a change as `status: complete`; that only means implementation tasks are done, **not** that the change is inactive.\n- Only archived changes under `openspec/changes/archive/` are inactive.\n\n| Active Changes | Action |\n|----------------|--------|\n| None | Create new change (see below) |\n| One | Auto-select it, announce and proceed |\n| Multiple | Ask user to select from list |\n\n**When multiple active changes exist:**\n```\nMultiple active changes detected. Which change should this feedback be appended to?\n\n1. config-management — System config CRUD management\n2. user-auth — User authentication enhancement\n\nPlease select 1 or 2:\n```\n\n**When no active change exists:**\n1. Derive kebab-case name from feedback (e.g., \"fix-menu-circular-ref\")\n2. If name exists, append suffix (\"-2\")\n3. Create: `openspec new change \"<name>\"`\n4. Generate minimal `proposal.md` (one paragraph summarizing context)\n5. Skip `design.md` for pure bug fixes unless architectural changes needed\n\nAnnounce: \"Applying feedback fixes to change: **<name>**\"\n\n\n### 2. Read Current Context\n\n| File | Purpose |\n|------|---------|\n| `tasks.md` | Task structure, naming conventions, numbering |\n| `design.md` | Architectural context |\n| `proposal.md` | Feature scope and intent |\n| `specs/` | Delta spec definitions |\n\n```bash\n# Locate existing unit tests in the impacted package before adding a new one\nrg --files <pkg-dir> | rg '_test\\\\.go$'\n```\n\n\n### 3. Analyze and Organize Issues\n\nFor each reported issue:\n\n**Classify by type:**\n- **bug** — Incorrect behavior, code doesn't match spec\n- **missing** — Feature incomplete, gaps in implementation\n- **ux** — UX improvement, no spec change needed\n- **test-gap** — Missing test coverage only\n\n**Classify by spec impact:**\n\n| Level | Definition | Action |\n|-------|------------|--------|\n| **implementation** | Spec is correct, code is wrong | Fix code only |\n| **spec-level** | Requirement missing/incomplete/changed | Update spec first, then fix |\n| **internal** | No user-observable change | Fix code, test optional |\n\n**Group related issues** — Same root cause → single task with multiple verification points.\n\n\n### 4. Update Delta Specs (for Spec-Level Issues Only)\n\nFor spec-level issues, update specs **before** recording tasks:\n\n1. Identify affected capability: `specs/<capability>/spec.md`\n2. Apply delta operation:\n\n```markdown\n<!-- ADDED: New requirement -->\n### Requirement: Parent Selector Circular Prevention\nThe system SHALL disable the current menu and all its descendants in the parent selector\nto prevent circular references.\n\n#### Scenario: Edit menu with children\nWHEN user edits a menu that has child menus\nTHEN the parent selector SHALL disable the current menu and all descendant menus\n\n<!-- MODIFIED: Changed requirement (include full original block) -->\n### Requirement: Import Error Handling\nThe system SHALL display error messages when import fails.\n**MODIFIED:** Error messages SHALL include row number, field name, and validation failure reason.\n\n<!-- REMOVED: Deprecated requirement -->\n### Requirement: Legacy Import Format\nThe system SHALL support legacy CSV format.\n**REMOVED:** This format is no longer supported.\n**Migration:** Use the new CSV format with header row.\n```\n\n\n### 5. Write Task List to tasks.md\n\nAppend a **Feedback section** to `tasks.md`:\n\n```markdown\n## Feedback\n\n- [ ] **FB-1**: Parent selector allows circular references in menu edit\n- [ ] **FB-2**: Import error messages lack row and field details\n- [ ] **FB-3**: No test coverage for reset password feature\n```\n\n**Numbering:** Sequential `FB-1`, `FB-2`, etc. Continue from last number if section exists.\n\n**One line per task** — No sub-fields. Analysis happens during fix phase.\n\n**Confirm with user** before writing to file.\n\n**Test coverage planning (internal):**\n- Behavior-changing code change → Unit test required\n- Internal-only optimization → Unit test optional unless logic risk increased\n- Prefer extending the nearest `*_z_unit*_test.go` or `*_test.go` in the same package\n\n\n### 6. Execute Fixes (Loop)\n\nFor each task:\n\n**a. Announce:** `## Fixing FB-X: <issue title>`\n\n**b. Investigate** — Read source files, confirm root cause\n\n**c. Implement** — Minimal, focused fix following existing patterns\n\n**d. Write/update unit tests** — Prefer the affected package's existing `*_z_unit*_test.go` or `*_test.go` files and keep assertions focused on the changed logic\n\n**e. Assess Impact Scope (MANDATORY)**\n\nAfter implementing, identify regression risk:\n\n| Change Type | Map To Tests |\n|-------------|--------------|\n| Package-level logic | Targeted test for changed function/method + package regression tests |\n| Shared utility | Utility package unit tests + highest-value dependent package tests already covering reuse |\n| DB/DAO logic | DAO/model package unit tests with focused fixtures, mocks, or test helpers |\n| Public API validation | Handler/service package unit tests that assert the changed validation path |\n| Refactor without behavior change | Existing package tests that prove behavior parity |\n\n```bash\n# Example: Find unit tests related to a changed symbol or package\nrg -l \"GenDao|gdao\" . -g '*_test.go'\n```\n\nAnnounce:\n```\n### Impact Analysis for FB-X\n- Modified: cmd/gf/internal/cmd/gendao/gendao.go\n- Affected package: cmd/gf/internal/cmd/gendao\n- Unit tests: cmd/gf/internal/cmd/gendao/gendao_test.go\n- Regression command: go test ./cmd/gf/internal/cmd/gendao -run 'TestGenDao'\n```\n\n**f. Verify (MANDATORY before marking complete)**\n\n1. Run new/updated unit tests for this task → **must pass**\n2. Run ALL identified package-level regression tests → **must pass**\n3. Only then: mark task `[x]` in tasks.md\n\nIf regression fails:\n- Fix inline if related to current change\n- Add as new FB task if separate issue\n\n**g. Run review** — Invoke `gf-review` skill after completion\n\n\n### 7. Comprehensive Verification\n\nAfter all fixes:\n\n1. Aggregate regression tests from all tasks\n2. Run full set in single pass\n3. Report:\n```\n### Comprehensive Verification Results\n- Total tests: N\n- Passed: N\n- Failed: N (list with details)\n- Regression tests: all passed ✓ / X failures\n```\n\nIf failures → add new FB tasks, loop to Step 6.\n\n\n### 8. Report Completion\n\n```markdown\n## Feedback Complete\n\n**Change:** <name>\n**Issues reported:** X\n**Issues fixed:** Y/X\n**Tests added:** Z unit tests / focused assertions\n**Regression tests run:** R tests across N packages\n**Verification:** all passed / N issues remaining\n\n### Fixed This Session\n- [x] FB-1: <title> ✓ (unit test: TestGenDao_FiltersInvalidTables | package: ./cmd/gf/internal/cmd/gendao ✓)\n- [x] FB-2: <title> ✓ (unit test: existing package coverage extended | package: ./cmd/gf/internal/cmd ✓)\n\n### Remaining (if any)\n- [ ] FB-3: <title> — blocked by <reason>\n```\n\n\n## Edge Cases\n\n| Situation | Handling |\n|-----------|----------|\n| Single issue | Still follow full workflow |\n| Missing test cases only | Classify as test-gap, implement tests |\n| Fix reveals more issues | Add as new FB tasks |\n| \"Bug\" is actually feature request | Re-classify as spec-level, update specs first |\n| Unit test not feasible (docs/spec only) | Note reason explicitly and skip only when no runtime code changes exist |\n| Multiple feedback rounds | All tasks in single Feedback section, sequential numbering |\n\n\n## Guardrails\n\n- **Append to active change if exists** — Never create new change when active ones exist\n- **Specs before tasks for spec-level issues** — Update delta specs first\n- **Write tasks before fixing** — Never code without recording\n- **Confirm task list with user** — User validates analysis\n- **Minimal fixes** — No refactoring beyond issue scope\n- **Behavior-changing fix needs unit test** — No exceptions unless the change is docs/spec only\n- **No green check without green unit tests** — Mark `[x]` only after tests pass\n- **Impact analysis mandatory** — Every fix requires package-level regression test identification\n- **Regression failures block completion** — Must resolve before marking done\n- **Update tasks.md in real time** — Mark complete immediately after verification\n- **Match file language** — Use same language as existing content in target file\n\n<!-- File: .agents/skills/gf-review/SKILL.md (Tokens: ~1402 | Category: anthropic-skill) -->\n---\nname: gf-review\ndescription: >-\n Code and specification review for OpenSpec workflow. Triggers automatically after /opsx:apply\n task completion, after /gf-feedback task completion, and before /opsx:archive. Use when\n user requests code review, spec compliance check, or when explicitly invoked via /gf-review.\ncompatibility: Requires OpenSpec CLI and GoFrame v2 skill.\n---\n\n# GF Review\n\nStructured code and specification review for the OpenSpec development workflow.\n\n**Spec Source**: `AGENTS.md` is the single source of truth for all review criteria.\n\n\n## When This Skill Activates\n\n**Automatic triggers:**\n- After completing each task in `/opsx:apply`\n- After completing each task in `/gf-feedback`\n- Before executing `/opsx:archive`\n\n**Manual trigger:**\n- User explicitly requests: \"review this code\", \"check spec compliance\", \"/gf-review\"\n\n\n## Review Workflow\n\n### 1. Identify Scope\n\nDetermine what needs to be reviewed:\n\n1. **After task completion** — Review files modified/created by the completed task\n2. **Before archive** — Review all changes in the current OpenSpec change\n3. **Manual invocation** — Ask user to specify scope or use current change\n\n**Mandatory scope collection rules:**\n\n1. Start with repository status, not `git diff` alone:\n ```bash\n git status --short\n git ls-files --others --exclude-standard\n ```\n2. Treat **all tracked and untracked changes** as review candidates, including:\n - staged files\n - unstaged files\n - untracked files shown as `??`\n - untracked directories shown as `?? path/`\n3. When `git status --short` reports an untracked directory, expand it to concrete files before review:\n ```bash\n find <path> -type f\n # Or prefer:\n rg --files <path>\n ```\n4. If the task ran generators such as `make ctrl`, `make dao`, codegen scripts, or produced new test files, explicitly include the generated untracked files in review scope even if they do not appear in `git diff`.\n5. `git diff` may be used only as a secondary narrowing aid after status collection. It is **never sufficient by itself** for review scope definition.\n\nRun `openspec status --change \"<name>\" --json` to understand the current change state.\n\n### 2. Load Specifications\n\nRead `AGENTS.md` to load all specifications. This is the single source of truth.\n\n### 3. Backend Code Review\n\n**Trigger**: Changes to files under `apps/lina-core` directory\n\n1. Invoke `goframe-v2` skill for GoFrame framework conventions\n2. Check against `AGENTS.md` backend code specifications\n\n### 4. RESTful API Review\n\n**Trigger**: Any API endpoint changes\n\nCheck against `AGENTS.md` API design specifications.\n\n### 5. Project Specification Review\n\n**Trigger**: Any implementation changes\n\nCheck against `AGENTS.md` architecture design specifications and code development specifications.\n\n### 6. SQL Review\n\n**Trigger**: New or modified files under `apps/lina-core/manifest/sql/`、`apps/lina-core/manifest/sql/mock-data/`、`apps/lina-plugins/**/manifest/sql/` or SQL snippets embedded in related delivery docs\n\nCheck against `AGENTS.md` SQL file management specifications, at minimum covering:\n1. File naming, versioning, and single-iteration single-file rules\n2. Seed DML vs mock data separation\n3. **Idempotent execution safety** — SQL must be safe to run multiple times without duplicate-object errors or duplicate seed data; verify use of `IF [NOT] EXISTS`, `IF EXISTS`, `INSERT IGNORE`, or equivalent safe re-entry patterns\n4. **Seed write style compliance** — delivered SQL must reject `INSERT ... ON DUPLICATE KEY UPDATE` and reject explicit writes to `AUTO_INCREMENT` `id` columns in seed/mock/install data\n5. Whether schema/data changes still match the current change scope and deployment path\n\n### 7. Unit Test Review\n\n**Trigger**: New or modified Go implementation files, or new/modified Go unit test files matching `*_test.go`\n\nCheck at minimum:\n1. Behavior-changing Go code includes focused unit coverage in the same package, preferably by extending existing `*_z_unit*_test.go` or `*_test.go`\n2. Tests assert the changed logic directly instead of relying on broad workflow-level coverage when a package-level test is sufficient\n3. Verification uses targeted `go test ./path/to/pkg -run TestName` during development and package-level `go test ./path/to/pkg` for regression\n\n### 8. Generate Review Report\n\n```markdown\n## GF Review Report\n\n**Change:** <change-name>\n**Scope:** <task-specific / full change>\n**Files Reviewed:** <count>\n**Scope Source:** `git status --short` + `git ls-files --others --exclude-standard` + task/change context\n\n### Backend Code Review\n✓ All checks passed / ⚠ N issues found\n\n### RESTful API Review\n✓ All endpoints compliant / ⚠ N violations found\n\n### Project Spec Review\n✓ Compliant with AGENTS.md / ⚠ N violations found\n\n### SQL Review\n✓ No SQL changes / ✓ SQL changes compliant / ⚠ N SQL issues found\n\n### Unit Test Review\n✓ Unit tests are focused and sufficient / ⚠ N issues found\n\n### Summary\n- **Critical:** N (must fix before archive)\n- **Warnings:** N (recommended to fix)\n\n### Recommended Actions\n1. [Specific action with AGENTS.md reference]\n```\n\n\n## Issue Severity\n\n| Level | Behavior |\n|-------|----------|\n| **Critical** | Block archive, must fix |\n| **Warning** | Show but allow proceed |\n\n\n## Integration Points\n\n| Workflow Step | Behavior |\n|---------------|----------|\n| `/opsx:apply` task done | Review, offer to fix issues before next task |\n| `/gf-feedback` task done | Review, fix before marking complete |\n| `/opsx:archive` | Review all changes, block on critical issues |\n\n\n## Guardrails\n\n- **AGENTS.md is the single source of truth** — All spec references point to it\n- Only check categories relevant to changed files\n- Scope identification MUST include untracked files and expanded untracked directories; never rely on `git diff` alone\n- Behavior-changing Go code without focused unit tests is a review finding unless the author documents why tests are not applicable\n- Don't block on warnings — only critical issues block archive\n- Include file paths and line numbers in issue reports\n- Offer to fix issues automatically when straightforward\n\n<!-- File: .agents/skills/git-commit-push/SKILL.md (Tokens: ~1535 | Category: anthropic-skill) -->\n---\nname: git-commit-push\ndescription: Review the current git working tree, generate a commit message from the actual diff using the repository's commit or PR-title convention, commit all current changes on the active branch, and push that branch to `origin`. Use this whenever the user asks to \"commit\", \"push\", \"commit and push\", \"generate a commit message\", \"commit the current changes\", or wants the current branch changes sent upstream without hand-writing the git commands.\n---\n\n# Git Commit Push\n\nInspect the current repository changes, derive a concise commit subject that matches the repository convention, commit every current modification on the active branch, and push that branch to `origin`.\n\nThis skill is for execution, not just advice. When it triggers, actually run the git workflow unless the repository state makes that unsafe or impossible.\n\n## When To Use\n\n- The user asks you to commit the current changes, with or without asking for push\n- The user wants you to write the commit message from the diff instead of inventing one up front\n- The user mentions the repo's PR or commit naming convention and wants you to follow it\n- The user says things like \"commit the current branch\", \"help me commit\", \"commit and push\", \"generate a commit message and push\", or \"send these changes to origin\"\n\n## Core Behavior\n\n1. Confirm you are inside a Git repository and detect the active branch with `git branch --show-current`.\n2. Inspect the working tree before committing:\n - `git status --short --branch`\n - `git diff --stat`\n - `git diff --cached --stat`\n - `git diff -- . ':(exclude)package-lock.json'` or narrower path filters only when needed for readability\n3. If the repository contains `.github/PULL_REQUEST_TEMPLATE.MD`, read it and treat its PR-title rules as the default commit-subject convention.\n4. Generate a commit subject from the actual changed files and diff content, not from the user prompt alone.\n5. Stage every current modification on the branch with `git add -A`.\n6. Commit once with the generated message.\n7. Push the current branch to `origin` with `git push origin <current-branch>`.\n\n## Commit Message Rules\n\nThe commit message is formatted as follows: `<type>[optional scope]: <description>` For example, `fix(os/gtime): fix time zone issue`\n + `<type>` is mandatory and can be one of `fix`, `feat`, `build`, `ci`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`\n + `fix`: Used when a bug has been fixed.\n + `feat`: Used when a new feature has been added.\n + `build`: Used for modifications to the project build system, such as changes to dependencies, external interfaces, or upgrading Node version.\n + `ci`: Used for modifications to continuous integration processes, such as changes to Travis, Jenkins workflow configurations.\n + `docs`: Used for modifications to documentation, such as changes to README files, API documentation, etc.\n + `style`: Used for changes to code style, such as adjustments to indentation, spaces, blank lines, etc.\n + `refactor`: Used for code refactoring, such as changes to code structure, variable names, function names, without altering functionality.\n + `perf`: Used for performance optimization, such as improving code performance, reducing memory usage, etc.\n + `test`: Used for modifications to test cases, such as adding, deleting, or modifying test cases for code.\n + `chore`: Used for modifications to non-business-related code, such as changes to build processes or tool configurations.\n + After `<type>`, specify the affected package name or scope in parentheses, for example, `(os/gtime)`.\n + The part after the colon uses the verb tense + phrase that completes the blank in\n + Lowercase verb after the colon\n + No trailing period\n + Keep the title as short as possible. ideally under 76 characters or shorter\n+ If there is a corresponding issue, add either `fixes #1234` (the latter if this is not a complete fix) to this comment\n\n### Examples\n#### Commit message with description and breaking change footer\n```\nfeat: allow provided config object to extend other configs\nBREAKING CHANGE: `extends` key in config file is now used for extending other config files\n```\n\n#### Commit message with ! to draw attention to breaking change\n```\nfeat!: send an email to the customer when a product is shipped\n```\n\n#### Commit message with scope and ! to draw attention to breaking change\n```\nfeat(api)!: send an email to the customer when a product is shipped\n```\n\n#### Commit message with both ! and BREAKING CHANGE footer\n```\nfeat!: drop support for Node 6\nBREAKING CHANGE: use JavaScript features not available in Node 6.\n```\n\n#### Commit message with no body\n```\ndocs: correct spelling of CHANGELOG\n```\n\n#### Commit message with scope\n```\nfeat(lang): add Polish language\n```\n\n#### Commit message with multi-paragraph body and multiple footers\n```\nfix: prevent racing of requests\n\nIntroduce a request id and a reference to latest request. Dismiss\nincoming responses other than from latest request.\n\nRemove timeouts which were used to mitigate the racing issue but are\nobsolete now.\n\nReviewed-by: Z\nRefs: #123\n```\n\n## Execution Rules\n\n- Commit all current tracked and untracked changes in the working tree, because this skill is for \"commit the current state\" requests\n- If there are no changes, say so clearly and stop before commit or push\n- If `git branch --show-current` is empty, explain that `HEAD` is detached and stop unless the user explicitly asks you to commit from detached `HEAD`\n- Never use `--force`, `--force-with-lease`, or history-rewriting commands unless the user explicitly asks\n- If push fails because the remote branch moved, report the exact failure and stop instead of auto-rebasing or auto-merging\n- Do not silently drop files from the commit unless the user asked to exclude them\n\n## Suggested Command Flow\n\n```bash\ngit status --short --branch\ngit diff --stat\ngit diff --cached --stat\ntest -f .github/PULL_REQUEST_TEMPLATE.MD && sed -n '1,220p' .github/PULL_REQUEST_TEMPLATE.MD\nbranch_name=$(git branch --show-current)\ngit add -A\ngit commit -m \"<generated-subject>\"\ngit push origin \"$branch_name\"\n```\n\nInspect `git diff --cached` again after staging if the pre-stage diff was noisy or if untracked files materially change the scope.\n\n## Output Contract\n\nWhen you use this skill:\n\n- Tell the user which branch you committed\n- Provide the final commit subject you used\n- Mention that you staged all current changes\n- Report the push target as `origin/<branch>`\n- If commit or push did not happen, explain exactly why\n\n## Example\n\nUser request:\n\n```text\nGenerate a commit message that follows this repository's convention, then commit and push the current branch\n```\n\nExpected behavior:\n\n- Inspect the repo status and diff\n- Generate a conventional subject from the real changes\n- Run one commit for the whole current working tree\n- Push the active branch to `origin`\n\n<!-- File: .agents/skills/git-worktree/SKILL.md (Tokens: ~1370 | Category: anthropic-skill) -->\n---\nname: git-worktree\ndescription: Create and actively use an isolated git worktree for the user's task, then continue the task inside that new directory. Use this whenever the user asks for a separate worktree, isolated checkout, clean branch directory, safer parallel changes, or a fresh workspace to avoid unrelated local edits.\n---\n\n# Git Worktree\n\nCreate a dedicated `git worktree` for the current task, then keep working inside that new directory instead of the original checkout.\n\nThis skill is about execution, not just advice. When it triggers, actually create the worktree unless the repository state makes that impossible.\n\nDo not introduce helper scripts for this skill. Use direct `git` and shell commands inline.\n\n## When To Use\n\n- The user explicitly asks for a new `git worktree`, independent branch directory, or isolated workspace\n- The current checkout contains unrelated local changes and isolation is the safest way forward\n- The user wants parallel work on multiple tasks without stashing or disturbing the original worktree\n- The user says things like \"create a separate branch folder\", \"open a fresh worktree\", \"use a clean checkout\", or \"work in an isolated workspace\"\n\n## Core Rule\n\nAfter creating the worktree, treat the new path as the active working directory for the rest of the task.\n\nIn any agent environment, \"enter the directory\" means:\n\n- Run subsequent commands against the new worktree path\n- Apply all edits under that worktree path\n- Do not keep using the original checkout by accident\n- Confirm the handoff by running at least one follow-up command in the new worktree\n\nNever claim you \"switched\" unless your subsequent actions actually target the new `worktree_path`.\n\nIf your environment supports a per-command working directory, use it for every later command. If it does not, prefix later commands with an explicit `cd <worktree_path> && ...`.\n\n## Name Derivation\n\n- Derive a short ASCII kebab-case task slug from the user's real task, such as `login-timeout-fix` or `user-export`\n- Do not use generic names like `git-worktree`, `new-worktree`, or `task` unless the request is too vague\n- If the request is mostly non-ASCII or no good slug is obvious, fall back to `task-$(date +%Y%m%d-%H%M%S)`\n- Default branch prefix is `worktree/`\n- Default worktree directory is a sibling of the repository root, named `<repo-name>-<slug>`\n\n## Default Workflow\n\n1. Inspect the repository context from the current checkout:\n - `git rev-parse --show-toplevel`\n - `git branch --show-current`\n - `git status --short`\n - `git worktree list --porcelain`\n2. Decide a task slug yourself using the rules above\n3. Build branch and path names inline, then create the worktree with direct shell commands like:\n\n ```bash\n repo_root=$(git rev-parse --show-toplevel)\n repo_name=$(basename \"$repo_root\")\n parent_dir=$(dirname \"$repo_root\")\n source_branch=$(git -C \"$repo_root\" branch --show-current)\n if [ -n \"$source_branch\" ]; then\n source_ref=\"$source_branch\"\n else\n source_ref=\"HEAD@$(git -C \"$repo_root\" rev-parse --short HEAD)\"\n fi\n\n slug=\"<task-slug>\"\n base_branch=\"worktree/$slug\"\n branch_name=\"$base_branch\"\n base_path=\"$parent_dir/$repo_name-$slug\"\n worktree_path=\"$base_path\"\n index=2\n\n while git -C \"$repo_root\" show-ref --verify --quiet \"refs/heads/$branch_name\" || [ -e \"$worktree_path\" ]; do\n branch_name=\"${base_branch}-$index\"\n worktree_path=\"${base_path}-$index\"\n index=$((index + 1))\n done\n\n git -C \"$repo_root\" worktree add -b \"$branch_name\" \"$worktree_path\" HEAD\n ```\n\n4. Immediately verify the handoff inside the new worktree, for example:\n\n ```bash\n pwd\n git status --short --branch\n ```\n\n These verification commands must run against `worktree_path`.\n\n5. Announce the new active path briefly, then continue the main task there\n6. For the remainder of the task, use `worktree_path` as the working directory for every relevant command or edit operation\n\n## Behavior Rules\n\n- Default base ref is `HEAD` from the current checkout so uncommitted local changes are not dragged into the new worktree\n- If a branch name or path already exists, auto-increment it instead of failing\n- If you are already inside a non-default worktree and the user still wants another isolated workspace, create a new one from the current `HEAD`\n- If the directory is not a Git repository, explain that clearly and do not pretend a worktree was created\n- If worktree creation succeeds, continue the user's actual task instead of stopping at setup\n- If worktree creation fails because of filesystem permissions, request the minimal approval needed and retry\n\n## Uncommitted Change Policy\n\nThe safe default is isolation from uncommitted changes.\n\n- If the source checkout is dirty, still create the new worktree from `HEAD` unless the user explicitly asks to carry local edits over\n- Do not silently stash, reset, or move the user's existing changes\n- If the user wants local edits copied into the new worktree, use an explicit flow such as a temporary commit, patch, or cherry-pick, and say what you are doing\n\n## Output Contract\n\nWhen you use this skill:\n\n- Tell the user which branch and directory were created\n- Make it clear that subsequent work is now happening inside that path\n- Mention the source ref and whether the original checkout was dirty when that context matters\n- Do not stop after setup if the user asked for additional work; continue the task in the new worktree\n\n## Example\n\nUser request:\n\n```text\nCreate a separate worktree for this task and then start implementing it.\n```\n\nExpected behavior:\n\n- Inspect current repo status\n- Create a new `worktree/...` branch and sibling directory with direct `git worktree` commands\n- Switch all following commands to that directory\n- Continue the requested implementation there\n\n## Cleanup\n\nOnly remove a worktree when the user asks or when cleanup is clearly part of the task.\n\nBefore cleanup:\n\n- Check status in the worktree you created\n- Make sure you are removing the correct path\n- Never remove the user's original checkout\n\n<!-- File: .agents/skills/openspec-explore/SKILL.md (Tokens: ~1683 | Category: anthropic-skill) -->\n---\nname: openspec-explore\ndescription: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.2.0\"\n---\n\nEnter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.\n\n**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.\n\n**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.\n\n\n## The Stance\n\n- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script\n- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.\n- **Visual** - Use `mermaid` for architecture diagrams, flowcharts, and similar visuals. If you need line breaks inside `mermaid`, use `<br/>` instead of `\\n`. ASCII box-drawing is allowed only when mermaid is a poor fit, and those blocks must stay in English.\n- **Adaptive** - Follow interesting threads, pivot when new information emerges\n- **Patient** - Don't rush to conclusions, let the shape of the problem emerge\n- **Grounded** - Explore the actual codebase when relevant, don't just theorize\n\n\n## What You Might Do\n\nDepending on what the user brings, you might:\n\n**Explore the problem space**\n- Ask clarifying questions that emerge from what they said\n- Challenge assumptions\n- Reframe the problem\n- Find analogies\n\n**Investigate the codebase**\n- Map existing architecture relevant to the discussion\n- Find integration points\n- Identify patterns already in use\n- Surface hidden complexity\n\n**Compare options**\n- Brainstorm multiple approaches\n- Build comparison tables\n- Sketch tradeoffs\n- Recommend a path (if asked)\n\n**Visualize**\n\nUse `mermaid` for system diagrams, state machines, data flows, and architecture sketches:\n\n```mermaid\nflowchart LR\n A[\"State A\"] --> B[\"State B\"]\n```\n\n**Surface risks and unknowns**\n- Identify what could go wrong\n- Find gaps in understanding\n- Suggest spikes or investigations\n\n\n## OpenSpec Awareness\n\nYou have full context of the OpenSpec system. Use it naturally, don't force it.\n\n### Check for context\n\nAt the start, quickly check what exists:\n```bash\nopenspec list --json\n```\n\nThis tells you:\n- If there are active changes\n- Their names, schemas, and status\n- What the user might be working on\n\n### When no change exists\n\nThink freely. When insights crystallize, you might offer:\n\n- \"This feels solid enough to start a change. Want me to create a proposal?\"\n- Or keep exploring - no pressure to formalize\n\n### When a change exists\n\nIf the user mentions a change or you detect one is relevant:\n\n1. **Read existing artifacts for context**\n - `openspec/changes/<name>/proposal.md`\n - `openspec/changes/<name>/design.md`\n - `openspec/changes/<name>/tasks.md`\n - etc.\n\n2. **Reference them naturally in conversation**\n - \"Your design mentions using Redis, but we just realized SQLite fits better...\"\n - \"The proposal scopes this to premium users, but we're now thinking everyone...\"\n\n3. **Offer to capture when decisions are made**\n\n | Insight Type | Where to Capture |\n |--------------|------------------|\n | New requirement discovered | `specs/<capability>/spec.md` |\n | Requirement changed | `specs/<capability>/spec.md` |\n | Design decision made | `design.md` |\n | Scope changed | `proposal.md` |\n | New work identified | `tasks.md` |\n | Assumption invalidated | Relevant artifact |\n\n Example offers:\n - \"That's a design decision. Capture it in design.md?\"\n - \"This is a new requirement. Add it to specs?\"\n - \"This changes scope. Update the proposal?\"\n\n4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.\n\n\n## What You Don't Have To Do\n\n- Follow a script\n- Ask the same questions every time\n- Produce a specific artifact\n- Reach a conclusion\n- Stay on topic if a tangent is valuable\n- Be brief (this is thinking time)\n\n\n## Handling Different Entry Points\n\n**User brings a vague idea:**\n\n> User: I'm thinking about adding real-time collaboration\n\nReal-time collab is a big space. Let me think about this...\n\n```mermaid\nflowchart LR\n A[\"Awareness<br/>Presence\"] --> B[\"Coordination<br/>Cursors\"] --> C[\"Sync<br/>CRDT\"]\n```\n\nWhere's your head at?\n\n**User brings a specific problem:**\n\n> User: The auth system is a mess\n\nAfter reading the codebase:\n\n```mermaid\nflowchart TD\n G[\"Google OAuth\"] --> S[Session]\n GH[\"GitHub OAuth\"] --> S\n E[\"Email Magic\"] --> S\n S --> P[Perms]\n```\n\nI see three tangles. Which one's burning?\n\n**User is stuck mid-implementation:**\n\n> User: `/opsx:explore add-auth-system`\n> The OAuth integration is more complex than expected\n\nAfter reading change artifacts: you're on task 4, \"Implement OAuth flow\". Trace what's involved, explore options, then ask whether to update the design or add a spike task.\n\n**User wants to compare options:**\n\n> User: Should we use Postgres or SQLite?\n\nGeneric answer is boring. What's the context?\n\n> User: A CLI tool that tracks local dev environments\n\nThat changes everything.\n\n| | `SQLite` | `Postgres` |\n| --- | --- | --- |\n| Deployment | embedded | needs server |\n| Offline | yes | no |\n| Single file | yes | no |\n\n`SQLite`. Not even close. Unless... is there a sync component?\n\n\n## Ending Discovery\n\nThere's no required ending. Discovery might:\n\n- **Flow into a proposal**: \"Ready to start? I can create a change proposal.\"\n- **Result in artifact updates**: \"Updated design.md with these decisions\"\n- **Just provide clarity**: User has what they need, moves on\n- **Continue later**: \"We can pick this up anytime\"\n\nWhen it feels like things are crystallizing, you might summarize:\n\n```\n## What We Figured Out\n\n**The problem**: [crystallized understanding]\n\n**The approach**: [if one emerged]\n\n**Open questions**: [if any remain]\n\n**Next steps** (if ready):\n- Create a change proposal\n- Keep exploring: just keep talking\n```\n\nBut this summary is optional. Sometimes the thinking IS the value.\n\n\n## Guardrails\n\n- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.\n- **Don't fake understanding** - If something is unclear, dig deeper\n- **Don't rush** - Discovery is thinking time, not task time\n- **Don't force structure** - Let patterns emerge naturally\n- **Don't auto-capture** - Offer to save insights, don't just do it\n- **Do visualize** - A good mermaid diagram is worth many paragraphs\n- **Do explore the codebase** - Ground discussions in reality\n- **Do question assumptions** - Including the user's and your own\n\n<!-- File: .agents/skills/openspec-propose/SKILL.md (Tokens: ~1043 | Category: anthropic-skill) -->\n---\nname: openspec-propose\ndescription: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.2.0\"\n---\n\nPropose a new change - create the change and generate all artifacts in one step.\n\nI'll create a change with artifacts:\n- proposal.md (what & why)\n- design.md (how)\n- tasks.md (implementation steps)\n\nWhen ready to implement, run /opsx:apply\n\n\n**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.\n\n**Steps**\n\n1. **If no clear input provided, ask what they want to build**\n\n Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:\n > \"What change do you want to work on? Describe what you want to build or fix.\"\n\n From their description, derive a kebab-case name (e.g., \"add user authentication\" → `add-user-auth`).\n\n **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.\n\n2. **Create the change directory**\n ```bash\n openspec new change \"<name>\"\n ```\n This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.\n\n3. **Get the artifact build order**\n ```bash\n openspec status --change \"<name>\" --json\n ```\n Parse the JSON to get:\n - `applyRequires`: array of artifact IDs needed before implementation (e.g., `[\"tasks\"]`)\n - `artifacts`: list of all artifacts with their status and dependencies\n\n4. **Create artifacts in sequence until apply-ready**\n\n Use the **TodoWrite tool** to track progress through the artifacts.\n\n Loop through artifacts in dependency order (artifacts with no pending dependencies first):\n\n a. **For each artifact that is `ready` (dependencies satisfied)**:\n - Get instructions:\n ```bash\n openspec instructions <artifact-id> --change \"<name>\" --json\n ```\n - The instructions JSON includes:\n - `context`: Project background (constraints for you - do NOT include in output)\n - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)\n - `template`: The structure to use for your output file\n - `instruction`: Schema-specific guidance for this artifact type\n - `outputPath`: Where to write the artifact\n - `dependencies`: Completed artifacts to read for context\n - Read any completed dependency files for context\n - Create the artifact file using `template` as the structure\n - Apply `context` and `rules` as constraints - but do NOT copy them into the file\n - Show brief progress: \"Created <artifact-id>\"\n\n b. **Continue until all `applyRequires` artifacts are complete**\n - After creating each artifact, re-run `openspec status --change \"<name>\" --json`\n - Check if every artifact ID in `applyRequires` has `status: \"done\"` in the artifacts array\n - Stop when all `applyRequires` artifacts are done\n\n c. **If an artifact requires user input** (unclear context):\n - Use **AskUserQuestion tool** to clarify\n - Then continue with creation\n\n5. **Show final status**\n ```bash\n openspec status --change \"<name>\"\n ```\n\n**Output**\n\nAfter completing all artifacts, summarize:\n- Change name and location\n- List of artifacts created with brief descriptions\n- What's ready: \"All artifacts created! Ready for implementation.\"\n- Prompt: \"Run `/opsx:apply` or ask me to implement to start working on the tasks.\"\n\n**Artifact Creation Guidelines**\n\n- Follow the `instruction` field from `openspec instructions` for each artifact type\n- The schema defines what each artifact should contain - follow it\n- Read dependency artifacts for context before creating new ones\n- Use `template` as the structure for your output file - fill in its sections\n- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file\n - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact\n - These guide what you write, but should never appear in the output\n\n**Guardrails**\n- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)\n- Always read dependency artifacts before creating a new one\n- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum\n- If a change with that name already exists, ask if user wants to continue it or create a new one\n- Verify each artifact file exists after writing before proceeding to next\n</yakaai_skills>"}