Shadows Project Architect

Structured project planning — requirements analysis, architecture design, task breakdown, dependency mapping, milestone definition. Use when starting a new p...

Security Scan

The skill is an instruction-only project-planning template whose requirements and runtime instructions are consistent with its stated purpose and request no elevated permissions or installs.

Purpose & Capability

Name, description, and SKILL.md all describe structured project planning and the instructions implement that workflow. The skill requests no binaries, env vars, or config paths, which is proportionate for a purely advisory planning tool. Minor metadata inconsistency: SKILL.md includes an 'openclaw.homepage' URL while the registry metadata lists 'Homepage: none' — this is likely benign bookkeeping but worth noting.

Instruction Scope

SKILL.md confines the agent to asking questions, producing structured text (requirements, architecture, ADRs, task lists, critical path, milestones) and explicitly states it will not execute commands, read files, or make network calls. There are no instructions that reference system files, credentials, or external endpoints beyond an informational homepage URL in metadata.

Install Mechanism

No install spec and no code files — the skill is instruction-only. That is the lowest-risk install mechanism and matches the declared pure-advisory purpose.

Credentials

The skill requires no environment variables, credentials, or config paths. This is proportional to a planning/architect role; there are no unexplained secret requests or unrelated credential needs.

Persistence & Privilege

Flags show always:false and default autonomous invocation allowed (normal). The skill does not request permanent presence, nor does it instruct modifying agent/system configs. No elevated persistence or cross-skill config access is indicated.

Assessment

This skill is an instruction-only project-planning template and appears internally consistent and low-risk. Before installing: (1) confirm you won't paste any secrets or proprietary credentials into prompts (the skill may ask detailed project/context questions); (2) because it's purely advisory, review generated plans for accuracy and security implications before acting on them; (3) watch for future updates that add install scripts, network calls, or env-var requirements — those would materially change the risk profile.

Project Architect — Structured Planning Protocol

Version: 1.1.0 | Author: Shadows Company | License: MIT

---

WHEN TO TRIGGER

• Starting a new project from scratch
• Planning a major feature or module
• User says "plan this", "architect", "design the system"
• Refactoring a large codebase
• Breaking a monolith into services

WHEN NOT TO TRIGGER

• Small bug fixes or single-file changes
• User already has a detailed plan
• Quick prototyping / experimentation

PREREQUISITES

No binaries required. This is a pure planning and reasoning skill. It produces structured text output (project plans, architecture documents, task breakdowns) without executing any commands or requiring any external tools.

---

PROTOCOL — 5 PHASES

Phase 1 — REQUIREMENTS CAPTURE

Ask the user (max 5 questions):

1. What — What does this system/feature do? (core functionality)
2. Who — Who uses it? (user personas)
3. Scale — Expected load/data volume? (performance requirements)
4. Constraints — Tech stack preferences, budget, timeline?
5. Integration — What existing systems does it connect to?

Phase 2 — ARCHITECTURE DESIGN

Based on requirements, define:

System Components:

[Component A] --> [Component B] --> [Component C]
       |                                  |
       v                                  v
  [Database]                        [External API]

For each component:

• Responsibility (single purpose)
• Interface (inputs/outputs)
• Technology choice (with rationale)
• Data model (key entities)

Architecture Decisions Record (ADR):

### ADR-001: [Decision Title]
- **Status**: Accepted
- **Context**: [Why this decision was needed]
- **Decision**: [What was decided]
- **Consequences**: [Trade-offs accepted]

Phase 3 — TASK BREAKDOWN

Break the project into implementable tasks:

## Epic 1: [Name]
- [ ] Task 1.1: [Description] (~Xh)
- [ ] Task 1.2: [Description] (~Xh)
  - Depends on: Task 1.1
- [ ] Task 1.3: [Description] (~Xh)

## Epic 2: [Name]
- [ ] Task 2.1: [Description] (~Xh)
  - Depends on: Task 1.2

Rules:

• Each task must be completable in 1-4 hours
• Dependencies explicitly stated
• Effort estimate for each task
• Tasks ordered by dependency chain

Phase 4 — DEPENDENCY MAPPING

Identify critical path:

1. Map task dependencies as a directed graph
2. Identify the longest path (critical path)
3. Identify parallelizable work streams
4. Flag external dependencies (APIs, approvals, data)

Phase 5 — MILESTONE DEFINITION

Define 3-5 milestones:

### Milestone 1: Foundation (Week 1)
- [x] Project setup, CI/CD pipeline
- [x] Core data models
- [x] Basic API skeleton
**Demo**: API responds to health check

### Milestone 2: Core Features (Week 2-3)
- [ ] Feature A implementation
- [ ] Feature B implementation
**Demo**: User can perform primary workflow

### Milestone 3: Polish & Deploy (Week 4)
- [ ] Error handling, edge cases
- [ ] Documentation
- [ ] Production deployment
**Demo**: Live system accessible to users

---

SECURITY CONSIDERATIONS

This skill is purely advisory — it generates project plans, architecture documents, and task breakdowns as text output. It does not execute commands, read sensitive files, make network calls, or modify any configuration. Zero risk profile.

---

OUTPUT FORMAT

# Project Plan: [Name]
**Date**: [YYYY-MM-DD]

## 1. Requirements Summary
[Concise requirements from Phase 1]

## 2. Architecture
[Diagram + component descriptions + ADRs]

## 3. Task Breakdown
[Epics with tasks, estimates, dependencies]

## 4. Critical Path
[Dependency chain visualization]

## 5. Milestones
[3-5 milestones with demo criteria]

## 6. Risks
| Risk | Probability | Impact | Mitigation |
|------|------------|--------|------------|
| ...  | ...        | ...    | ...        |

## 7. Next Steps
[First 3 tasks to start immediately]

---

RULES

1. Ask before assuming — never design without understanding requirements
2. Simple first — start with the simplest architecture that could work
3. No over-engineering — design for current needs, not hypothetical futures
4. Explicit dependencies — every task must state what it depends on
5. Demo-driven milestones — each milestone must have a demonstrable outcome

---

Published by Shadows Company — "We work in the shadows to serve the Light."