Skip to content
Back to skills

Project Initializer

ASecurity

Initializer agent for the project-level harness — turn a spec or issue into feature_list.json, init.sh, verify.yaml, and an initial commit.

  • 6 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added June 1, 2026
ai-agentsbashgit

Security analysis

A100/100

Scanned June 1, 2026

npx -y skills add opencue/cuecards --skill project-initializer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Project Initializer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Project Initializer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/opencue-project-initializer/badge)](https://www.skillsdirectory.com/skills/opencue-project-initializer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: project-initializer
description: Initializer agent for the project-level harness — turn a spec or issue into feature_list.json, init.sh, verify.yaml, and an initial commit.
requires_tools:
  - project_init
  - project_status
  - progress_append
  - bash_exec
  - file_read
  - file_write
---

# Project Initializer

Use exactly once per project, when `session_mode == feature_loop` and `.agx/project/` does not yet exist (system prompt will say "Initializer 阶段").

## Inputs

- A spec markdown, GitHub issue, or natural-language feature description.
- The repo root (`workspace_dir` or first non-default taskspace).

## Steps

1. **Read the spec end-to-end.** Use `file_read` if the user pointed at a file, otherwise capture the user's message as the source of truth.
2. **Decompose into ≥ 5 deliverables.** Each feature must:
   - have a stable `id` (kebab-case, ≤ 32 chars),
   - be **independently mergeable** (its commit can land on main without breaking others),
   - declare 1–3 concrete `acceptance_criteria` (observable behavior, not implementation steps),
   - declare `depends_on` only for hard ordering constraints,
   - get an integer `priority` (lower = sooner; reserve 100 for "later").
3. **Call `project_init`** with the full feature list. The tool writes `feature_list.json`, seeds `status.json` with `phase=initialize`, and drops template `init.sh` + `verify.yaml`.
4. **Customize `init.sh`** via `bash_exec` (or `file_write` with the diff path = `.agx/project/init.sh`):
   - install language runtime / package manager dependencies,
   - apply migrations / generate seed data,
   - **must be idempotent** (running twice on the same machine should not break anything).
5. **Customize `verify.yaml`** with the project's real test/lint commands. Keep the `bootstrap` step that runs `init.sh`.
6. **Smoke-run** with `verify_run` (no `feature_id`) to confirm the initial gate is green on a clean checkout.
7. **Commit** the harness files via `bash_exec`:
   ```
   git add .agx/project init.sh verify.yaml
   git commit -m "chore(project): initialize harness with N features"
   ```
   Keep this commit small — only harness files, no business code.
8. **Append a closing progress note** with `progress_append` (e.g. `"[initialize-done] commit=<sha> features=N"`) and tell the user the project is ready for a Coding session.

## Forbidden

- Editing business code in this session.
- Selecting or completing a feature — that is the Coding phase's job.
- Hardcoding secrets in `init.sh` or `verify.yaml`.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…