| name | agent-workflow-system |
|---|---|
| description | Generate a reusable agent-driven project workflow as filesystem-based Agent Skills. Use when bootstrapping planning, refinement, architecture, implementation, review, and iteration skills for personal software projects. |
Create a reusable agent-driven workflow system for personal software projects.
The system enforces a structured lifecycle:
Idea
↓
plan-writer
↓
plan-refiner
↓
architect
↓
implementer
↓
reviewer
↓
refine-again
The workflow is specification-first and requires traceability between plans, specifications, and implementation tasks.
Project setup must follow this order:
- Set up the project structure.
- Ask which agent runtime the user is setting up: Claude Code, Codex, both, or another runtime.
- Clone and install selected third-party skills into the runtime-appropriate skill directory.
- Create the project's own workflow skills as valid
SKILL.mdfiles in the runtime-appropriate project skill directory. - Verify the project's own skills can discover and use appropriate external skills for specialized tasks.
Do not skip cross-skill verification when external skills are installed.
- Prevent implementation before requirements are clear.
- Ensure every implementation task traces back to a requirement.
- Ensure every requirement traces back to a plan.
- Enable continuous refinement and iteration.
- Allow agents to discover and use more specialized skills when available.
- Standardize project organization across repositories.
- Support solo-founder workflows without unnecessary process overhead.
- Replace project management tools.
- Replace source control workflows.
- Replace CI/CD systems.
- Enforce specific programming languages or frameworks.
.agents/
└── skills/
├── init-project/
│ └── SKILL.md
├── plan-writer/
│ └── SKILL.md
├── plan-refiner/
│ └── SKILL.md
├── architect/
│ └── SKILL.md
├── implementer/
│ └── SKILL.md
├── reviewer/
│ └── SKILL.md
└── refine-again/
└── SKILL.md
docs/
├── plans/
├── specs/
└── tasks-implementation.md
Runtime-specific project skill directories:
.claude/skills/ # Claude Code project skills
.agents/skills/ # Codex/project agent skills
During setup, ask the user which agent runtime they are using before installing or generating skills.
Supported choices:
- Claude Code
- Codex
- Both Claude Code and Codex
- Other
Use the runtime choice to decide where to install third-party skills and where to generate the project's own workflow skills.
| Runtime | Third-party skill target | Project workflow skill target |
|---|---|---|
| Claude Code | ~/.claude/skills/ |
.claude/skills/ |
| Codex | ~/.codex/skills/ |
.agents/skills/ |
| Both | ~/.claude/skills/ and ~/.codex/skills/ |
.claude/skills/ and .agents/skills/ |
| Other | Ask for the user-level skill directory | Ask for the project-level skill directory |
If the user selects Other, confirm that the runtime supports directory-based skills with SKILL.md frontmatter before generating or copying skills. If it uses a different format, ask for the expected format and adapt only after approval.
Project setup may install skills from trusted external repositories.
Default external source:
git clone https://github.com/alirezarezvani/claude-skills.gitInstall only selected skill folders from an external source. Do not bulk-install every folder by default.
Target locations:
~/.claude/skills/ # Claude Code
~/.codex/skills/ # Codex
custom path # Other runtimes, user-provided
Before copying an external skill:
- Use the runtime target selected during setup.
- Ask for approval before cloning remote repositories or writing to home-directory skill folders.
- Clone the repository into a temporary or vendor directory outside the generated skill target.
- Inspect the selected skill folder before installation.
- Copy only folders that contain a valid
SKILL.md. - Verify each copied
SKILL.mdfollows the Skill File Format section. - Preserve the original folder name unless it violates skill naming rules.
- Do not overwrite an existing installed skill without approval.
- Treat external skills as executable third-party code and surface any scripts or unusual file access patterns.
Installed external skills are reusable capabilities, not project requirements. They must not change the generated plans, specs, or implementation tasks unless a later workflow step explicitly uses them.
Generated workflow skills must be able to use skills from other sources when those skills are installed and appropriate for the task.
Relevant skill sources include:
.agents/skills/ # Project workflow skills
.claude/skills/ # Claude Code project skills
~/.claude/skills/ # Claude Code user skills
~/.codex/skills/ # Codex user skills
custom paths # Other runtime skill directories
Before a generated skill starts substantive work:
- Identify the task type and required expertise.
- Check available skill metadata from project and installed external skill sources.
- Prefer the most specific skill that directly matches the task.
- Use external skills for specialized work such as research, UI design, security review, framework-specific implementation, document generation, or domain analysis.
- Use generated workflow skills for lifecycle control: planning, refining, architecture, implementation, review, and iteration.
- Combine skills only when their responsibilities are complementary.
- Do not use a skill whose scope conflicts with the active workflow boundary.
- State which skills are being used and why.
When a generated workflow skill uses another skill:
- Pass only the context needed for the subtask.
- Preserve the current workflow boundary.
- Validate the other skill's output before integrating it.
- Do not let an external skill overwrite requirements, plans, or tasks without explicit workflow approval.
- Record any assumptions, risks, or unresolved questions returned by the other skill.
Every generated workflow skill must be a directory containing a SKILL.md file.
Each SKILL.md must start with YAML frontmatter:
---
name: skill-name
description: Brief description of what this skill does and when to use it.
---name:
- Use lowercase letters, numbers, and hyphens only.
- Keep it under 64 characters.
- Do not use XML tags.
- Do not use reserved words such as
anthropicorclaude.
description:
- Keep it non-empty.
- Keep it under 1024 characters.
- Explain both what the skill does and when to use it.
- Do not use XML tags.
After frontmatter, each generated skill must include:
# Skill Name## Purpose## When to Use## Responsibilities## Skill Discovery## Workflow## Output## Boundaries
Generated skills may include extra sections only when they improve execution clarity.
When this system generates or regenerates any workflow skill, it must write valid Agent Skill files, not plain prompt files. Do not generate .agents/skills/*.md files directly; generate .agents/skills/<skill-name>/SKILL.md.
Each generated workflow skill must include the Cross-Skill Usage rules in its ## Skill Discovery section so it can use appropriate skills from project, Claude Code, or Codex skill sources.
The system follows strict traceability:
Plan
↓
Spec
↓
Requirement
↓
Task
↓
Implementation
Every artifact must reference its parent.
Every specification must reference a plan.
Example:
Parent Plan:
PLAN-001
Source:
docs/plans/2026-06-10-user-notifications/SUMMARY.mdEvery requirement must have a unique identifier.
Example:
REQ-001
Users shall receive email notifications.
REQ-002
Users shall manage notification preferences.Every task must reference a requirement.
Example:
TASK-001
Requirement:
REQ-001
Description:
Implement notification service.The Refiner must flag:
- Tasks without requirements.
- Requirements without tasks.
- Specs without plans.
- Plans without specs.
Bootstrap the workflow system.
Create:
docs/plans/
docs/specs/
docs/tasks-implementation.md
Ask the user whether they are setting up Claude Code, Codex, both, or another runtime.
Create the runtime-appropriate project skill directory from the Runtime Target Selection section.
Optionally install selected external skills from trusted sources into the runtime-appropriate user skill directory.
Generate starter skill directories with SKILL.md files that follow the Skill File Format section and include ## Skill Discovery.
Verify generated skills can use appropriate external skills without violating workflow boundaries.
Never overwrite existing files without approval.
Check existing project structure.
Create missing project directories.
Ask which agent runtime the user is using: Claude Code, Codex, both, or another runtime.
If another runtime:
- Ask for the user-level third-party skill directory.
- Ask for the project-level workflow skill directory.
- Confirm whether the runtime supports
SKILL.mdfiles with YAML frontmatter.
Ask whether to install external skills.
If yes:
- Confirm source repository, defaulting to
https://github.com/alirezarezvani/claude-skills.git. - Confirm the runtime-derived target skill directory.
- Ask for approval to clone the source repository and write selected skills to the target skill directory.
- Clone the source into a temporary or vendor directory.
- List available skill folders.
- Ask which selected skills to install.
- Copy selected valid skill folders into the chosen target skill directory.
- Report skipped folders and validation issues.
Generate the project's own workflow skill directories in the runtime-appropriate project skill directory, using SKILL.md files that follow the Skill File Format section.
Verify each generated workflow skill includes ## Skill Discovery and can use appropriate installed external skills for specialized subtasks.
Generate tasks file.
Output setup report.
- All folders exist.
- All skill files exist.
- Runtime choice is recorded in the setup report.
- Any requested external skills are installed in the selected runtime skill directory.
- Generated workflow skills are installed in the selected runtime project skill directory.
- Any skipped external skills are reported with reasons.
- Generated workflow skills include
## Skill Discovery. - Generated workflow skills can use appropriate external skills without crossing their workflow boundaries.
- No existing files overwritten.
Convert an idea into an implementation plan.
Create:
docs/plans/YYYY-MM-DD-feature-name/
Generate:
SUMMARY.md
phase-01.md
phase-02.md
...
Read:
docs/plans/
docs/specs/
tasks-implementation.md
Determine:
- Goal
- Audience
- Scope
- Constraints
- Success metrics
Include:
- Overview
- Goals
- Non-goals
- Risks
- Dependencies
Each phase contains:
- Objective
- Complexity
- Tasks
- Verification
- Expected Output
No implementation.
Act as a requirements auditor.
Analyze:
plans
specs
tasks
Identify:
- Gaps
- Ambiguity
- Missing requirements
- Missing tasks
- Contradictions
The Refiner must never silently assume missing information.
Instead it must:
State assumption
Explain risk
Ask user for clarification
Load all relevant plans.
Load all related specifications.
Load implementation tasks.
Validate:
Plan → Spec
Spec → Requirement
Requirement → Task
Example:
Missing Requirement Coverage
REQ-007 exists.
No implementation task found.
Questions must focus on:
- Business logic
- Edge cases
- Permissions
- Failure handling
- Constraints
Update:
docs/specs/
tasks-implementation.md
Wait for approval.
No architecture. No implementation.
Design the technical solution.
Create:
docs/specs/architecture.md
- Plans
- Specs
- Refined requirements
Produce:
- Components
- Services
- APIs
- Data model
- Integrations
Document:
- Scaling risks
- Security risks
- Performance risks
Architecture specification.
No coding.
Implement approved work.
Translate:
Requirements
+
Architecture
+
Tasks
into code.
- Plans
- Specs
- Architecture
- Tasks
Follow tasks exactly.
Run:
- Tests
- Linting
- Build
Create:
implementation-report.md
Containing:
- Files changed
- Tests added
- Verification results
- Known limitations
Validate implementation quality.
Review:
- Requirements coverage
- Code quality
- Security
- Performance
- Testing
- Specs
- Architecture
- Implementation report
Check:
- Requirement coverage
- Missing functionality
- Security concerns
- Technical debt
review-report.md
Containing:
- Critical issues
- Major issues
- Minor issues
- Suggestions
APPROVED
or
CHANGES REQUESTED
Turn lessons learned into the next iteration.
Analyze:
- Review findings
- Bugs
- User feedback
- Metrics
Gather:
- Production issues
- Feedback
- Test failures
Classify:
P0
P1
P2
P3
Create:
docs/plans/YYYY-MM-DD-refinement/
- Lessons learned
- New requirements
- Updated backlog
- Next iteration plan
Return to:
plan-refiner
for the next cycle.
All skills must follow these rules.
Before executing:
- Identify the task type and required expertise.
- Check whether a more specialized skill exists in project skills or installed external skills.
- Prefer the most specialized skill available.
- Use existing agent capabilities when appropriate.
- Consider installed external skills in
~/.claude/skills/or~/.codex/skills/when available. - Use the appropriate external skill for specialized subtasks, then integrate the result within the active workflow boundary.
- Do not duplicate existing functionality.
Every skill must:
- State assumptions.
- Explain decisions.
- Highlight uncertainty.
- Surface risks.
Never silently infer critical requirements.
May:
- Create plans
Must not:
- Design architecture
- Write code
May:
- Audit requirements
Must not:
- Design architecture
- Write code
May:
- Design systems
Must not:
- Write production code
May:
- Write code
Must not:
- Invent requirements
May:
- Critique implementation
Must not:
- Rewrite requirements
May:
- Create future iterations
Must not:
- Modify implementation directly
The workflow is complete when:
- Every plan has a linked spec.
- Every spec has linked requirements.
- Every requirement has linked tasks.
- Every task has been implemented.
- Reviewer approves implementation.
- Refinement backlog is documented.
- Traceability is preserved end-to-end.