mirror of
https://github.com/affaan-m/ECC.git
synced 2026-10-14 20:25:26 +02:00
Affaan MustafaandGitHub
c70874fae9
Adds a curated, Pi-native, skills+prompts-only profile at pi/core/ for downstream packagers that mirror GitHub Releases. - manifests/pi-core.json: explicit include lists, per-item exclusion reasons, curation rules, safety allowlists; every root skill and command must be classified. - scripts/build-pi-core.js regenerates pi/core deterministically (package.json from VERSION, LICENSE, README.md, CURATION.md, skills/, commands/); --check fails CI on drift. council is renamed ecc-council inside pi/core only. - Safety checks: no callable endpoints outside the allowlist, no npx/curl|sh/pip install, no secrets, no absolute home paths, no symlinks, valid frontmatter, no duplicate names. - CI: build + drift check and an offline Pi CLI load test of pi/core. - Release: VERSION, package.json and pi/core/package.json at 2.2.2, CHANGELOG, tag-triggered release verification, and a two-week cadence in CONTRIBUTING.md. pi/core: 123 of 293 skills and 24 of 94 commands; 35,006 characters of skill description text.
50 lines
1.3 KiB
Markdown
50 lines
1.3 KiB
Markdown
---
|
|
description: Guided feature development with codebase understanding and architecture focus
|
|
---
|
|
|
|
A structured feature-development workflow that emphasizes understanding existing code before writing new code.
|
|
|
|
## Phases
|
|
|
|
### 1. Discovery
|
|
|
|
- read the feature request carefully
|
|
- identify requirements, constraints, and acceptance criteria
|
|
- ask clarifying questions if the request is ambiguous
|
|
|
|
### 2. Codebase Exploration
|
|
|
|
- use `code-explorer` to analyze the relevant existing code
|
|
- trace execution paths and architecture layers
|
|
- understand integration points and conventions
|
|
|
|
### 3. Clarifying Questions
|
|
|
|
- present findings from exploration
|
|
- ask targeted design and edge-case questions
|
|
- wait for user response before proceeding
|
|
|
|
### 4. Architecture Design
|
|
|
|
- use `code-architect` to design the feature
|
|
- provide the implementation blueprint
|
|
- wait for approval before implementing
|
|
|
|
### 5. Implementation
|
|
|
|
- implement the feature following the approved design
|
|
- prefer TDD where appropriate
|
|
- keep commits small and focused
|
|
|
|
### 6. Quality Review
|
|
|
|
- use `code-reviewer` to review the implementation
|
|
- address critical and important issues
|
|
- verify test coverage
|
|
|
|
### 7. Summary
|
|
|
|
- summarize what was built
|
|
- list follow-up items or limitations
|
|
- provide testing instructions
|